[fpc-devel]Format() incompatibility with Delphi

[Michalis Kamburelis]

Hi

What should
  Format('%d %d %0:d %d', [0, 1, 2, 3])
return ? Delphi help is clear about that : Setting the index specifier 
affects all subsequent formatting, so it should return '0 1 0 1' (and 
it does when compiled with Delphi).

FPC help is not clear about that. And unfortunately it turns out that 
Format() implemented in FPC's SysUtils does not behave like in Delphi: 
Format() call mentioned above returns '0 1 0 2' when compiled with FPC 
(so it is like Setting the index specifier _does not_ affect subsequent 
formatting).

To fix this (i.e., make it Delphi-compatible) you have to change in file 
sysstr.inc in function Checkarg at line 862 (as of latest FPC version 
from CVS) from
  if Index=-1 then
begin
DoArg:=Argpos;
inc(ArgPos);
end
  else
DoArg:=Index;
to
  if Index=-1 then
DoArg:=Argpos else
DoArg:=Index;
  ArgPos:=DoArg+1;

This fix may broke existing code (that depends on the way how Format() 
in FPC works) but I guess that such code may be considered buggy anyway 
since FPC documentation was not clear about whether setting index 
specifier affects subsequent formatting or not. Besides, if you want to 
make Format() fully Delphi-compatible, there is no other way to fix 
this, you have to change it's present behaviour.

BTW, I would also advice adding some notes about that to the FPC 
SysUtils.Format documentation.

Regards,
Michalis Kamburelis [EMAIL PROTECTED]
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]TThread hara-kiri

[Michalis Kamburelis]

Pedro Lopez-Cabanillas wrote:
Hi,

Does the example program threads.pp (doc/examples/fcl/threads.pp) work for 
anybody under Linux?

It aborts for me as soon as the first thread is created, printing Killed.

Regards,
Pedro
When I compile it with 1.9.1 I get the same effect - program is 
immediately killed (the message Killed is printed by bash, it 
indicates that the program was killed by SIGKILL). When I compile it 
with 1.0.10 (with fcl distributed with 1.0.10) things are even worse.

This is a question to FPC developers - is this example supposed to work 
(i.e. is TThread class now officially implemented in fcl or is it just a 
stub that may work but don't have to) ?

Michalis

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel]Small bugfix for SysUtils.CompareMem

[Michalis Kamburelis]

Hi

I just found a bug in CompareMem function in SysUtils.

CompareMem(p1, p2, 0) (third argument = zero) should always return true 
(and ignore values p1 and p2). But, currently, it does not. CompareMem 
is implemented like

function CompareMem(P1, P2: Pointer; Length: cardinal): Boolean;
var
  i: cardinal;
begin
  for i := 0 to Length - 1 do
  begin
...
  end;
  Result := True;
end;
so it _looks_ like it's good - when Length=0 then we have
  for i:=0 to -1 do ...
so this loop should never be executed even once. Right ? Wrong. Wrong 
because Length and i are Cardinals (unsigned) and so calculating 
Length-1 gives some extremely big positive value (namely, it's 
High(Length) = $) (well, this bug would be catched at runtime by 
compiling RTL with runtime checks for overflow... but RTL is usually 
compiled without these checks).

So CompareMem(..., ..., 0) produces always false or EAccessViolation.

There are many ways to fix this - most elegant for me is to add a line
  if Length = 0 then Exit(true);
at the beginning of this function.
Thanks,
Michalis Kamburelis
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]fpc and ppc386

[Michalis Kamburelis]

OK, I just figured out what was the cause of this problem.

In SysUtils.ExecuteProcess you were wrapping ppcbin compiler filename 
(like '/usr/local/ppc386') inside quotes (to make it something like 
'/usr/local/ppc386') but you were not stripping those quotes anywhere 
before passing this to execve (i.e. FpExecVE). So it shouldn't work 
(since execve should not tolerate any additional quotes in filename, 
even if it does on some UNIXes).

Patch to rtl/unix/unixutil.pp attached with (too many?) comments, it 
modifies StringToPPChar behavior so that it strips those quotes.

Regards,
Michalis
Index: unixutil.pp
===
RCS file: /FPC/CVS/fpc/rtl/unix/unixutil.pp,v
retrieving revision 1.3
diff -c -r1.3 unixutil.pp
*** unixutil.pp 3 Nov 2003 09:42:28 -   1.3
--- unixutil.pp 12 Feb 2004 18:25:43 -
***
*** 76,81 
--- 76,95 
Create a PPChar to structure of pchars which are the arguments specified
in the string S. Especially usefull for creating an ArgV for Exec-calls
Note that the string S is destroyed by this call.
+   
+   Quotes () are stripped from arguments.
+   WARNING: This function strips quotes from arguments but it does NOT
+   parse S properly, e.g. when S = 'foo bar' it will be (incorrectly) 
+   splitted to TWO arguments: 'foo' and 'bar'. To solve this elegantly
+   one should parse S correctly (taking care NOT to break arguments at
+   spaces between quotes) and one should specify how quotes that should
+   make their way into final arguments should be safely encoded in S 
+   (e.g. as '\' ? How do we encode '\' then, as '\\' ?). 
+   
+   I guess it's not so important because functions StringToPPChar are needed 
+   (only?) for deprecated functions Execl and such in module Unix.
+   That's why FpExecL are better then their counterparts without Fp:
+   they don't have this problem.
  }
  
  begin
***
*** 99,104 
--- 113,121 
nr  : longint;
Buf : ^char;
p   : ppchar;
+   
+   TempP, Result:ppchar;
+   Len:Integer;
  
  begin
buf:=s;
***
*** 112,118 
inc(buf);
 end;
getmem(p,nr*4);
!   StringToPPChar:=p;
if p=nil then
 begin
   {$ifdef xunix}
--- 129,136 
inc(buf);
 end;
getmem(p,nr*4);
!   Result:=p;
!   StringToPPChar:=Result;
if p=nil then
 begin
   {$ifdef xunix}
***
*** 134,139 
--- 152,170 
   while not (buf^ in [' ',#0,#9,#10]) do
inc(buf);
 end;
+ 
+  { strip quotes () around arguments }
+  TempP:=Result;
+  while TempP^  nil do
+  begin   
+   Len := StrLen(TempP^);  
+   if (Len1) and (TempP^[0] = '') and (TempP^[Len-1] = '') then
+   begin
+TempP^[Len-1] := #0; { delete last  }
+Inc(TempP^); { delete first  }
+   end;
+   Inc(TempP);
+  end;
  end;
  
  

[fpc-devel]/FPC/CVS/fpc/rtl/morphos : Permission denied

[Michalis Kamburelis]

I see (via viewcvs) that new directory rtl/morphos (with system.pp) was 
created just yesterday. But cvs client doesn't allow me to update it, 
fails at rtl/morphos with

  cvs server: failed to create lock directory for 
`/FPC/CVS/fpc/rtl/morphos' (/FPC/CVS/fpc/rtl/morphos/#cvs.lock): 
Permission denied
  cvs server: failed to obtain dir lock in repository 
`/FPC/CVS/fpc/rtl/morphos'

Is there some problem on freepascal.org cvs repository with correct 
permissions ?

Regards,
Michalis
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel]Mode field for TSearchRec under UNIX

[Michalis Kamburelis]

Hi

Kylix adds field Mode to TSearchRec type under Linux. This field comes 
directly from UNIX stat structure (st_mode field). It is useful when you 
already have TSearchRec describing some file and you want to check the 
exact type of that file, e.g. is it a symbolic link ? is it a device 
?. It would be silly to call lstat with full filename, when all needed 
information was already available when constructing TSearchRec for this 
file.

I am not exactly a Kylix enthusiast but this Mode field is something 
that I consider useful. I guess that you will agree with this since you 
already added OS-specific fields to TSearchRec for Windows and Netware.

So I made a small patches to rtl/objpas/sysutils/filutilh.inc and 
rtl/unix/sysutils.pp to implement this. Well, that wasn't much work; 
all information was already available. I'm attaching those patches as 
filutilh.inc.patch and sysutils.pp.patch. I'm also attaching very 
short demo program, mode_field_demo.pas, to show that it really works.

Note: it would be more elegant to wrap Mode field inside something 
like FindData: TUNIXFindData. This would break Kylix compatibility, 
but I don't know is there a real need to be compatible with Kylix. 
Personally, I want something like Mode field to be included in 
TSearchRec not because of Kylix compatiblity but because it's just useful.

BTW: Are you going to apply my Libc fixes (from letter A few fixes for 
Libc unit) ? If you want I can provide a simple test program (to show 
that those fixes are really needed and that they are really fixing the 
problems) and/or ready-to-apply patches.

Regards,
Michalis
Index: filutilh.inc
===
RCS file: /FPC/CVS/fpc/rtl/objpas/sysutils/filutilh.inc,v
retrieving revision 1.2
diff -u -u -r1.2 filutilh.inc
--- filutilh.inc8 Feb 2004 14:50:51 -   1.2
+++ filutilh.inc24 Feb 2004 17:59:07 -
@@ -28,6 +28,9 @@
 {$ifdef netware}
 FindData : TNetwareFindData;
 {$endif}
+{$ifdef UNIX}
+Mode : TMode;
+{$endif}
   end;
 
 Const
Index: sysutils.pp
===
RCS file: /FPC/CVS/fpc/rtl/unix/sysutils.pp,v
retrieving revision 1.36
diff -u -u -r1.36 sysutils.pp
--- sysutils.pp 13 Feb 2004 10:50:23 -  1.36
+++ sysutils.pp 24 Feb 2004 17:58:22 -
@@ -25,7 +25,7 @@
 {$DEFINE HAS_OSERROR}
 
 uses
-  Unix,errors,sysconst;
+  Baseunix,Unix,errors,sysconst;
 
 { Include platform independent interface part }
 {$i sysutilh.inc}
@@ -33,7 +33,7 @@
 
 implementation
 
-Uses UnixUtil,Baseunix;
+Uses UnixUtil;
 
 {$Define OS_FILEISREADONLY} // Specific implementation for Unix.
 
@@ -197,7 +197,7 @@
   If Result then
 begin
 GlobSearchRec^.GlobHandle:=P^.Next;
-Result:=Fpstat(GlobSearchRec^.Path+StrPas(p^.name),SInfo)=0;
+Result:=FpLStat(GlobSearchRec^.Path+StrPas(p^.name), @SInfo)=0;
 If Result then
   begin
   Info.Attr:=LinuxToWinAttr(p^.name,SInfo);
@@ -210,6 +210,7 @@
Name:=strpas(p^.name);
Time:=Sinfo.st_mtime;
Size:=Sinfo.st_Size;
+   Mode:=Sinfo.st_mode;
end;
   end;
 P^.Next:=Nil;
uses BaseUnix, Unix, SysUtils;

var 
  SR:TSearchRec;
  FindResult:Integer;
begin
 FindResult:=FindFirst('/*', faAnyFile, SR);
 try
  while FindResult=0 do
  begin 
   Writeln(SR.Name:20, ' symlink ? ', FpS_ISLNK(SR.Mode));
   FindResult:=FindNext(SR);  
  end;
 finally FindClose(SR) end;
end.

[fpc-devel]UnixUtil.FNMatch bug

[Michalis Kamburelis]

Hi

I found some bugs in UnixUtil.FNMatch function. In short, patterns like 
'*~' matched anything (instead of matching only filenames ending with 
'~'). I'm attaching patch unixutil.patch that fixes these issues. I'm 
also attaching a test program, fnmatch_test.pas, so you can see that 
these bugs really occur and this patch really fixes them. You may want 
to include this test program somewhere in FPC tests/ dir (tests/test/ 
?). This test program is heavily commented, hopefully it explains 
exactly what bugs were present in FNMatch implementation and why it's OK 
now.

Note to FPC 1.0.10 users: you can use this patch to fix these issues for 
FPC 1.0.10 too. You have to apply this to rtl/unix/linux.pp file. Oh, 
and the test program is usable under FPC 1.0.10 too.

Regards,
Michalis
{ Some tests of UnixUtil.FNMatch function
  (or Linux.FNMatch function under FPC 1.0.10). }

uses 
  SysUtils, {$ifdef VER1_0} Linux {$else} UnixUtil {$endif}, Libc;

{ Tests results of UnixUtil.FNMatch versus given GoodResult
  and result of Libc.FNMatch. They all should be equal. 
  (I'm using Libc.FNMatch to
1) make sure that GoodResult is really correct
2) show that UnixUtil.FNMatch behaves really the same way as
   FNMatch from Libc (actually, Libc.FNMatch should get 
   FNM_NOESCAPE as the 3rd arg to be fully identical)
   (i.e., it behaves the same after applying my fixes to 
   UnixUtil.FNMatch...)
3) test Libc, while we're at it :-)
  )
}
procedure Check(const Pattern, Name:string; GoodResult:boolean);
var UnixUtilResult, LibcResult:boolean;
begin
 UnixUtilResult:=
   {$ifdef VER1_0} Linux {$else} UnixUtil {$endif} .FNMatch(Pattern, Name);
 LibcResult:=Libc.FNMatch(PChar(Pattern), PChar(Name), 0) = 0;

 { We have 3 results. All should be equal. }
 if (UnixUtilResultLibcResult) or (LibcResultGoodResult) then
  Writeln(Format('%s with %s incorrect: %6s %6s %6s',
[ Pattern, Name,
  BoolToStr(UnixUtilResult), BoolToStr(LibcResult), BoolToStr(GoodResult) ]));
