I have a program written in MP2. It used to work well. But when I try to compile it using MP3 Final, it is compiled successfully but when I run it, an error occurs. I used WTK Simulator, microemulator and my Samsung U600 to test. It has error on all three.
Here is the link to download the source code: http://files.myopera.com/mtmaster/files/VinaSo.zip
Sorry for my bad English.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Bad version information", seems I made a mistake when rebuilding the H.class stub from source. The next release (3.1 ALPHA) will contain this bug fixed.
The manual fix: if you want to fix it locally, just download the H.java source code, and compile in the standard way (take care of readjusting the paths before using the following code):
Then put the generated/preverified class into your Stubs subdirectory (in the installation root of MP3).
After that just recompile your project with MP3 and it will be working.
A temporary workaround: another way to get your midlet working right now with MP3 and without messing with the stub recompilation (may be you don't have and even can't have all the java stuff required installed in the system you are working), is just compile your project with MP2, extract the H.class, replace the H.class of MP3 (located in Stubs subdirectory of the Installation root) with that one you extracted, compile with MP3 and celebrate, it will be working.
Thanks for your report!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm affraid you will have to wait to MP4 to be released to get full unicode support. I understand the current need for it but to satisfy that need is out of the scope of the goals of the 3.x series. Besides that, and to provide an analysis on the subject I must say that it involves too much code to rewrite (in Delphi and in C, at least) and also a lot of testing to adapt MP3 for that. For example, besides I can adjust the IDE's code editor to fully handle unicode without much work, a problem that follows that change is the Preprocessor (which I wrapped into mp3PP.dll) adaptation. I'm using the one I found available: the JEDI Pascal Preprocessor, which is an ansi preprocessor, so it will corrupt your cyrillic characters.
Currently I have no time to port it to support unicode or to code a brand new preprocessor supporting unicode from scratch. If you have a pascal preprocessor supporting unicode to suggest, just let me know and I will take a look at it. But all that is just to mention the IDE's code editor and preprocessor parts… it's far more than just that: after all that comes the compiler part. And remember the current one is just the Niksa's C original, extended first by Artem (who, for example, replaced the lexer with a new one), and currently extended and maintained by me. Finally, all this process involves a good testing phase, to be sure everything work as expected. This is very important specially in a project like this.
So, resuming, measuring all that, and having in mind that the whole MP3 project will be dropped when MP4 gets released, in my point of view (I'm just at charge of the 3.x series), it's out of it's goals to modify the current code editor, port the current preprocessor and extend the old compiler to support unicode, specially when the original project goal (to have an open source IDE, preprocessor and compiler in FreePascal) is already started. Hopefully you understand what I mean, and be sure I agree that the full unicode support is a must for MP4 (which by definition involves a fresh rewrite from scratch of everything).
Thanks for your report anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a program written in MP2. It used to work well. But when I try to compile it using MP3 Final, it is compiled successfully but when I run it, an error occurs. I used WTK Simulator, microemulator and my Samsung U600 to test. It has error on all three.
Here is the link to download the source code: http://files.myopera.com/mtmaster/files/VinaSo.zip
Sorry for my bad English.
"Bad version information", seems I made a mistake when rebuilding the H.class stub from source. The next release (3.1 ALPHA) will contain this bug fixed.
The manual fix: if you want to fix it locally, just download the H.java source code, and compile in the standard way (take care of readjusting the paths before using the following code):
Then put the generated/preverified class into your Stubs subdirectory (in the installation root of MP3).
After that just recompile your project with MP3 and it will be working.
A temporary workaround: another way to get your midlet working right now with MP3 and without messing with the stub recompilation (may be you don't have and even can't have all the java stuff required installed in the system you are working), is just compile your project with MP2, extract the H.class, replace the H.class of MP3 (located in Stubs subdirectory of the Installation root) with that one you extracted, compile with MP3 and celebrate, it will be working.
Thanks for your report!
Using
crashes the executable with an error message.
Sorry:
I'm affraid you will have to wait to MP4 to be released to get full unicode support. I understand the current need for it but to satisfy that need is out of the scope of the goals of the 3.x series. Besides that, and to provide an analysis on the subject I must say that it involves too much code to rewrite (in Delphi and in C, at least) and also a lot of testing to adapt MP3 for that. For example, besides I can adjust the IDE's code editor to fully handle unicode without much work, a problem that follows that change is the Preprocessor (which I wrapped into mp3PP.dll) adaptation. I'm using the one I found available: the JEDI Pascal Preprocessor, which is an ansi preprocessor, so it will corrupt your cyrillic characters.
Currently I have no time to port it to support unicode or to code a brand new preprocessor supporting unicode from scratch. If you have a pascal preprocessor supporting unicode to suggest, just let me know and I will take a look at it. But all that is just to mention the IDE's code editor and preprocessor parts… it's far more than just that: after all that comes the compiler part. And remember the current one is just the Niksa's C original, extended first by Artem (who, for example, replaced the lexer with a new one), and currently extended and maintained by me. Finally, all this process involves a good testing phase, to be sure everything work as expected. This is very important specially in a project like this.
So, resuming, measuring all that, and having in mind that the whole MP3 project will be dropped when MP4 gets released, in my point of view (I'm just at charge of the 3.x series), it's out of it's goals to modify the current code editor, port the current preprocessor and extend the old compiler to support unicode, specially when the original project goal (to have an open source IDE, preprocessor and compiler in FreePascal) is already started. Hopefully you understand what I mean, and be sure I agree that the full unicode support is a must for MP4 (which by definition involves a fresh rewrite from scratch of everything).
Thanks for your report anyway.