Re: [fpc-devel] Prototype optimisation... Sliding Window

[Flávio Etrusco via fpc-devel]

Kudos! In the end, did it make much of a difference in the compilation time?

Em sex., 25 de fev. de 2022 às 02:08, J. Gareth Moreton via fpc-devel
 escreveu:
>
> I did it!
>
> After a good week of work and getting things wrong, I finally found a
> solution that works nicely and is extensible, at least for x86.  A bit
> of refactoring and it can be ported to other platforms.  I'm just
> running the test suites to see if I can break things now.  Honestly the
> hard part was making sure all the registers were tracked properly.
>
> https://gitlab.com/CuriousKit/optimisations/-/commits/sliding-window
>
> Please feel free to test it and break it!
>
> It will likely undergo adjustments over time to refactor bits and
> pieces, add extra instructions (especially as it doesn't support SHRX
> and SHLX yet, for example) and see if I can make the sliding window more
> efficient - I increased it in size from 8 to 16 and then 32 entries,
> since even at 16, some optimisations were missed in the RTL, but this
> depends on a number of factors.
>
> It's gotten some pretty good optimisations.  On x86_64-win64 under -O4,
> the three lazarus binaries... before:
>
> lazarus.exe:
>
> 313,990,206
> 313,873,982
>
> lazbuild.exe
>
> 59,704,391
> 59,725,895
>
> startlazarus.exe
>
> 27,471,147
> 27,461,419
>
> And the compiler itself, ppcx64.exe:
>
> 3,777,536
> 3,766,272
>
> Remember that though I call the component a "sliding window", it's only
> because it's very similar to how LZ77 finds start points for run-length
> encoding, and the comments and variable names mention run-length
> encoding as it scans sequences of identical instructions.  However, at
> no point is it actually performing data compression, and the end-result
> is common subexpression elimination.  All the space savings are from the
> removal of redundant sequences of instructions, giving both a space and
> a speed boost.
>
> Almost every source file in the compiler and the RTL shows some kind of
> improvement.  A lot of them are just redundant pointer deallocations, so
> this will help with cache misses and the like - that aside though, here
> are a couple of my favourites... one from dbgdwarf -
> TDebugInfoDwarf.appendsym_fieldvar_with_name_offset:
>
> Before:
>
>  ...
> .Lj682:
>  leaq(,%r13,8),%rcx
>  movq120(%rdi),%rax
>  cqto
>  idivq%rcx
>  imulq%r13,%rax
>  movq%rax,%r12
>  addq56(%rbp),%r12
>  leaq(,%r13,8),%rcx
>  movq120(%rdi),%rax
>  cqto
>  idivq%rcx
>  movq%rdx,%rsi
>  cmpb$0,U_$SYSTEMS_$$_TARGET_INFO+276(%rip)
>
> After:
>
>  ...
> .Lj682:
>  leaq(,%r13,8),%rcx
>  movq120(%rdi),%rax
>  cqto
>  idivq%rcx
>  imulq%r13,%rax
>  movq%rax,%r12
>  addq56(%rbp),%r12
>  movq%rdx,%rsi
>  cmpb$0,U_$SYSTEMS_$$_TARGET_INFO+276(%rip)
>
> This one has successfully removed an IDIV instruction because the
> algorithm was able to detect that the subroutine wanted the remainder in
> %edx, and it was still available from the first IDIV call because it
> hadn't been overwritten, and neither %r13 nor %rdi had changed values so
> the references are the same.
>
> This one is from SysUtils' IsLeapYear function and is one I have
> personally wanted to optimise further ever since I first saw its
> disassembly after I implemented the fast "x mod const = 0" algorithm.
>
> Before:
>
>  ...
>  imulw$23593,%cx,%ax
>  rorw$2,%ax
>  cmpw$655,%ax
>  ja.Lj6979
>  imulw$23593,%cx,%ax
>  rorw$4,%ax
>  cmpw$163,%ax
>  setbeb%al
>  ret
> .Lj6979:
>  ...
>
> After:
>
>  ...
>  imulw$23593,%cx,%ax
>  rorw$2,%ax
>  cmpw$655,%ax
>  ja.Lj6979
>  rorw$2,%ax
>  cmpw$163,%ax
>  setbeb%al
>  ret
> .Lj6979:
>  ...
>
> In this case, the RLE doesn't produce an exact match since the end
> result of %ax is different, but the important point to note is that as
> long as %cx doesn't change value (which it doesn't). the first sequence
> can be transformed into the second sequence via a "rorw $2,%ax"
> instruction, so the end result is that "imulw $23593,%cx,%ax; rorw
> $4,%ax" is transmuted into "rorw $2,%ax" based on the previous value of
> %ax, thus removing a multiplication.
>
> Because this has been a mammoth undertaking and is quite a major
> addition to the compiler, I'm going to hold off making a merge request
> until I write a document on it, like I've done in the past with some of
> the other larger optimisations I've made.  The branch is available at
> the link at the top of this e-mail though if anyone wants to take a look
> at it.
>
> One final note is that this optimisation is rather slow and specialist,
> so much so that I've added a new optimizer switch named 'cs_opt_asmcse'
> ("Assembly CSE", to differentiate it from "Node CSE"); this is enabled
> by default with -O3, and requir

Re: [fpc-devel] Fwd: While - Otherwise Statement

[Flávio Etrusco]

On Mon, Oct 12, 2015 at 7:15 PM, David W Noon
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 12 Oct 2015 15:11:18 -0400, Wkitty42 (wkitt...@windstream.net)
> wrote about "Re: [fpc-devel] Fwd: While - Otherwise Statement" (in
> <561c05d6.4010...@windstream.net>):
>
>> On 10/12/2015 02:02 PM, Dmitry Boyarintsev wrote:
>>>
>>> The next step would probably be controlled "break", where a user
>>> would be able to specify how many nested loops needed to broken
>>> from.
>
> Hi Mark,
>
> You might have seen me write things like this in the old OS2PROG echo
> of Fidonet some 20+ years ago. ... :-)
>
> The only language I know that offers that level of control is PL/I,
> where the break statement is coded as LEAVE.  It is handled by
> labelling the loop control statement and coding the required label in
> the LEAVE statement. For example:
>
>loop_1: DO i = 1 TO m;
>   loop_2 : DO j = 1 TO n;
>  loop_3: DO k = 1 TO p;
>...
>IF some_condition THEH
>   LEAVE loop_3;[...]

If I'm not missing something, Java implements 'break' just like this.
I'd like such enhancement, but right now is there any reason to avoid
'goto' besides the bad karma?

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

Re: [fpc-devel] VMS Pascal Compiler mode

[Flávio Etrusco]

On Mon, Oct 27, 2014 at 8:37 AM, Sven Barth  wrote:
> On 27.10.2014 11:51, Richard Apthorp wrote:
>>
>> Hi Sven,
>>
>> Thanks for the reply. Yes some of it could be handled by a unit for
>> special types etc but not  sure what adding a new mode means or how to do
>> it, could this handle differences such as -
>> Type conversions:
>> Var::integer  instead of integer(var)
>> Passing in characters arrays:
>> Procedure Proc(str : array [A..B] of char);
>> Defaulting parameters
>> Procedure Proc(p1 : integer := 1; p2,p3:integer);
>> And calling it in different ways:
>> Proc(,2,3);
>> Proc(1,p3 := 3, p2:= 2);
>
>
> Maybe you should indeed first try to list all differences then we could help
> you with judging how hard they are to be implemented. E.g. calling arguments
> by name is already implemented for some special cases (AFAIK for
> IDispatchable interfaces or something like that) so that would already be
> there. And then we could guide you for implementing them starting from the
> easy ones to the hard ones so that you could get familiar with the compiler.
>
> Regards,
> Sven

It would be really nice if one could enable calling arguments by name
using modeswitch ;-)
http://www.freepascal.org/docs-html/prog/progsu106.html

> PS: Please keep the fpc-devel list as recipent as well (either as main To or
> as CC) so that others interested in this topic can read your messages as
> well. Maybe it would be better if you'd subscribe to the list, because then
> others don't need to CC you if they answer.
>
>
>>
>> -Original Message-
>> From: Sven Barth [mailto:pascaldra...@googlemail.com]
>> Sent: 25 October 2014 13:10
>> To: FPC developers' list; Richard Apthorp
>> Subject: Re: [fpc-devel] VMS Pascal Compiler mode
>>
>> On 24.10.2014 13:22, Richard Apthorp wrote:
>>>
>>> Porting a large project running on the VMS operating system written in
>>> Pascal to Linux and Free Pascal.
>>> However there is no compiler switch for HP VMS Pascal. Would be really
>>> useful if just the main syntax differences could be catered for eg:
>>> Specifying parameter names in procedure calls (instead of overload) -
>>> I could provide a list.
>>> Noticed GNU Pascal has such a compiler switch.
>>> Anyway in the middle of writing a pre-processor to make the syntax
>>> changes but wondering if anybody has done something similar?
>>> HP having just announced VMS retirement after 35 years there must be a
>>> lot of HP Pascal around some of which will need to be ported!
>>
>>
>> I'm not aware of anyone developing a compiler mode for HP VMS Pascal (or
>> Compaq Pascal as it seems to be called). So feel free to implement it
>> yourself (you could start small by only adding the new mode first and maybe
>> a compatibility unit for special type declarations that will be
>> automatically loaded like the ObjPas unit for modes Delphi and ObjFPC or the
>> MacPas unit for the Mac Pascal mode).
>>
>> Regards,
>> Sven

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

Re: [fpc-devel] suggestion: virtual method co-variance

[Flávio Etrusco]

On Tue, Oct 14, 2014 at 7:40 AM, Marco van de Voort  wrote:
>
> I recently had to dive a bit into C++ again, and reconnected with a feature
> I liked at first sight, the C++ covariance of virtual methods (changing the
> return type of a overriden method to a descendant of the original type).
> Googling a bit it seems that some languages(C#) also seem to allow this for
> parameters.  (not just return types)
>
> I suddenly wondered why it was never proposed or talked about  for FPC,
> since it seems such a nice feature.  Is there something particularly wrong
> with it?
>
> To a certain degree it can be emulated with generics, but that it
> requires a generic for every type, and must be prepared in the library code.
>

Actually this was kind of talked ;-)
http://lists.freepascal.org/pipermail/fpc-devel/2014-February/033394.html

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] svn/github conduits broken?

[Flávio Etrusco]

Probably some new user committed to svn and the user mapping for these
git repositories weren't updated...

-Flávio

On Sun, Sep 7, 2014 at 4:02 AM, Michal Wallace  wrote:
> https://github.com/alrieckert/freepascal/
> https://github.com/graemeg/freepascal/
>
> Both of these usually sync several times an hour with svn,
> and they both died approximately one a week ago.
>
> Did something change with the svn setup?
>
> -tangentstorm
>
>
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] override works, even if result type changed?

[Flávio Etrusco]

On Sun, Feb 23, 2014 at 1:56 PM, Martin Frb  wrote:
> Just found that the below works.
>
> Note, that the result type of "a" (overridden) is different.
> Well, TFoo2 will always satisfy the needs of TFoo, so it seems save. I still
> found it surprising. Is it intended?
>
>
> program Project1;
> type
>   TFoo= class
>   public
> function a: TFoo; virtual;
>   end;
>
>   TFoo2= class(TFoo)
>   public
> function a: TFoo2; override;
>   end;
>
> function TFoo2.a: TFoo2;
> begin
> end;
>
> function TFoo.a: TFoo;
> begin
> end;
>
> begin
> end.
>

I hope so :) [1]
But it seems (from a 2011 blog) Delphi still doesn't allow that?
I wouldn't mind fpc allowed contravariant arguments too ;) (But I
guess I only ever missed it once or twice...)

Regards,
Flávio

[1] 
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Issue 0025028 (Florian)

[Flávio Etrusco]

Just a few points, since nobody replied yet ;-)

On Wed, Feb 19, 2014 at 5:55 PM, Thaddy  wrote:
> This is marked as won't fix.
> I do not fully understand that.
>
> In Delphi, an interface is given a guid internally whatsoever it is
> declared.

Are you sure about that? I remember different for Delphi 7.