end;

begin
 { Those tests fail with original FNMatch code, because FNMatch 
   allowed '*x' (for any 'x') to match anything (ending with 'x' or not, 
   zero length or not). }
 Check('*~', 'foo', false);
 Check('*b', 'foo', false);
 Check('*?', '', false);
 Check('???*o', 'foo', false);
 Check('*???*o', 'foo', false);

 { When first error is solved, we can see other problem
   (that was hidden by previous bug):
   When the '?' in Pattern matches last char of Name,
   some problems arise. That's because of original FNMatch code
 '?' : begin
 inc(j);
 Found:=(j=LenName);
   end;
   Nonsense ?
   This should check FIRST if (j=LenName). 
   If not, if should terminate whole DoFNMatch with false, 
   not only the loop labeled
   'find the next character in pattern, different of ? and *'.
   And in that loop, variable i should get a chance to be  LenPat. 
   
   Tests below ensure that these additional fixes are also applied. 
   I.e. these tests worked before my fixes were applied AND they
   work after my fixes are applied. But they we're causing trouble
   when I was working on this and my fixes we're applied only partially. }
 Check('*?', '?', true);
 Check('*?', 'a', true);
 
 { Some additional tests, they worked before my fix and they work
   after my fix. Just to be sure that everything is OK now. }
 Check('*o', 'foo', true);
 Check('*.~', 'foo', false);
 Check('*.b', 'foo', false);
 Check('*.o', 'foo', false);
 Check('*??*o', 'foo', true);
 Check('?o', 'foo', false);
 Check('??o', 'foo', true);
 Check('?o?', 'foo', true);
 Check('o??', 'foo', false);
 Check('*', 'foo', true);
end.Index: unixutil.pp
===
RCS file: /FPC/CVS/fpc/rtl/unix/unixutil.pp,v
retrieving revision 1.5
diff -u -r1.5 unixutil.pp
--- unixutil.pp 15 Mar 2004 20:43:07 -  1.5
+++ unixutil.pp 6 May 2004 01:54:31 -
@@ -227,19 +227,25 @@
   '?' : Found:=(j=LenName);
   '*' : Begin
 {find the next character in pattern, different of ? and *}
-  while Found and (iLenPat) do
+  while Found do
 begin
 inc(i);
+if iLenPat then Break;
 case Pattern[i] of
   '*' : ;
   '?' : begin
+  if jLenName then 
+  begin
+   DoFNMatch:=false;
+   Exit;
+  end;
   inc(j);
-  Found:=(j=LenName);
 end;
 else
   Found:=false;
 end;
end;
+  Assert((iLenPat) or ( (Pattern[i]'*') and (Pattern[i]'?') ));
 {Now, find in name the character which i points to, if the * or ?
  wasn't the last character in the pattern, else, use up all the
  chars in 

[fpc-devel]UnixUtil.FNMatch bug - new patch version

[Michalis Kamburelis]

Hi again,

Previous patch still missed to correct some bugs (those we're still bugs 
in original FNMatch code, not new bugs introduced by my fixes, in case 
you might ask...).

  '*o' should not match 'blah.ow' and
  '*o' should not match 'fox'
Anyway, I'm attaching new version of the patch (unixutil.patch) and new 
version of the test program (fnmatch_test.pas). Just forget about 
previous ones.

BTW, I also corrected indentation around that couple lines of code that 
I am fixing. I hope you don't mind. Original indentation was totally 
messed up and inconsistent; I just couldn't resist, so I corrected it.
I hope this will make reading this code easier.

--
Michalis
{ Some tests of UnixUtil.FNMatch function
  (or Linux.FNMatch function under FPC 1.0.10). }
  
uses 
  SysUtils, {$ifdef VER1_0} Linux {$else} UnixUtil {$endif}, Libc;
  
{ Tests results of UnixUtil.FNMatch versus given GoodResult
  and result of Libc.FNMatch. They all should be equal. 
  (I'm using Libc.FNMatch to
1) make sure that GoodResult is really correct
2) show that UnixUtil.FNMatch behaves really the same way as
   FNMatch from Libc (actually, Libc.FNMatch should get 
   FNM_NOESCAPE as the 3rd arg to be fully identical)
   (i.e., it behaves the same after applying my fixes to 
   UnixUtil.FNMatch...)
3) test Libc, while we're at it :-)
  )
}
procedure Check(const Pattern, Name:string; GoodResult:boolean);
var UnixUtilResult, LibcResult:boolean;
begin
 UnixUtilResult:= 
   {$ifdef VER1_0} Linux {$else} UnixUtil {$endif} .FNMatch(Pattern, Name);
 LibcResult:=Libc.FNMatch(PChar(Pattern), PChar(Name), 0) = 0;

 { We have 3 results. All should be equal. }
 if (UnixUtilResultLibcResult) or (LibcResultGoodResult) then
  Writeln(Format('%s with %s incorrect: %6s %6s %6s',
[ Pattern, Name,
  BoolToStr(UnixUtilResult), BoolToStr(LibcResult), BoolToStr(GoodResult) ]));
end;

