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

[David Arno]

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.

What I tried to do was use as3hx to convert the ActionScript target of ANTLR
to haXe. Aside from the fact that as3hx cannot cope with global constants,
all was fine: I created the haXe source files I needed. I then tried to
figure out how to compile that source into a bytecode library that could be
linked against by other haXe projects. It was suggested to me that this
isn't possible and that for every project, haXe has to compile then entire
source every single time.

My real aim is to create a haXe equivalent of the Flex SDK that could then
be compiled to JavaScript, Neko etc. The idea that I'd have to tell people
"here is the Flex SDK as a mass of haXe source files that the haXe compiler
will recompile every time you recompile your project" is too ridiculous an
idea for words. Also, the idea that anyone trying to create a commercial
library for haXe has to do so via source is a complete non-starter. So I
seriously hope I have this wrong.

If haXe can compile source to an intermediary form usable by all targets,
please could someone tell me how to do this? If not, then I need to raise
this as a serious - needs fixing like yesterday - bug against the language
and I'd appreciate it if someone could point me to the correct place to do
that.

Thanks,
David Arno.


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

[Juraj Kirchheim]

This is inherently impossible (or let's just say "rea hard") due to
the way conditional compilation works (i.e. at string level instead of
expression level). Changing this represents an enormous break of
backward compatibility and is therefore very unlikely to happen.

Still the question remains: Why exactly you would need that?

On Thu, Dec 22, 2011 at 12:00 AM, David Arno <[hidden email]> wrote:

> 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.
>
> What I tried to do was use as3hx to convert the ActionScript target of ANTLR
> to haXe. Aside from the fact that as3hx cannot cope with global constants,
> all was fine: I created the haXe source files I needed. I then tried to
> figure out how to compile that source into a bytecode library that could be
> linked against by other haXe projects. It was suggested to me that this
> isn't possible and that for every project, haXe has to compile then entire
> source every single time.
>
> My real aim is to create a haXe equivalent of the Flex SDK that could then
> be compiled to JavaScript, Neko etc. The idea that I'd have to tell people
> "here is the Flex SDK as a mass of haXe source files that the haXe compiler
> will recompile every time you recompile your project" is too ridiculous an
> idea for words. Also, the idea that anyone trying to create a commercial
> library for haXe has to do so via source is a complete non-starter. So I
> seriously hope I have this wrong.
>
> If haXe can compile source to an intermediary form usable by all targets,
> please could someone tell me how to do this? If not, then I need to raise
> this as a serious - needs fixing like yesterday - bug against the language
> and I'd appreciate it if someone could point me to the correct place to do
> that.
>
> Thanks,
> David Arno.
>
>
> --
> haXe - an open source web programming language
> http://haxe.org

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

[Raoul Duke]

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

[Baluta Cristian]

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

[singmajesty]

In my experience, generating the C++ files is *very* fast. It is putting  
these files through the C++ compiler that takes some time. Fortunately  
most C/C++ compilers do cache results so that it compiles much faster the  
next time around.



On Wed, 21 Dec 2011 15:30:56 -0800, 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

[Raoul Duke]

On Wed, Dec 21, 2011 at 5:16 PM, Joshua Granick
<[hidden email]> wrote:
> In my experience, generating the C++ files is *very* fast. It is putting
> these files through the C++ compiler that takes some time.

ah, yes, that sounds right -- it was something about the whole C++
chain that was painful. sorry to wrongly disparage the haxe compiler
there.

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

[George McBay]

I don't use the haxe/C++ target so I'm not sure how relevant this is,
but generally compilers do a timestamp compare between the .o file and
the associated .c/.cpp file and if the .c/.cpp file is newer than the
last .o, they'll recompile.

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.



On Wed, Dec 21, 2011 at 5:16 PM, Joshua Granick
<[hidden email]> wrote:

> In my experience, generating the C++ files is *very* fast. It is putting
> these files through the C++ compiler that takes some time. Fortunately most
> C/C++ compilers do cache results so that it compiles much faster the next
> time around.
>
>
>
>
> On Wed, 21 Dec 2011 15:30:56 -0800, 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

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

[Cauê W.]

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

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

[Tarwin Stroh-Spijer]

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

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

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

[Cauê W.]

Actually it's got nothing to do with distributing binaries without source code (at least for me), it's got more to do with scalability. It's just that even though the haxe compiler is blazing fast, needing a full recompilation of everything is a limitation at some point, specially if we have a very big inheritance tree that needs to be parsed to even give completion. So anyway, as the projects get bigger, at some point it becomes necessary to separate the compilation in steps, even in different files. For flash/swfs we already can do that with -swf-lib; this could also be done with some work for C# and Java, but not for most other targets.

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

--
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

[Tarwin Stroh-Spijer]

Isn't this what the new compiler will help with in some way? The caching thing?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Dec 21, 2011 at 7:17 PM, Cauê Waneck <[hidden email]> wrote:

Actually it's got nothing to do with distributing binaries without source code (at least for me), it's got more to do with scalability. It's just that even though the haxe compiler is blazing fast, needing a full recompilation of everything is a limitation at some point, specially if we have a very big inheritance tree that needs to be parsed to even give completion. So anyway, as the projects get bigger, at some point it becomes necessary to separate the compilation in steps, even in different files. For flash/swfs we already can do that with -swf-lib; this could also be done with some work for C# and Java, but not for most other targets.

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

--
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

[Cauê W.]

I'm not sure... Are you talking about the display server? It will help to show --display completions faster, but it won't help too much at the need to compile the whole application.

2011/12/22 Tarwin Stroh-Spijer <[hidden email]>

Isn't this what the new compiler will help with in some way? The caching thing?

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 7:17 PM, Cauê Waneck <[hidden email]> wrote:

Actually it's got nothing to do with distributing binaries without source code (at least for me), it's got more to do with scalability. It's just that even though the haxe compiler is blazing fast, needing a full recompilation of everything is a limitation at some point, specially if we have a very big inheritance tree that needs to be parsed to even give completion. So anyway, as the projects get bigger, at some point it becomes necessary to separate the compilation in steps, even in different files. For flash/swfs we already can do that with -swf-lib; this could also be done with some work for C# and Java, but not for most other targets.

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

--
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

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

[Tarwin Stroh-Spijer]

Sorry, my misunderstanding. I assumed that if it was going to cache for completion it would cache these intermediates for compilation well?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Dec 21, 2011 at 7:46 PM, Cauê Waneck <[hidden email]> wrote:

I'm not sure... Are you talking about the display server? It will help to show --display completions faster, but it won't help too much at the need to compile the whole application.

2011/12/22 Tarwin Stroh-Spijer <[hidden email]>

Isn't this what the new compiler will help with in some way? The caching thing?

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 7:17 PM, Cauê Waneck <[hidden email]> wrote:

Actually it's got nothing to do with distributing binaries without source code (at least for me), it's got more to do with scalability. It's just that even though the haxe compiler is blazing fast, needing a full recompilation of everything is a limitation at some point, specially if we have a very big inheritance tree that needs to be parsed to even give completion. So anyway, as the projects get bigger, at some point it becomes necessary to separate the compilation in steps, even in different files. For flash/swfs we already can do that with -swf-lib; this could also be done with some work for C# and Java, but not for most other targets.

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

--
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

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

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

[Cauê W.]

hmmm maybe! I'm not sure also ! :)

2011/12/22 Tarwin Stroh-Spijer <[hidden email]>

Sorry, my misunderstanding. I assumed that if it was going to cache for completion it would cache these intermediates for compilation well?

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 7:46 PM, Cauê Waneck <[hidden email]> wrote:

I'm not sure... Are you talking about the display server? It will help to show --display completions faster, but it won't help too much at the need to compile the whole application.

2011/12/22 Tarwin Stroh-Spijer <[hidden email]>

Isn't this what the new compiler will help with in some way? The caching thing?

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 7:17 PM, Cauê Waneck <[hidden email]> wrote:

Actually it's got nothing to do with distributing binaries without source code (at least for me), it's got more to do with scalability. It's just that even though the haxe compiler is blazing fast, needing a full recompilation of everything is a limitation at some point, specially if we have a very big inheritance tree that needs to be parsed to even give completion. So anyway, as the projects get bigger, at some point it becomes necessary to separate the compilation in steps, even in different files. For flash/swfs we already can do that with -swf-lib; this could also be done with some work for C# and Java, but not for most other targets.

I'm a little confused as to "why" this is needed? Is it so you can distribute libraries without giving people access to source? The main reason I see this would be good for haxe (as you said it's generally pretty damn fast) is for selling stuff. That is selling things which you don't want to give the source for.