> In FPC, this mechanism is also in place.
>
> I refer:
>
> IWhatEverInterface = type IInterface;  // which has a guid.. and type
> inference works correctly

But this doesn't generate a new GUID (if you create an object that
implements only IInterface, testing "is IWhatEverInterface" returns
true).


> I am a known - but well meaning - idiot, but can you please explain why you
> closed this as "won't fix" as the issue seems to be completely fixable and
> reasonable.
>
> Regards,
>
> Thaddy,

If Delphi indeed behaves like that then maybe it's valid RFE for Delphi mode.
OTOH automatically generating a GUID defeats a few features of having
a stable GUID. And even if fpc could avoid modifying the GUID on every
modification inside the unit by reading the PPU (which I don't believe
it does), deleting the PPU would modify it. And then there's the added
(little?) overhead, and the cases where you really don't want to allow
IS and AS, and probably other technical implications I'm not aware ;-)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] for loop unroll optimization

[Flávio Etrusco]

On Sun, Dec 15, 2013 at 10:29 AM, Daniel Sapundjiev  wrote:
> Hi,
>
> Can  someone explain the main idea behind the code
>
> In optloop.pas
>
> function unroll_loop(node : tnode) : tnode;
>
>
>
> What is the unroll about?
>
> Thanks in advance
>
> Daniel Sapoundjiev
>


http://en.wikipedia.org/wiki/Loop_unwinding

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

Re: [fpc-devel] Re: TBits problem

[Flávio Etrusco]

On Wed, Nov 6, 2013 at 5:45 AM, Andrea Mauri  wrote:
> any hint?
> should I have to open a bug report?
>
> Il 31/10/2013 16:23, Andrea Mauri ha scritto:
>>
>> Dear All,
>> I am using TBits object but I found some errors using it. Before adding
>> a bugreport to the bugtracker I would be sure that there is nothing that
>> I am doing wrong.
>> Below a small procedure that highlights the wrong behaviour of TBits
>> object.
>>
>> var
>>i, bsize1, bsize2: integer;
>>b1, b2, b3: TBits;
>>s1, s2, s3: string;
>> begin
>>bsize1:= 16;
>>bsize2:= 164;
>>b1:= TBits.Create;
>>b2:= TBits.Create(bsize2);
>>b3:= TBits.Create;
>>for i:= 0 to bsize1 - 1 do
>>  b1[i]:= True;
>>
>>b2.OrBits(b1);
>>b3.OrBits(b1);
>>for i:= b1.Size to bsize2 - 1 do
>>  b3[i]:= False;
>>if not b2.Equals(b3) then
>>begin
>>  s1:= bitstostring(b1);
>>  s2:= bitstostring(b2);
>>  s3:= bitstostring(b3);
>>end;
>>b1.Free;
>>b2.Free;
>>b3.Free;
>>
>> where bitstostring is a simple function as below:
>>
>> function bitstostring(b:TBits): string;
>> var
>>i: integer;
>>bs: string;
>> begin
>>bs:= '';
>>for i:= 0 to b.Size - 1 do
>>  if b[i] then
>>bs:= bs + '1'
>>  else
>>bs:= bs + '0';
>>Result:= bs;
>> end;
>>
>> What I got is that b2 has set to 1 not only the bits that are 1 in b1
>> but also some other bits. b2 and b3 should be the same but they are not.
>>
>> I tested it on Win32 using lazarus:
>> Lazarus 1.0.13 r42910M FPC 2.6.2 i386-win32-win32/win64
>>
>> Could you please let me know if you can reproduce it or if I am doing
>> something wrong?
>>
>> Best regards,
>> Andrea Mauri
>>
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel


If you send a minimal test-case and actual results you might have a
better chance at getting a reply...

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Little feature teaser

[Flávio Etrusco]

On Fri, Aug 2, 2013 at 1:07 PM, Sven Barth  wrote:
> On 02.08.2013 17:50, Flávio Etrusco wrote:
>>
>> On Fri, Aug 2, 2013 at 12:34 PM, Sven Barth 
>> wrote:
>>>
>>> On 02.08.2013 17:01, Mattias Gaertner wrote:
>>>>
>>>>
>>>> On Fri, 02 Aug 2013 13:18:53 +0200
>>>> Sven Barth  wrote:
>>
>>
>> (...)
>>
>>>> What about code size?
>>>
>>>
>>>
>>> The code size for one unit is the same as if you had (in that example)
>>> declared a variant of "IsIn" for each "LongInt" and "String". So for each
>>> "IsIn" specialization with different types new code is generated if it
>>> does not yet exist in that unit. This means that if you call
>>> "IsIn"
>>> in different units you'll have a "IsIn" implementation in each
>>> unit. This is the same as for generic types btw.
>>>
>>> Regards,
>>> Sven
>>
>>
>>
>> And the same (problem) in C++. Is there some proposal to mitigate the
>> code duplication? Or the official position is that if the project is
>> big enough to suffer from the bloat it should avoid itself the
>> duplicate declarations?
>
>
> The problem is that it's not really possible with the unit concept FPC uses.
> If you want to share the code with other units the code needs to be callable
> from the interface section, but when you are working in the implementation
> section (where most specializations take place) you should not modify the
> interface section anymore as this needs to trigger a recompilation of all
> units that depend on that unit. This already leads to some hard to detect
> bugs in context with inlining (which does exactly that, because the node
> tree of the inline function is stored in the interface part of the PPU). The
> type of interdependencies are for example a problem in FPC itself which
> leads to strange compilation bugs (e.g. identifier not found, although it
> exists, corrupted unit loadings, etc) if you do a normal compile (Ctrl+F9 in
> Lazarus) after you changed something in the interface section of some heavy
> used unit. These bugs of course need to fixed, but they are very hard to
> reproduce in smaller setups...
>
>
> Regards,
> Sven


Thank you very much for the detailed explanation :)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Little feature teaser

[Flávio Etrusco]

On Fri, Aug 2, 2013 at 12:34 PM, Sven Barth  wrote:
> On 02.08.2013 17:01, Mattias Gaertner wrote:
>>
>> On Fri, 02 Aug 2013 13:18:53 +0200
>> Sven Barth  wrote:

(...)

>> What about code size?
>
>
> The code size for one unit is the same as if you had (in that example)
> declared a variant of "IsIn" for each "LongInt" and "String". So for each
> "IsIn" specialization with different types new code is generated if it
> does not yet exist in that unit. This means that if you call "IsIn"
> in different units you'll have a "IsIn" implementation in each
> unit. This is the same as for generic types btw.
>
> Regards,
> Sven


And the same (problem) in C++. Is there some proposal to mitigate the
code duplication? Or the official position is that if the project is
big enough to suffer from the bloat it should avoid itself the
duplicate declarations?

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

[fpc-devel] Re: Bug in StrUtils.ReplaceStr and ReplaceText

[Flávio Etrusco]

On Mon, Mar 25, 2013 at 10:28 PM, Flávio Etrusco
 wrote:
> Hello,
>
> functions ReplaceStr and ReplaceText don't set their results (in trunk).
>

The bug is also present in 2.6.2.

> Best regards,
> Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Bug in StrUtils.ReplaceStr and ReplaceText

[Flávio Etrusco]

Hello,

functions ReplaceStr and ReplaceText don't set their results (in trunk).

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Should the compiler work, if compiled with -Cr?

[Flávio Etrusco]

>
> The particular crash in question is by
>   cstringpattern: AnsiString;
>   len:=length(cstringpattern);
>   recordtokenbuf.write(cstringpattern[1],len);
> with a len of zero, writing 0 bytes from an address that is out of range.
>
>
> Could be solved by using
>  {$PUSH} {$R-}
>  {$POP}
> around those lines.
>

Or typecast it to PChar...
I always found it a PITA that Delphi raises an Exception when
accessing the ending #0 with $R+ :-/

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

Re: [fpc-devel] Improper OUT usage.

[Flávio Etrusco]

On Mon, Mar 11, 2013 at 3:44 AM, Jonas Maebe  wrote:
>
> On 10 Mar 2013, at 22:08, Sven Barth wrote:
>
>> On 10.03.2013 20:39, Flávio Etrusco wrote:
>>> I'd really like the compiler would stop with an error if it can't
>>> prove a variable/out/result is initialized.
>>> Did anybody try implementing this in FPC?
>>
>> Have fun fixing the errors then:
>
> I thought he meant inside the routine with the out-parameter, i.e. add a 
> similar check for out-parameters as for function results. On the caller side 
> it doesn't matter whether or not the out-parameter is already initialized.
>
> Jonas

Yes, I meant this. And for a second I too thought "where is the out
param here?", but he's talking about the (local) variable case, which
I also mentioned. Because 'FillChar' (and quite some other frequently
used functions I AFAIR) receives a 'var' instead of 'out' I can't use
it.

I will only dare asking one more thing for now: FPC's employment of
SSA means having a similar level of checking as in Java (check
branches, for scalar values) is "doable", right?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Improper OUT usage.

[Flávio Etrusco]

On Mon, Mar 11, 2013 at 3:07 AM, Sven Barth  wrote:
> Am 11.03.2013 02:31 schrieb "Flávio Etrusco" :
>
>> On Sun, Mar 10, 2013 at 6:08 PM, Sven Barth 
>> wrote:
>> > (...)
>> >   TTest = record
>> > t: LongInt;
>> >   end;
>> > var
>> >   t: TTest;
>> > begin
>> >   FillChar(t, SizeOf(t), 0);
>> > end;
>> > (...)
>> >
>> > The above code will have the hint that "t" is not initalized.
>> >
>> > Regards,
>> > Sven
>>
>> t.t := 0; // ;-)
>
> I don't consider this a nice solution...

I don't either ;-)
Of course the check would need a switch, I don't intend to change the
whole Pascal code base...
My post was indeed about getting some more persperctive about the
roadblockers - WRT both application and implementation - but I decide
it was too big and "cleaned" a bit too much :-$


>> This reminds me that a magic compiler procedure to zero-fill records
>> without the sizeof parameter (and without the hint) has always been on
>> my wishlist :-) (now I'll have to dig the message where sb explained
>> why FillChar couldn't be declared with 'out' - IIRC something
>> regarding interfaces)
>
> In 2.7.1 (implemented for around three quarter of a year):
>
> === example begin ===
>
> t := Default(TTest);
>
> === example end ===
>
> Regards,
> Sven

Great! Almost fantastic :-)
Looking forward for the 2.8 release.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Improper OUT usage.

[Flávio Etrusco]

On Sun, Mar 10, 2013 at 6:08 PM, Sven Barth  wrote:
> On 10.03.2013 20:39, Flávio Etrusco wrote:
>>
>> I'd really like the compiler would stop with an error if it can't
>> prove a variable/out/result is initialized.
>> Did anybody try implementing this in FPC?
>
>
> Have fun fixing the errors then:
>
> === example begin ===
>
> type
>   TTest = record
> t: LongInt;
>   end;
> var
>   t: TTest;
> begin
>   FillChar(t, SizeOf(t), 0);
> end;
>
> === example end ===
>
> The above code will have the hint that "t" is not initalized.
>
> Regards,
> Sven

t.t := 0; // ;-)
This reminds me that a magic compiler procedure to zero-fill records
without the sizeof parameter (and without the hint) has always been on
my wishlist :-) (now I'll have to dig the message where sb explained
why FillChar couldn't be declared with 'out' - IIRC something
regarding interfaces)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Improper OUT usage.

[Flávio Etrusco]

On Sun, Mar 10, 2013 at 11:56 AM, Marco van de Voort  wrote:
> In our previous episode, Vincent Snijders said:
>> > So be careful if you use OUT with types that have range limitations. Not
>> > setting the out parameter can make debug tools like gttt difficult.
>> >
>>
>> You found a big in fcp-passrc, because if you have an out parameter,
>> then the callee has to output a valid variable. If it asumes that is
>> initialized when called, then it must use var instead.
>
> I already had changed it to var in r23760. I did want to warn for the
> bug's pattern, so I wrote this to the ml.
>

I'd really like the compiler would stop with an error if it can't
prove a variable/out/result is initialized.
Did anybody try implementing this in FPC?

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

Re: [fpc-devel] Status of SEH in FPC

[Flávio Etrusco]