begin
 { Those tests fail with original FNMatch code, because FNMatch 
   allowed '*x' (for any 'x') to match anything (ending with 'x' or not, 
   zero length or not). }
 Check('*~', 'foo', false);
 Check('*b', 'foo', false);
 Check('*?', '', false);
 Check('???*o', 'foo', false);
 Check('*???*o', 'foo', false);

 (*This test fails with original FNMatch code, because after line
 'inc(j);{We didn't find one, need to look further}'
   found is still assumed to be true (while it should be false) *)
 Check('*o', 'blah.ow', false);
 
 { This fails with original FNMatch code because subsequent tries
   to match char right after '*' (i.e., 'o' in this case) actually
   can miss that 'x'  'o' when 'x' is the last char of Name. }
 Check('*o', 'fox', false);

 { When first error is solved, we can see other problem
   (that was hidden by previous bug):
   When the '?' in Pattern matches last char of Name,
   some problems arise. That's because of original FNMatch code
 '?' : begin
 inc(j);
 Found:=(j=LenName);
   end;
   Nonsense ?
   This should check FIRST if (j=LenName). 
   If not, if should terminate whole DoFNMatch with false, 
   not only the loop labeled
   'find the next character in pattern, different of ? and *'.
   And in that loop, variable i should get a chance to be  LenPat. 
   
   Tests below ensure that these additional fixes are also applied. 
   I.e. these tests worked before my fixes were applied AND they
   work after my fixes are applied. But they we're causing trouble
   when I was working on this and my fixes we're applied only partially. }
 Check('*?', '?', true);
 Check('*?', 'a', true);
 
 { Some additional tests, they worked before my fix and they work
   after my fix. Just to be sure that everything is OK now. }
 Check('*o', 'foo', true);
 Check('*.~', 'foo', false);
 Check('*.b', 'foo', false);
 Check('*.o', 'foo', false);
 Check('*??*o', 'foo', true);
 Check('?o', 'foo', false);
 Check('??o', 'foo', true);
 Check('?o?', 'foo', true);
 Check('o??', 'foo', false);
 Check('*', 'foo', true);
end.Index: unixutil.pp
===
RCS file: /FPC/CVS/fpc/rtl/unix/unixutil.pp,v
retrieving revision 1.5
diff -u -u -r1.5 unixutil.pp
--- unixutil.pp 15 Mar 2004 20:43:07 -  1.5
+++ unixutil.pp 6 May 2004 05:39:55 -
@@ -227,44 +227,56 @@
   '?' : Found:=(j=LenName);
   '*' : Begin
 {find the next character in pattern, different of ? and *}
-  while Found and (iLenPat) do
+  while Found do
 begin
 inc(i);
+if iLenPat then Break;
 case Pattern[i] of
   '*' : ;
   '?' : begin
+  if jLenName then begin DoFNMatch:=false; Exit; end;
   inc(j);
-  Found:=(j=LenName);
 end;
 else
   Found:=false;
 end;
end;
+  Assert((iLenPat) 

[fpc-devel] Video.CursorX/Y 1-based under UNIX

[Michalis Kamburelis]

Hi.
I'm just playing with unit Video and I found some strange thing. It 
looks like a bug in my opinion, but it's so obviously implemented in 
Video unit that I fear that it's some feature :

Under UNIXes CursorX / CursorY are 1-based. While SetCursorPos takes 
0-based parameters on all OSes, and CursorX / CursorY are 0-based on Win32.

Although docs never explicitly say that CursorX and CursorY should be 
0-based, I think that they should be, because
- SetCursorPos takes 0-based params, so obviously CursorX and CursorY 
should follow the same convention,
- under Win32 CursorX and CursorY are 0-based, and rtl/win32/video.pp is 
clearly implemented to keep this assumption.

What's strange is that looking at sources rtl/unix/video.pp, it looks 
like someone intended that behavior, i.e. that CursorX and CursorY are 
1-based.

--
Michalis
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TList slowness in classes

[Michalis Kamburelis]

Hi,
I tested your code and found that indeed version in ucopylist is 
slightly faster (by about 9.5 / 7 =~ 1.357). Two things:

1. Speedup is only 1.357x, not 3x, like you said. Are you sure that 
you're getting 3x speedup ? On what OS and with what FPC version are you 
testing this ? I was doing tests with Linux/i386 with FPC 1.9.4 and 
1.9.5 (from CVS 2004-12-20).

2. Still, speedup 1.357x may be significant in some cases so I 
investigated what's the cause:

After many tests I found that this slight speedup is caused by the fact 
that in ucopylist you declared string constants SListIndexError, 
SListCapacityError and SListCountError as normal constants while with 
original Classes unit these constants are taken from RTLConst unit that 
defines them as resourcestrings.

Using resourcestrings in RTL is a must, since this allows to translate 
error messages without modifying unit Classes sources.

However in this case exceptions are not raised, so resourcestrings are 
not actually used. But it looks that any procedure that uses some 
resourcestring in implementation is doomed to be slower than the similar 
procedure that instead uses normal string consts, *even if this 
procedure doesn't actually access the string at runtime*. It seems that 
if some procedure uses resourcestring then upon entry it does some 
lengthy initialization of this resourcestring, even if it will not 
actually make use of that resourcestring.

I'm attaching a simple demo program that shows this. When compiled like
  fpc -OG -O2 -Op2 demo_resourcestring_slow.pas
(to get maximum optimizations) sample output of it is
  Time of Foo_Normal: 16
  Time of Foo_ResourceString: 106
So time difference is really noticeable. Question goes to FPC 
developers, maybe such cases with using resourcestrings can be speed up ?

Regards,
--
Michalis
Ales Katona wrote:
I've read a complaint about TList being slow so I decided to give it a 
test.
Quite frankly the test showed this is truth, but I couldn't find out why.
I found out that if I copy the TList from classes as-is into my unit 
and use this
copy, it is about 3x faster in certain conditions. I have no idea why 
this is so but
I think there's something wrong...

I posted my test at http://members.chello.sk/ales/testlist.zip
Just download, unzip and compile:
you'll get swap time and access time for the original TList
uncomment {$DEFINE USEMYLIST} to get the times for my copy of TList
The copy there is unchanged.
Ales Katona
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
{$mode objfpc}{$H+}

uses
  {BaseUnix, Unix needed only to implement Clock} BaseUnix, Unix,
  SysUtils;

function Clock: Int64;
var Dummy: tms;
begin
 Clock := FpTimes(Dummy);
end;

const
  SNormal= 'blah blah blah blah blah blah blah blah blah blah';
resourcestring
  SResString = 'blah blah blah blah blah blah blah blah blah blah';

{ Foo_Normal and Foo_ResourceString do the same thing,
  but Foo_Normal uses normal string constant while
  Foo_ResourceString uses resourcestring. }

procedure Foo_Normal(i: Integer);
begin
 if i = -1 then raise Exception.Create(SNormal);
end;

procedure Foo_ResourceString(i: Integer);
begin
 if i = -1 then raise Exception.Create(SResString);
end;


{ Note that when I call Foo_Normal and Foo_ResourceString
  i is always = 0 so Exception is never actually raised.
  So string constants SNormal and SResString are not really used. }

const
  TestCount = 1000;
var
  i: Integer;
  Start: Int64;
begin
 Start := Clock;
 for i := 0 to TestCount do Foo_Normal(i);
 Writeln('Time of Foo_Normal: ', Clock - Start);

 Start := Clock;
 for i := 0 to TestCount do Foo_ResourceString(i);
 Writeln('Time of Foo_ResourceString: ', Clock - Start);
end.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TList slowness in classes

[Michalis Kamburelis]

Peter Vreman wrote:
This is because there is an extra (implicit) Try/Finally block.
Thank you and Peter for answers. This way I was able to see how
try...finally section looks in assembler :) Anyway, I understand that
the answer is can't be speed up. OK, I can live with that.

That is not correct. For your own code you can disable the implicit
exception frame with a directive:
{$IMPLICITEXCEPTIONS OFF}
Indeed when I put {$IMPLICITEXCEPTIONS OFF} at the beginning of 
demo_resourcestring_slow.pas, Foo_Normal and Foo_ResourceString work 
equally fast. Nice, that's a solution in cases when I know that some 
code will not exit with exception.

But I risk that if I ever call Foo_ResourceString(-1) that will raise 
exception from Foo_ResourceString, I can get memory leaks, right ? Or 
can I predict in certain cases that using {$IMPLICITEXCEPTIONS OFF} is 
safe (no memory leaks) even when procedure will raise some exceptions ? 
If the answer is yes, then maybe it's safe to compile parts of FPC 
sources in lists.inc (like TList.Get) inside {$IMPLICITEXCEPTIONS OFF} ?

--
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TList slowness in classes

[Michalis Kamburelis]

Vincent Snijders wrote:
Michalis Kamburelis wrote:
I felt that results of this discussion are so important that I created 
a page in FPC wiki about it:

http://www.freepascal.org/wiki/index.php/Avoiding_implicit_try_finally_section 

There's an URL to mail archives of this discussion, and a small demo 
program that shows trick proposed by Mattias how to avoid this 
implicit try...finally block.

(I also created Writing_efficient_code page, that links between FPC 
page and Avoiding_implicit_try_finally_section page).

Michalis.
Did you try this with today compiler?
I think Peter Vreman turned of implicit try finally for resource strings.
Vincent.
I just updated from CVS and rebuild FPC, and indeed, timings of my test 
program are now
  Time of Foo_ResourceString:18
  Time of Foo_ResourceString_Faster: 16
So it's fixed in compiler. Great!

Are there any other cases where this issue may be significant ? If no, 
I'll mark this wiki page clearly as only for FPC earlier than 
2004-12-28 (to-be-removed when 2.0 comes in), else I will update it.

(Note: we can continue this talk on wiki page
http://www.freepascal.org/wiki/index.php/Talk:Avoiding_implicit_try_finally_section
already started by Vincent with that question)
Thanks!
--
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TList slowness in classes

[Michalis Kamburelis]

Vincent Snijders wrote:
Michalis Kamburelis wrote:
Are there any other cases where this issue may be significant ? If no, 
I'll mark this wiki page clearly as only for FPC earlier than 
2004-12-28 (to-be-removed when 2.0 comes in), else I will update it.

(Note: we can continue this talk on wiki page
http://www.freepascal.org/wiki/index.php/Talk:Avoiding_implicit_try_finally_section 

already started by Vincent with that question)
Thanks!

I haven't tested it, but I have this hunch.
Ansistrings (not constant) also require implicit try finally.
If you use ansi strings only in a seldom used if-branch in a procedure, 
you could extract the procedure too, just like you did for the resource 
string.

for example:
If (i0) then
  'do something but not with ansistrings
else
  writeln('Invalid value: '+IntToStr(i));
Regards,
Vincent.
I suspected that every type that needs to be initialized/finalized 
creates such try...finally block, but didn't have time to check. But I 
checked it now. OK, page in wiki is changed, and demo program there is 
changed.

--
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Changes to gtk 2 bindings

[Michalis Kamburelis]

Hi
I have a couple of corrections to gtk 2 bindings, gtk2forpascal. I also 
made gtkglext bindings that could be incorporated into gtk 2 bindings, 
if it feels appropriate (since, as far as I know, initial goal of 
gtk2forpascal was to include gtkglext bindings, but they were not 
implemented because interface of gtkglext library was changing rapidly).

Since gtk2forpascal bindings are now incorporated into FPC source tree, 
my question is: should I submit my patches/additions to gtk 2 bindings 
here, as patches versus fpc packages/extra/gtk2/ sources, or should I 
submit them to gtk2forpascal on sourceforge ? In other words, where does 
development of gtk2forpascal continue -- as part of FPC, or on 
gtk2forpascal sourceforge place ?

Regards,
Michalis.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changes to gtk 2 bindings

[Michalis Kamburelis]

Hi
So here they are. Initially I was making my changes versus gtk2forpascal 
from sourceforge, but now I made them versus FPC sources, since I can't 
connect to gtk2forpascal cvs on sourceforge. I also noticed that version 
from FPC tree already contains some of the fixes I was going to send... 
excellent.

I'm attaching patch to packages/extra/gtk2/, it fixes various small 
things: compiling gtk_demo, {$linklib c} and {$linklib pthread} needed 
under FreeBSD, using HasGTK2_2 symbol in gtk2.pas, correct name for 
identifier TGtkAccelGroupFindFunc, and four missing functions for 
GtkWindow (gtk_window_fullscreen/unfullscreen, 
gtk_window_set_keep_above/below).

Note that I added {$define GTK2_2} at the beginning of gtk2.pas -- I 
think that GTK = 2.2 is installed pretty everywhere where any GTK 2.x 
is installed. But this may be a matter of personal experience, so feel 
free to remove this bit if you think that's better.

And here you can find my gtkglext translation (12 KB):
http://www.camelot.homedns.org/~michalis/unofficial/gtkglext.tar.gz
I tested it (gtk 2 bindings with my patches and gtkglext) on Linux, 
FreeBSD (5.3) and Win32. In the gtkglext archive you will find 
subdirectory examples/, there is one simple test program using gtkglext, 
gears.pas. This is rewritten in Pascal version of gears.c from gtkglext 
examples. You can also look at the units and programs on my www page, 
they use gtk2 and gtkglext, though they are not very good example 
programs for teaching how to use gtkglext (since gtk code is there 
embedded in rather large unit).

Michalis.
Index: examples/gtk_demo/stock_browser.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/examples/gtk_demo/stock_browser.inc,v
retrieving revision 1.1
diff -u -u -r1.1 stock_browser.inc
--- examples/gtk_demo/stock_browser.inc 24 Jan 2005 21:58:04 -  1.1
+++ examples/gtk_demo/stock_browser.inc 1 Mar 2005 01:16:18 -
@@ -68,7 +68,7 @@
   stock_item_info_get_type := StockItemInfoType;
 end;
 
-function STOCK_ITEM_INFO_TYPE: GType; inline;
+function STOCK_ITEM_INFO_TYPE: GType;
 begin
   STOCK_ITEM_INFO_TYPE := stock_item_info_get_type;
 end;
Index: glib/glib2.pas
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/glib/glib2.pas,v
retrieving revision 1.3
diff -u -u -r1.3 glib2.pas
--- glib/glib2.pas  3 Feb 2005 21:59:45 -   1.3
+++ glib/glib2.pas  1 Mar 2005 01:16:27 -
@@ -61,6 +61,11 @@
   {$endif}
 {$endif}
 
+{$ifdef FREEBSD}
+  {$linklib c}
+  {$linklib pthread}
+{$endif}
+
 {$IFNDEF KYLIX}
   {$PACKRECORDS C}
 {$ELSE}
Index: gtk+/gtk/gtk2.pas
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtk2.pas,v
retrieving revision 1.2
diff -u -u -r1.2 gtk2.pas
--- gtk+/gtk/gtk2.pas   31 Jan 2005 14:08:25 -  1.2
+++ gtk+/gtk/gtk2.pas   1 Mar 2005 01:16:28 -
@@ -18,6 +18,8 @@
   }
 unit gtk2; // keep unit name lowercase for kylix
 
+{$define GTK2_2}
+
 {$H+}
 {$IFDEF FPC}
   {$mode objfpc}
