Re: [fpc-devel] Video unit -- bug? Tracedump -- request?
Video doesn't restore terminal settings on Linux after exiting -- the command line doesn't show any typed in text, and doesn't process CR characters... Is this a bug? And if not, what's the cure? (except of course manual reset of the console after execution) Do you call donevideo? LineInfo/Tracedump -- Is there an easy way to make the output of the tracedump after a crash be appended to a file? Or redirected at all? I need people to submit bug-reports, and while using Video unit the dumps arent readable at all on linux... :-( Don't know, try: ./x 2 filename.txt For heaptrc you can use SetHeapTrcOutput(heap.log). For normal runtime errors/exceptions with backtrace there is no way to redirect. The writing of that info is to stdout for compatibility. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
On 15 feb 2005, at 02:35, DrDiettrich wrote: 1) Properties for Object type. I guess this won't be that hard to add, given that we already support global properties (so they're not really tied to classes) 2) Sets with minimal size, at least with 1 and 2 bytes for replacement of Byte and Word types. This would be quite a bit more work. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in PWidechar and refcounting
Alexey Barkovoy wrote: PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design. In Delphi WideString is not reference counted at all. The layout of the string prefix is dictated by the Windows API (BSTR type), and AFAIK Windows also doesn't use reference counting with this type, or with OLEVariants containing wide strings. That is something Windows specific. For Kylix it is reference counted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Video unit -- bug? Tracedump -- request?
Marco van de Voort wrote: Video doesn't restore terminal settings on Linux after exiting -- the command line doesn't show any typed in text, and doesn't process CR characters... Is this a bug? And if not, what's the cure? (except of course manual reset of the console after execution) Do you call donevideo? Yes. Always. I also use Keyboard, now that I think about it (and call DoneKeyboard too). LineInfo/Tracedump -- Is there an easy way to make the output of the tracedump after a crash be appended to a file? Or redirected at all? I need people to submit bug-reports, and while using Video unit the dumps arent readable at all on linux... :-( Don't know, try: ./x 2 filename.txt This is not something I can tell a non-programmer beta-tester to do -- I wanted something simple :-(. Peter Vreman wrote: For normal runtime errors/exceptions with backtrace there is no way to redirect. The writing of that info is to stdout for compatibility. Isn't there any way to catch stdout to a file? (I tried to check in a ExitrProc wether ExitCode is non-zero and if so Assign StdOut, but assigning stdout doesn't seem to work -- guess it cant be reasigned...) At your service, Kornel Kisielewicz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
After eliminating dozens of bugs now I have a working version of Abbrevia for Delphi. Unfortunately this version is not usable with FPC, primarily because FPC doesn't support properties for the Object type. In my code I like to use Object for records with methods and properties, which need no dynamic memory allocation. In Abbrevia this feature allowed to eliminate near 100 methods of various classes, and simplified more code. After all I found the following essential features missing in FPC: 1) Properties for Object type. Since which Delphi version is this allowed? FPC has an explicit check for delphi mode to disable property in tp style object. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
After eliminating dozens of bugs now I have a working version of Abbrevia for Delphi. Unfortunately this version is not usable with FPC, primarily because FPC doesn't support properties for the Object type. In my code I like to use Object for records with methods and properties, which need no dynamic memory allocation. In Abbrevia this feature allowed to eliminate near 100 methods of various classes, and simplified more code. After all I found the following essential features missing in FPC: 1) Properties for Object type. Since which Delphi version is this allowed? FPC has an explicit check for delphi mode to disable property in tp style object. D6 accepts: type x = object fblaat : integer; property blaat:integer read fblaat write fblaat; end; assignig fblaat and writeln(blaat) also works. So it seems it works as expected in D6. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
2) Sets with minimal size, at least with 1 and 2 bytes for replacement of Byte and Word types. I consider both features as vital in translations from C to Pascal, and in the detection and elimination of bugs. Will it be possible to add these features to FPC, this year? I'm interested in the last one. What is exactly the problem with it, except foreign data, like API declarations (which are rare anyway), and binary files? The C argument is a bit doubtful, since there are more such problems (like bitpacking, not being able to exactly duplicate any union), so 1:1 remapping is not really possible anyway. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Abbrevia and Delphi compatibility
Hello Jonas,
Wednesday, February 16, 2005, 11:24:00 AM, you wrote:
1) Properties for Object type.
Should already work with {$mode Delphi} - if this feature is not
broken again now.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Abbrevia and Delphi compatibility
Hello Marco, Wednesday, February 16, 2005, 1:32:58 PM, you wrote: Currently FPC has special code that forbids property in objects for delphi mode. At least Delphi versions from 2 to 7 support propereties for old-style objects. This feature is used BTW in KOL library. Some years ago I implemented a patch for FPC 1.1 which resolved this feature for Delphi compatible mode but suppressed for all others. I hope that this feature is not removed also now (but I have not latest FPC builds now). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in PWidechar and refcounting
- Original Message - From: DrDiettrich [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tuesday, February 15, 2005 4:11 AM Subject: Re: [fpc-devel] Bug in PWidechar and refcounting Alexey Barkovoy wrote: PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design. In Delphi WideString is not reference counted at all. The layout of the string prefix is dictated by the Windows API (BSTR type), and AFAIK Windows also doesn't use reference counting with this type, or with OLEVariants containing wide strings. In e-mail above I've not said anywhere about reference-counting, I've said WideString are managed by compiler. For example if you declare WideString local variable in procedure it will be automatically freed at the end of procedure in compiler generated try ... finally block. And if you declare PWideChar, allocate memory for it, when it's up to you to free this memory after you no longer need it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
2) Sets with minimal size, at least with 1 and 2 bytes for replacement
of Byte and Word types.
This is already correctly working (at least in FPC 1.9.x). For example:
type
{$MINENUMSIZE 2}
enumDMUS_VARIATIONT_TYPES = (
DMUS_VARIATIONT_SEQUENTIAL {= 0}, (* Play sequential starting with
variation 1. *)
DMUS_VARIATIONT_RANDOM {= 1}, (* Play randomly. *)
DMUS_VARIATIONT_RANDOM_START {= 2}, (* Play sequential starting with a
random variation. *)
DMUS_VARIATIONT_NO_REPEAT{= 3}, (* Play randomly, but don't play the
same variation twice. *)
DMUS_VARIATIONT_RANDOM_ROW {= 4} (* Play randomly as a row: don't
repeat any variation until all have played. *)
);
begin
WriteLn(SizeOf(enumDMUS_VARIATIONT_TYPES));
end.
will write 2
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
D6 accepts:
type x = object
fblaat : integer;
property blaat:integer read fblaat write fblaat;
end;
assignig fblaat and writeln(blaat) also works.
So it seems it works as expected in D6.
Same with FPC, the below program prints 1234 (recent 1.9.7):
{$mode delphi}
type x = object
fblaat : integer;
procedure fillblaat;
property blaat:integer read fblaat write fblaat;
end;
procedure x.fillblaat;
begin
fblaat:=1234; // this 1234 is printed.
end;
var y:x;
begin
y.fblaat:=1234;
y.fillblaat; // this can be omitted and it still works
writeln(y.blaat);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
After eliminating dozens of bugs now I have a working version of Abbrevia for Delphi. Unfortunately this version is not usable with FPC, primarily because FPC doesn't support properties for the Object type. In my code I like to use Object for records with methods and properties, which need no dynamic memory allocation. In Abbrevia this feature allowed to eliminate near 100 methods of various classes, and simplified more code. After all I found the following essential features missing in FPC: 1) Properties for Object type. Since which Delphi version is this allowed? FPC has an explicit check for delphi mode to disable property in tp style object. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
On 16 feb 2005, at 13:24, Alexey Barkovoy wrote: 2) Sets with minimal size, at least with 1 and 2 bytes for replacement of Byte and Word types. This is already correctly working (at least in FPC 1.9.x). For example: No, those are enumerations, not sets. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TShiftState as enum
TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TShiftState as enum
TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Of course that is possible. It requires some imagination though (and a feel for obfuscated Pascal) type myset = set of ( a1,a2,a3,a4,a5,a6); // workaround types const beginmyset=ord(low(myset)); endmyset=ord(high(myset)); type uglyenum = beginmyset..endmyset; uglyset= set of uglyenum; var b : myset; i : integer; begin b:=[a1,a2,a3]; for i:=ord(low(myset)) to ord(high(myset)) do if i in uglyset(b) then writeln(i); end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TShiftState as enum
TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Of course that is possible. It requires some imagination though (and a feel for obfuscated Pascal) The example fails in Delphi 6 btw, but works in FPC :-) Delphi does not allow low/high on sets (I vote to keep this FPC extension btw) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