On Sun, Mar 3, 2013 at 1:28 AM, Sergei Gorelkin  wrote:
> 03.03.2013 2:53, Flávio Etrusco пишет:
>
>> Hello,
>>
>> what's the current state of the SEH in FPC trunk?
>> IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
>> in the 2.7 roadmap, but I can't find any related brach, or commit, or
>> post.
>> Also AFAIU would have some gains in both executable size and speed,
>> correct?
>>
> By now SEH is fully implemented for Win64 target, but you need to cycle the
> compiler with OPT=-dTEST_WIN64_SEH to enable it.
> The most of it was committed in revision 20098.
>
> The effect of SEH is two-fold: it gives some performance gain when running
> without exceptions, but big penalty when exceptions occur. It somewhat
> reduces code size but at the same time adds some data, so executable size
> may not reduce.
>
> The main advantage of SEH is the conformance with OS exception handing
> scheme. Without it, it was almost impossible to use DLLs that raise
> exceptions.
>
> Regards,
> Sergei

Thanks. And are there any plans to implement it for Win32?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Status of SEH in FPC

[Flávio Etrusco]

Hello,

what's the current state of the SEH in FPC trunk?
IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
in the 2.7 roadmap, but I can't find any related brach, or commit, or
post.
Also AFAIU would have some gains in both executable size and speed, correct?

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Flávio Etrusco]

On Thu, Feb 7, 2013 at 2:33 PM, Graeme Geldenhuys
 wrote:
> On 2013-02-06 19:24, Graeme Geldenhuys wrote:
>> Semaphore functionality seems pretty simple though, (...)

Not if you want high performance and multi-processor support.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Problem with nested classes and const struct values

[Flávio Etrusco]

FWIW FPC 2.6.0 also triggers the same error. AFAICS this problem is
somewhat analogous to the limitation when declaring members in a
record. Are you sure the unit in your big project is being compiled?

-Flávio

On Mon, Apr 30, 2012 at 3:39 PM, Andrew Brunner
 wrote:
> Well,
>
> The problem started when I did a fresh install of Ubuntu 12.04.
> The main project that uses similar code to my attached test had FPC raise
> the same error but with similar code.
> Presently, a fresh build of FPC and Lazarus allows me to build my big
> project however, the test project still won't build with
>
> Compiling ./Test.lpr
> Test.lpr(65,36) Error: Incompatible types: got "Pointer" expected "PCLSInfo"
> Test.lpr(65,44) Error: Illegal expression
> Test.lpr(66,36) Error: Incompatible types: got "Pointer" expected "PACLInfo"
> Test.lpr(66,44) Error: Illegal expression
> Test.lpr(73) Fatal: There were 4 errors compiling module, stopping
> Fatal: Compilation aborted
>
> But yet my big project with very complex nested declarations compiles just
> fine
> 
> unit coAdmin;
>
> interface
>   uses hTimer,hHTTP,hHTTPd,hRSR,uRSR,Classes,uCoreObjects,uKeywords,
>     hSRConsts,uTimer,uStringArray,uVarString,uKPList,hDateUtils,uFileUtils,
>
> dbmDomains,dbmCoreObjects,dbmUserAccounts,dbmRSS,dbmCalendaring,hDatabase;
>
> Type
>   ns=class
>   Type
>     Admin=class
>     const
>       XMLInf:TXMLInfo=(
>         Enabled                  : false;
>       );
>       ACLInf:TACLInfo=(
>         Name                     : 'Admin';
>         NameSpace                : '/core/admin';
>         Caption                  : 'Administration Core Object';
>         Prompt                   : 'User can access administration
> dashboard';
>         Description              : 'Back-end system administration handler'
>       );
>       CLSInf:TCLSInfo=(
>         Name                     : 'TAdminCore';
>         Location                 : 'coAdmin.pas';
>       );
>       Header:TCoreObjectInfo=(
>         ID                       : 0;
>         ProviderID               : 0;
>         Enabled                  : true;
>         Anonymous                : false;
>         NotifyOnBuffersChanged   : false;
>         Scale                    : 0;
>         CLSInfo                  : @CLSInf;
>         ACLInfo                  : @ACLInf;
>       );
>     
>
>
> On Mon, Apr 30, 2012 at 1:12 PM, Jonas Maebe 
> wrote:
>>
>>
>> On 30 Apr 2012, at 16:48, Andrew Brunner wrote:
>>
>> > This problem did not exist a few days ago.
>>
>> Can you be more precise? I just checked with trunk from before the
>> jvmbackend merge (which is from Thursday), and that one also gives an error.
>>
>>
>> Jonas___
>> 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 maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Strange Problem!

[Flávio Etrusco]

You program isn't valid. You're assigning a constant (a global
variable) to Result, so you shouldn't change it's contents through a
pointer (if you change it normally the compiler+RTL will COW the
value).
You can use a shortstring or:
Result := StringOfChar(' ', 16);

-Flávio

On Tue, Apr 24, 2012 at 7:36 PM, Amir  wrote:
> Hi,
>
> I have encountered a strange problem. I developed the following function as
> a faster implementation for IntToStr:
>
>
> function MyIntToStr (n: Int64): AnsiString;
> const
>  MaxLength= 16;
>
> var
>  CurDigit: PChar;
>  Sign: Boolean;
>
> begin
>  Result:= '                ';
>
>  CurDigit:= @(Result [MaxLength]);
>  Sign:= False;
>
>  if n< 0 then
>  begin
>    Sign:= True;
>    n:= -n;
>
>  end;
>  if n= 0 then
>    Exit ('0');
>
>
>  while n<> 0 do
>  begin
>    CurDigit^:= Char (48+ n mod 10);
>    Dec (CurDigit);
>    n:= n div 10;
>
>  end;
>  if Sign then
>    CurDigit^:= '-';
>
> end;
>
> And then, in main , I have
>
> begin
>  WriteLn (MyIntToStr (5458));
>  WriteLn (MyIntToStr (5458));
>  WriteLn (MyIntToStr (2));
>
> end.
>
> The output is:
>           5458
>           5458
>           5452
>
> I tried gdb and noticed the first line of MyIntToStr (Result:= '...') is not
> executed correctly. I am using fpc-2.6.0-1.x86_64
>
>
> Thanks,
> Amir
> ___
> 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

Re: [fpc-devel] JVM: Question regarding converted Java code

[Flávio Etrusco]

On Thu, Dec 29, 2011 at 10:49 AM, Jonas Maebe  wrote:
> On 28 Dec 2011, at 23:28, Sven Barth wrote:
>
>> 1) as it seems to be a rather usual practice in Java, would it be possible 
>> to disable the "Constructor should be public" warnings if the target cpu is 
>> the JVM?
>
> Yes.

BTW, is there anything you dislike about Java "constructor model"? ;-)
 (i.e. must call some inherited constrcutor, constructor can be -
enforced - private, default public constructor if none declared, etc)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ansistring code page

[Flávio Etrusco]

On Thu, Oct 13, 2011 at 7:13 PM, Paul Ishenin  wrote:
> 13.10.2011 21:21, Jonas Maebe wrote:
>>
>> This I don't really understand.
>
> This is how delphi works according to my tests. I will retest to be 100%
> sure.
>
>> Shouldn't the constant be converted at run time from UTF-8 to the
>> DefaultSystemCodePage to make sure that an ansistring(0) variable always
>> contains strings encoded in the DefaultSystemCodePage? If you assign e.g. a
>> string(866) variable to a plain ansistring variable, then such a conversion
>> is also done, no?
>
> Best regards,
> Paul Ishenin

Does this also happen if the string contains non-ASCII chars? If it
doesn't, the first case seems like a fine optimization to me ;-)

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

Re: [fpc-devel] Re: Converting records back and forth. (Forward declarations for records needed ?!?)

[Flávio Etrusco]

And this feature can be implemented with operators, but this is
discussion for fpc-pascal, I guess.

-Flávio

On Tue, Sep 20, 2011 at 9:52 AM, Sven Barth  wrote:
> Am 19.09.2011 12:32, schrieb Skybuck Flying:
>>
>> Not sure if it compiles in free pascal, but it does compile in Delphi XE
>> at least ;)
>
> See here: http://wiki.freepascal.org/Helper_types
>
>> // solution: record helper
>> TrecordBhelper = record helper for TrecordB
>> private
>> // mData : double;
>> public
>> // property Data : double read mData write mData; // must be in TrecordB
>> apperently ?!?
>
> Helper types must not contain fields as they aren't instantiated.
>
> Regards,
> Sven
> ___
> 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

Re: [fpc-devel] ViewVC configuration

[Flávio Etrusco]

On Mon, Sep 19, 2011 at 5:55 AM, Vincent Snijders
 wrote:
> 2011/9/18 Flávio Etrusco :
>> On Sat, Sep 17, 2011 at 5:55 AM, Michael Van Canneyt
>>  wrote:
>>>
>>>
>>
>> It made, thanks a lot!
>> You can see for yourself:
>> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/?root=lazarus&view=log
>> I guess now I can add a link in the wiki ;-)
>
> How can it be turned off? I prefer to see all files in a directory at
> once, instead of going through another page selection.
>
> For example from
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/ide/?root=lazarus I
> cannot choose lazarus.lpi anymore.
>
> Vincent

Sorry, Michael (and Vincent) I didn't know it also applied to file listings :-/

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

Re: RE : [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

On Mon, Sep 19, 2011 at 4:36 AM, Marco van de Voort  wrote:
> In our previous episode, Fl?vio Etrusco said:
>> compatibility feature, and as such should care more about correctness
>> and ease-of-use rather than performance. I thought the endless bugs
>> WRT to char vs codepoint indexes, even in Java-developed software,
>> would buy my argument...
>
> IMHO you are seeking the problems in the tools, while the problem is PEBKAC

I partly agree it's PEBKAC, but why make it easy to get wrong when you
can avoid it? Isn't that the point of Pascal? Isn't that the point of
AnsiStrings? Isn't that the point of strong typed languages in
general?

> The base principle should be to mess with strings as little as possible, in
> that sense you are right.
>
> I don't like the Java/C# way that you have to manually allocate extra
> objects (stringbuilders etc) to get(performant) access to the characters 
> though.

At least we are not tied by bytecode & VM, so I think we can make better ;-)
Is it unthinkable to have the basic/native string type an object?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: RE : [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

On Sun, Sep 18, 2011 at 11:45 AM, Jonas Maebe  wrote:
>
> On 18 Sep 2011, at 13:57, Flávio Etrusco wrote:
>
>> One obvious way to mitigate this would be to store the last
>> CodePoint->Char in the string record, so that at least the most common
>> case is covered.
>
> ... and so that the common case is broken in multithreaded environments.
>
> Directly indexing a string will most likely always work using fixed-length 
> steps (8, 16, 32 bit).
> If you want to iterate based on anything else (such as code points), use some 
> kind of
> iterator model instead.
>
> Jonas

By "the most common case" I meant non-threaded ;-) But no, I don't see
any trivial and efficient solution to avoid the worst case (but among
threadvars, per-string fixed lookup table, shared lookup caches,
per-reference data (like Object), etc, there must be a good solution).
Basically I think the UnicodeString should move farther (than
AnsiString) away from PChar, from the compiler/RTL POV.
I think that the user should (have to) use the iterator model to
*efficiently* iterate over the string, but I see indexed access as a
compatibility feature, and as such should care more about correctness
and ease-of-use rather than performance. I thought the endless bugs
WRT to char vs codepoint indexes, even in Java-developed software,
would buy my argument...

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