@@ -28,15 +30,18 @@
 
 {$IFDEF GTK2_2}
 {$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
 {$ENDIF}
 
 {$IFDEF GTK2_4}
 {$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
 {$DEFINE HasGTK2_4}
 {$ENDIF}
 
 {$IFDEF GTK2_6}
 {$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
 {$DEFINE HasGTK2_4}
 {$DEFINE HasGTK2_6}
 {$ENDIF}
Index: gtk+/gtk/gtkaccelgroup.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtkaccelgroup.inc,v
retrieving revision 1.1
diff -u -u -r1.1 gtkaccelgroup.inc
--- gtk+/gtk/gtkaccelgroup.inc  24 Jan 2005 21:58:04 -  1.1
+++ gtk+/gtk/gtkaccelgroup.inc  1 Mar 2005 01:16:29 -
@@ -50,7 +50,8 @@
 accel_path_quark : TGQuark;
  end;
 
-  Tgtk_accel_group_find_func = function (key:PGtkAccelKey; closure:PGClosure; 
data:gpointer):gboolean;
+  Tgtk_accel_group_find_func = function (key:PGtkAccelKey; closure:PGClosure; 
data:gpointer):gboolean; cdecl;
+  TGtkAccelGroupFindFunc = Tgtk_accel_group_find_func;
 {$ENDIF read_interface_types}
 
 
//--
Index: gtk+/gtk/gtkwindow.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtkwindow.inc,v
retrieving revision 1.1
diff -u -u -r1.1 gtkwindow.inc
--- gtk+/gtk/gtkwindow.inc  24 Jan 2005 21:58:04 -  1.1
+++ gtk+/gtk/gtkwindow.inc  1 Mar 2005 01:16:35 -
@@ -233,6 +233,14 @@
 procedure gtk_window_unstick(window:PGtkWindow); cdecl; external gtklib;
 procedure gtk_window_maximize(window:PGtkWindow); cdecl; external gtklib;
 procedure gtk_window_unmaximize(window:PGtkWindow); cdecl; external gtklib;
+
+{$ifdef HasGTK2_2}
+procedure gtk_window_fullscreen(window: PGtkWindow); cdecl; external gtklib;
+procedure gtk_window_unfullscreen(window: PGtkWindow); cdecl; 

[fpc-devel] Interbase.TIBTransaction should publish some private things

[Michalis Kamburelis]

Hi
Looking at Interbase unit (fcl/db/interbase/interbase.pp), I see that 
TIBTransaction was probably meant to publish properties AccessMode, 
IsolationLevel, LockResolution and TableReservation. This would be 
definitely useful to users of this class. I'm attaching simple patch 
that does this.

Michalis.
Index: interbase.pp
===
RCS file: /FPC/CVS/fpc/fcl/db/interbase/interbase.pp,v
retrieving revision 1.15
diff -u -r1.15 interbase.pp
--- interbase.pp	14 Feb 2005 17:13:12 -	1.15
+++ interbase.pp	16 Mar 2005 11:30:30 -
@@ -175,6 +175,16 @@
 { Transaction must be assigned to some database session, for which purpose
   you must use this property}
 property Database : TIBDatabase read FDatabase write FDatabase;
+
+{ These four properties will be used in next StartTransaction calls }
+property AccessMode: TAccessMode
+  read FAccessMode write FAccessMode default amReadWrite;
+property IsolationLevel: TIsolationLevel
+  read FIsolationLevel write FIsolationLevel default ilReadCommitted;
+property LockResolution: TLockResolution
+  read FLockResolution write FLockResolution default lrWait;
+property TableReservation: TTableReservation
+  read FTableReservation write FTableReservation default trNone;
   end;
 
 { TIBQuery }
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Changing transaction properties specific to IB when using IBConnection

[Michalis Kamburelis]

Hi
I played with Sqldb and IBConnection units, and now I see the real 
benefit of them: there's only one dataset and one transaction class for 
all Firebird, PostgreSQL and MySQL bindings. Each specific database 
binding must only introduce new TSQLConnection descendant. It's great 
since it gives me even easier switching between various databases. This 
reminds me the zeos project.

However, there's a problem. In real programs I want to be able to set 
some FB-specific transaction parameters. By doing this I'm agreeing to 
sacrifice some portability of my programs across various databases, but 
I think it's useful, at least with FB, since there are many sensible 
transaction isolation modes and I want to be able to choose what I want.

When I was playing with Interbase unit yesterday, this was simple, much 
like with Delphi's IBX: just set appropriate properties of 
TIBTransaction class, like IsolationLevel.

How to get equivalent functionality with Sqldb and IBConnection ?
I implemented some small patches that enable this. The essential thing 
is new public function TSQLTransaction.SQLHandle that gives an access to 
TIBTrans class specific to FB database. Note that this forced me to 
write some additional code to react when user changes value of 
TSQLConnection.Database property. User of this code must be prepared 
that changing TSQLConnection.Database resets properties of SQLHandle.

(
Some notes about the problem with resetting properties of SQLHandle:
This problem is (at least partially) inevitable, since when value of 
Database property changes, it may change to a different descendant of 
TSQLConnection so the set of available properties may change anyway. So 
I think that the current method (that will implicitly reset all 
properties of SQLHandle, because internally FTrans will be destroyed and 
then (at the next call to SQLHandle) created again) is OK.
)

Now I can change properties of FB transaction doing e.g.
  (SQLTransaction.SQLHandle as TIBTrans).IsolationLevel := ilReadCommitted;
Attached patch also fixes a small bug, by changing in 
TSQLQuery.InternalOpen FieldByName to FindField. See inside the patch 
for comments what it solves.

One more thing: note that default IsolationLevel of 
IBConnection.TIBTrans is ilConcurrent, while default IsolationLevel of 
Interbase.TIBTransaction is ilReadCommitted. It's not my fault :), 
that's the way they were done. And none of my patches tries to change 
it, since it would be an incompatible change. However, I would advice 
changing default IsolationLevel of Interbase.TIBTransaction to 
ilConcurrent. This way not only IBConnection and Interbase units would 
use the same IsolationLevel by default, but also this would make 
Interbase.TIBTransaction a little more compatible to Delphi's IBX and to 
standard FB behaviour (empty TPB passed to isc_start_transaction is 
equivalent to isc_tpb_concurrency).

Michalis.
cvs server: Diffing .
Index: db.pp
===
RCS file: /FPC/CVS/fpc/fcl/db/db.pp,v
retrieving revision 1.38
diff -u -r1.38 db.pp
--- db.pp	16 Feb 2005 09:31:58 -	1.38
+++ db.pp	18 Mar 2005 03:39:48 -
@@ -1264,7 +1264,6 @@
 FDatabase  : TDatabase;
 FDataSets  : TList;
 FOpenAfterRead : boolean;
-Procedure SetDatabase (Value : TDatabase);
 Function GetDataSetCount : Longint;
 Function GetDataset(Index : longint) : TDBDataset;
 procedure RegisterDataset (DS : TDBDataset);
@@ -1272,6 +1271,7 @@
 procedure RemoveDataSets;
 procedure SetActive(Value : boolean);
   Protected
+Procedure SetDatabase (Value : TDatabase); virtual;
 procedure CloseTrans;
 procedure openTrans;
 Procedure CheckDatabase;
cvs server: Diffing dbase
cvs server: Diffing interbase
cvs server: Diffing memds
cvs server: Diffing mysql
cvs server: Diffing odbc
cvs server: Diffing sdf
cvs server: Diffing sqldb
Index: sqldb/sqldb.pp
===
RCS file: /FPC/CVS/fpc/fcl/db/sqldb/sqldb.pp,v
retrieving revision 1.14
diff -u -r1.14 sqldb.pp
--- sqldb/sqldb.pp	14 Feb 2005 17:13:12 -	1.14
+++ sqldb/sqldb.pp	18 Mar 2005 03:39:48 -
@@ -116,6 +116,7 @@
 FAction  : TCommitRollbackAction;
   protected
 function GetHandle : Pointer; virtual;
+procedure SetDatabase(Value: TDatabase); override;
   public
 procedure Commit; virtual;
 procedure CommitRetaining; virtual;
@@ -126,6 +127,27 @@
 destructor Destroy; override;
 property Handle: Pointer read GetHandle;
 procedure EndTransaction; override;
+
+{ Use this to get access to transaction properties/methods that are
+  specific to some TSQLConnection descendant, e.g. when 
+  Database is TIBConnection then this SQLHandle returns always 
+  an instance of class TIBTrans.
+
+  Notes:
+  - You must assign Database before using this property
+  - Each time you change Database property, you're causing

[fpc-devel] Fix to IBConnection field names

[Michalis Kamburelis]

Hi
(This is completely unrelated to my previous patches to sqldb and
ibconnection.)
A simple correction that fixes a problem in IBConnection with field
names: in TIBConnection.LoadField you look for field names using
SQLDA^.SQLVar[x].AliasName, but in TIBConnection.AddFieldDefs you create
fields with names using SQLDA^.SQLVar[x].SQLName. This is not good, as
field's SQLName may be '' while it's AliasName may be 'COUNT' or
something like that. In general, I think that you should use AliasNames
everywhere. This also gives developer (the one who writes SQL
statements) ability to change default field names using SQL (since you
can explicitly say in select SQLs what AliasName should be used for some
fields).
So the fix is (I don't attach a patch, since this is too small..):
change in TIBConnection.AddFieldDefs implementation SQLName to
AliasName. This way in whole IBConnection unit only AliasName of
fields is used, never SQLName.
Michalis.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection

[Michalis Kamburelis]

Michael Van Canneyt wrote:
...
I would propose to introduce a enumerated
TSQLTransactionStyle =(tsConcurrent,tsReadCommit, etc.);
Then add a TransactionStyle to TSQLTransaction;
This must be mapped by the TSQLConnection when creating the handle.
...
Indeed, this would be more elegant than my solution, but this would 
require finding some common functionality between various databases 
(Firebird, PostgreSQL, MySQL, and thinking about others in the future). 
I.e. something that would be both flexible and yet (at least relatively) 
portable to all TSQLConnection descendants. I'll look into this 
tomorrow. Although I may need some help about what transaction modes can 
be expressed in PostgreSQL and MySQL. I'll see tomorrow what I can do 
(and where I will need some help :).

Michalis.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection

[Michalis Kamburelis]

I wrote:
Michael Van Canneyt wrote:
...
I would propose to introduce a enumerated
TSQLTransactionStyle =(tsConcurrent,tsReadCommit, etc.);
Then add a TransactionStyle to TSQLTransaction;
This must be mapped by the TSQLConnection when creating the handle.
...
Indeed, this would be more elegant than my solution, but this would 
require finding some common functionality between various databases 
(Firebird, PostgreSQL, MySQL, and thinking about others in the future). 
I.e. something that would be both flexible and yet (at least relatively) 
portable to all TSQLConnection descendants. I'll look into this 
tomorrow. Although I may need some help about what transaction modes can 
be expressed in PostgreSQL and MySQL. I'll see tomorrow what I can do 
(and where I will need some help :).

1. After reading docs of PostgreSQL and MySQL (I know possibilities of 
Firebird by heart :), I must admit that I don't see a way to define 
TSQLTransactionStyle in a way that would be both really flexible and 
portable to all 3 databases (Firebird, PostgreSQL, MySQL). Every 
database has an idea of at least two transaction modes like

a) Concurrent (aka Snapshot)
b) Read committed
... but that's all. Many details seem to be different, especially read 
committed mode has many diffeent variants and possibilities (whether 
one multirow select can be only partially affected by committing some 
other transaction ? In Firebird yes, it's always possible, in PostgreSQL 
you can avoid this. What should happen when uncommitted data is pending 
? In Firebird -- many choices: read committed record version, wait for 
committing or rollback, return immediately with error... PostgreSQL 
seems to always return committed record version. Anyway -- these are 
just examples).

I'm waiting for your opinion on this point. How exactly would you 
propose TSQLTransactionStyle to be defined, and how it should behave 
when some modes cannot be implemented in some database ?

2. To clear field for our discussion, I'm attaching all my simple 
corrections to fcl/db/ as a patch to this email. This patch does *not* 
mess with anything related to changing transaction modes (neither your 
way of TSQLTransactionStyle nor my initial way of exposing 
TSQLTransaction.SQLHandle). In other words, this is the patch that you 
want to apply now, no matter what is your answer to point 1 above :)

Summary of changes in this patch:
-- Default TIBTransaction.IsolationLevel is changed to ilConcurrent. 
This makes TIBTransaction more consistent with TIBConnection behaviour, 
and Delphi's IBX, and Firebird C API (as I explained in one of previous 
letters).

-- In units Interbase and IBConnection, SQLVar[...].AliasName is used 
everywhere, instead of SQLVar[...].SQLName. As I explained in previous 
letter [fpc-devel] Fix to IBConnection field names, using AliasName is 
just better than SQLName. Consider e.g. `select count(*) from ...', that 
has one field with SQLName = '' but AliasName = 'COUNT'. Also, developer 
writing SQL statememt has full control over what alias name will be 
assigned for the field.

-- Fix for Sqldb unit that used in one place FieldByName while FindField 
+ manual check was required. This is described in detail in comments 
inside patch.

-- TIBDatabase should allow setting Transaction from non-nil to nil 
(TIBDatabase must anyway be prepared everywhere to handle the case when 
Transaction = nil), and also TIBDatabase should automatically set it's 
Transaction property to nil when Transaction instance is destroyed 
(using FreeNotification). I rearranged TIBDatabase.SetTransaction to 
make it (in my opinion) cleaner.

Michalis.
cvs diff: Diffing .
cvs diff: Diffing dbase
cvs diff: Diffing interbase
Index: interbase/interbase.pp
===
RCS file: /FPC/CVS/fpc/fcl/db/interbase/interbase.pp,v
retrieving revision 1.16
diff -u -r1.16 interbase.pp
--- interbase/interbase.pp	17 Mar 2005 09:02:17 -	1.16
+++ interbase/interbase.pp	20 Mar 2005 03:13:15 -
@@ -52,6 +52,8 @@
 procedure SetDBDialect;
 procedure SetTransaction(Value : TIBTransaction);
   protected
+procedure Notification(AComponent: TComponent; 
+  Operation: TOperation); override;
 function GetHandle : pointer; virtual;
   { This procedure makes connection to Interbase server internally.
 Is visible only by descendants, in application programming
@@ -180,7 +182,7 @@
 property AccessMode: TAccessMode
   read FAccessMode write FAccessMode default amReadWrite;
 property IsolationLevel: TIsolationLevel
-  read FIsolationLevel write FIsolationLevel default ilReadCommitted;
+  read FIsolationLevel write FIsolationLevel default ilConcurrent;
 property LockResolution: TLockResolution
   read FLockResolution write FLockResolution default lrWait;
 property TableReservation: TTableReservation
@@ -383,22 +385,24 @@
 
 procedure TIBDatabase.SetTransaction(Value : TIBTransaction);
 

Re: [fpc-devel] lazarus bug report + fix: Utf8ToUnicode doesn't work correctly

[Michalis Kamburelis]

Michael Van Canneyt wrote:
On Wed, 4 May 2005, Jonas Maebe wrote:

On 4 mei 2005, at 12:04, Michael Van Canneyt wrote:

It contains a fixed version of the Utf8ToUnicode function. Since it
is part of
the rtl, I close this lazarus issue and send you this message. I did
not test
the fixed version.
The files in the zip file are not usable; They're in some unicode format,
which
I can't use nor check on Linux.
They're plain UTF-8. I know for a fact there are editors under Linux which
support that (at least emacs does, and it would surprise me immensely if vim
doesn't). Anyway, here's the plain ascii version of the -fixed file.

I already got it from Vincent and applied the patch. But:
- diff doesn't grok unicode.
- joe doesn't grok it either.
- kate  kwrite - no grok.
- PFE (Windows) doesn't grok it either.   
- Apparently vim converts to plain ascii before editing.
I didn't look at this patch, but if it's really UTF-8 then you can open 
the patch in Emacs (use `C-x RET c utf-8 RET C-x C-f FILENAME RET' 
to make sure that utf-8 will be understood), make sure you're in 
diff-mode (`M-x diff-mode' if necessary), then `C-c C-a' (or `M-x 
diff-apply-hunk') will apply hunks of the patch. I don't know does it 
solve the problems here (especially since FPC doesn't grok unicode...) 
but it's a painless way to apply patch encoded in UTF-8.

- Last but not least: The FPC Compiler also doesn't grok unicode :-)
So much for unicode :/
Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Trivial fix to trunk/fcl/image/fpimgcmn.pp

[Michalis Kamburelis]

Hi

Compilation of fpimgcmn.pp is broken starting from revision 33 (some 
part of code that was $ifdefed earlier by VER1_0 stayed), I'm attaching 
a trivial patch.
Index: fpimgcmn.pp
===
--- fpimgcmn.pp	(wersja 36)
+++ fpimgcmn.pp	(kopia robocza)
@@ -18,8 +18,6 @@
 
 interface
 
-  PByteArray = ^TByteArray;
-
 function Swap(This : Longword): longword;
 function Swap(This : integer): integer;
 function Swap(This : Word): Word;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] DB Bug in 2.0.1?

[Michalis Kamburelis]

Tony Maro wrote:

Jonas Maebe wrote:



On 21 jul 2005, at 00:40, Tony Maro wrote:


Can someone confirm the date issue for me?




I can't confirm it, but I do want to mention that I fixed all  
datetime-related routines for *nix platforms in sysutils a while ago.  
They operated based on the supposition that the dates they get are in  
Windows format, as opposed to the number of seconds since x/x/1970.



I have a concern on that - and please keep in mind I've not even looked 
at the code, so I don't know if it's an issue or not.


My main purpose in using FPC is to write cross-platform applications.  
 From what I gather, I'll now need to understand that TDateTime doesn't 
actually store things the same way on different OS's?  I know, FPC's 
goal is not specifically Delphi compatibility, but...


Here's a quote I found online:
In Delphi for Win32 (and Kylix), TDateTime is defined as a Double 
(64-bit floating-point number). Date and time information is stored as 
the count of days since midnight on 30-Dec-1899.


Here you can see that even Kylix uses the same methodology in storing 
TDateTime values.


I can see both perspectives, but if the idea is to make it easier to 
develop cross-platform software, I'd expect TDateTime to be stored the 
same way across platforms regardless of how the OS counts.  A lot of 
software written for Delphi is going to be awfully hard to convert for 
Linux, Mac, etc if TDateTime is stored differently everywhere.




AFAIK TDateTime internal format is the same for all platforms, and 
compatible to Delphi. I guess that Jonas meant his change at revision 
444, see

  svn diff -r 443:444
These fixes concern DateTimeToFileDate and FileDateToDateTime. The 
FileDate meaning is OS-dependent (and Jonas fixed DateTimeToFileDate and 
FileDateToDateTime to work accordingly).


(It's worth mentioning that good code shouldn't rely on internal 
TDateTime format anyway. Usually TDateTime should be treated as opaque 
type, and operated only using standard routines, like the ones from 
DateUtils unit.)


Michalis

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] GetAppConfigDir under Unices