I'm with selling stuff, I just think that if there's people who want to do that then it would be nice if they could put up time / money to create this packaging process.

If it's not for selling (ie hide my code) then don't we already have some kind of ZIP package for haxelib? Kind of like an SWC (but with source rather than compiled code?)


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Dec 21, 2011 at 6:45 PM, Cauê Waneck <[hidden email]> wrote:

So if haxe/C++ is regenerating/updating the timestamp of the C++ code
file each time it compiles, the compiler 'caching' won't help.

hxcpp only changes the timestamp of the changed cpp files. So basically it will only recompile what you've changed.

About haxe being ready for precompilation, I really think there should be a precompiled haxe format with all externs signatures of a previous compilation. This is a little harder because of the multi-target nature of haxe, but I guess all our targets accept in a way or another multiple compilation units:

php we can just copy the second output to the first and it's ok;

java, neko and flash can dynamically load one module into another

js you can include several .js in the same page (though not very recommended) or you can even copy/paste the second content into the first output

c# needs to be compiled as a dll

c++ can be compiled as a static library.

IMHO it would be a really good thing to have our own optimized format to describe a compilation. This could mean that libraries (haxelib) could come precompiled, and it seems very essential for languages where we lose the haxe signatures from their output (like php, neko, cpp - where we can't do like swfs and use the binary form as an extern itself)

--
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

--
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

[Johann Borck]

On 12/22/2011 04:17 AM, Cauê Waneck wrote:
> Actually it's got nothing to do with distributing binaries without source code (at least for me),
> it's got more to do with scalability. It's just that even though the haxe compiler is blazing
> fast, needing a full recompilation of everything is a limitation at some point
You make it sound like this was an inherent limitation of haxe, WHICH IT IS NOT (I know you know,
but for everyone following this thread wondering). Remember this thread started with some weird
allegation *the language* haxe had problems with separate compilation. Look at neko, perfectly
separately compilable modules. It's not a language limitation, if anything it is badly designed (at
least in this regard) compiler backends.

