Any problems with Beta 9?
Brought to you by:
anthonysteele
Menu
▾
▴
Beta 9 has been out for a week, and no verifiable bugs have been reported. If you've been holding back on using previous version, please give this one a more thorough test.
I was not aware that beta9 was released.
There is one bug, if you can call it that:
Expected program, package, library, unit near CONST
At line 22 col 1 in SYM_Main.pas
This error, I guess, is due to the fact that that unit is not really a unit, but an include file. You only find out about it when you're formatting a whole folder.
I am not sure if JCF should be modified to handle this sort of thing. But, then if it did not do that, it would miss out on code such as IBO where *.pas files are routinely included all over the place.
I suppose, the ideal thing to do would be to load and format all included *.pas files.
Another thing is, it tries to format things within compiler directives that are not enabled. Such as
{$IFNDEF DELPHI_8_OR_GREATER}
Wrong compiler version!!!
{$ENDIF}
BTW, this just an example.
Finally, even though it *has* become somewhat faster, it still took me about 3 hours to format my test corpus (55 MB pas source) on an Athlon XP 3200+ with 2 Gig RAM and the fastest disk I could lay my hands on. DelForEx handles the same stuff in a few minutes.
I have not had the opportunity to test for memory leaks.
Cheers,
Adem
For the compiler directives, go to the preprocessor page of the format settings, and check enable . Then enter the defined symbols that are used in your code (in the e.g. given, you would put DELPHI_8_OR_GREATER in that list).
Should work now. There are times when you will want to parse and format all code in or out of {$IFDEF}s and times like this, when you don't.
I was not aware of that one either. And, it is a very useful feature --one that I would like to see enhanced in upcoming version. IOW, it would be very useful if it could do an initila pass on the *.pas file and gather a list of compiler directives (and also a list of $I --include-- files) so that the user would be able to pick and choose which ones s/he wants enabled.
A very interesting feature it would be. But, maybe in a later version.
Cheers,
Adem
That started to work in Beta 6, and has been worked on in betas 6-9. I think it's stable now.
> Expected program, package, library, unit near CONST
At line 22 col 1 in SYM_Main.pas
>This error, I guess, is due to the fact that that unit is not really a unit
Indeed, the formatter expects a complete unit, and this always starts with the keyword 'unit', or 'program', 'package', or 'library'.
It is I suppose possible to parse the include file as a "partial unit" if the first keyword is "const", "var", "type" etc, but according to which rules?
e.g. code such as "procedure foo; procedure bar; procedure fish; " without procedure bodies is legal and normal in the interface section, but not in the implementation section.
This is unlikely to go in for 2.0 - perhaps it should be a feature request?
Yes, a future feature request.
But, it would be a much more useful if you could couple this with the compiler directive stuff I wrote elsewhere in this thread,
Cheers,
Adem
> Finally, even though it *has* become somewhat faster, it still took me about 3 hours to format my test corpus (55 MB pas source) on an Athlon XP 3200+ with 2 Gig RAM and the fastest disk I could lay my hands on. DelForEx handles the same stuff in a few minutes."
It would be interesting to know what technique DelForExp uses to achive this - is it simpler and dumber than JCF 2.0, ie using a linear technique like Jcf 1.0, or is it smater than Jcf 2.0 and using a yacc-generated or table-driven grammar or the like, not the recursive descent parsing used here.
If it is forgiving about input, e.g. can format your include files, but has trouble with complex constructs, this would indicate the "dumber" option.
JCF is a cross between a compiler and formatter, whereas, it seems, DelForEx is rather less ambitious.
DelForEx will never tell you about syntactic errors, or even things like missing else statements in the 'case' blocks or that you should use 'Result' instead of function name in assignments.
DelForEx does not care, either, whether the code you have in there makes compilation sense. So, it is, in your words a /dumber/ solution.
I value your work greatly --though at times you might have felt I did not :-) -- for, if nothing else, producing a nearly perfect definition of the language.
Dont get me wrong, formatting is obviously very useful, but in this particular case, IMHO, the potential value of the by-product can be said to have exceeded the main one.
Speed is an issue but only for so long. Once the corner cases are covered, which you seem to have done, speeding the whole thing up --upto and beyond that of Delphi-- is just a matter of optimization. Not too simple, but simple enough; IMHO.
Keep up the good work --it definitely is good work.
Cheers,
Adem
Nope. I spoke too soon. There is this silly case that is
not covered.
It comes from Bochs For Delphi (or something like it). From the cpu.pas in there has constructs like this.
Cheers,
Adem
Type
TDummy = Record
Case integer Of
0: (
ERX: LongWord;
Word: Record
Filler: Word;
Case integer Of
0: (
RX: Word;
Byte: Record
RH: Byte;
RL: Byte;
End;
);
End;
);
End;
TSomeObject = Class(TObject)
Private
FDummy: Array[0..8] Of TDummy;
Public
Property AL: Byte Read FDummy[0].RL Write FDummy[0].RL;
Property CL: Byte Read FDummy[1].RL Write FDummy[1].RL;
Property DL: Byte Read FDummy[2].RL Write FDummy[2].RL;
Property BL: Byte Read FDummy[3].RL Write FDummy[3].RL;
Property AH: Byte Read FDummy[0].RH Write FDummy[0].RH;
Property CH: Byte Read FDummy[1].RH Write FDummy[1].RH;
Property DH: Byte Read FDummy[2].RH Write FDummy[2].RH;
Property BH: Byte Read FDummy[3].RH Write FDummy[3].RH;
Property AX: Word Read FDummy[0].RX Write FDummy[0].RX;
Property CX: Word Read FDummy[1].RX Write FDummy[1].RX;
Property DX: Word Read FDummy[2].RX Write FDummy[2].RX;
Property BX: Word Read FDummy[3].RX Write FDummy[3].RX;
Property SP: Word Read FDummy[4].RX Write FDummy[4].RX;
Property BP: Word Read FDummy[5].RX Write FDummy[5].RX;
Property SI: Word Read FDummy[6].RX Write FDummy[6].RX;
Property DI: Word Read FDummy[7].RX Write FDummy[7].RX;
Property EAX: LongWord Read FDummy[0].ERX Write FDummy[0].ERX;
Property ECX: LongWord Read FDummy[1].ERX Write FDummy[1].ERX;
Property EDX: LongWord Read FDummy[2].ERX Write FDummy[2].ERX;
Property EBX: LongWord Read FDummy[3].ERX Write FDummy[3].ERX;
Property ESP: LongWord Read FDummy[4].ERX Write FDummy[4].ERX;
Property EBP: LongWord Read FDummy[5].ERX Write FDummy[5].ERX;
Property ESI: LongWord Read FDummy[6].ERX Write FDummy[6].ERX;
Property EDI: LongWord Read FDummy[7].ERX Write FDummy[7].ERX;
Property IP: Word Read GetIP Write SetIP;
End;
I can't get that to compile in Delphi 7
The closest that I can get to compile is this:
TSomeObject = Class(TObject)
Private
FDummy: Array[0..8] Of TDummy;
Public
Property DRXummy: TDummy Read FDummy[0] Write FDummy[0];
Property E: LongWord Read FDummy[0].ERX Write FDummy[0].ERX;
// "undeclared Identifier 'RL' " Property AL: Byte Read FDummy[0].RL Write FDummy[0].RL;
End;
.. Which does indeed fail in Beta 9. ... Onward to Beta 10
I am sorry it did not compile. It was a pseudo code to save you from having to go through a lot of chaff. It seems it did not help.
The real code is available at
http://sourceforge.net/projects/bochs2delphi/
But, it uses so many *.pas files as include files --which made my life hell in trying to figure out what was going on. I combine all the includes into the cpu.pas file where they belonged. I can send you the monolithic file if you want me to.
Abd you can download the originial code from the above link to see how JCF behaves with *.pas files as include files.
Cheers,
Adem
Fix is tested and is in SourceForge cvs.
> I was not aware that beta9 was released.
You can set it up so that Surceforge sends you an email when there is a new release.
Here's a couple of lines that don't reformat correctly with my settings. The context of this code is the OnClick handler of Button1 on a form:
if Sender <> Button1 then // Another button was clicked
Exit;
"// Another button was clicked" is an end-of-line comment, and the only code on the following line is "Exit;"
When the formatter runs this code, it moves "Exit;" to the end of the line that has the comment.
I don't know if the cfg settings influence this. Let me know if you need more info. jozzb@hotmail.com.
- JB
I can't replicate this in Beta 9. Post a bug report if you can.
got the bug report ... replicated and fixed
HELP!!!
Beta9:
Is anyone else getting a runtime error 216 at 00403B76 on startup? It happens immediately when I double click on JCFGUI.EXE.
I tried cleaning out my registry, removing all old Jedi setup parameters but it didn't help.
XP Pro wants to send a debug message to M$ when the crash occurs. I'd send you the debug dump, but the ^$*#@! XP exception catcher locks the debug dump file and then promptly eats it if you don't send it to Redmond.
BTW, JcfNotepad (B9) does the same thing, at a slightly different address. I don't normally use JcfNotepad, so I'd rather have JCFGUI fixed.
I have all the latest patches installed in XP. The machine is a 3.35 GHz P-IV, with 1 GB of RAM on board. I have hyperthreading turned on, FWIW.
I just ran a quick test on previous Betas - Beta6 starts up OK without a crash. Beta8 does the same thing as Beta9... Kaboom! I guess I'll revert to B6 for a while.
Kevin
I'm running XP, and have never had this problem. It sounds like a configuration issue. Do other Delphi programs that use the VCL and JCL run ok?
No, JCL/JVCL blows up on this machine too. I think its CPU speed related, since the JCL CPU info unit crashes when benchmarking very fast Pentiums like mine. There may be other JCL crash locations, but this is the first problem area that came to my attention.
I don't think its a configuratation issue, since I renamed/erased all the Jedi Format config files and registry entries I could find and the problem still occurs.
Note that Beta6 works OK on the same machine. I have not had any other reliability issues with the machine.
I can't debug Jedi Formatter since I am unable to install JCL/JVCL on this machine. It blows up as soon as I activate it in Delphi :-(
I see there is a new release of JCL, JCL 1.22, released on 2002-10-21. Does this help?
If not, and you haven't already done so, you may want to log a JCL bug. http://projectjedi.sourceforge.net/