[Michalis Kamburelis]

Hi

I just tested SysUtils.GetAppConfigDir under Linux and I see that it 
returns

  GetHomeDir + ApplicationName
(when Global = false). Shouldn't it rather return
  GetHomeDir + '.' + ApplicationName
? Config directories in user's home dir traditionally start with '.' to 
be somewhat hidden. I would expect GetAppConfigDir to follow this 
practice.


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PR advancement

[Michalis Kamburelis]

Ales Katona wrote:

Michalis Kamburelis wrote:


Ales Katona wrote:


[...]



2. Can I use Free Pascal/Lazarus for commercial development?




This is the 4th question of current FAQ. And I assume that you 
actually wanted to say closed source, this is not the same thing as 
commercial.



If you look at forums and mailing lists, NO people DON'T get it. You 
need to explicitly tell them YES YOU CAN STATIC LINK WITH OUR ENHANCED 
LGPL. Honestly the thing in the FAQ is good for lawyers only.




Reading FPC and Lazarus mailing lists, and I don't see such problems. 
And I understood the FAQ, even though IANAL. There's a text


  It is therefore possible to create closed source or proprietary 
software using Free Pascal.


I think that this is even more explicit (and understandable to 
non-programmers) than your proposed Yes you can static link with our 
enhanced LGPL.





3. Are there any real world applications made with Free Pascal/Lazarus?




I guess that even a manager is able to type fpc or lazarus into 
google.



And he'll find a bunch of fanboy websites.



So what answer would you propose for the FAQ question Are there any 
real world applications made with Free Pascal/Lazarus ? A huge list of 
every program that was ever compiled with FPC ? A short list of chosen 
projects ? Who will decide and maintain the list of most bright 
projects developed using FPC+Lazarus ?



4. Why should I use Free Pascal/Lazarus?




Which is horribly outdated and utterly useless. Also it only specializes 
on comparing FP dialect of Pascal with other languages.
One half of currently listed advantages is basicly a pissing contest 
against C/C++ and the other is saying we got OOP/other features too you 
know.



[...]

Then propose a better text / feature list for Advantages page...

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PR advancement

[Michalis Kamburelis]

Ales Katona wrote:


So what answer would you propose for the FAQ question Are there any 
real world applications made with Free Pascal/Lazarus ? A huge list 
of every program that was ever compiled with FPC ? A short list of 
chosen projects ? Who will decide and maintain the list of most 
bright projects developed using FPC+Lazarus ?


This selection is done already. See news on main fpc page.


Hm, after giving it some thought, and after seeing 
[http://www.freepascal.org/gallery.html] link, I have to agree: such 
selection looks nice.


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] [RFC] fpdoc output comment from the source

[Michalis Kamburelis]

Mark de Wever wrote:

Hi all,

I like to put a lot of comment in the source and I would like fpdoc to
output this comment into the output files. I wrote a small patch to do
this with types, it puts all the comment in front of a type declaration 
into the output html as section Comment text. 



(This is kind of shameless self promotion, since I took the PasDoc 
projects this year: )