Re: RE : [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

On Sun, Sep 18, 2011 at 6:50 AM, Marco van de Voort  wrote:
> In our previous episode, Fl?vio Etrusco said:
>>
>> That's somewhat what I was thinking. Actually something like
>>
>>   UnicodeString = object
>>   (...)
> Such ability is not unique for an object. One can also do something like
> that with a native type.
>


Of course. That wasn't meant as a real implementation, I just decided
to write some code instead of explaining in words.
Basically my point was to people discussing endlessly without any data
or observations, that FPC already provides much of the tools for a
non-native implementation to be made and gather real and practical
data.

> It was discussed and rejected.
>  The trouble is that it is not that easy, consider the first thing a
> long time pascal user will do is fix his existing code which has many
> constructs that loop over a string:
>
> setlength(s2,s1);
> for i:=1 to length(s1) do
>  s2[i]:=s1[i];
>
> Now, to return codepoint[i], you need to parse all codepoints before [i].
>
> So instead of O(n) this loop suddenly becomes O(n^2)

I hope then that either I'm wrong or that you change your mind ;-)
IMHO what must be changed is the way to deal with strings.
I must assume from this preoccupation that you're talking about a a
directive to make the String keyword instantiate a UnicodeString?
Also IMVHO in that compiler mode the code just needs to work, not
fast, and the user code be updated/fixed.
One obvious way to mitigate this would be to store the last
CodePoint->Char in the string record, so that at least the most common
case is covered.

Best regards,
Flávio

PS. Sorry for the double post, Marco.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: RE : [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

On Sat, Sep 17, 2011 at 10:59 AM, DaWorm  wrote:
> This might be total crap, so bear with me a moment,  In an object like
> a Stringlist, there is a default property such as Strings, such that
> List.Strings[1] is equivalent to List[1], is there not?  If, as in
> .NET or Java, all strings become objects, then you could have a String
> object whose default property is Chars, whose type isn't really a
> char, but another String whose length is one entity.

That's somewhat what I was thinking. Actually something like

  UnicodeString = object
  strict private
FEncoding: Integer;
FBuffer: AnsiString;
function GetCodePointAt(AIndex: SizeInt): Integer;
procedure SetCodePoint(AIndex: SizeInt; p_Value: Integer);
  public
property CodePoint[AIndex: SizeInt]: Integer read GetCodePointAt
write SetCodePoint; default;
  end;


I just don't whether something like this is already implemented in the
test branches, at least for -err- testing...

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

Re: [fpc-devel] ViewVC configuration

[Flávio Etrusco]

On Sat, Sep 17, 2011 at 5:55 AM, Michael Van Canneyt
 wrote:
>
>
> On Fri, 16 Sep 2011, Flávio Etrusco wrote:
>
>> Hello,
>> may the FreePascal's ViewVC installtion be configured to paginate log
>> results?
>> It's log_pagesize in viewvc.conf.
>
> I added the entry. But it's undocumented, so I'm not sure if it will have
> any effect.
>
> Michael.

It made, thanks a lot!
You can see for yourself:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/?root=lazarus&view=log
I guess now I can add a link in the wiki ;-)
Curiously the pagesize for the lazarus seems to differ from fpc, but
well, who cares :)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] ViewVC configuration

[Flávio Etrusco]

Hello,
may the FreePascal's ViewVC installtion be configured to paginate log results?
It's log_pagesize in viewvc.conf.

Best regards,
Flávio

PS. There's no mention of any bugs related to it since 1.0.1 ;-)
http://viewvc.tigris.org/source/browse/*checkout*/viewvc/tags/1.1.11/CHANGES
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: the feature request, that started the discussion [Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwa

[Flávio Etrusco]

>
>> 2) Execution of that properties. (getter)
>> I understand it depends on GDB, and FPC can probably not affect it much.
>>
>> As far as the dwarf debug info can have an influence (if at all), it
>> would be nice, if execution was NOT automatic.
>
> This is in contradiction with 1.
>

I guess Martin means that dwarf3 data must allow gdb (or any other reader) to
differentiate whether the property is "implemented" by a getter or a
field.

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

Re: [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

Who will be the first to write a UnicodeString object that uses an
AnsiString as buffer so we can start doing some tests?
What is in the cpstrnew and other unicode branches of FPC? (sorry, I'm
using a 3G limited connection and FPC doesn't have a viewvc...)
Can we start putting well thought-out specs and use-cases in the wiki
instead of the endless swinging discussion?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode support (yet again)

[Flávio Etrusco]

On Wed, Sep 14, 2011 at 6:04 AM, Felipe Monteiro de Carvalho
 wrote:
> On Wed, Sep 14, 2011 at 10:46 AM,   wrote:
>>> Can you clarify a bit. When you say "unicode string" to you mean UTF-16
>>> (Delphi's definition of a unicode string), or do you mean a Unicode
>>> string in the true sense - it can be utf-8 or utf-16 etc depending on
>>> the platform's native encoding.
>>
>> This has not yet been decided.
>
> IMHO a platform-dependent string would be the worse solution of all
> ... far worse then migrating to UTF-16.
>
> It adds tiny bit of speed while it puts a large development complexity
> burdain ... I imagine how one would explain that kind of thing to
> newbies ...
>

Why would the internal enconding of a RTLString/UnicodeString have to
affect any effect how you program if the RTL/API is done right?

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

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

[Flávio Etrusco]

On Mon, Sep 12, 2011 at 11:42 PM, Hans-Peter Diettrich
 wrote:
> DaWorm schrieb:
>>
>> I don't understand why a property with a getter could ever be ran by a
>> debugger.  If I have a property called NextValue, implanted by a method
>> called GetNextValue, that increments a field, stores it in a database, and
>> returns the new value, I absolutely do not want the debugger to execute that
>> even if I'm dumb enough to try to ask it to view that property.
>
> Right, property getters can have side effects, like all procedures. That's
> why I already suggested an hint on property declarations, telling which data
> item should be displayed for the property.
>
> DoDi
>

Yes. Delphi has/had an option to enable function calls/side effects on
property evaluation.
Often times the getter is "pure" (no side-effects, just return a field
value), it's just either virtual or an interface property, or fetched
from an internal helper.
GDB supposedly has support for reverse execution/walking back; I don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)

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

Re: [fpc-devel] Delphi XE2 uses FPC for iOS target

[Flávio Etrusco]

On Fri, Aug 12, 2011 at 9:18 AM, Michael Schnell  wrote:
> On 08/12/2011 01:56 PM, Thaddy wrote:
>>
>> It is not slow at all, it is lightning fast.
>
> So it obviously does use rendering hardware.
>>
>> As far as I suspect the framebuffer manipulation is indeed through the
>> kernel.
>
> I did not take a look into the framebuffer driver API, but it's quite
> obvious that it does provide support for hardware rendering.
>>
>> If you use openGL v2 there's of course just one abstraction layer extra.
>
> Yep. I did understand wrong that not using GL would imply not using the
> rendering hardware and directly writing to  the pixel array instead.
>
> -Michael
>

I remember people complaining that Android didn't do (IIRC) screen
composition on the GPU, and this was even officially disclaimed.
Unfortunately all I could find right now is this:
http://androidforums.com/android-lounge/29584-why-doesnt-androids-gui-use-gpu-acceleration.html
Hmm, and this: 
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html

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

Re: [fpc-devel] Const optimization is a serious bug

[Flávio Etrusco]

On Sat, Jul 9, 2011 at 6:55 PM, Hans-Peter Diettrich
 wrote:
> Flávio Etrusco schrieb:
>
>> Isn't this unfortunately encumbered by patents?
>> http://wiki.winehq.org/CompilerExceptionSupport
>>
>> http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent
>
> Software patents should not be a problem outside the USA. A nice try, but
> unimportant for non-resident free software writers and distributors.
>
> DoDi
>

I know that, I just wanted to raise the issue, since nobody raised it
and I don't/didn't whether all FPC developers lived outside US.
I'm brazilian (and live in Brazil) and this is - for now... - not an
issue here either.

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

Re: [fpc-devel] Const optimization is a serious bug

[Flávio Etrusco]

On Fri, Jul 8, 2011 at 7:05 AM, Jonas Maebe  wrote:
(...)
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for "try",
> but low overhead when an exception actually occurs (of course, since
> exceptions are supposed to happen only exceptionally, that's not a really
> good selling point). The main reason we use it is because it's easy to
> implement.
>
> A better approach would be to use SEH-based exception handling (which has no
> overhead at all for "try", and a high overhead in case an exception occurs),
> but that woud require
> a) support for generating EH frames for all platforms (it's currently only
> supported for a number of i386 and x86-64 platforms)
> b) support for parsing EH frames on all platforms and performing exception
> handling based on that
>
> This is definitely something we want, but nobody has found the time yet to
> implement it.
(...)

Isn't this unfortunately encumbered by patents?
http://wiki.winehq.org/CompilerExceptionSupport
http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent

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

Re: [fpc-devel] Compiling FPC with DEBUG

[Flávio Etrusco]

>
> Thanks, I will try.
> BTW, what that mean DEBUG=1? Is it exists =2, =3, etc?

AFAIK no.

>> 2) Did you try running make inside the dir with debug then running the
>> normal compile&install procedure?
>
> No, I didn't because I didn't know this procedure.
>
>> AFAICT fpc-pascal was ok (if not better) for this question.
>
> I posted in fpc-pascal, but nobody answered me!
>

I know, that's why I said that ;-)
I was going to reply there yesterday but I couldn't because my
internet connection (TIM 3G) was problematic. And still is :-/
Sometimes people take time to reply. Specially when the answer was not
so difficult to find in google ;-)

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

Re: [fpc-devel] Compiling FPC with DEBUG

[Flávio Etrusco]

On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas  wrote:
> Hi,
>
> I compile FPC with success using my tutorial:
> http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
>
> Questions:
> 1- How can I compile all packages with DEBUG option?
> 2- How can I compile just one package, eg fcl-xml, with DEBUG option?
>
> Thanks,
>
> Marcos Douglas


1) 
http://free-pascal-general.1045716.n5.nabble.com/Building-FPC-with-debug-information-td3211375.html
2) Did you try running make inside the dir with debug then running the
normal compile&install procedure?

AFAICT fpc-pascal was ok (if not better) for this question.

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

Re: [fpc-devel] 019605: Safety check for "const s: string" (similar to Range or Overflow checks)

[Flávio Etrusco]

>
>>> On top of what I already wrote on mantis. I believe my initial idea can
>>> be further simplified.
>>>
>>> Given:  procedure Foo(const s1, s2: string);
>>
>> What about records, arrays etc. containing ref. counted types?
>
> This case is shlighly different.
>(...)

I suppose Florian already knows that, he just meant it's basically the
same programming/coding error. And also guess he meant "where do we
stop"? ;-)
Maybe just adding the option to disable the const optimization and
letting the programmer figure out whether it fixes or not a bug is a
good enough addition?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Declare variables inside the code

[Flávio Etrusco]

On Tue, May 10, 2011 at 1:26 PM, kingbiz...@gmail.com
 wrote:
> I have been playing on other languages sometimes and I see some features
> that speed-up a lot the code creating. I'm posting here one, I want to see
> what you think about it.
>
> Good: fast algorithm testings, code creating
> Bad?: not a standard of the pascal language
>

I'd love that, not for the coding speed argument, but for the
maintenance argument: reducing escope thus reducing chances of error.
But what I'd like the most is a compilation mode where parameters (or
even local variables) are 'const' (or write-once) by default :-)
Enforcing explicit declaration of every field, class or global used in
a function would be nice too ;-)
But please don't tell to use ADA or the new RedHat language :-D

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type pointer to record before record.

[Flávio Etrusco]

> type
>  TMyRecord = record
>  mPrev : ^TMyRecord; // not allowed.
>  end;

Marco, only if you happen to know from the top of your head, would it
be possible and without consequences to allow this kind of
construction? (i.e. a pointer reference to itself)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] http://freepascal.org/develop.var is outdated (points to 2.2 branch)

[Flávio Etrusco]

Hello,

The FPC "Development" page (http://freepascal.org/develop.var) still
links to 2.2 releases and branch, no mention of 2.4...

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Parameters must match exactly?

[Flávio Etrusco]

On Wed, May 19, 2010 at 2:37 PM, "Vinzent Höfler"
 wrote:
> Graeme Geldenhuys :
>
>> Florian Klaempfl het geskryf:
>> >
>> > At least we try to avoid it to make it people too easy to shoot
>> > themself into the foot.
>>
>> Developers should be free to shoot themselves wherever they want! It
>> should be their choice, not yours.  :-)
>
> In that respect I'm 100% with Florian, although our opinions may differ in 
> the specific details. ;) Yes, shooting yourself in the foot should be 
> possible. But should it be easy, too? Definitely no!
>
> :
>
> -- 8< --
> Pascal
>   The compiler won't let you shoot yourself in the foot.
> -- 8< --
>

