Jeg er særdeles spændt på at afprøve denne oversætter, men det er endnu ikke lykkedes mig at starte den.
Jeg har ActiveState ActivePython 2.6 installeret, og får derfor flg. besked når jeg prøver at starte:
ImportError: Bad magic number in C:\mascara\es4translator\__init__.pyc
Hvor er kildefilerne? Jeg troede at projektet var open source? Uden kildefilerne er jeg tvunget til at lave en særskilt installation af Python, kun til at afvikle oversætteren... det er ikke praktisk...
Hej Mindplay, (I'm answering in English since other readers might have the same issue.)
The error you get: "Bad magic number" is due to running under an incompatible Python version. Mascara requires Python 2.5, while you are running the new 2.6, and the versions are not immediately compatible. (Revisions should be compatible though - Mascara should run on all 2.5.x versions.)
I know it's a hassle to install the Python separately, and I'm looking into creating a one-step installer which installs the right Python version along with the translator.
Right now you will have to manually install Python 2.5. (There should be no problem running a Python 2.5 in parallel with your existing 2.6 installation though.)
I'm sorry, I know how annoying each extra installation step is, when you just want to try out a piece of software.
The source code is not yet available for download, I plan to make it available when the version leaves the beta-stage.
Hope you decide to try it out anyway! And of course I am very interested in hearing any additional problem you might have, so we can get them fixed.
I should have posted in english, but the site came up in danish and so I automatically switched ;-)
I installed Python 2.5, and successfully ran the software.
To be able to start testing in depth, I also wrote a small PHP script and an Apache rewrite that catches the .es4 extension and transparently recompiles the files to JavaScript as needed.
It seems to work great :-)
The one negative impression I've had so far, is the compilation time...
Compiling the files takes too much time - typically 5+ seconds per file, on a 2GHz dual core machine with 4GB of RAM.
The slow response will get in the way of comfortable development.
I wonder if the overhead could be caused by Python and standard libraries loading up, rather than the compiler itself?
If so, one helpful optimization would be to allow compilation of multiple scripts in one go - so that a whole set of scripts could be recompiled in one go.
If not - I know there's no way to really compile Pyhon code, but maybe packaging it as a single executable, and using one of the optimization libraries I've seen that are supposed to speed up Python scripts at the expense of some memory overhead, could be an option?
Furthermore, you might consider the possibility of doing an Apache module - so that the compiler could load once and stay in memory, recompiling .es4 files on demand.
Speed is definitely an issue. I'm focusing on correctness first and haven't done much performance optimization. The major bottlenecks are parsing, which can definitely be improved (I'll be looking into Psyco among other things), but there is of course also a constant overhead with loading Python.
I like your suggestion about compiling several files at once. Probably there should be a simple build-system where a set of source files could be specified. The build system could then analyze dependencies and look at the timestamps on the files, and then only recompile files when it it necessary. This would definitely improve performance and make it easier to manage larger projects.
I didn't initially consider dynamic compilation on the web server, but you are not the first one to suggest it, so I realize it is an obvious need. I can see that it would improve the development cycle if you can just edit code, and press reload in the browser to see the consequences. A separate "compile"-step is just a hassle when you are used to the quick turnaround with classic JS development. And Mascara is supposed to make it easier, not harder, to develop JS. So I'll definitely consider this more throughly.
There is already a cgi-hook and a django-hook (suggested by James Wilson) in the distribution, but they are only included as proofs of concept, and does not employ any kind of caching (yet).
I saw the other CGI implementations, but as we do all our server-side development in PHP, I prefer to control compilation and caching from there. In production environments, this will also enable me to compress the compiled output...
I have two important questions at this point:
1. licensing - it's free for non-commercial applications, but what will be the licensing terms for commercial applications? (and I mean a license to use it to develop commercial applications - not a license to use the product iself as part of a commercial solution, just the generated code)
2. source code - I don't see it. The license file mentions the source code, but it doesn't look like the source code is available anywhere? Will the final product be open or closed source?
The licensing details are still being worked out, but will be disclosed when the beta phase is over and version 1.0 is released. But informally the plan is this:
- The product will be for pay, if you want to use it for production sites. Prices will be disclosed when it hits version 1.0.
- It will be free (as in free beer) for experimenting and learning.
- Source code will be made available since it is expected that advanced users might want to extend or customize the system. It will probably not be under an Open Source(TM) license as defined by the OSI, though.
Will it be license per developer, per site, per company,...?
Unrelated to those questions - the debug files produced with line number mappings... are there any existing tools capable of backtracing through those, to discover the location of an error in the original source?
(Sorry for the belated answer.) The licensing is going to be per developer using the translator. I think that is the most fair way to license development tools. You shouldn't be punished for being more productive and create more sites :-)
The debug files are a custom format which is only consumed by the command line translator itself.
It would be cool though, to create a JavaScript helper which could display the source location for runtime errors in the browser - that would work nicely together with a dynamic compilation work mode.
8 kommentarer:
Jeg er særdeles spændt på at afprøve denne oversætter, men det er endnu ikke lykkedes mig at starte den.
Jeg har ActiveState ActivePython 2.6 installeret, og får derfor flg. besked når jeg prøver at starte:
ImportError: Bad magic number in C:\mascara\es4translator\__init__.pyc
Hvor er kildefilerne? Jeg troede at projektet var open source? Uden kildefilerne er jeg tvunget til at lave en særskilt installation af Python, kun til at afvikle oversætteren... det er ikke praktisk...
Hej Mindplay,
(I'm answering in English since other readers might have the same issue.)
The error you get: "Bad magic number" is due to running under an incompatible Python version. Mascara requires Python 2.5, while you are running the new 2.6, and the versions are not immediately compatible. (Revisions should be compatible though - Mascara should run on all 2.5.x versions.)
I know it's a hassle to install the Python separately, and I'm looking into creating a one-step installer which installs the right Python version along with the translator.
Right now you will have to manually install Python 2.5. (There should be no problem running a Python 2.5 in parallel with your existing 2.6 installation though.)
I'm sorry, I know how annoying each extra installation step is, when you just want to try out a piece of software.
The source code is not yet available for download, I plan to make it available when the version leaves the beta-stage.
Hope you decide to try it out anyway! And of course I am very interested in hearing any additional problem you might have, so we can get them fixed.
I should have posted in english, but the site came up in danish and so I automatically switched ;-)
I installed Python 2.5, and successfully ran the software.
To be able to start testing in depth, I also wrote a small PHP script and an Apache rewrite that catches the .es4 extension and transparently recompiles the files to JavaScript as needed.
It seems to work great :-)
The one negative impression I've had so far, is the compilation time...
Compiling the files takes too much time - typically 5+ seconds per file, on a 2GHz dual core machine with 4GB of RAM.
The slow response will get in the way of comfortable development.
I wonder if the overhead could be caused by Python and standard libraries loading up, rather than the compiler itself?
If so, one helpful optimization would be to allow compilation of multiple scripts in one go - so that a whole set of scripts could be recompiled in one go.
If not - I know there's no way to really compile Pyhon code, but maybe packaging it as a single executable, and using one of the optimization libraries I've seen that are supposed to speed up Python scripts at the expense of some memory overhead, could be an option?
Furthermore, you might consider the possibility of doing an Apache module - so that the compiler could load once and stay in memory, recompiling .es4 files on demand.
Just ideas :-)
Hi Mindplay,
I'm happy to hear you got it running!
Speed is definitely an issue. I'm focusing on correctness first and haven't done much performance optimization.
The major bottlenecks are parsing, which can definitely be improved (I'll be looking into Psyco among other things), but there is of course also a constant overhead with
loading Python.
I like your suggestion about compiling several files at once. Probably there should be a simple build-system where a set of source files could be specified. The build system could then analyze dependencies and look at the timestamps on the files, and then only recompile files when it it necessary. This would definitely improve performance and make it easier to manage larger projects.
I didn't initially consider dynamic compilation on the web server, but you are not the first one to suggest it, so I realize it is an obvious need.
I can see that it would improve the development cycle if you can just edit code, and press reload in the browser to see the consequences. A separate "compile"-step is just a hassle when you are used to the quick
turnaround with classic JS development. And Mascara is supposed to make it easier, not harder, to develop JS.
So I'll definitely consider this more throughly.
There is already a cgi-hook and a django-hook (suggested by James Wilson) in the distribution, but they are only included as proofs of concept, and does not employ any kind of caching (yet).
Thanks for your suggestions!
I saw the other CGI implementations, but as we do all our server-side development in PHP, I prefer to control compilation and caching from there. In production environments, this will also enable me to compress the compiled output...
I have two important questions at this point:
1. licensing - it's free for non-commercial applications, but what will be the licensing terms for commercial applications? (and I mean a license to use it to develop commercial applications - not a license to use the product iself as part of a commercial solution, just the generated code)
2. source code - I don't see it. The license file mentions the source code, but it doesn't look like the source code is available anywhere? Will the final product be open or closed source?
The licensing details are still being worked out, but will be disclosed when the beta phase is over and version 1.0 is released. But informally the plan is this:
- The product will be for pay, if you want to use it for production sites. Prices will be disclosed when it hits version 1.0.
- It will be free (as in free beer) for experimenting and learning.
- Source code will be made available since it is expected that advanced users might want to extend or customize the system. It will probably not be under an Open Source(TM) license as defined by the OSI, though.
Sounds reasonable.
Will it be license per developer, per site, per company,...?
Unrelated to those questions - the debug files produced with line number mappings... are there any existing tools capable of backtracing through those, to discover the location of an error in the original source?
(Sorry for the belated answer.) The licensing is going to be per developer using the translator. I think that is the most fair way to license development tools. You shouldn't be punished for being more productive and create more sites :-)
The debug files are a custom format which is only consumed by the command line translator itself.
It would be cool though, to create a JavaScript helper which could display the source location for runtime errors in the browser - that would work nicely together with a dynamic compilation work mode.
Send en kommentar