> [..] For flash/swfs we already can do that with -swf-lib;
(QED)
> this could also be done with some work for C# and Java,
you also make it sound as if there were any Java and C# targets ;)
> but not for most other targets.
every backend that supports externs (so all of them, right?) could support separate compilation,
even if the target itself doesn't, or is source-only, or whatever.

regards,
Johann

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

[Cauê W.]

You make it sound like this was an inherent limitation of haxe, WHICH IT IS NOT (I know you know, but for everyone following this thread wondering). Remember this thread started with some weird allegation *the language* haxe had problems with separate compilation. Look at neko, perfectly separately compilable modules. It's not a language limitation, if anything it is badly designed (at least in this regard) compiler backends.

Yes, you're right, it's not a limitation of haxe, even though you might need to generate the externs yourself and handle the targets differences in each case. I just think an automated way to generate this kind of information (and maybe also more compact) would be a great addition. That's all!

this could also be done with some work for C# and Java,

you also make it sound as if there were any Java and C# targets ;)

I'm sorry about that :) I'm working a lot to get them delivered and sometimes I talk as if they were there already :) Anyway, this issue came to me mostly when I was thinking on -swf-lib -like solutions for .NET dlls and JARs :) 

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

[Tarwin Stroh-Spijer]

I think it's more about a standard way of having packages that are packages of cross platform libraries, that re pre-compiled I guess.