If you want to get documentation generated from comments in your source 
code, PasDoc may be a better tool for you. See [http://pasdoc.sf.net/].


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Benchmark for FreePascal

[Michalis Kamburelis]

Are we talking here about making a class that can read any TStream 
descendant line-by-line (i.e. by simple a'la Readln method) ?


Then I believe this was already discussed on fpc-pascal, I remember that 
I sent there my TTextReader class implementation that does just that. 
TTextReader class is also part of pasdoc code right now, you can see it 
here 
[http://cvs.sourceforge.net/viewcvs.py/*checkout*/pasdoc/pasdoc/source/component/PasDoc_ProcessLineTalk.pas].


Is this the kind of thing that is wanted ?

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] GetAppConfigDir and GetAppConfigFile output

[Michalis Kamburelis]

Felipe Monteiro de Carvalho wrote:

Hello,

I recently tryed to use those two functions, so I created a test app
with 4 functions:

  WriteLn(GetAppConfigDir(True));
  WriteLn(GetAppConfigDir(False));
  WriteLn(GetAppConfigFile(True));
  WriteLn(GetAppConfigFile(False));

The output on a GNU/Linux system:

/etc
/home/felipe/project1
/etc/project1.cfg
/home/felipe/.project1

Is the output for non global configurations correct?

Shoudn't it be:

/etc
/home/felipe/.project1
/etc/project1.cfg
/home/felipe/.project1.cfg

I never see programs create folders without the dot on the home
directory. This surely would be an unconvenient behavior.

The output is the same on 2.0.0 and 2.0.2
--
Felipe Monteiro de Carvalho



Some time ago I sent a patch that fixes this, it was applied to FPC 
2.1.1 and 2.0.3. Unfortunately it didn't make it to 2.0.2 release. See 
this thread on fpc-devel: 
[http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg03542.html].


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] trunk/fcl/Makefile.fpc doesn't include db dir

[Michalis Kamburelis]

Hi

In revision 1944 in trunk (log is + Add PTCpas package), among many 
changes to packages/extra/, fcl/Makefile.fpc was changed, line

  dirs=xml image db shedit passrc net fpcunit
was changed to
  dirs=xml image shedit passrc net fpcunit

Was there any reason to remove db dir from the build process ? If not, 
can you restore `db' there ? Everything inside fcl/db/ builds correctly, 
at least for me...


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PR results

[Michalis Kamburelis]

Daniël Mantione wrote:
[...]

- Pascal Game Programming - Big news on front page:
  http://www.pascalgameprogramming.com



I guess you wanted to say [http://www.pascalgamedevelopment.com/] ?

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Michalis Kamburelis]

(Second send, it seems that mails from my old email address do not reach 
fpc lists)


Den Jean wrote:

Hi,

I have a strange problem. My Qt4 demo program worked 
fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2.

Debugging shows that indeed a div by zero is done within
the Qt4 lib. However with FPC 2.0.0 or using C++ code the library
isn't bothered with the div by zero. When I use FPC 2.0.2 however
it is.



Maybe it was FPC 2.0.0 bug (that was fixed in the meantime) that caused
this SIGFPE inside qt to be ignored ? AFAIK it was always the intention
of FPC that if used library causes a signal like SIGFPE, this signal
*will not be ignored* and will cause our program to fail with some
exception.

Maybe you can workaround this with Set8087CW, just like it has to be
workarounded for OpenGL under Windows (see
[http://www.freepascal.org/bugs/showrec.php3?ID=3955]). Just add
Set8087CW($133F); at the beginning of your program (or even right
inside qt unit initialization) and see if it helps.

(Note that I'm writing this without any knowledge of qt or your testcase
--- I just thought that it may be helpful, sorry if it's not relevant :) ).

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Michalis Kamburelis]

Den Jean wrote:

Hi,

I have a strange problem. My Qt4 demo program worked 
fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2.

Debugging shows that indeed a div by zero is done within
the Qt4 lib. However with FPC 2.0.0 or using C++ code the library
isn't bothered with the div by zero. When I use FPC 2.0.2 however
it is.



Maybe it was FPC 2.0.0 bug (that was fixed in the meantime) that caused 
this SIGFPE inside qt to be ignored ? AFAIK it was always the intention 
of FPC that if used library causes a signal like SIGFPE, this signal 
*will not be ignored* and will cause our program to fail with some 
exception.


Maybe you can workaround this with Set8087CW, just like it has to be 
workarounded for OpenGL under Windows (see 
[http://www.freepascal.org/bugs/showrec.php3?ID=3955]). Just add 
Set8087CW($133F); at the beginning of your program (or even right 
inside qt unit initialization) and see if it helps.


(Note that I'm writing this without any knowledge of qt or your testcase 
--- I just thought that it may be helpful, sorry if it's not relevant :) ).


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Math.DivMod results should be signed

[Michalis Kamburelis]

Hi

I'm concerned with using DivMod in cases when Dividend is  0. DivMod 
declaration is


  procedure DivMod(Dividend: Integer; Divisor: Word;  var Result, 
Remainder: Word);


which means that it doesn't allow for Result and Remainder to be  0. 
But when Dividend is  0, Result and/or Remainder sometimes have to be  
0. For example,


var
  UnsignedDivResult, UnsignedModResult: Word;
  DivResult: SmallInt absolute UnsignedDivResult;
  ModResult: SmallInt absolute UnsignedModResult;
begin
  DivMod(-39, 20, UnsignedDivResult, UnsignedModResult);
end;

gets me UnsignedDivResult = 65535 and UnsignedModResult = 65517. Of 
course when treating memory as signed values (DivResult and ModResult), 
I can decipher correct values (-1 and -19) but that's obviously 
unclean. Sure I can also just use div and mod operators, they always 
get me correct values, but I understand that doing div and mod 
separately may be slower than DivMod on some processors.


I know that DivMod arguments have to stay as Word for Delphi compat. But 
in the light of the above, it seems like a good idea to add overloaded 
DivMod version that returns Result and Remainder as signed values ?


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unit linking to .obj files and fpcmake.

[Michalis Kamburelis]

J. Peter Mugaas wrote:
[...]
 On Win32, that may not be desirable since there seems to be several versions 
 of the ZLIB .DLL

Unfortunately, it's true that there are several (sometimes incompatible
-- various zlib versions, various calling conventions) zlib.dll versions
floating around.

Fortunately, there exists more-or-less standard zlib dll library for
win32. It can be obtained from [http://gnuwin32.sourceforge.net/]. It is
frequently updated, so all known security problems should be fixed
there. It's used by many programs (including gimp for windows, or
actually gtk 2 for windows; oh, and my programs :) ). It's named
zlib1.dll (with 1), so no conflicts with zlib.dll. As far as I am
aware, no software dared to ever install incompatible zlib1.dll version.
So this may be your solution.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unit linking to .obj files and fpcmake.

[Michalis Kamburelis]

J. Peter Mugaas wrote:
[...]
 
 And I noticed that the zlib1.dll filename is the same between the official 
 ZLib .DLL and the the one you mentioned.   The zlib version you mentioned has 
 a file size of 73.5 KB (75,264 bytes) while the official one has a file size 
 of 58.5 KB (59,904 bytes).  What's the key difference between the two?  What 
 are the standard calling conventions for them (stdcall or cdecl)?
 

The one on official [http://www.zlib.net/] was compiled with Microsoft
Visual C++. While gnuwin32 uses MinGW gcc and binutils for compilation.
That's the difference. Fortunately, they both use the same calling
convention: cdecl (see DLL_FAQ.txt for official zlib123-dll.zip from
[http://www.zlib.net/] and
[http://www.mail-archive.com/gnuwin32-users@lists.sourceforge.net/msg00103.html])
so they should be compatible.

 
Fortunately, there exists more-or-less standard zlib dll library for
win32. It can be obtained from [http://gnuwin32.sourceforge.net/].
It is
frequently updated, so all known security problems should be fixed
there. It's used by many programs (including gimp for windows, or
actually gtk 2 for windows; oh, and my programs :) ). It's named
zlib1.dll (with 1), so no conflicts with zlib.dll. As far as I am
aware, no software dared to ever install incompatible zlib1.dll
version.
 
 
 It might be.  I still am biased towards static linking some type of object 
 file (either the .obj form or an .a format) and I noticed that the 
 distribution you mentioned does have libz.a.  Does that statically link all 
 the zlib code or do would have to include the .dll?   If it does, then I 
 might want to consider that instead.
 

The .a file should contain the same thing as .dll, but for linking
statically. Libraries compiled on gnuwin32 (both static and dynamic) use
MinGW gcc and binutils for compilation, so they should be compatible
with FPC under Win32.

If I were you, I would still use dynamic library (.dll) anyway, because
that allows advanced users to manually update zlib1.dll your program uses.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] a shared library suggestion

[Michalis Kamburelis]

peter green wrote:
 yeah that technique requires far less stubs but it means that the coder has
 to manually call an init function.
 

Not necessarily, because you can load all addresses in initialization
section of the unit. That's what I do in my various wrappers.

 also how does your code respond if one of the entry points isn't found?
 

Looking at ibase60.inc, in this case the error is ignored (i.e. the
entry point is left as nil, this will result in error at runtime if
you try to call this function). But the technique is flexible --- you
could as well check GetProcedureAddress result and raise exception like
entry point %s missing if it's nil.

This technique also allows you to try to load from various dll/so names,
if you're not sure what the precise lib name will be on user system.
This is even used ibase60dyn, as it tries to load first fbclib then (if
that fails) gdslib (e.g. 'libfbclient.so' or 'libgds.so' on Unix). So it
will work with both Interbase and clean (not forced to be compatible
with Interbase) Firebird installations.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Language extension: absolute for classes

[Michalis Kamburelis]

Micah Milissent wrote:
 Hi,
 
 I want to bring up the following scenario: (need fixed font)
 
B  --  G
|   |
A  --  F
 
 All are classes, and usually A 'owns' F. So A has a field 'Field' of
 type F. Now, whenever A creates F, B overrides this (in virtual method
 or class type) to create a G.
 
 The problem now is that every time B wants to access G, it has to
 typecast Field to G.
 

You don't need new language construction for this ?

All you want is just to cover in class B identifier Field of class A.
So you should make Field a dummy function in class A (that just
returns a field value), and then you can redefine function name in
descendant classes. See the example below. Within the scope of class B
the Field function will return class G.

-
{$mode objfpc}

type
  TF = class
  end;

  TG = class(TF)
  end;

  TA = class
  private
FField: TF;
  protected
function Field: TF;
  end;

function TA.Field: TF;
begin
  Result := FField;
end;

type
  TB = class(TA)
  protected
function Field: TG;
  end;

function TB.Field: TG;
begin
  Result := (inherited Field) as TG;
end;

begin
end.
-

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Language extension: absolute for classes

[Michalis Kamburelis]

Micha Nelissen wrote:
 Michalis Kamburelis wrote:
 All you want is just to cover in class B identifier Field of class A.
 So you should make Field a dummy function in class A (that just
 returns a field value), and then you can redefine function name in
 descendant classes. See the example below. Within the scope of class B
 the Field function will return class G.
 
 This is a smart hack, at best. It's abuse of function syntax IMHO (as if
 they were fields). Second, you cannot assign to a function.
 
 If the functions were inline, it could be as optimal, I agree; then you
 have essentially localized the typecast to one place.
 
 I just want to tell the compiler what I can guarantee, but what it
 cannot automatically infer.
 

It can be done for properties too. And I agree, this can be considered
an abuse but not of the function syntax. It's an abuse of the rule
that you can always hide identifiers of parent class in a subclass.
Virtual methods are a typical clean solution to similar problems, but in
this case you want to change the method/property interface so we're left
with this unclean solution.

BTW That's why I agree with the cleaner approach of overriding
properties later in this thread.

Example below shows the same trick working for properties. Here Field
is a read/write property.

---
{$mode objfpc}

type
  TF = class
  end;

  TG = class(TF)
  end;

  TA = class
  private
FField: TF;
  protected
property Field: TF read FField write FField;
  end;

  TB = class(TA)
  private
function GetField: TG;
procedure SetField(Value: TG);
  protected
property Field: TG read GetField write SetField;
  end;

function TB.GetField: TG;
begin
  Result := (inherited Field) as TG;
end;

procedure TB.SetField(Value: TG);
begin
  (inherited Field) := Value;
end;

begin
end.
---

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Improve error message for #0005942: fpc gives Illegal unit name for 8 character unit name conflict

[Michalis Kamburelis]

Hi

See this bug report:
[http://bugs.freepascal.org/bug_view_page.php?bug_id=5942], with
resolution no change required. The result is the same still in FPC
2.3.1. I understand that the behavior should be kept as is, for
compatibility with TP and/or Delphi and filesystems with 8.3 filenames.

But the error message is so unclear that it makes you bang your head
into the wall when searching the problem :) --- error message speaks
about Error: Illegal unit name: TestUnit, not indicating anywhere that
actually the problematic identifier is TestUnitBla. When the TestUnit
interface is large, it's almost impossible to realize that this error
message is not related at all to unit TestUnit; declaration, it's only
related to uses TestUnitBla;. (And the cause may be simply that you
forgot to add -Fu with path where TestUnitBla.pas resides.)

Even compiling with -va doesn't indicate anywhere that the problem is
with TestUnitBla.

So, maybe at least improve error message to
  Error: Illegal unit name: TestUnit, expected TestUnitBla
This way it's clear that the problem is related to TestUnitBla
identifier, so it's more clear that TestUnit.pas is mistakenly picked up
as the source code for TestUnitBla.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] fpmake / fppkg (are great!)

[Michalis Kamburelis]

Joost van der Sluis wrote:
 With this release we also want to test our new packaging-system. After
 installing the package manager (fppkg) can be called from the
 command-line. For now only the 'lnet' package is available for
 installation through the package system. When all goes well it could be
 that more packages will be added.
 
 For more information about fppkg:
 http://wiki.freepascal.org/fppkg

I adjusted my own engine to be buildable and installable by fpmake, and
it seems to work mighty fine. Installing lnet by fppkg also went totally
easy.

It would be great to have fpmake system adopted by a lot of FPC
libraries. It would be even better to have a lot of packages available
from default fppkg package repository
(http://www.freepascal.org/repository/packages.xml). It makes the
compilation and installation trivial (right now, most(?) people use
custom methods in their libraries, special allunits.pas units and such;
even when it works Ok, it's better to have standardized method for this;
Makefile.fpc approach seem to never catch up). Another advantage is that
fppkg knows about dependencies. E.g. my game engine will soon depend on
lnet, so installing my game engine by fppkg could automatically pull
also lnet.

So when submission to the official fppkg registry will be open ---
please let us know :)

BTW, I just committed a lot of updates to
http://wiki.freepascal.org/FPMake, correcting many examples to be
compatible with fpmkunit interface in FPC 2.2.2 and 2.2.4rc1. I just
started my fun with fpmake, so if anyone is more knowledgeable in this,
please correct or revert any blunders I made.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] gboolean troubles with FPC trunk

[Michalis Kamburelis]

Hi,

Since revision 9898 the LongBool type behaves differently. This was done
for Delphi compatibility (see log message here
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=9898). In
short, if B is LongBool, then B := true; sets now B to $
(while previously it set B to 1).

This has some unexpected results. GTK's (glib and such) gboolean type is
defined as equal to LongBool, as it was very comfortable when doing GTK
programming. Unfortunately, GTK doesn't officially tolerate gboolean
values other than 0 and 1 (see docs
http://library.gnome.org/devel/glib/unstable/glib-Basic-Types.html#gboolean).
In most of the cases, this is invisible and things work as before, but:

1. Sometimes we get warnings like

(view3dscene:7005): GLib-GObject-WARNING **: value TRUE of type
`gboolean' is invalid or out of range for property
`do-overwrite-confirmation' of type `gboolean'

(when calling gtk_file_chooser_set_do_overwrite_confirmation(..., true))

2. The really ugly things happen when some library actually assumes that
the only valid values are 0 and 1. In particular, this bug bite me bad
because GtkGLExt implementation did in one place a comparison of a
gboolean value direct like if (direct == TRUE) . The TRUE in
this code comes from Glib headers and is just 1, so passing Pascal's
true literal ($) to this function is treated as false. (With
quite catastrophic results in this particular case, as then GtkGLExt
gives me indirect OpenGL context, which is a software context, without
GPU shaders and nearly useless for interesting OpenGL fun.)

IOW, we do have a tricky problem here. The tricky thing is that a lot of
GTK-related code may seem to work, but mysteriously fail in particular
cases. Anyone sees a nice solution?

Some quick ideas:

1. The solution putting most work on compiler developers would be to
implement a new type like LongBool01, that is assignment-compatible
with other boolean types, and internally always guaranteed to be 0
(false) or 1 (true). IOW, LongBool01 would be something like how
LongBool behaved before revision 9898 (except LongBool never guaranteed
this 0/1 behavior, but it seems we need a type that does guarantee this).

Then define gboolean = LongBool01, and everything magically works
everywhere. Users do not have to change anything. Compiler developers
have to deal with yet another boolean type inside the compiler.

2. The second option would be to put things in user hands, and force us
to correct our code. So gboolean should be defined like

  gboolean = (gfalse = 0, gtrue = 1);

and we need a trivial functions to convert from/to gboolean and normal
boolean, like

function ToGBoolean(const A: boolean): GBoolean; inline;
const
  T: array [boolean] of GBoolean = (gfalse, gtrue);
begin
  Result := T[A];
end;

and similar to convert GBoolean to boolean. The uncomfortable thing
about this is that all GTK/Glib/GtkGLExt/etc. code will have to be
corrected and infested with these dummy gboolean-boolean conversions.

Any ideas?

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Dynamic GUI/Console apptype

[Michalis Kamburelis]

Mimu Bunnylin wrote:
 
 But suppose I want a program that will continue running in a console if
 run from a console, but will not automatically create a new one if run
 from outside a console. 

You can declare a program as $apptype GUI, and then try using standard
file handles. If this succeeds, then the program runs in a console (or
has one of the standard handles explicitly redirected to a pipe etc.).
I'm using such approach to get a little Unix-like behavior under Windows.

This goes like

  Handle := GetStdHandle(STD_OUTPUT_HANDLE);

  if (Handle  INVALID_HANDLE_VALUE) and
 (Handle  0) then
StdOutStream := THandleStream.Create(Handle) else
StdOutStream := nil;

Then write to StdOutStream. In my experiments, you should be prepared
that even when StdOutStream  nil, still StdOutStream.WriteBuffer may
raise EWriteError, and then you should assume that stdout is not
available (you can free and nil StdOutStream then, as it's useless).

It would probably be possible to extend this approach, such that
standard Pascal Input / Output / ErrorOutput would use these handles
also, so that you could use standard Read[ln], Write[ln]. I was happy
enough with my StdOutStream approach, didn't bother to make Read[ln],
Write[ln] working.

For concrete code that initializes all three streams (for stdin, stdout,
stderr), for both Unix (where it always succeeds) and Windows (using
above approrach), you can take a look at my code, it's at the end of
http://vrmlengine.svn.sourceforge.net/viewvc/vrmlengine/trunk/kambi_vrml_game_engine/src/base/kambiclassutils.pas
(look for InitStdStreams procedure). Look also at the comments after
@section(Variables to read/write standard input/output using TStream
classes. in the interface.

Hope this helps,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] cmem not aligning memory

[Michalis Kamburelis]

Marco van de Voort wrote:
 In our previous episode, Jonas Maebe said:
 Or do we have to allocate more bytes for blocks that are a multiple of 8?
 FPC's default memory manager even guarantees 16 byte alignment (for vectors).
 
 So a possible solution is to allocate 16-sizeof(ptruint) bytes more?
 
 for 32-bit that would mean:
 
 12 bytes slacksizedata
 

Note that fftw_getmem and fftw_freemem (packages/fftw/src/fftw_s.pas)
already contain the code to allocate always aligned pointer. (They
allocate 15 bytes more for 16-bytes aligmnment, and store the value of
original unaligned pointer to pass it to free.)

One could use these as a workaround, to get aligned pointers from any
GetMem/FreeMem implementation.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proposal: Enhanced replacement for assignment operators

[Michalis Kamburelis]

Vinzent Höfler wrote:
 Alexander Klenin kle...@gmail.com:
 
 C-like operators reduce the number of required punctuation --
 I always think that the extra punctuation is bad for readability.
 
 Rght. Shrt sntncs r mch sr t rd.
 

This is more about

  SomeReallyLongVariableNameX += 10;

being nicer to read than

  SomeReallyLongVariableNameX := SomeReallyLongVariableNameX + 10;

You don't have to spend time realizing that it's the same variable (not
e.g. SomeReallyLongVariableNameY) if you read the 1st form.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Is GLUT_EXCLUSIVE_FPUMODE really needed?

[Michalis Kamburelis]

Hi,

This applies to GLUT_EXCLUSIVE_FPUMODE mode inside
packages/opengl/src/glut.pp source code. Reading history, I see it was
caused by this bug and patch:
http://bugs.freepascal.org/view.php?id=7570 . However, it's not needed
anymore, IMHO. It seems submitter of #7570 hacked glut unit, suspecting
the troubles inside GLUT, while in fact it is OpenGL library causing
floating point trouble.

Moreover, since FPC 2.2.0, we have a correct fix inside the gl.pp unit
itself (see #5914 and #7570). Inside gl.pp, we do SetExceptionMask to
hide fpu errors that may be raised by some OpenGL implementations on all
x86. This, in my view, makes the GLUT_EXCLUSIVE_FPUMODE not needed. The
GLUT_EXCLUSIVE_FPUMODE duplicates the work (adds the same ExceptionMask
flags) that is already done, in much simpler way, by gl.pp initialization.

Comments?

P.S. On an unrelated note, I'm preparing a patch to add freeglut
extensions to glut unit. It's actually ready, but now I'm wondering if
it's worth the trouble to deal with complications caused by
GLUT_EXCLUSIVE_FPUMODE, when instead we could just remove the
GLUT_EXCLUSIVE_FPUMODE hack :)

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Is GLUT_EXCLUSIVE_FPUMODE really needed?

[Michalis Kamburelis]

Ups, looks like I messed up bug numbers in my previous email.

This time correctly:

- The bugreport that caused the creation of GLUT_EXCLUSIVE_FPUMODE is
here: http://bugs.freepascal.org/view.php?id=8995 . I basically propose
to revert the changes caused by it to the GLUT unit (the whole {$ifdef
GLUT_EXCLUSIVE_FPUMODE} part).

- The other bugreports, #5914 and #7570, are my old bugreports that talk
about why fpu exception masking is needed at the very OpenGL unit (on
X86). They caused the proper solution, that make the
GLUT_EXCLUSIVE_FPUMODE obsolete IMHO.

Thanks,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Is GLUT_EXCLUSIVE_FPUMODE really needed?

[Michalis Kamburelis]

For anyone interested: I submitted my proposal to remove
GLUT_EXCLUSIVE_FPUMODE as
  http://bugs.freepascal.org/view.php?id=18107
and a patch with freeglut-extensions as
  http://bugs.freepascal.org/view.php?id=18108

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] CompareMem slower in FPC 2.4.4

[Michalis Kamburelis]

Hi,

In my tests, FPC 2.4.4 has much slower CompareMem than FPC 2.4.2, at
least for some cases:

# with fpc 2.4.4
$ time ./compare_mem_test 1
real0m7.795s
user0m7.764s
sys 0m0.008s
# with fpc 2.4.2
$ time ./compare_mem_test 1
real0m1.218s
user0m1.216s
sys 0m0.000s

This uses CompareMem to compare vectors 3 x Single (12 bytes). As you
can see, FPC 2.4.2 is  6 times faster, so it's a noticeable slowdown
(especially if this is a bottleneck of your algorithm :). This is on
Linux, i386 (32 bit).

I'm attaching the sample compare_mem_test.lpr, just compile by fpc
compare_mem_test.lpr.

I did some tests. In FPC 2.4.4 CompareMem equals to CompareByte. I tried
using CompareWord, which is ~2 times faster, and CompareDWord, which is
even better, but still --- even the best (CompareDWord) on FPC 2.4.4 is
~3 times slower than CompareMem on FPC 2.4.2.

Funny thing is, the fastest approach turned out to be the simplest one:
compare by (V1[0] = V2[0]) and (V1[1] = V2[1]) and (V1[2] = V2[2]).
This is *much* faster than every other approach. (And yes, I tested that
it wasn't optimized out :)

Any thoughts? Maybe something can be improved?

1. Why CompareMem got slower in FPC 2.4.4? Maybe something can be fixed?

2. The simple comparison (V1[0] = V2[0]) and... is much faster than
any CompareXxx. Any chance of improving it? In this case, size is known
at compile time, so maybe CompareXxx could be magic and (for
reasonably small sizes) the compiler could just generate a proper code
to compare them just like = operator? Just an idea of course, I don't
know how easy it would be to actually implement.

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] CompareMem slower in FPC 2.4.4

[Michalis Kamburelis]

Florian Klämpfl wrote:
 Am 01.06.2011 22:07, schrieb Michalis Kamburelis:
 Hi,

 In my tests, FPC 2.4.4 has much slower CompareMem than FPC 2.4.2, at
 least for some cases:
 
 I've commited an improved version in r17642

That's great :) I just tested with fpc from SVN (rev 17644), and can
confirm that CompareMem is much faster now. It beats CompareMem from
both FPC 2.4.4 and FPC 2.4.2:

FPC 2.4.2: 2.635s
FPC 2.4.4: 16.803s
FPC trunk: 1.931s

Although it's still slightly slower than comparing directly with (V1[0]
= V2[0]) and ..., which is ~1.2s for all 3 FPC versions mentioned
above. I guess there has to be some price for CompareMem being more
general, and checking size at runtime.

