1. After building a project and running it, the emulator fired up OK. Closed the emulator after program had run and made some changes to code and rebuilt - running project showed "Launching…" message but no emulator ran. Closing MP and re-opening led to project running OK again. Cannot seem to run emulator twice in same session of MP?
2. I erroneously introduced syntax error in code (Draw_Image instead of DrawImage). Messages only told me an error had occurred during build. Same in MP2 targeted the error precisely and allowed me to debug much more easily. Will make debugging large program after numerous amendments very difficult.
Enhancement request: When exiting MP and unsaved changes are pending, a message appears to warn changes will be discarded. If this was to say "Do you wish to save your changes before closing Midlet Pascal?" with Save/Discard/Cancel options it would be a single click to save and exit rather than the three actions needed currently (not that I'm lazy!).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. Well, besides I can not reproduce the bug in my environments, may be is not a good idea to wait the end of the execution of the emulator to enable again the Run action. When coding that I thought it was cool to block the Run action to avoid that cases where you hit it twice or more times in a row (and, depending on the emulator, you could end with many emulator instances), but I forgot completely that sometimes the emulator could hang or had a delayed process unloading for any reason. I just removed that "smart" behaviour.
2. I will need more information from you in this case, since in MP2 I get the error:
Compiling 'newproject.mpsrc'…
newproject.mpsrc:12: error, identifier 'Draw_Image' is not procedure, function, variable or unit name
Done - 1 error(s), 0 warning(s)
and in MP3 I get the error:
Compiling 'newproject.mpsrc'…
newproject.mpsrc(13): E428 identifier 'draw_image' is not procedure, function, variable or unit name
ERROR: an error ocurred compiling NewProject.mpsrc
which is the same error. Which output are you getting? Please copy/paste your MP3 output.
3. Yeah, thanks for pointing that out, I was about to forget to fix that. It was "negatively asking" to avoid accidental project overwriting when testing (this was to minimize the chances of someone overwriting his MP2 project when testing MP3, specially back in the ALPHA stages). Now it performs the classic behaviour: "Do you want to save the changes?" Yes/No/Cancel, like in notepad.
Thanks for your reports!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For (2), I get the following output in the Messages panel:
"Building C:\Users\Shaun\Source Code\Schmabble\Schmabble.mpproj
Started at 13/04/2010 17:39:30
Target Info
MIDlet Type: Classic MIDlet
Real Numbers: Fixed-point
ERROR: an error ocurred compiling Schmabble.mpsrc"
(note there's a typo "ocurred" should be "occurred").
I also used Compile Current File option in Project menu and got absolutely no messages at all (not sure what that option's for, though!).
Thanks, again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see all the messages you receive in the panel are IDE generated, so I will try to reproduce that (missing compiler messages) here in my environments.
Thanks for pointing out the typo, now it's fxed.
The "Compile Current File" option is provided to generate a single class/es (when possible) from the current unit only. You can find the class/es file/s at the classes subfolder in the Project folder. It's helpful in many situations like recovering a Project which source code is partially missed or corrupted, or when you only want to analyze the class file (constant pool, methods, bytecode, etc), or just when coding a single unit in a separate fashion and need to check everything is ok (the syntax, the libraries you are calling, etc), and other "other-than-building-a-project" scenarios.
Thanks again!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, that's a good hint. In fact, that can relate the other bug you reported: under your system the IDE is not detecting when the emulator ends (in any case I will mantain the fix I made for the reasons I described before: the emulator may hang on any system, etc).
But talking about this one, with missing compiler messages, the IDE is capturing the compiler's console output and, since you are experiencing the behaviour described, there is a problem with that redirection, so the goal is to determine which is it to fix it.
What I can say about this is that the console redirection MP3 uses works fine under all of the W32-bit possibilities I had tested: ME ("old" W32), XP ("mid" W32) , Vista ("new" W32) and Wine ("non-official" W32), but could not test it directly under Wow64 ("officially-emulated" W32) since I have not that kind of environment yet. But your experience under Wow64 talks about a bug.
A first guess on what's happening leads me to think about what Microsoft says in http://support.microsoft.com/kb/190351:
"Child processes that use such C run-time functions as printf() and fprintf() can behave poorly when redirected. The C run-time functions maintain separate IO buffers. When redirected, these buffers might not be flushed immediately after each IO call. As a result, the output to the redirection pipe of a printf() call or the input from a getch() call is not flushed immediately and delays, sometimes-infinite delays occur. This problem is avoided if the child process flushes the IO buffers after each call to a C run-time IO function. Only the child process can flush its C run-time IO buffers. A process can flush its C run-time IO buffers by calling the fflush() function."
So, may be the C run-time functions for W32 under WOW64 are not behaving exactly the same than in native 32-bit Windows systems (it's hard to think that is the case but Microsoft did stuff like that before), for example may be the STDOUT buffer size is different, or there is no more auto-flush when the process ends (that is important when the child process only outputs small stuff), or there is a bug in the Microsoft implementation (no, I don't think so), or any other weird thing (?) that is causing the console output not being flushed automatically.
I'm just blind guessing (I could not find rants about this topic in Wow64 forums), but if that is the case, the fix is what Microsoft suggests: to call fflush() call after each printf() the compiler does. I will try to find a 64-bit Windows system where I can develop/test this. Any outcome on this topic I will be posting it here.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, after a quick test (a friend of mine has a w7 64-bit system) I can discard the flushing problem. The fflush(stdout) additional call does not modify the behaviour at all.
But, at least there seems we are not alone after all with this console redirection problem under wow64:
I know I'm going to regret asking this but how does MP2 avoid this issue? (as that is generating compiler messages OK). Is it not a console-based compiler? You can probably tell compilers aren't my thing but I felt obliged to ask the question!
Many thanks for your continued efforts in looking into this issue.
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A couple of other things I've noticed whilst using Resources:
1. Using the context menu in the Project Manager pane on the Resources item, I select Delete and. although it works, get a couple of index out of bounds errors
2. It would be nice to add more than resource using the Add option (I used the context menu Add option on Resources in the Project Manager pane)
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the question of your previous post, MP2 implemented the compiler as a static library, so it was linked into the same .exe than the IDE. And this, as Niksa stated, was for speed reasons (at that time). Originally the compiler was an stand-alone .exe, just like now. This way we are doing the same than others compilers/IDEs: FPC/Lazarus, Delphi, etc, which is pretty much suitable for our general needs. In any case, the problem under Wow64 must be solved, otherwise we can not state that we fully support it. Let's see what happens.
About your current post stuff: How do you get that error? Please specify steps to reproduce it, since I can add and remove resources without problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am in the Project Manager windows and have any of my resources highlighted. I right-click and select Delete. I get the "Are you sure you want to delete it?" message and select Yes. I then get the "List index out of bounds (n)" message twice - 'n' being the number of resources I have remaining (when I assume it should be n-1 if the index starts at 0 as per Delphi etc.).
Please also note I assumed Delete meant delete from project and not delete from hard disk. It appears the latter is true which is different to MP2. Could the warning message say "Are you sure you wish to delete <resource name> from this project?" and an optional check box on the dialogue giving the user the option (defaulted to unchecked) to also delete from hard disk? This is safer and less likely to lead to users (especially those who are used to MP2) deleting valuable files.
Many thanks, as always
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the out-of-bounds bug I must say that I could not reproduce it yet, I've tried many combinations but everything works fine here. I will try with more time some other things like test this under Wow64, corrupted project files, etc.
About the Delete action itself, yeah, a checkbox will do that work. In any case it's a definition problem. Actions must have the correct counterpart, that means Include should have an Exclude, Add a Delete, and so on. And since the IDE is duplicating information in disk on Add (it's copying the file) it's counterpart must delete. I mean, the behaviour is correct, but an extra confirmation will be good too.
Btw, I will be testing soon in Wow64 a workaround to the console redirection problem too. I will be posting the results here.
Thanks for your report!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello again,
1. After building a project and running it, the emulator fired up OK. Closed the emulator after program had run and made some changes to code and rebuilt - running project showed "Launching…" message but no emulator ran. Closing MP and re-opening led to project running OK again. Cannot seem to run emulator twice in same session of MP?
2. I erroneously introduced syntax error in code (Draw_Image instead of DrawImage). Messages only told me an error had occurred during build. Same in MP2 targeted the error precisely and allowed me to debug much more easily. Will make debugging large program after numerous amendments very difficult.
Enhancement request: When exiting MP and unsaved changes are pending, a message appears to warn changes will be discarded. If this was to say "Do you wish to save your changes before closing Midlet Pascal?" with Save/Discard/Cancel options it would be a single click to save and exit rather than the three actions needed currently (not that I'm lazy!).
Hey,
1. Well, besides I can not reproduce the bug in my environments, may be is not a good idea to wait the end of the execution of the emulator to enable again the Run action. When coding that I thought it was cool to block the Run action to avoid that cases where you hit it twice or more times in a row (and, depending on the emulator, you could end with many emulator instances), but I forgot completely that sometimes the emulator could hang or had a delayed process unloading for any reason. I just removed that "smart" behaviour.
2. I will need more information from you in this case, since in MP2 I get the error:
Compiling 'newproject.mpsrc'…
newproject.mpsrc:12: error, identifier 'Draw_Image' is not procedure, function, variable or unit name
Done - 1 error(s), 0 warning(s)
and in MP3 I get the error:
Compiling 'newproject.mpsrc'…
newproject.mpsrc(13): E428 identifier 'draw_image' is not procedure, function, variable or unit name
ERROR: an error ocurred compiling NewProject.mpsrc
which is the same error. Which output are you getting? Please copy/paste your MP3 output.
3. Yeah, thanks for pointing that out, I was about to forget to fix that. It was "negatively asking" to avoid accidental project overwriting when testing (this was to minimize the chances of someone overwriting his MP2 project when testing MP3, specially back in the ALPHA stages). Now it performs the classic behaviour: "Do you want to save the changes?" Yes/No/Cancel, like in notepad.
Thanks for your reports!
Thanks for the very quick response.
For (2), I get the following output in the Messages panel:
"Building C:\Users\Shaun\Source Code\Schmabble\Schmabble.mpproj
Started at 13/04/2010 17:39:30
Target Info
MIDlet Type: Classic MIDlet
Real Numbers: Fixed-point
ERROR: an error ocurred compiling Schmabble.mpsrc"
(note there's a typo "ocurred" should be "occurred").
I also used Compile Current File option in Project menu and got absolutely no messages at all (not sure what that option's for, though!).
Thanks, again.
I see all the messages you receive in the panel are IDE generated, so I will try to reproduce that (missing compiler messages) here in my environments.
Thanks for pointing out the typo, now it's fxed.
The "Compile Current File" option is provided to generate a single class/es (when possible) from the current unit only. You can find the class/es file/s at the classes subfolder in the Project folder. It's helpful in many situations like recovering a Project which source code is partially missed or corrupted, or when you only want to analyze the class file (constant pool, methods, bytecode, etc), or just when coding a single unit in a separate fashion and need to check everything is ok (the syntax, the libraries you are calling, etc), and other "other-than-building-a-project" scenarios.
Thanks again!
For added info, I am running Windows 7 Home Premium (64-bit). I have both Midlet Pascal 2 and 3 installed.
Thanks for the Compile Current File info - very useful indeed.
Professor Yaffle
Well, that's a good hint. In fact, that can relate the other bug you reported: under your system the IDE is not detecting when the emulator ends (in any case I will mantain the fix I made for the reasons I described before: the emulator may hang on any system, etc).
But talking about this one, with missing compiler messages, the IDE is capturing the compiler's console output and, since you are experiencing the behaviour described, there is a problem with that redirection, so the goal is to determine which is it to fix it.
What I can say about this is that the console redirection MP3 uses works fine under all of the W32-bit possibilities I had tested: ME ("old" W32), XP ("mid" W32) , Vista ("new" W32) and Wine ("non-official" W32), but could not test it directly under Wow64 ("officially-emulated" W32) since I have not that kind of environment yet. But your experience under Wow64 talks about a bug.
A first guess on what's happening leads me to think about what Microsoft says in http://support.microsoft.com/kb/190351:
"Child processes that use such C run-time functions as printf() and fprintf() can behave poorly when redirected. The C run-time functions maintain separate IO buffers. When redirected, these buffers might not be flushed immediately after each IO call. As a result, the output to the redirection pipe of a printf() call or the input from a getch() call is not flushed immediately and delays, sometimes-infinite delays occur. This problem is avoided if the child process flushes the IO buffers after each call to a C run-time IO function. Only the child process can flush its C run-time IO buffers. A process can flush its C run-time IO buffers by calling the fflush() function."
So, may be the C run-time functions for W32 under WOW64 are not behaving exactly the same than in native 32-bit Windows systems (it's hard to think that is the case but Microsoft did stuff like that before), for example may be the STDOUT buffer size is different, or there is no more auto-flush when the process ends (that is important when the child process only outputs small stuff), or there is a bug in the Microsoft implementation (no, I don't think so), or any other weird thing (?) that is causing the console output not being flushed automatically.
I'm just blind guessing (I could not find rants about this topic in Wow64 forums), but if that is the case, the fix is what Microsoft suggests: to call fflush() call after each printf() the compiler does. I will try to find a 64-bit Windows system where I can develop/test this. Any outcome on this topic I will be posting it here.
Thanks again.
Well, after a quick test (a friend of mine has a w7 64-bit system) I can discard the flushing problem. The fflush(stdout) additional call does not modify the behaviour at all.
But, at least there seems we are not alone after all with this console redirection problem under wow64:
http://webcache.googleusercontent.com/search?q=cache:lZbiucLAl0UJ:social.msdn.microsoft.com/Forums/en/vclanguage/thread/e485a063-094f-41bc-bdc5-8a37b5996fab+http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/e485a063-094f-41bc-bdc5-8a37b5996fab
Anyway, I'll keep looking for a solution to this problem.
I know I'm going to regret asking this but how does MP2 avoid this issue? (as that is generating compiler messages OK). Is it not a console-based compiler? You can probably tell compilers aren't my thing but I felt obliged to ask the question!
Many thanks for your continued efforts in looking into this issue.
Professor Yaffle
A couple of other things I've noticed whilst using Resources:
1. Using the context menu in the Project Manager pane on the Resources item, I select Delete and. although it works, get a couple of index out of bounds errors
2. It would be nice to add more than resource using the Add option (I used the context menu Add option on Resources in the Project Manager pane)
Professor Yaffle
About the question of your previous post, MP2 implemented the compiler as a static library, so it was linked into the same .exe than the IDE. And this, as Niksa stated, was for speed reasons (at that time). Originally the compiler was an stand-alone .exe, just like now. This way we are doing the same than others compilers/IDEs: FPC/Lazarus, Delphi, etc, which is pretty much suitable for our general needs. In any case, the problem under Wow64 must be solved, otherwise we can not state that we fully support it. Let's see what happens.
About your current post stuff: How do you get that error? Please specify steps to reproduce it, since I can add and remove resources without problems.
j-a-s-d,
I am in the Project Manager windows and have any of my resources highlighted. I right-click and select Delete. I get the "Are you sure you want to delete it?" message and select Yes. I then get the "List index out of bounds (n)" message twice - 'n' being the number of resources I have remaining (when I assume it should be n-1 if the index starts at 0 as per Delphi etc.).
Please also note I assumed Delete meant delete from project and not delete from hard disk. It appears the latter is true which is different to MP2. Could the warning message say "Are you sure you wish to delete <resource name> from this project?" and an optional check box on the dialogue giving the user the option (defaulted to unchecked) to also delete from hard disk? This is safer and less likely to lead to users (especially those who are used to MP2) deleting valuable files.
Many thanks, as always
Professor Yaffle
About the out-of-bounds bug I must say that I could not reproduce it yet, I've tried many combinations but everything works fine here. I will try with more time some other things like test this under Wow64, corrupted project files, etc.
About the Delete action itself, yeah, a checkbox will do that work. In any case it's a definition problem. Actions must have the correct counterpart, that means Include should have an Exclude, Add a Delete, and so on. And since the IDE is duplicating information in disk on Add (it's copying the file) it's counterpart must delete. I mean, the behaviour is correct, but an extra confirmation will be good too.
Btw, I will be testing soon in Wow64 a workaround to the console redirection problem too. I will be posting the results here.
Thanks for your report!
The workaround for Wow64 seems to be working fine, it will be included in the next release.