If you only used ":-P" instead, Graeme... ;-)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Parameters must match exactly?

[Flávio Etrusco]

On Wed, May 19, 2010 at 12:16 PM, Florian Klaempfl
 wrote:
> Graeme Geldenhuys schrieb:
>> Florian Klaempfl het geskryf:
>>> At least we try to avoid it to make it people too easy to shoot themself
>>> into the foot.
>>
>>
>> Developers should be free to shoot themselves wherever they want! It should
>> be their choice, not yours.  :-)
>
> Then you should switch to K&R-C, it makes this much easier.

Sometimes I just don't when Graeme is kidding. I hope no one ever
disagrees Pascal is about helping developers not shooting themselves -
and others ;) - in the foot...

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

Re: [fpc-devel] Parameters must match exactly?

[Flávio Etrusco]

On Tue, May 18, 2010 at 3:39 AM, Graeme Geldenhuys
 wrote:
> Florian Klaempfl het geskryf:
>> http://en.wikipedia.org/wiki/Factory_method_pattern
>>> Sorry for the sarcasm,
>>
>> Sarcasm? For sarcasm, you need to have a clue.
>
> No need to be rude.
>

At first I thought it was rude too. But thinking again, sarcasm is
nothing more than a worse-than-cynical form of rudeness...

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

Re: [fpc-devel] Parameters must match exactly?

[Flávio Etrusco]

On Fri, May 14, 2010 at 11:45 AM, Graeme Geldenhuys
 wrote:
> Hi,
>
> I tried using FPC 2.5.1 today to see how compatible is our application with
> it compared to FPC 2.4.1
>
> I got stacks of the following errors.  Why is this change forced in FPC
> 2.5.1?  TBulkInvoiceRateListForm class is a descendant of TfpgWindowBase so
> there should be a problem. I don't understand. :-/
>
> -
> frm_bulkinvoiceratelist.pas(84,77) Error: Call by var for arg no. 2 has to
> match exactly: Got "TBulkInvoiceRateListForm" expected "TfpgWindowBase"
> fpg_base.pas(2207,31) Hint: Found declaration:
> TfpgApplicationBase.CreateForm(TComponentClass,out TfpgWindowBase);
> frm_bulkinvoiceratelist.pas(307) Fatal: There were 1 errors compiling
> module, stopping
> 
>
>
> To get my code to compile again, I have to change the following code from
>
>  fpgApplication.CreateForm(TBulkInvoiceRateListForm, BulkDiscountListForm);
>
> ...to this...
>
>  fpgApplication.CreateForm(TBulkInvoiceRateListForm,
>    TfpgWindowBase(BulkDiscountListForm));
>
> Now I have to include ugly casts all over the place. :-(
>
>
> I got similar issues with TStrings and TStringList. TStringList is a
> descendant of TStrings, but I can't pass a TStringList type as a parameter
> to a method declared with TStrings.
>
>
> Maybe I don't understand the var parameter correctly (but haven't tested to
> see what happens if I remove var from parameter list). If I have a class
> instance, when should I pass it to a method or function/procedure as var
> and when don't I need to use var parameters?
>
>
>
> Regards,
>  - Graeme -
>
> --

I thought this feature was an improvement over Delphi too. But IIRC
the argumentation was that it generated confusion, as somebody could
think a reintroduced method would be invoked instead of the base one.
I guess there was some other more compelling reason, but I can't
remember right now, but I'm positive this was already brought up on
the list.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StrUtils unit (is poorly implemented)

[Flávio Etrusco]

Issue tracker:
http://bugs.freepascal.org/view.php?id=16153

2010/3/30 Flávio Etrusco :
> On Tue, Mar 30, 2010 at 6:04 AM, Marco van de Voort  wrote:
>> In our previous episode, Fl?vio Etrusco said:
>>>
>>> Second question: In current code, when ASubText is '', AnsiStartStr
>>> returns False and
>>> AnsiEndsStr returns True. Is this correct?
>>
>> If the string='' then ansistartsstr returns true and endstr false
>>
>> if they string<>'' then both return false.
>
> I don't quite follow. This is what I get:
>
> AnsiStartsStr('', '')      = FALSE
> AnsiStartsStr('', 'aaa') = FALSE
> AnsiEndsStr('', '')       = TRUE
> AnsiEndsStr('', 'ab')    = TRUE
>
> Should I retain this behavior or what?
>
>
>> I'm using the Dutch locale in windows 7.
>>
>> Warning: one of the reasons I never bothered with the ansi* routines is:
>> - they are supposed to be locale dependant in their comparisons.
>> - they have support for mbcs versions of eastern locale codepages, where
>>   chars are not one byte.
>
> Sure. I know this would be relevant for sorting, but are there a
> locale were different byte sequences should be considered equal?
> Actually I guess that there are (like ae vs æ?), but anyway using
> CompareMem is better than the current implementation.
>
>
>> For these reasons, I left them high and dry till we have a bit more
>> direction on unicode. (which might skip them all together)
>
> I imagined that.
>
> Best regards,
> Flávio
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StrUtils unit (is poorly implemented)

[Flávio Etrusco]

On Tue, Mar 30, 2010 at 6:04 AM, Marco van de Voort  wrote:
> In our previous episode, Fl?vio Etrusco said:
>>
>> Second question: In current code, when ASubText is '', AnsiStartStr
>> returns False and
>> AnsiEndsStr returns True. Is this correct?
>
> If the string='' then ansistartsstr returns true and endstr false
>
> if they string<>'' then both return false.

I don't quite follow. This is what I get:

AnsiStartsStr('', '')  = FALSE
AnsiStartsStr('', 'aaa') = FALSE
AnsiEndsStr('', '')   = TRUE
AnsiEndsStr('', 'ab')= TRUE

Should I retain this behavior or what?


> I'm using the Dutch locale in windows 7.
>
> Warning: one of the reasons I never bothered with the ansi* routines is:
> - they are supposed to be locale dependant in their comparisons.
> - they have support for mbcs versions of eastern locale codepages, where
>   chars are not one byte.

Sure. I know this would be relevant for sorting, but are there a
locale were different byte sequences should be considered equal?
Actually I guess that there are (like ae vs æ?), but anyway using
CompareMem is better than the current implementation.


> For these reasons, I left them high and dry till we have a bit more
> direction on unicode. (which might skip them all together)

I imagined that.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StrUtils unit (is poorly implemented)

[Flávio Etrusco]

2010/3/29 Jonas Maebe :
>
> On 29 Mar 2010, at 08:57, Michael Van Canneyt wrote:
>
>> On Sun, 28 Mar 2010, Flávio Etrusco wrote:
>>
>>> are StrUtils just for Delphi compatibility or are they meant for "real
>>> use"?
>>> In the first case, is there an alternative unit? In the second, would
>>> simple patches to implement "AnsiStartsStr" and "AnsiEndsStr" with
>>> CompareMem (for starters) be accepted?
>>
>> They would be accepted.
>
> If accompanied by tests :)
>

First question: is there a rule for test project names? Is
tstrutils1.pp ok? Do I have to register the file somewhere? (couldn't
find anything about it on the wiki)

Second question: In current code, when ASubText is '', AnsiStartStr
returns False and
AnsiEndsStr returns True. Is this correct?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] StrUtils unit (is poorly implemented)

[Flávio Etrusco]

Hello,
are StrUtils just for Delphi compatibility or are they meant for "real use"?
In the first case, is there an alternative unit? In the second, would
simple patches to implement "AnsiStartsStr" and "AnsiEndsStr" with
CompareMem (for starters) be accepted?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] dward debug info - someone promiced more compact debug info than stabs

[Flávio Etrusco]

On Tue, Mar 16, 2010 at 12:41 PM, Paul Ishenin  wrote:
> 16.03.2010 22:33, Jonas Maebe wrote:
>>>
 Why dwarf information has so big debug files (comparing with stabs) on
 windows?
>>>
>>> Because Windows (just like Darwin) does not support referring to DWARF
>>> debug info from one object file to another, so a lot of debug information is
>>> duplicated in multiple units.
>>
>> We also encode more information when using DWARF than when using Stabs
>> (e.g. properties, absolute variables, public/private/protected information,
>> calling convention, virtuality of methods).
>
> But 200 Mb of info for 10Mb executable is too much. How do you think? I
> don't believe that other compilers on windows generates so fat output for
> dwarf. Do you know any similar numbers for gcc?
>
> Best regards,
> Paul Ishenin.

Haven't you ever used MSVC++? ;)

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

Re: [fpc-devel] dward debug info - someone promiced more compact debug info than stabs

[Flávio Etrusco]

On Tue, Mar 16, 2010 at 12:22 PM, Jonas Maebe  wrote:
>
> On 16 Mar 2010, at 15:58, Paul Ishenin wrote:
>
>> Why dwarf information has so big debug files (comparing with stabs) on
>> windows?
>
> Because Windows (just like Darwin) does not support referring to DWARF debug
> info from one object file to another, so a lot of debug information is
> duplicated in multiple units.
>
>
> Jonas

Out of curiosity, is this a limitation of gdb, the library loader, or
the dwarf/library format?


Many thanks,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] properties with getter evaluation in gdb

[Flávio Etrusco]

On Mon, Mar 15, 2010 at 7:31 AM, Jonas Maebe  wrote:
>
> On 15 Mar 2010, at 11:12, Paul Ishenin wrote:
>
>> 15.03.2010 17:01, Jonas Maebe wrote:
>>
>>> the only problem in that respect is that without the hacky
>>> patch mentioned earlier, GDB's Pascal parser does not support expressing
>>> method calls.
>>
>> The remaining question for me is whether you will implement that hacky
>> patch :) ?
>
> It has to be fixed first so it is no longer hacky. I don't know when I will
> have time for that.
>
>
> Jonas

Is it available somewhere?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] properties with getter evaluation in gdb

[Flávio Etrusco]

On Fri, Mar 12, 2010 at 2:11 PM, Jonas Maebe  wrote:
>
> On 12 Mar 2010, at 17:59, Paul Ishenin wrote:
>
>> 12.03.2010 23:51, Paul Ishenin wrote:
>>>
>>> If something more is required please let me know and I will search.
>> Also found the next document with more info: 
>> http://www.agner.org/optimize/calling_conventions.pdf
>
> It describes what we implement currently ("In Borland and Gnu compilers and 
> in 64 bit Linux and BSD, the return pointer is the first parameter"), but 
> that does not seem to be correct according to the bug report mentioned 
> earlier in this thread (there the function result for function test2 is in 
> ecx instead of in eax for some reason).
>

Can't we ask someone from Borland/Embarcadero? Are they that cheap to
hold back such kind of information?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus keeps it's secrets

[Flávio Etrusco]

On Wed, Mar 3, 2010 at 9:08 AM, Jonas Maebe  wrote:
>
> On 03 Mar 2010, at 12:18, Mattias Gaertner wrote:
>
>> On Wed, 03 Mar 2010 11:44:42 +0100
>> Michael Schnell  wrote:
>>
>>> How come LCL is installed with, and RTL is installed without debugging
>>> information ?
>>
>> To fit most user expectations.
>
> For example: if the RTL is compiled with debugging information, "step into"
> will also step into every reference count increase and decrease, every copy
> operation of one ansi/short/widestring to another one, every iocheck
> operation, every threadvar relocation, ...
>
>
> Jonas

And how to enable debug info only for FCL and packages?...

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTL and Unicode filenames operations.

[Flávio Etrusco]

On Wed, Feb 17, 2010 at 4:10 AM, dmitry boyarintsev
 wrote:
> Reported: http://bugs.freepascal.org/view.php?id=15795
>
> It's up to FPC team to accept or reject the package.
>
> thanks,
> dmitry

I've read somewhere that Windows ANSI functions support utf-8?
(despite the name)

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

Re: [fpc-devel] MemSize argument validity

[Flávio Etrusco]

>
> Afaik fastmm does this on Delphi. Together with having barriers before and
> after the allocation that are checked regularly to see if they are
> overwritten.

I'm sure somebody "has to" have asked this before (maybe even me :-$
), but has someone ever tried to port fastmm to FPC?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RFC: changing conditional compilation

[Flávio Etrusco]

