Re: [fpc-devel] darwin - rtl include files
On Tue, 16 May 2006, Micha Nelissen wrote: On Tue, 16 May 2006 16:11:43 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: IMHO: Eventually, you'll have to switch to parsing the .ppu files for some parts. Do .ppu files tell in what source file and what line a symbol is defined ? I don't know that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] smrtlinking on arm-wince
How can I check this? binutils is our friend :) I think the problem is not as much the imported functions from the windows unit, although that is interesting too, but more the used functions / procedures and methods from the classes unit. Do you know how I can check, that things are left out if I use smartlinking, (or added if I explicitly use static linking)? 110% agreed , but imported functions are quickly checkable arm-wince-pe-objdump -p MyTestProg.exe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On 16 mei 2006, at 21:50, Micha Nelissen wrote: between minor OS revisions). Libc is also guaranteed to be forward compatible (i.e., the situation that a program will not run anymore So an application linked against any future version of libc is guaranteed to work also against the current version ? No, it's the other way round. But Apple does distribute SDK's for older OS releases which you can build against, so your application will run on them too. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
On 16 May 2006, at 20:32, Michael Van Canneyt wrote: 1. It's heap based. There is a lot of memory manager overhead. 2. The implicit try...finally in each procedure that uses them introduces a memory penalty and a speed penalty. So I would really advise against this change. There is no gain, except maybe for some external path settings. identifiers etc: there short strings are more than enough. Of course such a change would be only for paths and for calling external tools. That's what USE_SYSUTILS is all about. But the last time Peter benchmarked it, it made the compiler nevertheless almost 20% slower. There is after all a lot of unit searching etc going on behind the scenes. Still, it may be better now with all the ansistring optimizations which have been added recently. The SysUtils unit misses some performance tweaks that the Dos unit has. Especially for the FindFirst/FindNext part. But this has low prio for the current developpers so it hasn't been analysed and fixed yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)
This is a follow-up on Bug #4738. I did more testing and have a
clearer idea of why it throws an EVariantError exception.
GetPropValue doesn't handle enumerated types correctly when
GetPropValue gets called with the 3rd parameter (PreferStrings) set to
True (the default).
GetPropValue returns a corrupt Variant of some sorts. Trying to
assign that variant to an enumerated type property using or a direct
assignment or via the SetPropValue raises the EVariantError exception.
I included the output showing the error and the desired result. Also
included is a much simpler example showing the bug compared to the
example referred to in the bug report 4738.
Hope this will help in solving the problem.
Compiler used: 2.0.2 release
OS Tested: Linux, Win2000
Regards,
- Graeme -
-- PrefferString := True --
[EMAIL PROTECTED]:~/programming/tests/enum_type$ ./enum
String:abcde ; Int:12345 ; Enum:Male ;
String: ; Int:0 ; Enum:Unknown ;
An unhandled exception occurred at $08099475 :
EVarianterror :
$08099475
$0809AB7C
$0808A426
$0805390B
$08091210
$080482DD TTESTOBJ__ASSIGNRTTI2, line 61 of enum.lpr
-- PrefferString := True --
-- PrefferString := False --
[EMAIL PROTECTED]:~/programming/tests/enum_type$ ./enum
String:abcde ; Int:12345 ; Enum:Male ;
String: ; Int:0 ; Enum:Unknown ;
String:abcde ; Int:12345 ; Enum:Male ;
-- PrefferString := True --
- enum.lpr --
program enum;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, SysUtils, TypInfo, Variants;
type
TGender = (genUnknown, genMale, genFemale);
const
cGenderGUI : array[TGender] of string =
( 'Unknown', 'Male', 'Female' );
type
TTestObj = class(TPersistent)
private
FPropStr: String;
FPropInt: integer;
FPropOrd: TGender;
public
procedure AssignRTTI1(Source: TPersistent);
procedure AssignRTTI2(Source: TPersistent);
procedure Assign(Source: TPersistent); override;
functionToString: string;
published
propertyPropStr: String read FPropStr write FPropStr;
propertyPropInt: integer read FPropInt write FPropInt;
propertyPropOrd: TGender read FPropOrd write FPropOrd;
end;
{ TTestObj }
procedure TTestObj.AssignRTTI1(Source: TPersistent);
begin
SetPropValue(Self, 'PropStr', TTestObj(Source).PropStr);
SetPropValue(Self, 'PropInt', TTestObj(Source).PropInt);
SetPropValue(Self, 'PropOrd', TTestObj(Source).PropOrd);
end;
procedure TTestObj.AssignRTTI2(Source: TPersistent);
var
lPropValue: Variant;
begin
lPropValue := GetPropValue(Source, 'PropStr');{ passed }
SetPropValue(Self, 'PropStr', lPropValue);
lPropValue := GetPropValue(Source, 'PropInt');{ passed }
SetPropValue(Self, 'PropInt', lPropValue);
// lPropValue := GetPropValue(Source, 'PropOrd', False); { passed }
lPropValue := GetPropValue(Source, 'PropOrd'); { fails }
SetPropValue(Self, 'PropOrd', lPropValue);
// PropOrd := lPropValue; { also fails }
end;
procedure TTestObj.Assign(Source: TPersistent);
begin
PropStr := TTestObj(Source).PropStr;
PropInt := TTestObj(Source).PropInt;
PropOrd := TTestObj(Source).PropOrd;
end;
function TTestObj.ToString: string;
const
C = 'String:%s ; Int:%d ; Enum:%s ;';
begin
Result := Format(C, [PropStr, PropInt, cGenderGUI[PropOrd]]);
end;
var
A, B: TTestObj;
begin
A := TTestObj.Create;
B := TTestObj.Create;
try
A.PropStr := 'abcde';
A.PropInt := 12345;
A.PropOrd := genMale;
Writeln(A.ToString);
{ output empty properties }
Writeln(B.ToString);
//B.Assign(A); { works }
//B.AssignRTTI1(A); { works }
B.AssignRTTI2(A); { fails }
Writeln(B.ToString);
finally
B.Free;
A.Free;
end;
end.
- end ---
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)
On Wed, 17 May 2006, Graeme Geldenhuys wrote:
This is a follow-up on Bug #4738. I did more testing and have a
clearer idea of why it throws an EVariantError exception.
GetPropValue doesn't handle enumerated types correctly when
GetPropValue gets called with the 3rd parameter (PreferStrings) set to
True (the default).
GetPropValue returns a corrupt Variant of some sorts. Trying to
assign that variant to an enumerated type property using or a direct
assignment or via the SetPropValue raises the EVariantError exception.
I included the output showing the error and the desired result. Also
included is a much simpler example showing the bug compared to the
example referred to in the bug report 4738.
Hope this will help in solving the problem.
While I think this is a bug that should be solved, I would suggest
to avoid the use of variants as much as possible. Your code can be
made a lot faster (and bug-free) by avoiding the use of variants
in the first place. This is valid for FPC, but also for Delphi.
Michael.
Compiler used: 2.0.2 release
OS Tested: Linux, Win2000
Regards,
- Graeme -
-- PrefferString := True --
[EMAIL PROTECTED]:~/programming/tests/enum_type$ ./enum
String:abcde ; Int:12345 ; Enum:Male ;
String: ; Int:0 ; Enum:Unknown ;
An unhandled exception occurred at $08099475 :
EVarianterror :
$08099475
$0809AB7C
$0808A426
$0805390B
$08091210
$080482DD TTESTOBJ__ASSIGNRTTI2, line 61 of enum.lpr
-- PrefferString := True --
-- PrefferString := False --
[EMAIL PROTECTED]:~/programming/tests/enum_type$ ./enum
String:abcde ; Int:12345 ; Enum:Male ;
String: ; Int:0 ; Enum:Unknown ;
String:abcde ; Int:12345 ; Enum:Male ;
-- PrefferString := True --
- enum.lpr --
program enum;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, SysUtils, TypInfo, Variants;
type
TGender = (genUnknown, genMale, genFemale);
const
cGenderGUI : array[TGender] of string =
( 'Unknown', 'Male', 'Female' );
type
TTestObj = class(TPersistent)
private
FPropStr: String;
FPropInt: integer;
FPropOrd: TGender;
public
procedure AssignRTTI1(Source: TPersistent);
procedure AssignRTTI2(Source: TPersistent);
procedure Assign(Source: TPersistent); override;
functionToString: string;
published
propertyPropStr: String read FPropStr write FPropStr;
propertyPropInt: integer read FPropInt write FPropInt;
propertyPropOrd: TGender read FPropOrd write FPropOrd;
end;
{ TTestObj }
procedure TTestObj.AssignRTTI1(Source: TPersistent);
begin
SetPropValue(Self, 'PropStr', TTestObj(Source).PropStr);
SetPropValue(Self, 'PropInt', TTestObj(Source).PropInt);
SetPropValue(Self, 'PropOrd', TTestObj(Source).PropOrd);
end;
procedure TTestObj.AssignRTTI2(Source: TPersistent);
var
lPropValue: Variant;
begin
lPropValue := GetPropValue(Source, 'PropStr');{ passed }
SetPropValue(Self, 'PropStr', lPropValue);
lPropValue := GetPropValue(Source, 'PropInt');{ passed }
SetPropValue(Self, 'PropInt', lPropValue);
// lPropValue := GetPropValue(Source, 'PropOrd', False); { passed }
lPropValue := GetPropValue(Source, 'PropOrd'); { fails }
SetPropValue(Self, 'PropOrd', lPropValue);
// PropOrd := lPropValue; { also fails }
end;
procedure TTestObj.Assign(Source: TPersistent);
begin
PropStr := TTestObj(Source).PropStr;
PropInt := TTestObj(Source).PropInt;
PropOrd := TTestObj(Source).PropOrd;
end;
function TTestObj.ToString: string;
const
C = 'String:%s ; Int:%d ; Enum:%s ;';
begin
Result := Format(C, [PropStr, PropInt, cGenderGUI[PropOrd]]);
end;
var
A, B: TTestObj;
begin
A := TTestObj.Create;
B := TTestObj.Create;
try
A.PropStr := 'abcde';
A.PropInt := 12345;
A.PropOrd := genMale;
Writeln(A.ToString);
{ output empty properties }
Writeln(B.ToString);
//B.Assign(A); { works }
//B.AssignRTTI1(A); { works }
B.AssignRTTI2(A); { fails }
Writeln(B.ToString);
finally
B.Free;
A.Free;
end;
end.
- end ---
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006, Mattias Gaertner wrote: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. The format is such that you can always read older/newer .ppu files: there are just certain types of blocks which you can't handle. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. I don't quite agree about this 'nice to have', but you're doing all the work, so you are right :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
Op Wed, 17 May 2006, schreef Michael Van Canneyt: source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. The format is such that you can always read older/newer .ppu files: there are just certain types of blocks which you can't handle. I think reading ppu files can be done reliably with the help of some meta data that describes the structure of the record. If you read a record from ppu, things will break if we change record. However, with some metadata that would get updated if the record changes an IDE would be able to get to the data reliably. The funny thing is that the compiler already generates such metadata: Runtime Type Information. However, it is burried in the compiler executable, and smartlinked away, so RTTI is currently not usable for this purpose. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)
Hi Michael, I do understand that variants are slow, but unfortunately I can't get rid of them. I use the tiOPF framework and in the framework we created a generic Assign method in our base class used for all objects. The Assign uses RTTI extensively with variants to handle all datatypes, except class types that the user might have added. This works perfectly, and the user never needs to worry about creating a custom Assign method for any object, the framework handles all that. The original example referred to in the bug report shows a bit of how the framework does that, but might have complicated the example app to much. That is why I posted a much simpler example now. Regards, - Graeme - While I think this is a bug that should be solved, I would suggest to avoid the use of variants as much as possible. Your code can be made a lot faster (and bug-free) by avoiding the use of variants in the first place. This is valid for FPC, but also for Delphi. Michael. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)
On Wed, 17 May 2006, Graeme Geldenhuys wrote: Hi Michael, I do understand that variants are slow, but unfortunately I can't get rid of them. I use the tiOPF framework and in the framework we created a generic Assign method in our base class used for all objects. I thought it came from there. Even so: This Assign() method does not need to use a variant, but can still offer the same functionality as it does now. It just means that the method needs to determine the actual type itself... The Assign uses RTTI extensively with variants to handle all datatypes, except class types that the user might have added. This works perfectly, and the user never needs to worry about creating a custom Assign method for any object, the framework handles all that. Variants are not required for this. Variants are for (excuse me the term) lazy coders... But I don't suggest rewriting tiOPF for this, it might lead a little bit too far :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. This is incorrect, the generic .ppu format didn't change for the last several years. The code needed to parse ppu's and retrieve symbol info is also stable for the last years. See how good an old ppudump works on current ppu files. The changes in the ppu are only at the end of the entries and doesn't influence the start of the entries that contain the name and location. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetPropValue and enumerated types (Bug #4738 follow-up)
Variants are not required for this. Variants are for (excuse me the term) lazy coders... I assure you that implementing variants is not for lazy coders. ;) Joost. ps: not that you don't know that ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006 10:58:46 +0200 (CEST) Peter Vreman [EMAIL PROTECTED] wrote: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. This is incorrect, the generic .ppu format didn't change for the last several years. The code needed to parse ppu's and retrieve symbol info is also stable for the last years. See how good an old ppudump works on current ppu files. The changes in the ppu are only at the end of the entries and doesn't influence the start of the entries that contain the name and location. Great. Then I will take a look. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: GetPropValue and enumerated types (Bug #4738 follow-up)
Is there any way to add extra notes to the original bug report, otherwise whoever looks at that bug report will never know about this post and the easier example? Graeme. On 17/05/06, Graeme Geldenhuys [EMAIL PROTECTED] wrote: This is a follow-up on Bug #4738. I did more testing and have a clearer idea of why it throws an EVariantError exception. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] make install into a cross-compiled unit hierarchy.
I have a problem installing a third-party package using the fpcmake build system. I built a cross-compiler for WinCE including a complete RTL for arm-wince. I now want to install a third-party package into an arm-wince unit hierarchy on a WindowsXP system. Make is assuming that you need to use a fpcmake in the arm-wince directory instead of using fpcmake in the i386-win32 version. This is causing make install to fail. === W:\Source\Indy\Indy10FPC\Libmake install INSTALL_PREFIX=c:\lazarus\pp CPU_TARGE T=arm OS_TARGET=wince PP=ppcrossarm.exe make -C System all make[1]: Entering directory `W:/Source/Indy/Indy10FPC/Lib/System' make[1]: Leaving directory `W:/Source/Indy/Indy10FPC/Lib/System' make -C Core all make[1]: Entering directory `W:/Source/Indy/Indy10FPC/Lib/Core' make[1]: Leaving directory `W:/Source/Indy/Indy10FPC/Lib/Core' make -C Protocols all make[1]: Entering directory `W:/Source/Indy/Indy10FPC/Lib/Protocols' make[1]: Leaving directory `W:/Source/Indy/Indy10FPC/Lib/Protocols' make -C System install make[1]: Entering directory `W:/Source/Indy/Indy10FPC/Lib/System' c:/lazarus/pp/bin/arm-wince/fpcmake.exe -p -Tarm-wince Makefile.fpc process_begin: CreateProcess(c:\lazarus\pp\bin\arm-wince\fpcmake.exe, c:/lazarus /pp/bin/arm-wince/fpcmake.exe -p -Tarm-wince Makefile.fpc, ...) failed. make (e=193): Error 193make[1]: *** [fpc_install] Error 193 make[1]: Leaving directory `W:/Source/Indy/Indy10FPC/Lib/System' make: *** [System_install] Error 2 === Does anyone have any ideas for installing the third-party units in the arm-wince unit hierarchy without using an arm-wince version of fpcmake (which probably would not work on a Win32 system). Thanks. -- Support the anti-Spam amendment - Join at http://www.cauce.org/ J. Peter Mugaas, [EMAIL PROTECTED] on 5/17/2006 http://wvnvm.wvnet.edu/~oma00215/ ICQ Number: 14297043 Finger for PGP Key ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
The SysUtils unit misses some performance tweaks that the Dos unit has. Especially for the FindFirst/FindNext part. But this has low prio for the current developpers so it hasn't been analysed and fixed yet. What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations it would probably fix some problems immediately just by upgrading to string[1000] or even string[500]. I wondered why Borland/FPC didnt' implement a 2 byte length storage short string in addition to the 1 byte length storage short string.. maybe just haven't gotten around to it? Maybe there are other reasons? I think it is a good idea to have a really short string which has a maximum element count of 255, and to also have another larger shortstring which can go past 500 if you want it to. You'd rarely use 60,000 you'd mainly use figures within the 255-2000 range. This would keep speed up without affecting way we think much - they are still short strings, just longer ones. You'd still have the option of using a 255 shortstring. Many changes would be needed if you turned items into an ansistring or a list of small 255 strings - but if all you had to do was upgrade the string to string[1000] it may serve the compiler well for 10 years until people start having hard drives with REALLY long paths that combine to exceed 1000 - then maybe you upgrade to 1500, or start separating the strings into a list of strings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations it would probably fix some problems immediately just by upgrading to string[1000] or even string[500]. There is the basis of a longstring type in the compiler which does that more or less, but it was never fully implemented, because nobody cares/cared about it. And you'd still have to convert these longstrings to ansistrings and back every time you interface with sysutils, which would introduce extra overhead. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
Jonas Maebe wrote: On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations it would probably fix some problems immediately just by upgrading to string[1000] or even string[500]. There is the basis of a longstring type in the compiler which does that more or less, but it was never fully implemented, because nobody cares/cared about it. And you'd still have to convert these longstrings to ansistrings and back every time you interface with sysutils, which would introduce extra overhead. IMHO, longstring are wasteful for memory, having a fixed length string of 1000 for paths, which on my computer paths are less 100 chars. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations it would probably fix some problems immediately just by upgrading to string[1000] or even string[500]. There is the basis of a longstring type in the compiler which does that more or less, but it was never fully implemented, because nobody cares/cared about it. And you'd still have to convert these longstrings to ansistrings and back every time you interface with sysutils, which would introduce extra overhead. IMHO, longstring are wasteful for memory, having a fixed length string of 1000 for paths, which on my computer paths are less 100 chars. My paths are less than 100 chars. That is not the problem. Otherwise I wouldn't be noticing the bugs I've noticed for the last few years. I've never had a path beyond about 50 characters. The problem seems to be that several OPTIONS and PATHS at some point get combined into one short string at the end of the funnel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
On 17 mei 2006, at 20:19, L505 wrote: We wouldn't have to use sysutils yet.. we could make a custom Dos unit which used longstrings instead of short strings, but keep the old Dos unit for compatibility.. This still means that someone has to finish and test longstring support in the compiler, and create this longstring Dos unit for all platforms. That's more work than it may seem, and partly wasteful since Dos is only a legacy compatibility unit. In fact, not all the shortstrings would have to be changed to long strings. Just some path related ones. As I've said already many times in this thread: of course only path- related stuff has to be changed in the compiler. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
We wouldn't have to use sysutils yet.. we could make a custom Dos unit which used longstrings instead of short strings, but keep the old Dos unit for compatibility.. This still means that someone has to finish and test longstring support in the compiler, and create this longstring Dos unit for all platforms. That's more work than it may seem, and partly wasteful since Dos is only a legacy compatibility unit. In fact, not all the shortstrings would have to be changed to long strings. Just some path related ones. As I've said already many times in this thread: of course only path- related stuff has to be changed in the compiler. I'm happy with current compiler because all I have to do is change several of my paths to a bit of a shorter path - it's not a big deal if you know this is an issue that you have to deal with. So now that the bug is known, I could live with it for really another 10 years. The important part is knowing this bug so I can work around it - if I hadn't figured this out I would have blamed all my problems on myself. Maybe it was GNU's fault, or someone elses.. but now I know what causes it. Longstring is not a feature that needs to be implemented this minute - just like templates/generics don't really need to be implemented this minute.. it's just a cool feature that has some advantages. What I wanted to clarify was that a longstring is not utter useless and does have some advantages, unless my reasoning is flawed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
Op Wed, 17 May 2006, schreef L505: On 17 mei 2006, at 19:59, L505 wrote: What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations it would probably fix some problems immediately just by upgrading to string[1000] or even string[500]. There is the basis of a longstring type in the compiler which does that more or less, but it was never fully implemented, because nobody cares/cared about it. And you'd still have to convert these longstrings to ansistrings and back every time you interface with sysutils, which would introduce extra overhead. IMHO, longstring are wasteful for memory, having a fixed length string of 1000 for paths, which on my computer paths are less 100 chars. My paths are less than 100 chars. That is not the problem. Otherwise I wouldn't be noticing the bugs I've noticed for the last few years. I've never had a path beyond about 50 characters. The problem seems to be that several OPTIONS and PATHS at some point get combined into one short string at the end of the funnel. Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. For some operating system you could implement a dos.exec which accepts an array of shortstrings, which could solve a lot of length problems. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] dominant short strings in compiler source
I'm happy with current compiler because all I have to do is change several of my paths to a bit of a shorter path - it's not a big deal if you know this is an issue that you have to deal with. So now that the bug is known, I could live with it for really another 10 years. The important part is knowing this bug so I can work around it - if I hadn't figured this out I would have blamed all my problems on myself. yep silent string truncation was not one of borlands smarter ideas. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] dominant short strings in compiler source
Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with shortstrings? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
an issue that you have to deal with. So now that the bug is known, I could live with it for really another 10 years. The important part is knowing this bug so I can work around it - if I hadn't figured this out I would have blamed all my problems on myself. yep silent string truncation was not one of borlands smarter ideas. Having to check and guard each and every string operation is also not really productive. KR tried that :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] dominant short strings in compiler source
Op Wed, 17 May 2006, schreef peter green: Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with shortstrings? Under Dos: Yes, the operating system didn't allow more. But remeber, filenames were in 8:3 format, so 128 bytes was enough for a directory tree of 10 levels deep. Even today, few people use directory trees that deep. Considering the 640k limit, the 128 bytes reserved in the PSP for the command line wasn't a that stupid tradeoff. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
Well, dos.exec of course requires the entire command line as a shortstring. This is no problem for Dos because Dos has a maximum path length of 128 chars. so with 2 max length paths plus some options in the command line your screwed with shortstrings? Could happen, but also it might require a dynamic array of shortstrings which then might end up being slower than just one longstring using shortstring + shortstring + shortstring concatenation into a longstring (instead of a dynamic array of shortstrings). But Daniel's array method would probably be the easiest thing to implement right now, since we don't have longstrings available at this time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