Thanks everyone,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] CompareMem slower in FPC 2.4.4

[Michalis Kamburelis]

Florian Klämpfl wrote:
 
 I improved CompareDWord as well, for your application it should be even
 better.
 

Ha, I hesitated earlier to mention that CompareWord and CompareDWord are
~4 times slower than equivalent (on the same number of bytes)
CompareMem/CompareByte calls :) Cool, times with latest FPC (rev 17651):

CompareMem: 1.928s
CompareWord: 1.270s
CompareDWord: 1.108s

These times directly help in my algorithm (I use it to aggressively
search for pairs of matching edges for shadow volumes). Great!

Thanks,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] convert comment help to fpcdoc

[Michalis Kamburelis]

2011/7/17 Sven Barth pascaldra...@googlemail.com:
 On 17.07.2011 08:08, Felipe Monteiro de Carvalho wrote:

 Since we are talking about help stuff, (in another thread)

 Do we have any tool to convert documentation written in javadoc style
 (those comments in the source code) to fpdoc xml? I like to write my
 documentation as comments...

 I don't know of anything of the FPC community, but at work we extended
 PasDoc ( http://pasdoc.sipsolutions.net/ ) to write fpdoc compatible XML
 files which was rather easy to do as the already is a XML output available.
 I haven't published this extension though as it was only used internally and
 now we've completly switched to PasDoc.


I wanted to implement output to fpdoc XML from pasdoc some time ago
too (http://pasdoc.sipsolutions.net/MichalisKamburelis#Fpdoc_output).
This would allow one to write comments inside sources, and generate
final documentation by fpdoc. This isn't really difficult, but there's
always not enough time...

For the proponents of docs should be outside sources, it should be
noted that in pasdoc, you can also put docs in separate files, by
using http://pasdoc.sipsolutions.net/ReadDescriptionFromFile . But,
admittedly, this does look ugly compared to nice fpdoc XML format.

As for whether it's better to put comments in sources or in separate
files, I really think this is a matter of preference... Sure, docs
make the unit interface much larger, but they also make it more
useful. And they encourage to update docs immediately together with
updating the API. The generated docs always contain a concise summary
of identifiers, if one wants it. I wrote some more comments about this
on 
http://pasdoc.sipsolutions.net/MichalisKamburelis#Should_documentation_be_placed_inside_units_interface.2C_or_in_separate_files_.3F
.

In short, I like having the both options --- fpdoc is best for docs in
separate files, pasdoc is best for docs inside source files. And
pasdoc is maintained (although not as actively as I'd like, volunteers
are welcome :)

Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Free Pascal 2.6.0 released!

[Michalis Kamburelis]

Felipe Monteiro de Carvalho wrote:

On Sun, Jan 1, 2012 at 2:12 PM, Jeff Duntemannj...@duntemann.com  wrote:

Bravo! My only question is: Are there any particular issues with respect to
using 2.6.0 with Lazarus?


For desktop platforms I don't know any issues. It works just as good as 2.4



I just found one small issue: if you use Lazarus 0.9.30.2 to compile 
graphic applications, it will pass -WG option to FPC, on all platforms. 
However FPC 2.6.0 rejects this option (Error: Illegal parameter: -WG) 
on platforms where it's not sensible (like Linux). Bottom line: you 
can't graphic applications from Lazarus (including lazbuild) 0.9.30.2 
using FPC 2.6.0 on Linux.


This is of course fixed in Lazarus SVN by Mattias already :) See 
revisions 31125 and 31127 
(http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=31125 
and 
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=31127 
). To workaround, you may need to backport these changes for Lazarus 
0.9.30.2 (or just switch to Lazarus SVN, which was my solution :).


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fixes 2.6.1 fails to install under Win32

[Michalis Kamburelis]

Graeme Geldenhuys wrote:

Hi,

I'm using a Win2000, and have a released FPC 2.6.0 installed. I updated
my FPC 2.6.1 to r23533 (latest revision to date). I run by usual
build.bat script (shown below). FPC, RTL and FCL seems to compile fine,
but the 'make install ...' seems to fail. I've never had such issues
before. It seems like the Makefile is broken, if you look at the odd
directory it tried to create.

Anybody else experiencing this, or have a solution?

8-8-8-8-8
make distclean
make all FPC=c:\FPC\2.6.0\bin\i386-win32\ppc386.exe
make install INSTALL_PREFIX=c:\fpc\2.6.1\
FPC=c:\FPC\2.6.0\bin\i386-win32\ppc386.exe



...snip...
6.exe --prefix=c:\fpc\2.6.1\
--unitinstalldir=c:\fpc\2.6.1\/units/i386-win32/fcl
-web
Installing package fcl-web
The installer encountered the following error:
Failed to create directory C:\fpc\2.6.1
--unitinstalldir=c:\fpc\2.6.1\\units\i3
86-win32\fcl-web\units\i386-win32\fcl-web\


Looks like using a backslash at the end of INSTALL_PREFIX=xxx argument 
quotes the following space, and so the whole thing becomes glued 
C:\fpc\2.6.1 + space + --unitinstalldir=


Do not use a final backslash, like

  make install INSTALL_PREFIX=c:\fpc\2.6.1

and things should be Ok. It would probably be even cleaner to use 
slashes everywhere:


  make install INSTALL_PREFIX=c:/fpc/2.6.1

Disclaimer: I didn't actually test this (not sitting on Windows right 
now), just guessing :)


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Threads in Android

[Michalis Kamburelis]

Sergio Flores wrote:
 I'm trying to use threads in Android, but it seems they are not working
 yet in FPC?

I'm using threads on Android successfully with FPC 2.7.1 (various SVN
revisions, since a couple of months) in Castle Game Engine
http://castle-engine.sourceforge.net/ (see unit
castle_game_engine/src/base/android/castleandroidnativeappglue.pas in
sources, heavily modified based on LCL customdrawn-android code).

An important note is that if you want to use threads, make sure that FPC
knows about the fact that your program is threaded, otherwise weird
things (including random crashes) can happen. See
http://wiki.freepascal.org/Multithreaded_Application_Tutorial#External_threads
. The cleanest solution is to create all threads using pure Pascal code,
like TThread class, and *not* directly use pthreads. And to use TThread
class, you have to include CThreads unit, and it should be the 1st unit
on uses clause.

 Using TThread requires including cthreads unit right?
 But including this unit makes the app imediately close at startup, silently, 
 with nothing in the log except a message saying the process died.