>> Hi Jonas,
>> As you can imagine I'd prefer to "solve" the $ifdef "problem" ;-)
>
> To be honest: no, I can't imagine why you would prefer that. The entire
> difference between $ifdef and $if is that $if checks the value of something
> (and hence will give an error if the symbol is undefined) and $ifdef checks
> whether it is defined or not. As far as I can tell, you would simply like to
> be able to use boolean constants in $if expressions.
>

Hope you rethink your opinion the next time you forget to add an {$I}
or mess up a define name ;-)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Debugging operators' overloards

[Flávio Etrusco]

Hello,
is there any known limitation on gdb integration or the debuginfo that
prevents gdb from stopping on breakpoints inside operator overload
functions?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RFC: changing conditional compilation

[Flávio Etrusco]

2010/2/9 Jonas Maebe :
>
> On 09 Feb 2010, at 01:24, Flávio Etrusco wrote:
>
>>> As far as I know, that's how macros behave.
>>>
>>> E.g.:
>>>
>>> {$macro on}
>>>
>>> {$define xxx:=1}
>>>
>>> {$if xxx}
>>> begin
>>> end.
>>> {$endif}
>>>
>>> If you undefine "xxx", you'll get a compile time error.
>>>
>>> Downside: they don't work with booleans for some reason, only with
>>> integers...
>>
>> Hi Jonas,
>> As you can imagine I'd prefer to "solve" the $ifdef "problem" ;-)
>
> To be honest: no, I can't imagine why you would prefer that.

Because everybody automatically uses $ifdef and most of the code would
work with minor intervention. E.g. we usually use something like
{.$define EnableDocking} to undefine the symbol. You'd just have to
force it explicitly $undef or some kind of {$define EnableDocking
disable} or 'false', or something.


> The entire
> difference between $ifdef and $if is that $if checks the value of something
> (and hence will give an error if the symbol is undefined) and $ifdef checks
> whether it is defined or not. As far as I can tell, you would simply like to
> be able to use boolean constants in $if expressions.

This would solve the problem for my code, not conditionals I'm trying
to use on 3rd party code...


>> Yes, I noticed the problem with bools - and that it would fail with
>> "string found but boolean expected" if the name was undefined -,
>
> The latter is the behaviour you want, no?

Yes - apart from puzzling error message to the casual users - but it'd
require to set a convention on the Macro value for on/off and back to
possibly causing errors due to typos.

> Jonas
>
> PS: please reply to the list___

Sorry, I just skip the list sometimes when I think the post will be
just noise to other people. I'd certainly get back to it when I have
something relevant to say ;-)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Announcing releases on LWN

[Flávio Etrusco]

Hello,

maybe it's a bit late to bring this issue (for the current releases),
but is there a reason there was no announcements for the later FPC
releases and no Lazarus announcements ever?
I think LWN is an important channel to divulging OSS projects.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] RFC: changing conditional compilation

[Flávio Etrusco]

Hello,

The problem I'm trying to solve is that I find the $define system to
have a (an unnecessary) propensity for errors caused by typos; if you
don't agree please ignore my YAAP (yet another annoying proposition).

Because of this propensity for erros with the $define system (and
because it causes unnecessary recompilation), I usually prefer to use
'consts' whenever possible; of course this doesn't work for many
cases, including multiplatform development, where you have to omit
whole function declarations and calls. Now there's Macros, but they
wouldn't solve the problem either, unless you'd use some crazy scheme
with "$if declared" or something AFAICS.
What I wished is to change (or add a directive to change) the way
$ifdef/ifndef work, enforcing that symbols are always declared, like
it was a boolean. So one would have to use e.g. {$define EnableFeature
false} to "undefine" it, otherwise conditionals would fail.

I can see it causing some minor annoyances, can anybody see any bigger
problem? (apart from thinking the idea is pointless, which should have
caused you to stop reading in the first paragraph ;-)

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Re[2]: [fpc-devel] Circular references and forward declarations

[Flávio Etrusco]

>
> To summarize: From the language/compiler point of view, large files are
> no problem. We already concluded that, and in some cases the language
> even forces you to use large files.
>
> But, from a personal - human point of view, large files are not always
> nice. At least, some people think so. They want to have some overview
> over the file, or have some preference for one class in a file. (Why?
> Well, people are not  logic entities, they can not handle very complex
> things) Yes, an IDE can help with that.

This reminds me of a component (or something) I intend(ed) to
implement to interactively navigate a synedit view with zoom. The
usage I envisioned for it was the file comparison tool (Pariter) I
started based on Angus Johnson's diff, but I think it would be
interesting to any source code editor...

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

On Tue, Dec 22, 2009 at 9:09 AM, Florian Klaempfl
 wrote:
> Flávio Etrusco schrieb:
>>  But what's your
>> opinion on extending it to standard procedures?
>
> I see no sense in doing so.
>

Do you mean this syntax or the feature at all? Do you know another way
to solve or help the problem I proposed? Would you prefer implementing
another feature (e.g. class or method versioning) instead?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

On Tue, Dec 22, 2009 at 6:34 AM, Jonas Maebe  wrote:
>
> On 22 Dec 2009, at 06:27, Alexander Klenin wrote:
>
>> I'd say rather something like
>>
>> CallSomething(Arg1:=10, Arg2:='Test')
>>
>> which is already sort-of-supported by Delphi for automation classes:
>>
>>
>> http://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi
>
> FPC also already supports it in that scenario.
>
>
> Jonas

Interesting. I guess this situation is little easier because the way
Automation procedure calls pass parameters, right? But what's your
opinion on extending it to standard procedures?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

On Tue, Dec 22, 2009 at 5:14 AM, Michael Schnell  wrote:
> Flávio Etrusco wrote:
>> WhAny alternatives?
>
> Using properties.
>
> -Michael

Err, I don't get it. How do I avoid the situation I mentioned with the
"class/record fields" alternative using properties?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

On Tue, Dec 22, 2009 at 2:27 AM, Alexander Klenin  wrote:
> On Tue, Dec 22, 2009 at 14:42, Paul Ishenin  wrote:
>> 22.12.2009 11:30, Flávio Etrusco wrote:
>>>
>>> Hi all,
>>> I want to propose a syntax extension for the compiler to check
>>> parameters' name on function/procure calls. Would such a patch be
>>> accepted? Does anybody have a suggestion for the  syntax? (i guess
>>> something along the line of a compiler directive to go together with
>>> the parameter value to avoid syntax incompatibility...)
>>
>> You mean something like Basic has:
>>
>> CallSomething(Arg1=10, Arg2='Test') ?
>
> I'd say rather something like
>
> CallSomething(Arg1:=10, Arg2:='Test')
>
> which is already sort-of-supported by Delphi for automation classes:
>
> http://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi
>
> Extending such support to native procedures and functions
> would be, in my opinion, a good idea.
>
> --
> Alexander S. Klenin

Hmm. Does it allow to pass parameter out of the declared order?
I just wanted the check for the correct parameter, but I'm sure people
will then want the additional feature... :-/ Not to mention that with
this syntax some people may think FPC is allowing C-like
assignment-with-result :-o
(And maybe we'd want something to make it clear we're talking about
destination parameters, not some clashing local variable/paramter...)

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

Re: [fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

On Tue, Dec 22, 2009 at 1:42 AM, Paul Ishenin  wrote:
> 22.12.2009 11:30, Flávio Etrusco wrote:
>>
>> Hi all,
>> I want to propose a syntax extension for the compiler to check
>> parameters' name on function/procure calls. Would such a patch be
>> accepted? Does anybody have a suggestion for the  syntax? (i guess
>> something along the line of a compiler directive to go together with
>> the parameter value to avoid syntax incompatibility...)
>
> You mean something like Basic has:
>
> CallSomething(Arg1=10, Arg2='Test') ?
>
> Best regards,
> Paul Ishenin.
>



On Tue, Dec 22, 2009 at 1:42 AM, Paul Ishenin  wrote:
> 22.12.2009 11:30, Flávio Etrusco wrote:
>>
>> Hi all,
>> I want to propose a syntax extension for the compiler to check
>> parameters' name on function/procure calls. Would such a patch be
>> accepted? Does anybody have a suggestion for the  syntax? (i guess
>> something along the line of a compiler directive to go together with
>> the parameter value to avoid syntax incompatibility...)
>
> You mean something like Basic has:
>
> CallSomething(Arg1=10, Arg2='Test') ?
>
> Best regards,
> Paul Ishenin.
>

Exactly! I didn't know/remember Basic had that. Oh well, another
feature I'll have to appreciate in VB (along with the - shell-like,
but poorly implemented - "begin block by default" and specific block
closers) despite my despise for the language ;-)

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

[fpc-devel] Idea/question about a language (syntax) extension

[Flávio Etrusco]

Hi all,
I want to propose a syntax extension for the compiler to check
parameters' name on function/procure calls. Would such a patch be
accepted? Does anybody have a suggestion for the  syntax? (i guess
something along the line of a compiler directive to go together with
the parameter value to avoid syntax incompatibility...)

Rationale:
I guess it's in "everybody"s interest to make auto-generated code and
code refactor more robust; For example, when populating DTOs (data
transfer objects) one have two options: assign each field by name and
run the risk of "forgetting" to initialize some field, or make a
constructor/initializer method and run the risk of changing order of
parameters of the same type.
What do you think? Any alternatives?

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TObject differences between fpc and delphi

[Flávio Etrusco]

(...)
> The ToString Javaism is poorly implemented in Delphi. I suggest that objfpc
> mode should be based on json or similar standards, which are already
> available. Not just rtti writeouts.
>

It's poorly implemented on Java too, nonetheless...

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

Re: [fpc-devel] Compiler hint for uninitialized local variable minor mistake

[Flávio Etrusco]

> (...)
>
> This is due to the fact that if you pass a variable to an out parameter and
> this variable is reference counted or contains reference counted elements
> (in case of an array/record/object), then the compiler has to insert
> finalization code at the caller side for this variable before passing it in.
> The result is that if tmp is reference counted but nevertheless somehow
> contained garbage, e.g. in a program like this:

Is Delphi's behavior the same? I'm not 100% I've read it on any
official source, but I never saw it behave differently than "var
without the warning". Delphi didn't even have the decency to
force/warn one to initialize in the function :-/
Doesn't this have some implications on COM calls? Or is it like this
way exactly to make COM work?

>
> Keep in mind that hints are the lowest level of "programming help" that the
> compiler has to offer, and it is generally impossible to make your code hint
> free. They are only intended to help you if you really are at wits end
> regarding what could be going wrong. Otherwise, it's best to stick to
> warnings and notes.
>

And this make hints so much less useful...

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Warning: Constructor should be public

[Flávio Etrusco]

Actually, your constructor has the same signature as 'TObject.Create',
so it should show a 'lower visibility' warning in Delphi, doesn't it?
But, indeed, FPC shows the warning (should be public) for all
constructors, even if you're not hiding from the parent class, and I
always found this a (minor) annoyance.
But the fact that the semantic of constructors in Delphi/ObjectPascal
have the same visibility rules of "common methods" (i.e. they force
the visibility of the constructor from the parent class) is just sad.
"Even" Java constructors' syntax is better ;-)
Not to mention that you can call constructors on instance "pointer"
(ok, I know this "hack is useful/used in streaming/persistence code),
even uninitialized ones...

-Flávio

On Mon, Apr 6, 2009 at 5:37 PM, Léo Willian Kölln  wrote:
> No.
> See my singleton example:
>
> TLoggerGeral = class
>  private
>  {$IFDEF WINDOWS}
>    class var FInstance : TLoggerGeral;
>  {$ELSE}
>    {$STATIC on}
>    FInstance : TLoggerGeral; static;
>  {$ENDIF}
>
>    constructor Create;
>
>  protected
>    pCritSection    : TCriticalSection;
>    pLogarDatas     : boolean;
>    pLogarTipos     : boolean;
>    pArquivoDestino : TextFile;
>    saidaConsole    : boolean;
>
>    class function getData: String;
>    class function tipoText(tipo: ETipoMensagem): String;
>    class procedure executaOperacaoPrioridade(tipo: ETipoMensagem);
>
>  public
>    destructor Destroy; override;
>    class function GetInstance: TLoggerGeral;
>    class procedure recebeMensagem(const mensagem: String; tipo:
> ETipoMensagem = NORMAL);
> end;
>
> A normal singleton and it complain!
>
> Léo Willian Kölln
>
>
> On Mon, Apr 6, 2009 at 4:41 PM, Graeme Geldenhuys
>  wrote:
>>> Simply question. Why?
>>
>>
>> What did you do, try and lower the visibility of the constructor?  If
>> so, that is also not allowed in Delphi as far as I know.
>>
>> Regards,
>>  - Graeme -
>>
>>
>> ___
>> fpGUI - a cross-platform Free Pascal GUI toolkit
>> http://opensoft.homeip.net/fpgui/
>> ___
>> fpc-devel maillist  -  fpc-de...@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
> ___
> fpc-devel maillist  -  fpc-de...@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

Re: [fpc-devel] Re: Debugger for FPC

[Flávio Etrusco]

>
> I still did not yet get any discussion rolling on the issue of "pure" read
> functions (that have no side-effect). The debugger might use a "pure" read
> function to show the property value, but it can't if the read function is
> not pure. gcc does know about pure functions, thus I suppose DWARF also does
> so. In gcc there is an appropriate procedure attribute that lets the
> programmer define a function as "pure" but I suppose that the compiler also
> can do this automatically.
>
> Delphi seems to do do something similar, as the debugger can show values for
> _some_ properties with read functions, but not for all of them. I suppose
> FPC can be made recognize many read functions as "pure" and thus instruct
> gdb to use the read functions to show the property value.
>
> -Michael

AFAICT Delphi allows one to 'Evaluate' _all_ properties, but only
allow 'Watch' properties with read functions if 'Allow side effects in
new watches' is enabled.

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

Re: [fpc-devel] Mantis monitoring configuration

[Flávio Etrusco]

>
> So this one you should get. IIRC you cannot turn off messages for issues you
> reported.

No problem, I don't want to do this ;-)


>>> BTW, did you know you have (at least) 2 accounts ?
>>>
>
>> Oops. No, I didn't. Or maybe I vaguely remember forgetting my password
>> and mantis not having a password retrieval mechanism at the time 8-)
>> Do they have the same email address? I'm only using the 'etrusco' login.
>
> Yes they have both the same email, thats how I found out (usually when
> strange things happen, pplk have a "forgotten" account). I saw that the last
> login of 'etrusco' was this year. Your other account
> "flavio.etru...@gmail.com" was last logged in at 2007-11-14 22:12
>
>
> Marc
>

Lame me :-$

Thanks again,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Mantis monitoring configuration

[Flávio Etrusco]

2009/3/3 Jonas Maebe :
>
> On 03 Mar 2009, at 06:47, Flávio Etrusco wrote:
>
>> what's the current status on this issue, please?
>> http://bugs.freepascal.org/view.php?id=8803
>
> In what sense? Do you still get emails for all bug reports, or do you not
> get any emails at all (even for your own bug reports)? As far as I know, the
> problem has been fixed, and I thought that email notifications had already
> been re-enabled also for the FPC project. I get them (for bugs on which I
> have commented only), but that doesn't count because I have a "developer"
> profile rather than a "reporter" profile.

AFAICS I get notifications from all bugs reported or modified.


> Did you check whether you have email delivery checked on your "my account"
> -> preferences page?

(Oops, in order to make my original post smaller I ended up removing a
bit too much)
Yes, I tried it. I've even disabled some notifications to lower the
number of messages but I still end up receiving a way more messages
than I'd like to. Unchecking all "Email on" options make me receive no
message at all, not even about my monitored or reported bugs - at
least the last I tried a couple of weeks ago.

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Mantis monitoring configuration

[Flávio Etrusco]

Hello,

what's the current status on this issue, please?
http://bugs.freepascal.org/view.php?id=8803

Best regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New -Xg option in the last 9778 revision

[Flávio Etrusco]

> > > That is partly true. The problem is that setting -Xs doesn't help if 
> > > there is also -g in the
> > > command line. So people think that the compiler strips the executable, 
> > > but in fact the binary is
> > > unstripped.
> > >
> >
> > But why doesn't FPC spit a warning when these (seemingly conflicting)
> > options are used?
>
> It silently switches off -Xs when debug info is selected.
>
> Michael.

Don't you think it should display a warning?

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

Re: [fpc-devel] New -Xg option in the last 9778 revision

[Flávio Etrusco]

On Jan 18, 2008 7:47 AM, Peter Vreman <[EMAIL PROTECTED]> wrote:
> >> I suggested using Lazarus and the OP said he had great doubts because the
> >> size of the exe of his test program is 10 times the size of that compiled 
> >> by
> >> Borland.
> >
> > Anyone who writes such texts doesn't look further than his nose.
> > Experience shows they will just hit the next thing which makes Lazarus
> > "unusable". Don't expect such idiots to become Lazarus users.
>
> That is partly true. The problem is that setting -Xs doesn't help if there is 
> also -g in the
> command line. So people think that the compiler strips the executable, but in 
> fact the binary is
> unstripped.
>
> The easiest way to solve this is with a check in Lazarus. When the strip 
> checkbox is checked a
> note shall be shown and asked to disable the debuginfo to make the option 
> work.
>
> The real solution is what a lot of people already asked for. Multiple build 
> modes like Visual C++
> also has.
>
> Peter
>

But why doesn't FPC spit a warning when these (seemingly conflicting)
options are used?

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

Re: [fpc-devel] .NET Reflection vs RTTI

[Flávio Etrusco]

> (...)
> As far as the information itself that's available through RTTI / Reflection
> is concerned, the type information available in .NET is truly complete, down
> to every field and every method of every type. Also, the ability to
> associate any number of custom attributes with any of the entities that make
> up the type information in .NET is a very powerful tool.
>
> Another huge advantage of Reflection in .NET over RTTI as provided by Delphi
> and FPC is that given an instance of an object and a MethodInfo object
> describing any of the accessible methods of that object it is trivial to
> call that method using MethodInfo.Invoke(Instance, [Array, Of, Parameters]).
> (Access to fields, properties and event is similar easy using the respective
> *Info objects).
>
> The combination of this (truly complete type information, easy access,
> custom attributes) makes it rather trivial to e.g. tag private fields of a
> class with the [Serializable] attribute and use Reflection to serialize the
> class to/from a stream.
>
> Cheers,
> Thorsten
>

You forgot to complete: (...) but 99% of time the it just makes for
useless bloat ;-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] property syntax extension

[Flávio Etrusco]

On 10/18/07, Inoussa OUEDRAOGO <[EMAIL PROTECTED]> wrote:
>
> > It is a strong point.
> >
> > On the other hard keeping the language clean is an important responsible
> > task we have. We never planned to be compatible with Delphi.NET. (I have
> > never considered Delphi.NET a real Pascal implementation; it departs
> > rather far from what Wirth designed). While .NET features will spread to
> > native code I'd like to consider native code features only. Some may
> > originate from .NET in the end, and can be considered, but only because
> > thy have become native Delphi features.
>
> I have a great respect toward FPC devel team. And I do
> anderstand and respect that FPC team do not plan to be
> compatible with Delphi.Net.
>
> But IMHO, if a new langage feature have to be introduced,
> a feature already implemented in Delphi, it will be good
> to make it compatible.   Mainly for code sharing.
>
> --
> Inoussa O.
>

I tend to agree, but Borland has neglected Delphi for so long that I really
wonder if anything above Delphi7 (or even D5) is truly relevant...

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

Re: [fpc-devel] property syntax extension

[Flávio Etrusco]

(...)
>
> Maybe:
>
> procedure MethodX; {%widgetsets win32 wince}
>
> This should be quicker and easier to implement then extending the ppu
> files.
>
> thanks,
> --
> Felipe Monteiro de Carvalho
>

Amen, brother Felipe ;-)
The only downside to is that  it'll probably be necessary to keep some
duplicated parser code...

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

Re: [fpc-devel] delphi compatibility issues

[Flávio Etrusco]

> Ow ?
> I've coded a lot if interfaces with D6 and luckily it complained if I
> forgot to implement some of them.
>


OTOH if the "abstract" keyword for classes was introduced/implemented
in FPC it would be nice to have "partial interface implementation"
just like Java ;-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Release of fpc-2.1.4 aka 2.2.0-beta

[Flávio Etrusco]

On 5/19/07, Joost van der Sluis <[EMAIL PROTECTED]> wrote:

Hello everybody,

I'm happy to announce that release 2.1.4 aka 2.2.0 beta is out. We ask
our users to test the changes made in the last few years. This beta will
be available for about two months, whereafter 2.2.0 will be released.
Helping us to test version 2.1.4 now, can avoid problems when you
finally update your fpc-version to 2.2.0.



Hello,

Is it more interesting from your (FPC developer) POV that people
use/test the 2.1.4 release or the 2.1.5 "branch"?

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [FPC 0008690]: Add option/directive to ignore "Parameter X not used" hint

[Flávio Etrusco]

On 4/14/07, Micha Nelissen <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] wrote:
> The "Parameter X not used" hint is specially annoying in the case you use
> many callback functions like the used in LCL (TNotifyEvent and alike).

Perhaps it's an idea to not show this hint by default for methods
declared in the published section of a class ? Most likely they are
callbacks.

Micha


Virtual methods could very probably join the dance ;-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Patch needed for 'make all' to build

[Flávio Etrusco]

Err, Marco, I guess this is not part of his change?

-Flávio

On 3/20/07, Marco van de Voort <[EMAIL PROTECTED]> wrote:

> Index: packages/base/Makefile.fpc
> ===
> --- packages/base/Makefile.fpc  (revision 6932)
> +++ packages/base/Makefile.fpc  (working copy)
> @@ -3,7 +3,7 @@
>   #
>
>   [target]
> -dirs=hash paszlib pasjpeg regexpr netdb
> +dirs=hash paszlib pasjpeg regexpr netdb fpmake
>   dirs_i386_linux=libc
>   dirs_x86_64_linux=libc
>   dirs_linux=gdbint libasync mysql ibase postgres oracle odbc \

Hmm, and should libc be enabled for x86_64 ? The original idea was not, and
to my knowledge this never has been tested?
___
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

Re: [fpc-devel] Google summer of code

[Flávio Etrusco]

Actually, one can have a Google account with any other "external" email address.

Cheers,
Flávio

On 3/12/07, Marc Weustink <[EMAIL PROTECTED]> wrote:

Felipe Monteiro de Carvalho wrote:
> I already submited.
>
> I simply said that many of our mentors don´t have yet a google account
> but will create one if we are accepted, and added a list of such
> people.

Good to know. I wasn't really waiting on yet_another_mail_account.
(otherwise I would already have a gmail from the early days)

Marc

___
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

Re: [fpc-devel] Array of Ansistring

[Flávio Etrusco]

Thanks for your replies, Florian and Jonas.
This is very nice! I was shocked and puzzled when I found the GNU libc
allocator didn't release VM back to the OS, it's great to confirm you
guys are (IMHO ;-) more sane than the gcc and libc folks :-)

Cheers,
Flávio


On 3/12/07, Jonas Maebe <[EMAIL PROTECTED]> wrote:


On 12 mrt 2007, at 16:25, Flávio Etrusco wrote:

> A slightly related question: does FPC memory manager release unused
> memory back to the OS?

Yes, but not all of it since that causes extreme slowdowns in certain
cases (due to constant freeing and reallocating memory to/from the OS).


Jonas___
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

Re: [fpc-devel] Array of Ansistring

[Flávio Etrusco]

A slightly related question: does FPC memory manager release unused
memory back to the OS?

Regards,
Flávio

On 3/12/07, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:

Jason P Sage wrote:
> MyArray:  Array of ansistring;
>
> There is code I saw that seems to work great using:
>
> SetLength(MyArray,100);
>
> Which allows MyArray[100]:='Some ansiString';

Dynamic arrays start at index 0 up to Length-1, so actually this code would 
corrupt memory ;) (but I assume this is a typo in your mail)

> What I don't know is how to clean this up.

It is cleaned automatically when the array goes out of scope (taking into 
account the refcounting of the dyn array itself), but of course also when you 
explicitly set the strings to '' or the array length to 0, as you proposed 
already. As Marco says, memory is usually not directly released back to the OS. 
BTW, memleaks can also be checked for with the heaptrc unit.

Regards,

Bram


___
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

Re: [fpc-devel] Tail recursion optimization

[Flávio Etrusco]

On a side note, fixing branch priority (order? I like compiler
programming but I'm not very into it :-(  ) takes the run time down by
about 20% on a Duron system...

Do you plan to add some related tricks to FPC? (I'm not talking about
the advanced "lively analysis" that is in the to-do, but rather some
simple tricks like moving code throwing exceptions as if was in the
'else' block, or (in the uncertain optimizations) move to 'else' the
biggest block or blocks containing a single or constant assignment...)

Cheers,
Flávio

On 10/11/06, Vincent Snijders  wrote:


There is a small, but measurable difference:
fpc 2.0.4: 9.04
fpc 2.0.4 without fwait: 8.96

So, there is some speedup, but not spectacular.

Vincent
___
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

Re: [fpc-devel] Suggestion for change: Overly strict check

[Flávio Etrusco]

> There's a reason, I always write "self.Identifier" and I also refuse to
> revert back to the so called Hungarian notation (like AParameter). Even
> if there is *no* parameter and/or field with that name it's always
> clear which part is meant.

This is not Hungarian notation. Hungarian is to prefix variable names
with the (abbreviated) type.



Thankfully I've read recently that this is "hungarian notation done wrong" ;-)
It said the guy quoted as being the creator of the "hungarian
notation" used prefixes according to use of the variable and/or its
scope. It seems he is a smart guy and knew variable type is a compiler
thing and we shouldn't be bothered with it ;-)
But then probably one of his colleagues in MS got it totally wrong and
started using this "type prefix" thing...

At my workplace we've standardized on using three "scope prefixes": p_
for function parameter, m_ for members/fields, and g_ for global. I
have used "scope prefixes" long before this/them and I as a
somewhat-die-hard-Pascal-programmer had a hard time getting used to
the underscores, which seems to divide the identifier and makes you
code look like C, but I barely notice it now ;-) And it's very
practical for code completion :-)
Most of the our projects nowadays are written in Java, though.

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Linking problem

[Flávio Etrusco]

I'd guess this library is exporting (and importing) in C++ symbols and
thus can't be linked with FPC?

-Flávio

On 9/23/06, Ivo Steinmann <[EMAIL PROTECTED]> wrote:

Hello all

I tried to link libmodplug.so but get this error:

/usr/lib/libmodplug.so: undefined reference to `operator new[](unsigned
int)'
/usr/lib/libmodplug.so: undefined reference to `operator delete(void*)'
/usr/lib/libmodplug.so: undefined reference to `operator delete[](void*)'
/usr/lib/libmodplug.so: undefined reference to `operator new(unsigned int)'

do I have to link another library also (something like libstd) or is
there a way that I can define those function in my application? Im a
littlebit confused about "operator"

greets
Ivo
___
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

Re: [fpc-devel] Reading empty collection from stream

[Flávio Etrusco]

Agreed, this is one of the weird Delphi misfeatures...

In later SynEdit versions I implemented custom streameing functions
which only store the "diff" from default keystrokes (i.e. the removed
and added keystrokes compared to the default list).

-Flávio

On 9/7/06, Marc Weustink <[EMAIL PROTECTED]> wrote:

Vincent Snijders wrote:
> Hi,
>
> I am investigating Lazarus issue 7305. The TSynEdit class has a
> KeyStrokes property of the type TSynEditKeyStrokes, which is a
> TCollection descendant. The TSynEdit constructor fills the collection
> with some default items. If I remove the items and stream the TSynEdit,
> the following line is shown in the lfm:
> Keystrokes = <>
>
> If I read this lfm, I don't get a empty KeyStrokes collection, but one
> filled with the default value.
>
> I suspect the following lines in TReader.ReadCollection cause this
> behaviour:
> if not EndOfList then
>   Collection.Clear;
>
> Is this a bug or by design? How do I load an empty collection from a
> stream, if the collection has a default value?

Delphi has the same construction, which is IMO a design flaw.
IMO when a collection is "default" is shouldn't be streamed, so there
would be nothing written.
I don't know why it is there, since when a "default" collection is
written, all elements are written. So it never will be <>.

> Note, if I remove the 'Keystrokes = <>' line from the lfm, I will get
> the default collection too, so I wonder why there are two ways to get
> the default collection.

I propose to remove the "if not EndOfList then Collection.Clear;" line.



Marc
___
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

Re: Re[4]: [fpc-devel] Re: dominant short strings in compiler source

[Flávio Etrusco]

On 5/19/06, Пётр Косаревский <[EMAIL PROTECTED]> wrote:

Sorry, these two letters were accidentally sent personally.

To Felipe Monteiro de Carvalho:

> > probably Windows will become totally utf16 (not really unicode, but
> > at least utf16) really soon (at least in newer versions in a way
> > incompatible with current ones).
>
> A small correction, utf16 is a type of unicode.

Uh, Unicode is a big standard with lotsa features.

UTF.. is "Unicode transformation format".

So, utf16 is a type of representing unicode characters.

And, as I think, basic utf16 support does not include support for representing 
symbols by several utf16 units (unicode is to be about 100 symbols, neither 
much more, nor significantly less).

Also, support for ligatures and other features is weird to non specialized 
programmers too.

I don't think that Windows will support all unicode features in their 
implementation of utf16 in filenames.

But Windows, MS Office, MS Internet Explorer and some more M$ products are 
listed on unicode page as programs supporting unicode.


As the name implies, UTF is a format to allow to represeting every and
all Unicode symbols using diferent block/character size.
UCS-2 and UCS-4 are subsets of the Unicode which can be represented by
single 16bit and 32bit - respectively - characters. UTF-8 and UTF-16
(is there UTF-32?) can represent all of Unicode using encondig some
ranges of symbols with multible "characters".




To FlАvio Etrusco:

> copy of the string) you should access it as a PChar.
>
> as 'const' and 'var', and maybe using PChar in some few places, or can
>
> Cheers,
> Fl  vio

PChar type is no less ugly for pascal than dynamic array.


Why dynamic arrays are ugly? So TList (and TStringList, for that
matter) is ugly, too?
PChar is as ugly as any other Pointer, but in low-level programming it
can be necessary.
Also, using some compiler trickery can be done to optimize usage of
AnsiStrings so we can avoid use of PChars, but of course this will
have to wait a bit.


I have null characters in my strings sometimes. If a char may have zero code, 
string should be able to contain it at any place.


Just get a PChar to the end to the string and compare your runner to
it, instead of searching #0 ;-)

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] 'Variable may not have been initialized' hints

[Flávio Etrusco]

Hi all,
please let me ask a few questions about this "issue":
- why these are hints instead of warnings? (maybe because the code
isn't still show too many false positives?)
- why are they shown to AnsiStrings? Aren't all AnsiStrings always initialized?
- would/will you accept patches to fix FPC code that receives 'var'
parameters but should be changed to 'out'?

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Re[2]: [fpc-devel] Re: dominant short strings in compiler source

[Flávio Etrusco]

On 5/19/06, Daniël Mantione <[EMAIL PROTECTED]> wrote:



Op Thu, 18 May 2006, schreef Flávio Etrusco:

> > L> Dynamic arrays can be very handy and I never knew anyone who avoids
> > L> them. Of course if your array has fixed length there's no reason
> > L> to use a dynamic array either.
> > L> Fortunately it's no very often that one falls in Borland's trap
> > L> that dynamic arrays aren't copy-on-write like AnsiStrings... BTW,
> > L> is this the behaviour in FPC, too?

Free Pascal is Delphi compatible.


I know that FPC aims to be Delphi-compatible, but it's not always the
case, as e.g. the WideStrings were reference-counted until a couple of
months ago.
So you are saying that in this is specific case FPC is already
(unfortunately, as for the WideStrings case) compatible with Delphi?


A lot of people use getmem combined with possibly reallocmem if the array
size should change after initial allocation. It is low level programming
and therefore ugly, but dynamic arrays are being considered ugly as well
by many people because they differ a lot from standard Pascal semantics.

> > L> It's simply because the code has to check there's only one reference
> > L> to the string on each change. If you know there's no concurrent
> > L> access to the string (e.g. you app is single-threaded, or you have a
> > L> local copy of the string) you should access it as a PChar.

This code:

procedure z;

var a:string;

begin
  a:='abc';
end;

... generates this monster with $H+:

P$TESTASTRING_Z:
pushebp
mov ebp,esp
sub esp,52
mov dword [ebp-4],0
lea eax,[ebp-24]
mov ecx,eax
lea eax,[ebp-48]
mov edx,eax
mov eax,1
callNEAR FPC_PUSHEXCEPTADDR
callNEAR FPC_SETJMP
pusheax
testeax,eax
jne NEAR [EMAIL PROTECTED]
lea edx,[ebp-4]
mov eax,edx
callNEAR FPC_ANSISTR_DECR_REF
mov eax,dword [_$PROGRAM$_L12]
mov dword [ebp-4],eax
[EMAIL PROTECTED]:
callNEAR FPC_POPADDRSTACK
mov edx,dword INIT__SYSTEM_ANSISTRING
lea eax,[ebp-4]
callNEAR fpc_finalize
pop eax
testeax,eax
je  NEAR [EMAIL PROTECTED]
callNEAR FPC_RERAISE
[EMAIL PROTECTED]:
leave
ret

With $H- the result is:

P$TESTASTRING_Z:
pushebp
mov ebp,esp
sub esp,256
lea ecx,[ebp-256]
mov edx,dword _$PROGRAM$_L9
mov eax,255
callNEAR fpc_shortstr_to_shortstr
leave
ret

It is therefore not surprising that the shortstring version is faster.
Other reasons why they are faster are that temporary strings are allocated
on the stack, a "sub esp," is a lot faster than a getmem.
Shortstrings also do not need reallocmem if they grow.

> > L>
> > L> > But they are said to be improved in recent versions (recent
> > L> snapshots?).
> > L>
> > L> I find it strange that the cost of copying a ShortString (maybe
> > L> because they are at most 255 bytes? Maybe cache locality usually
> > L> is fine in this case? 8-|   ) is lower(better) than the
> > L> locked-count-reference and the exception trapping...

A shortstring copy is really fast. They are copied with 4 bytes at a time
in assembler code, so you need at most 64 steps to copy a string of
maximum length. Most strings are shorter, like the example above.

However, you are right that copying is a limiting factor in shortstring
performance.

> > L> Anyway, isn't it just the case to correctly optimize string
> > L> parameters as 'const' and 'var', and maybe using PChar in some few 
places, or
> > L> can you think of any other reason for AnsiStrings to be slower than
> > L> ShortStrings?

A lot of them, see above.

Daniël


Wow, thanks really a lot for all the info :-)
What is the disassembler you use? Is there any nice free one? I'll try
to digest that assembly since I'm not a "close friend" to it ;-)
Also, that case is IMHO the bad case of AnsiString (i.e. we have to
add a reference). I'm more interested if there's any overhead when
reading from a 'const' string parameter...

Cheers,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: dominant short strings in compiler source

[Flávio Etrusco]

On 5/19/06, Daniël Mantione <[EMAIL PROTECTED]> wrote:



Op Fri, 19 May 2006, schreef Micha Nelissen:

> On Fri, 19 May 2006 18:29:29 +0100
> Peter Vreman <[EMAIL PROTECTED]> wrote:
>
> > There are already some complains about the memory usage. Increasing the
> > string size adds a lot more overhead. Especially for all the small labels
> > like .L1 etc. Already using longstrings will add 3 bytes for the length
> > alsomost doubling the size from 4 to 7 bytes.
>
> Don't shortstrings always use 256 bytes of memory ?

It depends on wether they are stored in a variable of type "string", or
allocated on the heap with a "Pstring". In all data structures where
memory usage is an issue, the memory friendly Pstring is used.

Still, because the compiler uses a lot of short strings, the internal heap
data structures are an important factor in the memory usage of these
strings.

Daniël



Forgive me if I'm saying BS but it's been about 10 years since I
programmed in TurboPascal (and used ShortStrings), but don't
ShortStrings use the size they are declared with? And 255 is just
default size (if no size is specified)?

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