ie I might want to have an ecryption package that comes with:

 - swc

 - dll

 - .n file

etc

And they're all zipped up in some kind of .pkg, that also contains the extern file. So you can do some kind thing like "-compiled-lib myLib.pkg" and then this will be included in the final output.

I think this is more a discussion that should be put towards NME though, not the language itself, as that is a packager of sorts which looks to make targeting multi-platform work well in a standard way.

haxe itself can output to multiple targets, but has no promise of those targets all running the same way, and that's fine really - you're never going to have server vs front-end running the same way, one doesn't show you visuals to start with.

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Dec 21, 2011 at 8:37 PM, Cauê Waneck <[hidden email]> wrote:

You make it sound like this was an inherent limitation of haxe, WHICH IT IS NOT (I know you know, but for everyone following this thread wondering). Remember this thread started with some weird allegation *the language* haxe had problems with separate compilation. Look at neko, perfectly separately compilable modules. It's not a language limitation, if anything it is badly designed (at least in this regard) compiler backends.

Yes, you're right, it's not a limitation of haxe, even though you might need to generate the externs yourself and handle the targets differences in each case. I just think an automated way to generate this kind of information (and maybe also more compact) would be a great addition. That's all!

this could also be done with some work for C# and Java,

you also make it sound as if there were any Java and C# targets ;)

I'm sorry about that :) I'm working a lot to get them delivered and sometimes I talk as if they were there already :) Anyway, this issue came to me mostly when I was thinking on -swf-lib -like solutions for .NET dlls and JARs :) 

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

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

[Nicolas Cannasse]

Le 22/12/2011 05:03, Cauê Waneck a écrit :
> hmmm maybe! I'm not sure also ! :)

The parsed files cache is also used for normal compilation, so yes it
also speed up compilation times.

Best,
Nicolas

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

[Nicolas Cannasse]

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.
>
> What I tried to do was use as3hx to convert the ActionScript target of ANTLR
> to haXe. Aside from the fact that as3hx cannot cope with global constants,
> all was fine: I created the haXe source files I needed. I then tried to
> figure out how to compile that source into a bytecode library that could be
> linked against by other haXe projects. It was suggested to me that this
> isn't possible and that for every project, haXe has to compile then entire
> source every single time.
>
> My real aim is to create a haXe equivalent of the Flex SDK that could then
> be compiled to JavaScript, Neko etc. The idea that I'd have to tell people
> "here is the Flex SDK as a mass of haXe source files that the haXe compiler
> will recompile every time you recompile your project" is too ridiculous an
> idea for words. Also, the idea that anyone trying to create a commercial
> library for haXe has to do so via source is a complete non-starter. So I
> seriously hope I have this wrong.

You don't have it wrong.

There is no current standard way to package libraries for haXe, apart
from distributing the source through haxelib. Thanks to the compiler
being very fast, we were so far able to handle very large libraries with
still better performances than AS3 compiler + SWC packages usages.

So please refrain jumping to conclusions before hitting into an actual
issue.

Also, there are currently several platform-specific possibilities, which
involve creating a compiled "library" and then using only its externs
without recompiling its sources :

- for Flash you can create SWCs
- for C++ I guess you can create .lib (.a) files that will get only linked
- for JS you can include first your lib.js before your actual code
etc.

However, you're right there is still no solution for commercial
libraries, and it would maybe be nice to have a general packaged
solution for libraries (both haxe standard library and haxelib).

This is something I'm seriously considering adding, especially since now
we have the server-mode haXe compiler that could highly benefit from
having such a system.

As noted by Juraj however, you would still need to create a
library-package per-platform, and these libraries would no longer be
customizable through conditional compilation.

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.

Things can always get better, but being too much assertive is not a good
way to start a friendly discussion among peer developers :)

Best,
Nicolas





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

[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