Yes, using TThread + CThreads should be Ok, and works Ok for me. At
least with FPC 2.7.1. I was not able to get anywhere with FPC 2.6.x on
Android, and finally gave up since everything seemed smooth on FPC
2.7.1, see
https://sourceforge.net/p/castle-engine/wiki/Android%20development/#fpc-for-android
.

So I would try, in this order:

1. See does the problem still occur with FPC 2.7.1?

ZenGL wiki has some patches related to threads with FPC 2.6.1, see
http://zengl.org/wiki/doku.php?id=compilation:android .

2. If the app still fails, maybe the thread creation worked but
something else failed? You probably already use  __android_log_write, so
use it more :) --- maybe it failed in some unit's initialization clause?
For example, I had an issue with some Android models crashing when using
dlopen too early (before activity started).

Hope this helps,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenGL 3.3 Core

[Michalis Kamburelis]

2017-05-21 22:38 GMT+02:00 Mathias :
> Is there an option with Lazarus own board means to activate the OpenGL 3.3
> core mode. Or is it enough for me to do the following?
>
>   OpenGLControl.OpenGLMajorVersion := 3;
>   OpenGLControl.OpenGLMinorVersion := 3;
>

These TOpenGLControl properties are passed to the underlying API to
indicate that you want a context that supports this specific OpenGL
version. So, yes, this is the way to get OpenGL 3.3 context.

However, it's not implemented on all platforms. As far as I see, only
the GTK widgetset actually uses the Major/MinorVersion, other
widgetsets simply ignore it.

But in practice, you will also get a 3.3 context without requesting
it, if your OpenGL supports it, and it has ARB_compatibility. See
https://www.khronos.org/opengl/wiki/Core_And_Compatibility_in_Contexts
about the gory details.

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenGL 3.3 Core

[Michalis Kamburelis]

 2017-05-26 18:48 GMT+02:00 Kostas Michalopoulos :
> I'd use an enum with values like (glcDefaultProfile, glcCoreProfile,
> glcCompatibilityProfile). Default would leave things as-is (when versioning
> is introduced to backends that currently do not support it, it will either
> use a backend-specific default or leave it unspecified where possible), Core
> will explicitly request a core profile and Compatibility will explicitly
> request a compatibility profile. Under OSes where compatibility isn't
> available, the context creation would fail.
>
> For bonus points, i'd rename glcCoreProfile to glcRequireCoreProfile and
> instead of glcCompatibilityProfile i'd use glcPreferCompatibilityProfile and
> glcRequireCompatibilityProfile. glcRequireCoreProfile would work like above,
> glcPreferCompatibilityProfile will first try to use the compatibility
> profile but fallback to core if not available (so that the drivers avoid the
> extra checks) and glcRequireCompatibilityProfile will fail if the
> compatibility profile doesn't exist - basically having the profiles as
> glcDefaultProfile, glcPreferCompatibilityProfile,
> glcRequireCompatibilityProfile and glcRequireCoreProfile.
>

I like all of these ideas:)

And they are easily implementable by
https://www.khronos.org/registry/OpenGL/extensions/ARB/GLX_ARB_create_context.txt
(used by the GTK implementation):

- glcRequireCoreProfile and glcRequireCompatibilityProfile results in
the appropriate bit set of GLX_CONTEXT_PROFILE_MASK_ARB .
- glcPreferCompatibilityProfile would need to eventually query for
another profile, as you write (I'm not sure do we really need it much?
I see that sometimes it can be useful, if the implementation can adapt
to use either "old fixed-function renderer" or not, but I'm not sure
is this a large need.)
- ForwardCompatible = true sets the
GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB bit in GLX_CONTEXT_FLAGS_ARB .

Not that I'm volunteering to implement them (I'm not having much time,
and I mostly use my own OpenGL context creation in CastleWindow). But
it makes sense and I would gladly test it:)

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

[Michalis Kamburelis]

2018-05-02 18:21 GMT+02:00 Maciej Izak :
> Hello,
>
> I was kicked away today from core team (probably by Michael Van Canneyt).
>

This is unfortunate. I saw how the recent discussion escalated (and it
seems it was fueled with past disagreements). The end result (Maciej
leaving core) sucks, IMHO.

I have a lot of respect for both Maciej Izak and Michael Van Canneyt.
You both do a lot of work making open-source Pascal, and FPC in
particular, grow. So, this outcome is saddening.

I hope that, if we can't work out a better solution, at least both
projects (FPC and NewPascal) will try to pull their modifications
(both ways) and benefit from work on both sides.

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Trivial error in shellapi.pp after revision 40020

[Michalis Kamburelis]

Hi,

Change in 
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=40020
introduced a small typo, line 25 of shellapi.pp has

$endif}

instead of

{$endif}

(missing "{"), thus building a cross-compiler to Windows fails.

shellapi.pp(25,1) Fatal: Syntax error, "UNIT" expected but "ordinal const" found

Can you add "{" ? :) Thanks!

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

[Michalis Kamburelis via fpc-devel]

Thanks for the answers,

I have submitted issue
https://gitlab.com/freepascal.org/fpc/source/-/issues/40229 describing
how to reproduce the problem.

Hopefully it can get some attention :) I would very much like to add
"web" target to CGE, to be able to just run CGE games in a browser.
It's going to be my highest-priority thing after upcoming CGE 7.0
release.

Regards,
Michalis

czw., 30 mar 2023 o 21:11 Nikolay Nikolov via fpc-devel
 napisał(a):
>
>
> On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote:
> > Hi,
> >
> > We're experimenting with compiling Castle Game Engine using FPC
> > WebAssembly target.
> >
> > A lot of units and classes compiled smoothly, however we hit a weird
> > bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors
> > "Wasm32 symbol xxx without index value error" at the code trying to
> > use various property setters or methods. Examples:
> >
> > x3dcamerautils.pas(344,0) Error: Wasm32 symbol
> > X3DFIELDS$_$TSFROTATION_$__$$_SETVALUE$TGENERICVECTOR4 without index
> > value error
> >
> > // where TSFRotation.Value is a property with record type, with getter
> > and setter methods
> >
> > x3dcamerautils.pas(344,0) Error: Wasm32 symbol
> > X3DFIELDS$_$TX3DSIMPLEMULTFIELD$3$CRCD1E2ED59_CRCAB5A7799_$__$$_GETITEMS$$TSINGLELIST
> > without index value error
> >
> > // where TX3DSimpleMultField.GetItems is a method of a generic class)
> >
> > x3dcamerautils.pas(344,0) Error: Wasm32 symbol
> > X3DFIELDS$_$TSFFLOAT_$__$$_SETVALUE$SINGLE without index value error
> > x3dcamerautils.pas(344,0) Error: Wasm32 symbol
> >
> > // where TSFFloat.SetValue is a simple setter for a Single property, no 
> > generics
> >
> > castlescenecore.pas(8822,0) Error: Wasm32 symbol
> > CASTLESHAPEINTERNALSHADOWVOLUMES$_$TSHAPESHADOWVOLUMES_$__$$_PREPARERESOURCES
> > without index value error
> >
> > // where TShapeShadowVolumes.PrepareResources is a simple method,
> > without any parameters, in a simple non-generic class
> >
> > Weirder, on another machine, the symbols reported contain some exe
> > filenames at the place of initial "$_$" (maybe independent compiler
> > bug at message display?):
> >
> > x3dloadinternalgeo.pas(234,0) Error: Wasm32 symbol
> > X3DFIELDS/usr/bin/dbus-update-activation-environmentTSFFLOAT_$__$$_SETVALUE$SINGLE
> > without index value error
> >
> > x3dloadinternalgeo.pas(234) Error: Wasm32 symbol
> > X3DFIELDS/home/michalis/bin/castle-engineTSFFLOAT_$__$$_SETVALUE$SINGLE
> > without index value error
> >
> > Sometimes the errors can be workarounded by some simple actions --
> > like moving the property getter/setter protected->private, or avoiding
> > the call to that particular method. But the solutions, as well as
> > causes, seem ~random from our perspective. And all in all, we didn't
> > finish the compilation of X3DNodes unit because after each
> > fix/workaround/hack for a specific case, another similar error pops
> > up.
> >
> > Grepping FPC for the asmw_e_illegal_unset_index (this is "Wasm32
> > symbol $1 without index value error"), the error can occur when symbol
> > cannot be found in the list where compiler expected it to be.
> >
> > We don't have any simple bugreport about it (yet), as the error really
> > manifests only in a big unit, that is interconnected with a few other
> > big units. Isolating the testcase (and/or doing much needed refactor
> > of this unit :) ) will take a while.
> >
> > Does anyone have a hint:
> >
> > - What does this error really mean? What is internally wrong at
> > compilation to cause it? What could be the culprit?
> >
> > - Is there some universal workaround for it (on CGE side) or fix on
> > the compiler side?
> >
> > Even a vague hint could at least help us prepare an isolated
> > bugreport, because otherwise we have a rather big chunk of code to
> > dissect in order to provide a simple FPC testcase :)
>
> Even a big unit is fine for a bug report, as long as all the code is
> publicly available for download. If you can't seem to get it to
> reproduce with a small test case, you can mention in the bug report that
> you tried, but didn't succeed and still provide the full code needed.
> AFAIK, the Castle Game Engine is open-source, so this shouldn't be a
> problem?
>
> Nikolay
>
> >
> > Regards,
> > Michalis
> > ___
> > fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

[Michalis Kamburelis via fpc-devel]

Hi,

We're experimenting with compiling Castle Game Engine using FPC
WebAssembly target.

A lot of units and classes compiled smoothly, however we hit a weird
bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors
"Wasm32 symbol xxx without index value error" at the code trying to
use various property setters or methods. Examples:

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFROTATION_$__$$_SETVALUE$TGENERICVECTOR4 without index
value error

// where TSFRotation.Value is a property with record type, with getter
and setter methods

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TX3DSIMPLEMULTFIELD$3$CRCD1E2ED59_CRCAB5A7799_$__$$_GETITEMS$$TSINGLELIST
without index value error

// where TX3DSimpleMultField.GetItems is a method of a generic class)

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFFLOAT_$__$$_SETVALUE$SINGLE without index value error
x3dcamerautils.pas(344,0) Error: Wasm32 symbol

// where TSFFloat.SetValue is a simple setter for a Single property, no generics

castlescenecore.pas(8822,0) Error: Wasm32 symbol
CASTLESHAPEINTERNALSHADOWVOLUMES$_$TSHAPESHADOWVOLUMES_$__$$_PREPARERESOURCES
without index value error

// where TShapeShadowVolumes.PrepareResources is a simple method,
without any parameters, in a simple non-generic class

Weirder, on another machine, the symbols reported contain some exe
filenames at the place of initial "$_$" (maybe independent compiler
bug at message display?):

x3dloadinternalgeo.pas(234,0) Error: Wasm32 symbol
X3DFIELDS/usr/bin/dbus-update-activation-environmentTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

x3dloadinternalgeo.pas(234) Error: Wasm32 symbol
X3DFIELDS/home/michalis/bin/castle-engineTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

Sometimes the errors can be workarounded by some simple actions --
like moving the property getter/setter protected->private, or avoiding
the call to that particular method. But the solutions, as well as
causes, seem ~random from our perspective. And all in all, we didn't
finish the compilation of X3DNodes unit because after each
fix/workaround/hack for a specific case, another similar error pops
up.

Grepping FPC for the asmw_e_illegal_unset_index (this is "Wasm32
symbol $1 without index value error"), the error can occur when symbol
cannot be found in the list where compiler expected it to be.

We don't have any simple bugreport about it (yet), as the error really
manifests only in a big unit, that is interconnected with a few other
big units. Isolating the testcase (and/or doing much needed refactor
of this unit :) ) will take a while.

Does anyone have a hint:

- What does this error really mean? What is internally wrong at
compilation to cause it? What could be the culprit?

- Is there some universal workaround for it (on CGE side) or fix on
the compiler side?

Even a vague hint could at least help us prepare an isolated
bugreport, because otherwise we have a rather big chunk of code to
dissect in order to provide a simple FPC testcase :)

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changes to TProcess

[Michalis Kamburelis via fpc-devel]

Michael Van Canneyt wrote:
> Needless to say, the component remains backwards compatible.
>
> There is now a testsuite for the TProcess command, so everything was tested.
> but nothing beats testing in the wild, so I would appreciate it if people
> could test it and provide feedback.

Great additions -- making it easier to use pipes is important, and
it's very natural to be able to connect with pipes a few TProcess
instances.

I tested the changes with Castle Game Engine (not using new features
yet, just tested it is backwards-compatible for us), it works great.
We use TProcess in our build tool and editor (editor runs build tool,
build tool can run FPC and other programs).

Regards,
Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel