Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 09.01.2018 02:59 schrieb "Ryan Joseph" :



> On Jan 9, 2018, at 3:30 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
>
> Recently I did a very simple test with Delphi XE3 using TList
and a stock TList. Adding 50,000 and 200,000 integer values to each list,
and timing the creation of the list and population of the list. Then I also
timed the destruction of the list. I was horified to find out how much
slower Delphi's Generics were compared to TList and TObjectList.
Destruction was 250x slower in many cases. Creation and population of the
list was 5x-10x slower.

What does this have to do with generics exactly? If I understand correctly
generics are “meta-programming” where they essentially just re-insert a
generated class based on the template (c++’s naming scheme makes more sense
imo) but they don’t actually add any runtime code.


But you need to program in a way that allows the usage of multiple,
different types. That can more often than not lead to worse performance.

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

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 08.01.2018 12:52 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:



> On Jan 8, 2018, at 5:58 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> FPC essentially reparses a generic during specialization so I'd say that
they definitely affect compile times.

Does c++  not “specialize” in one location like FPC? looking at c++ code I
often see things like Vector used in multiple locations instead of
declaring a single type (I have no idea why they would do that but it’s
very common). Maybe that’s why compile times are so slow?


C++ specializes once per compilation unit (and per unique type parameters).
FPC does this as well, but in addition it will try to reuse a compatible
specialization that's located in the interface section of a used unit.

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

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 08.01.2018 08:50 schrieb "Ryan Joseph" :

I was talking with a c++ developer who explained how templates are
implemented in c++ and how use some recursive method which causes them to
totally murder compile times. This isn’t the first I’ve heard of the
problem though and I recall some game studios who develop engines in c++
saying they are strictly off limits for the same reasons.

Having just started to use generics in FPC myself I was curious if FPC
suffers from the same problem of slow compile times?


FPC essentially reparses a generic during specialization so I'd say that
they definitely affect compile times. However we're still only doing a
single pass of parsing. This while the compilation might be slower it might
not be as bad as with a C++ compiler.

As far as I know no one has done a benchmark for that however.

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

Re: [fpc-pascal] First pas2js public release

[Sven Barth via fpc-pascal]

On 07.01.2018 15:03, Ingemar Ragnemalm wrote:
> and here is an (almost) fully working snake game:
> 
> http://ragnemalm.se/images/santa/snake/snake.html
> 

Perhaps you should write somewhere how the snake is controlled. I
personally am used to using all four cursor keys to control the snake's
movement based on the global coordinate system instead of only left and
right from the local coordinate system on the snake. So I was quite
confused at first as I used "Up", but the snake didn't move there... ^^'

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

Re: [fpc-pascal] Final Methods support

[Sven Barth via fpc-pascal]

Am 06.01.2018 17:31 schrieb "Marcos Douglas B. Santos" :

Does FPC have support for final methods?

Please see ->
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/
Methods_(Delphi)#Final_Methods


Should be supported since 2009, so that would be from at least 2.6.0.

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

Re: [fpc-pascal] String message methods and the self parameter

[Sven Barth via fpc-pascal]

Am 06.01.2018 17:25 schrieb "Ewald" :

Hi,

When reading https://www.freepascal.org/docs-html/ref/refsu31.html#
x82-1040006.5.7 I stumbled on the following text at the bottom of the page:

"In addition to this mechanism, a string message method accepts a self
parameter:
Procedure StrMsgHandler(Data: Pointer;
Self: TMyObject); Message ’OnClick’;

When encountering such a method, the compiler will generate code that loads
the Self parameter into the object instance pointer. The result of this is
that it is possible to pass Self as a parameter to such a method.

Remark: The type of the Self parameter must be of the same class as the
class the method is defined in."

1. This code snippet fails to compile with the message "Message handlers
can take only one call by ref. parameter" (revision 30487, $mode objfpc)
2. "[...] When encountering such a method, [...]": What are the exact
criteria: the parameter name, the parameter type, ...?
3. Can anybody explain what the part "The result of this is that it is
possible to pass Self as a parameter to such a method." entails? How can it
be passed with DispatchStr?
4. Can somebody give an example on how to use this functionality?


Judging from the implementation inside the RTL I'd say that this is a bug
in the documentation. String message methods work like ordinal ones and
take only one parameter.

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

Re: [fpc-pascal] Translate C code

[Sven Barth via fpc-pascal]

Am 06.01.2018 12:23 schrieb "Ryan Joseph" :



> On Jan 6, 2018, at 5:25 PM, Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu> wrote:
>
> So it doesn't crash, because it never loads from this "invalid" address it
> calculates.

Are we talking about the address on the stack at compile time? If no memory
was ever allocated (which I thought nil suggested) then I don’t see where
it’s getting an address of anything.


In this case Nil does in fact have the address 0. Thus the address of a
field in a record with address 0 is its offset in the record.

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

Re: [fpc-pascal] Possible Memory Leak in TThread.Synchronize

[Sven Barth via fpc-pascal]

Am 03.01.2018 12:32 schrieb "Tony Whyman" :


function CheckSynchronize(...)

and this ends with:

else
  begin
  { for Queue entries we dispose the entry and raise the exception }
  Dispose(tmpentry);
  if Assigned(exceptobj) then
raise exceptobj;
  end;
tmpentry := PopThreadQueueHead;
end;

The line "Dispose(tmpentry);" also disposes of a SynchronizeEvent but,
unlike TThread.DoneSynchronizeEvent, there is no RtlEventDestroy.

Am I correct in pointing the finger here for the memory leak?


I know you already found your problem, but nevertheless as explanation:
this code is only reached by asynchronously added events (TThread.Queue())
and there no event is needed, this none is freed or even allocated.

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

Re: [fpc-pascal] Why win64 program are considerably bigger in exe size than win 32?

[Sven Barth via fpc-pascal]

Am 31.12.2017 00:19 schrieb "Martok" :

Am 22.12.2017 um 09:30 schrieb Dennis:
> I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8.
> I discovered my program exe size increased from 6M to 9M.
Just for fun, I wrote a small program to parse Linker Map files and show the
image occupation by source object file (~unit).


Could/would you provide that tool as open source? Does it only work with
PE/COFF or also ELF?


First lesson: FPC's internal linker is *a lot* better than the GNU linker
when
it comes to discarding unused parts. Good job there!



Good to know :D

Second lesson: the RTL's system and classes are large, compared to Delphi
(at
least older versions). They can do more as well, so I'll call that a draw.

And now the on-topic part: this compares an "empty" project (Lazarus:
Project->New->Program), compiled for win32 and win64

As you can see, the win64 image is about a third larger - but not so much
because of the code segments (they end shortly after the cyan "bar" for
typinfo,
before the second occurrence of classes), but more so because of the data
sections following. A lot of that is unwind info (.xdata), I'm afraid I
don't
know what .pdata usually is.


.xdata and .pdata are both used for SEH related data on the non-i386
Windows platforms (x84_64 and ARM as well as the obsolete MIPS and PowerPC
targets).

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

Re: [fpc-pascal] Cannot find entry point of a routine inside a windows 64 dll

[Sven Barth via fpc-pascal]

On 15.12.2017 16:10, Dennis wrote:
>>
>> Okay, that explains things a bit more.
>>
>> May I ask you to provide a small example consisting of program and
>> library (source only) that works in 32-bit, but fails in 64-bit? Try
>> way I can check myself what is going on as I have a Delphi starter on
>> my 64-bit Windows as well. Though it will be the weekend till I'll
>> have the time to look at it.
> 
> Sven,
> 
> Attached is a zipped file containing the Caller program and Callee dll.
> Both Compiled ok in windows 32 but when running Caller.exe, it reported
> the error.
> 
> Thanks a lot.

There were two adjustments I had to do to make it work correctly:

- add {$mode objfpc} to Caller.lpr as I was compiling from the commandline
- adjust the casing of ReOpenExcelWorkBook so that it matched the one
from ReopenExcelWorkBook (these are case sensitive!)

With these changes it worked without problem on win64.

That said you might want to apply the following two points to your
library interface:
- export/import functions/procedures using explicit names (extending
"external LibName" to "external LibName name 'ProcName'" for each
routine to import and adding "name 'ProcName'" for each routine in the
exports section) to be sure that no name mangling interferes here
- add an explicit calling convention to each routine for import and
export (you could use "register", the default calling convention since
Delphi and FPC *should* be compatible here, but "stdcall" would be my
suggestion to be on the save side)

Additionally you can check for any discrepancies using the Dependency
Walker ( http://www.dependencywalker.com/ ). Just open the executable
while the library is located in the same directory and you can see which
routines mismatch.

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

Re: [fpc-pascal] First pas2js public release

[Sven Barth via fpc-pascal]

Am 17.12.2017 08:01 schrieb "code dz" :

good news & thanks for the effort

is it similar to Emscripten ?


Not really. Emscripten (and WebAsm) has the goal to convert native programs
that rely on pointers. It is essentially an assembly language in
JavaScript. Pas2JS is on the other hand a transpiler and does not - as
Michael explained - support native features like pointers. Also if you look
at the generated code you can still understand it without much effort.

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

Re: [fpc-pascal] Cannot find entry point of a routine inside a windows 64 dll

[Sven Barth via fpc-pascal]

Am 13.12.2017 18:13 schrieb "Dennis" <de...@avidsoft.com.hk>:



Sven Barth via fpc-pascal wrote:

> Am 13.12.2017 11:39 schrieb "Dennis Poon" <den...@avidsoft.com.hk  den...@avidsoft.com.hk>>:
>
>
>
> Just for clarification: is the excel_xp.dll written by you or by a 3rd
> party? Or are you talking about a different library written by you? Because
> in the latter case the interfacing choice between your program and *that*
> library nicht be the culprit.
>
> Let me explain. My program is a 32 bit program that collects real time
stock prices and group the prices by each minute into Open, High, Low,
Close, Volume of that minute. The program needs to add these rows of
open,high,lose,close,volume in real-time to an opened Excel Spreadsheet
(that the end users will write his own VBA formula to manipulate the rows I
add).  To do so, I need to use Microsoft OLE Automation but I don't know
how to do it in Lazarus. But there is a component in Delphi that uses OLE
Automation to update an excel spreadsheet, so I wrote my own excel_xp.dll
in Delphi to use that TExcelApplication component (from Delphi) which is
then called by my 32-bit lazarus program.  Everything worked in 32-bit.

Since there is no FREE 64-bit Delphi IDE available, before I purchase a
64-Bit delphi, I need to make sure my Lazarus program can compile to 64 bit
windows program and can call a 64-bit windows DLL so I use Lazarus 64 bit
to write a stub 64-bit windows dll to be called by my 64-bit Lazarus
program. However, on running, it complained "Cannot find entry point of a
routine ", which never happened when everything was 32-bit.

My question is why the exact routine definitions worked in 32-bit but did
not work in 64 bit.


Okay, that explains things a bit more.

May I ask you to provide a small example consisting of program and library
(source only) that works in 32-bit, but fails in 64-bit? Try way I can
check myself what is going on as I have a Delphi starter on my 64-bit
Windows as well. Though it will be the weekend till I'll have the time to
look at it.

Someone might asked why I did not compile the TExcelApplication directly in
Lazarus to do without the linked dll. I tried, it just won't compile and
the task of translating the huge source files from Delphi to FPC is too
daunting.


 What kind of errors did you face?

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

Re: [fpc-pascal] Cannot find entry point of a routine inside a windows 64 dll

[Sven Barth via fpc-pascal]

Am 13.12.2017 11:39 schrieb "Dennis Poon" <den...@avidsoft.com.hk>:



Sven Barth via fpc-pascal wrote:

Am 13.12.2017 03:04 schrieb "Dennis" <de...@avidsoft.com.hk  de...@avidsoft.com.hk>>:
>
> I am converting my windows 32 program to 64 bit.
> It compiled with lazarus without any problem.(fpc 3.0.2)
>
> I also compile the dll that is used, into a 64 bit dll.
>
> However, when I ran the 64 bit program, windows reported 'cannot
> find the entry point "the routine name in the dll" (the dll file name)
>
> In the routine of the dll, there is an out parameter of type
> WideString,
>
> could this be the problem?
>
> If not, what else could be the cause of the problem?
>
>
> Considering the code you gave I really wonder how that ever worked... Did
> you set the calling convention using the $calling directive? Otherwise you
> need to add it to every function. Also you're on the eager side by using
> the "name" clause for the external as you can be sure then what name is
> used. Lastly are you sure that the DLL you're dealing with is a 64-bit
> library?
>
> In the original 32 bit program, I wrote the windows 32-bit dll in the
Starter (FREE) edition of Delphi and call (using those codes I showed you)
from my FPC 32 bit program without any problem.
Since there is NO FREE Delphi for 64 bit version, I wrote a windows 64-bit
program using FPC 64 bit and then try calling it from my FPC 64-bit program
and encountered the "Cannot find entry point of a routine inside a windows
64 dll" error.


Just for clarification: is the excel_xp.dll written by you or by a 3rd
party? Or are you talking about a different library written by you? Because
in the latter case the interfacing choice between your program and *that*
library nicht be the culprit.

In the 32 bit program, I did not use the $calling directive and did not use
'name' clause and it worked perfectly.
I could add the name clause in the 64 bit program, but can you teach me how
to use the $calling directive?
Since in the 64 bit version, i will be writing both the dll and the calling
program, what $calling directive should I use?
Do I need to specify it clearly on both the dll and the calling code?


Perhaps before we go to this you should first explain a bit more how the
structure of your application looks like (regarding libraries), cause
currently I'm kinda confused.


Maybe you should take a look at fpSpreadsheet which allows you to work with
> Excel files of different versions directly and does not need a library.
>
> I tried to use the fpSpreadsheet sample program last time. If the 64 bit
dll thing did not work out, I will have to rely on the fpSpreadsheet thing
but my customers are all used to Excel and prefer sticking to it :-(


Are you trying to interact with a love running Excel instance? In that case
I agree. However if your trying to modify Excel files that are currently
closed then it shouldn't matter whether you use fpSpreadsheet.

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

Re: [fpc-pascal] Overloading IN operator

[Sven Barth via fpc-pascal]

Am 13.12.2017 02:37 schrieb "Fabio Luis Girardi" :

Hi all!

I want to extend some operators in Freepascal. I want to achieve something
like this:

if aStr in ['string item 1', 'string item 2', 'string item 3'] then
  ...
else
  ...;

Following the examples to overload operators, I wrote:

operator in (a:String; b:array of string):Boolean;
var
  c: Integer;
begin
  Result:=false;
  for c:=0 to High(b) do
if b[c]=a then begin
  result:=true;
  exit;
end;
end;

But when I try compile this piece of code:

if aStr in ['string item 1', 'string item 2', 'string item 3'] then
  ...
else
  ...;

I got:

Error: Ordinal expression expected


The problem is not the operator, but the array: before 3.1.1 the "[...]"
operator if used outside a parameter that is an open array *always*
generates a set. This only changed in trunk a few months ago so that the
operator can be used as an array constructor as well. So for now you'd need
to use an array variable on the right side.

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

Re: [fpc-pascal] Cannot find entry point of a routine inside a windows 64 dll

[Sven Barth via fpc-pascal]

Am 13.12.2017 03:04 schrieb "Dennis" :

I am converting my windows 32 program to 64 bit.
It compiled with lazarus without any problem.(fpc 3.0.2)

I also compile the dll that is used, into a 64 bit dll.

However, when I ran the 64 bit program, windows reported 'cannot find the
entry point "the routine name in the dll" (the dll file name)

In the routine of the dll, there is an out parameter of type WideString,

could this be the problem?

If not, what else could be the cause of the problem?


Considering the code you gave I really wonder how that ever worked... Did
you set the calling convention using the $calling directive? Otherwise you
need to add it to every function. Also you're on the eager side by using
the "name" clause for the external as you can be sure then what name is
used. Lastly are you sure that the DLL you're dealing with is a 64-bit
library?

Maybe you should take a look at fpSpreadsheet which allows you to work with
Excel files of different versions directly and does not need a library.

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

Re: [fpc-pascal] How is EntryInformation.OS.haltproc assigned?

[Sven Barth via fpc-pascal]

On 04.12.2017 21:15, Juha Manninen wrote:
> I am testing with a 64-bit Manjaro Linux.
> I get an access violation when closing any LCL application built with
> QT bindings using FPC trunk. When using FPC 3.0.2 there was no access
> violation, and neither with other widgetsets. Only FPC trunk + QT
> posed a problem.
> I remember seeing this for some time, surely half a year, when testing
> FPC trunk.
> An app only says:
>   An unhandled exception occurred at $7F180E69437C:
>   EAccessViolation:
> $7F180E69437C
> Breakpoints inside the app did not reveal anything.
> 
> I wanted to find out what is happening and built FPC trunk with debug info.
> The error happens in procedure System_exit in rtl/linux/system.pp, at line:
>   EntryInformation.OS.haltproc(ExitCode);
> 
> Backtrace is not very useful:
>  #0 SYSTEM_EXIT at system.pp:174
>  #1 fpc_do_exit at ../inc/system.inc:1076
>  #2 main at project1.lpr:20
> 
> In debugger the data in both records "EntryInformation" and
> "EntryInformation.OS" look valid.
> Apparently the haltproc is not assigned. Where should it be assigned?
> The only place under rtl/linux I find haltproc assigned is in
> "si_dll.inc". There procedure _FPC_shared_lib_haltproc deals with
> shared libraries. Not relevant here.

haltproc is assigned in the RTL's Linux startup files. Depending on
whether the specific platform uses assembler or Pascal startup its
either rtl/linux//*prt0.as or rtl/linux//si_*.inc. The
specific file depends on whether you're linking against C-libraries
(cprt0.as, si_c.inc) or not or whether you're building a library
(dllprt0.as, si_dll.inc) or a static program (prt0.as, si_prc.inc). In
case of x86_64 the assembler files are used despite the Pascal files
already existing.

> After the crash I get an assembly window pointing to this line:
>  760AE37C 660f6f442410   movdqa 0x10(%rsp),%xmm0
> Isn't xmm0 a SSE2 register or something? I don't think the compiler
> generated such code.

Yes, xmm0 is a SSE2 register, but they're part of the x86_64 ABI (both
SysV and Windows) and can be used without problems as all x86_64
processers support it (with I think only the really early Athlons being
exceptions).

> Amazingly enough the Lazarus IDE itself when built with QT bindings
> does not crash at the end. Somehow the QT bindings are quilty but how?
> Any clues where I should look for the problem?
Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is there a way to execute code after 'initialization' and before 'main', i. e. AddExitProc complement?

[Sven Barth via fpc-pascal]

Am 28.11.2017 20:04 schrieb "Роман via fpc-pascal" <
fpc-pascal@lists.freepascal.org>:

'Initialization' sections are executed in poorly predictable order, so I
want to partially order them according to some form of explicit
prioritization and execute before control flow enters main block (so I
won't need to run all that initialization by hand, neither I would be able
to forget to do that).


If unit A uses unit B in the interface section then unit B's initialization
section is always run before A's. For the implementation section the same
holds true if there isn't a cycle otherwise it depends on the unit load
order.

Like:

unit UnitA;
...
procedure Init;

initialization
  RegisterUnit('UnitA', @Init);
end;

unit UnitB;
...
procedure Init;

initialization
  RegisterUnit('UnitB', @Init, {priority} +1);
end;

...
procedure SortAndInitialize;
...

Can I run SortAndInitialize before 'main' without additional user actions?


No, you can't.

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

Re: [fpc-pascal] fpc procedure modifier []

[Sven Barth via fpc-pascal]

On 16.11.2017 20:25, Maciej Izak wrote:
> 
> 
> 2017-11-16 20:17 GMT+01:00 Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org <mailto:fpc-pascal@lists.freepascal.org>>:
> 
> One other point to differentiate them: the modifier one always ends with
> a semicolon after the closing bracket, Delphi's attributes never do
> that.
> 
> 
> sadly this is not true at all :(
> 
> see:
> 
> https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=35000
> 
> in above example it works without semicolon without any problems 

Okay, that might be true in the middle of the modifier list, but not if
it's the last one:

=== code begin ===

unit tprocmod;

interface

procedure Bla; cdecl; [public, overload]

var
  test: LongInt;

implementation

procedure Bla;
begin
end;


end.

=== code end ===

This results in "Syntax error, ";" expected but "VAR" found".

In how far that can be used to handle the modifiers and attributes
together in parallel needs to be seen...

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

Re: [fpc-pascal] fpc procedure modifier []

[Sven Barth via fpc-pascal]

On 16.11.2017 14:12, Sven Barth wrote:
> Am 16.11.2017 14:01 schrieb "Mattias Gaertner"
> <nc-gaert...@netcologne.de <mailto:nc-gaert...@netcologne.de>>:
> 
> On Thu, 16 Nov 2017 11:49:59 +0100
> Maciej Izak <hnb.c...@gmail.com <mailto:hnb.c...@gmail.com>> wrote:
> 
> > 2017-11-16 11:39 GMT+01:00 Mattias Gaertner
> <nc-gaert...@netcologne.de <mailto:nc-gaert...@netcologne.de>>:
> >
> > > What $modes support this?
> > > The reason I ask is I'm trying to distinguish them from Delphi
> > > Attributes in pparser.
> > >
> >
> > for Delphi like attributes FPC will have new modeswitch
> "prefixedattributes" .
> > The implicit usage for $prefixedattributes  in
> DELPHI/DELPHIUNICODE mode is
> > not decided yet (but IMO this is probable scenario).
> 
> Good to know. Thanks.
> 
> So, how will FPC distinguish the two []?
> 
> 
> The only idea I have is to check whether the first identifier is a
> attribute and if not handle it as a modifier (or if a comma is following
> the first identifier). 

One other point to differentiate them: the modifier one always ends with
a semicolon after the closing bracket, Delphi's attributes never do that.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc procedure modifier []

[Sven Barth via fpc-pascal]

On 16.11.2017 15:10, Mattias Gaertner wrote:
> On Thu, 16 Nov 2017 14:12:18 +0100
> Sven Barth via fpc-pascal <fpc-pascal@lists.freepascal.org> wrote:
> 
>> [...]
>> So, how will FPC distinguish the two []?
>>
>>
>> The only idea I have is to check whether the first identifier is a
>> attribute and if not handle it as a modifier (or if a comma is following
>> the first identifier).
> 
> pparser can't do that.
> 
> And I fear that this heuristic will lead to confusing error messages. I
> hope there is a better way.
> 
> Delphi does not support it. It thinks it is an undefined attribute. So
> IMO FPC's [] modifier should be disabled in mode delphi+delphiunicode.
> So the problem will only happen in mode objfpc or when the user
> enable the modeswitch prefixedattributes.
> 
> Maybe pparser can use a heuristic. What is the syntax and keywords of
> fpc's [] modifier?

Keywords are all supported modifiers.

"["  [,[,...]] "]"

And this can be mixed and matched with non-bracketed modifiers, so the
following is valid:

=== code begin ===

procedure Bla; cdecl; [public, overload]; iocheck;
begin
end;

=== code end ===

> 
> If it is correct that FPC's modifier was never documented and is
> hardly used, perhaps a $modeswitch procmodifierbrackets can be
> added?

It is at least not totally undocumented:
https://www.freepascal.org/docs-html/current/ref/refsu81.html#x199-22100014.10.12

It's a feature that FPC supports and thus there are probably users out
there that use it no matter whether it's in Delphi mode or not.

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

Re: [fpc-pascal] fpc procedure modifier []

[Sven Barth via fpc-pascal]

Am 16.11.2017 14:01 schrieb "Mattias Gaertner" :

On Thu, 16 Nov 2017 11:49:59 +0100
Maciej Izak  wrote:

> 2017-11-16 11:39 GMT+01:00 Mattias Gaertner :
>
> > What $modes support this?
> > The reason I ask is I'm trying to distinguish them from Delphi
> > Attributes in pparser.
> >
>
> for Delphi like attributes FPC will have new modeswitch
"prefixedattributes" .
> The implicit usage for $prefixedattributes  in DELPHI/DELPHIUNICODE mode
is
> not decided yet (but IMO this is probable scenario).

Good to know. Thanks.

So, how will FPC distinguish the two []?


The only idea I have is to check whether the first identifier is a
attribute and if not handle it as a modifier (or if a comma is following
the first identifier).

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

Re: [fpc-pascal] installing cross fpc in parallel to systems fpc

[Sven Barth via fpc-pascal]

Am 10.11.2017 18:59 schrieb "Marc Santhoff" :

On Fr, 2017-11-10 at 18:22 +0100, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
>
> On Fri, 10 Nov 2017, Marc Santhoff wrote:
>
> > What is that, is ppc used for bootstrapping the cross compiler
> > regardless of any other fpc maybe installed?
>
> Yes. First that ppc gets built with the "other FPC" installed. Or you can
> specify a startup compiler explicitly with FPC= argument to the make. It
> doesn't even need the rtl or anything, just the "ppcXXX" native compiler.
>
> During the first round it builds this new native compiler + rtl which will
> be used to bootstrap the actual crosscompiler then.

Ok. So I have a newer compiler for the base system built on the fly,
nice.


Not really, because only the compiler and RTL are rebuild for the native
system when cross building FPC, all the packages are still missing. So you
nevertheless need to do a complete build for your host life you had done
for your cross compilation target.

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

Re: [fpc-pascal] WinHTTP.h Translation

[Sven Barth via fpc-pascal]

Am 10.11.2017 04:06 schrieb "African Wild Dog" :

Hello,

Does Free Pascal has any header translations for WinHTTP.h

?


Yes, unit WinHTTP in packages/winunits-base.

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

Re: [fpc-pascal] MINIX 3 support

[Sven Barth via fpc-pascal]

Am 10.11.2017 00:05 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:

Does FPC support the MINIX 3 target platform? Or has somebody attempted to
port FPC to that platform?


No, FPC does not support MINIX 3 though I did play around with the idea
some years ago (not that there had been any results). Considering that
nowadays I think they use ELF as well it shouldn't be too hard to start a
port though (not that I'd be the one to do it :P)

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

Re: [fpc-pascal] InitThread/DoneThread

[Sven Barth via fpc-pascal]

Am 27.10.2017 11:08 schrieb "Ryan Joseph" :



> On Oct 27, 2017, at 4:02 PM, Michael Van Canneyt 
wrote:
>
> Why you were advised to include these calls explicitly ?
>
> The only reason I can think of is when your code runs in a DLL, called by
an
> application that creates threads externally, or when you have callbacks
from
> a DLL which can be called from a thread created by the DLL.

I don’t remember because it was years ago. I believe Jonas advised this but
it may have been related to Objective Pascal and some bugs that existed
back then. The threads I’m creating are coming from Apple's Cocoa framework
(which were crashing) but I was also using it in the SDL library for
platform independent threads (which isn’t crashing).

Maybe just old obsolete information so I’ll remove them since they weren’t
doing anything anyways as far as I can tell. Thanks.


I'd guess that this was before lazy initialization of threadvars for
pthreads was implemented (in 2.4 or 2.6 I think). Nowadays that should
indeed not be necessary anymore.

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

Re: [fpc-pascal] Generic compiler error

[Sven Barth via fpc-pascal]

Am 23.10.2017 14:37 schrieb "Maciej Izak" <hnb.c...@gmail.com>:

2017-10-23 14:33 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Don't know. Only time will tell.
>

Did we have new team member? I would like to meet him! ;)


Sadly time isn't around that often. :P (and why do you assume that it's a
he? :P)

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

Re: [fpc-pascal] Generic compiler error

[Sven Barth via fpc-pascal]

Am 23.10.2017 12:55 schrieb "Marcos Douglas B. Santos" <m...@delfire.net>:

On Mon, Oct 23, 2017 at 6:50 AM, Sven Barth via fpc-pascal
<fpc-pascal@lists.freepascal.org> wrote:
> Am 23.10.2017 08:29 schrieb "Marco van de Voort" <mar...@stack.nl>:
>
> In our previous episode, Sven Barth via fpc-pascal said:
>>
>> Type aliases are currently not supported in mode Delphi. In mode ObjFPC
>> they might work, but I'm not sure about that either...
>>
>> That said I also don't see the use of type aliases for generics...
>
> How about a simple
>
>
> type   = anotherunit.;
>
> ?
>
> That is often what I use type aliases for, aliasing code that has been
> factored out of an unit back in.
>
>
> Okay, that's an acceptable use case ^^'

So, can we have this in the next version?  :)


Don't know. Only time will tell.

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

Re: [fpc-pascal] Callbacks as nested functions

[Sven Barth via fpc-pascal]

Am 23.10.2017 11:49 schrieb "Ryan Joseph" :

Is there anyway to get callbacks to work as nested functions? I get crashes
when I try this and I assume it’s because the the compiler is replacing the
first parameter with another value.


What exactly are you trying? If the nested function accesses its outer
scope then it definitely won't work. For that you'd need to wait for
anonymous function support (which are planned - at least a far as I'm
concerned - to also support nested functions).

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

Re: [fpc-pascal] Generic compiler error

[Sven Barth via fpc-pascal]

Am 23.10.2017 08:29 schrieb "Marco van de Voort" <mar...@stack.nl>:

In our previous episode, Sven Barth via fpc-pascal said:
>
> Type aliases are currently not supported in mode Delphi. In mode ObjFPC
> they might work, but I'm not sure about that either...
>
> That said I also don't see the use of type aliases for generics...

How about a simple


type   = anotherunit.;

?

That is often what I use type aliases for, aliasing code that has been
factored out of an unit back in.


Okay, that's an acceptable use case ^^'

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

Re: [fpc-pascal] Generic compiler error

[Sven Barth via fpc-pascal]

Am 23.10.2017 04:14 schrieb "Marcos Douglas B. Santos" :

Hi,

In Pascal we can do this:

type
  TXStream = TStream;

Now, TXStream is just an alias to TStream.

How do the same with generic classes, using mode delphi?

  TBar = TFoo;



Type aliases are currently not supported in mode Delphi. In mode ObjFPC
they might work, but I'm not sure about that either...

That said I also don't see the use of type aliases for generics...

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

Re: [fpc-pascal] Plans to support various ISO modes

[Sven Barth via fpc-pascal]

Am 22.10.2017 10:51 schrieb "Dominik Rappaport" :

Hi,

I hope this question is not part of the FAQ list. What are the plans for
FPC as to the support of the various ISO modes of Pascal? At the moment,
there is a switch to enable "ISO" mode, but it's unclear to me which ISO
standard this option enforces (Standard Pascal 1983 or 1990 or Extended
Pascal). In particular, because even some features from Standard Pascal are
missing:


 The ISO mode refers to Standard Pascal. In trunk there's also a new
work-in-progress ExtPas mode.

For example, FPC:

1. Doesn't raise an error or warning if the wrong order of statements (var
before type) is specified, as mandated by Standard Pascal
2. Doesn't raise an error or warning if "(input, output)" or an equivalent
statement is missing after "program", as mandated by Standard Pascal


Patches welcome.

3. Doesn't implement the get and put procedure
4. Doesn't support Standard Pascal I/O (like f^ as the current input/output)


AFAIK these should be implemented in trunk.

5. Doesn't implement conformant arrays


It might be that these are supported in trunk as well, but I'm not sure.


I've found an old statement where you referred everybody looking for strict
ISO compliance to GNU Pascal. However, GNU Pascal has been discontinued, so
the question arises, whether FPC is going to support a "strict
Standard/Extended Pascal mode" (ideally both) with a full support of these
standards.


Trunk supports Standard Pascal good enough that the P5 code can be compiled
without changes. And yes, the end goal is to have full support for both
standards (especially for ExtPas, which is still in its infancy, patches
are welcome).

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

Re: [fpc-pascal] State of Extended RTTI

[Sven Barth via fpc-pascal]

Am 21.10.2017 04:16 schrieb "Nicholas Ring" :
>
> Hi,
>
> I am just wondering where eRTTI is at for Free Pascal. I have found this
5 year old thread (
http://fpc-devel.freepascal.narkive.com/4OnA5HH5/state-of-extended-rtti),
so I am hoping that it is just around the corner...?

It's WIP, but no time frame. Hopefully before we release 3.2.0.

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

Re: [fpc-pascal] Printing types in generics

[Sven Barth via fpc-pascal]

Am 19.10.2017 08:41 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
>
> > On Oct 19, 2017, at 12:58 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > And your case for tkSString crashes, because that is a ShortString, not
a AnsiString thus you need to cast to PShortString (best avoid "(P)String"
in this context as this could lead to different results depending on the
modeswitches). For the other string types you need to look at tkAString
(AnsiString), tkWString (WideString) and tkUString (UnicodeString).
> >
>
> I know why it crashes at least. Thanks.

You're welcome. :)

> Btw why can’t type helpers be used here? I though you could add those and
just call .Show() or something but I couldn’t figure that out.

You'd need a type helper for every type that you might specialize with and
all those would need to be in scope during the declaration (not
specialization!) of your generic as otherwise they wouldn't be found during
specialization.

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

Re: [fpc-pascal] Printing types in generics

[Sven Barth via fpc-pascal]

Am 19.10.2017 07:45 schrieb "Ryan Joseph" :
>
> How should you print types in generics for debugging? here’s an example
of how I’m doing it now but it’s hacky (forced type casting pointers) and
tkSString crashes like it is. There should be a better solution I think.

There isn't really a better solution, except that you could move that code
to a separate class or record so that you can use it in other
classes/record than TStaticArray as well...
And your case for tkSString crashes, because that is a ShortString, not a
AnsiString thus you need to cast to PShortString (best avoid "(P)String" in
this context as this could lead to different results depending on the
modeswitches). For the other string types you need to look at tkAString
(AnsiString), tkWString (WideString) and tkUString (UnicodeString).

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

Re: [fpc-pascal] Initializing constant (translate from C)

[Sven Barth via fpc-pascal]

Am 16.10.2017 21:36 schrieb "Darius Blaszyk" :
>
> Here's an interesting one. In C I have this code:
>
> #define ID1 MAKE_ID('A', 'B')
>
> Where MAKE_ID is a macro that depending on the endianness of the target
will create either AB or BA.
>
> How would I be able to translate this into Pascal? ID1 preferably would
need to remain a constant. I tried using an inline function without
success. If all fails I will need to define them all individually using an
ifdef for different endian systems. But this would be my last resort.

Best use inline functions for both ID1 and MAKE_ID. The compiler should
optimize away the calls and do a constant concatenation.

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

Re: [fpc-pascal] AbstractError in 3.1.1

[Sven Barth via fpc-pascal]

Am 12.10.2017 13:59 schrieb "Ryan Joseph" :
>
>
>
> > On Oct 12, 2017, at 5:35 PM, Michael Van Canneyt 
wrote:
> >
> > Normally not :)
> >
> > What Sven wanted to ascertain was why you get this error, which is
totally abnormal.
>
> Ok did some tests and here’s an example of how to reproduce it. It’s the
name “system” which is doing it and if I remove that name the error goes
away.
>
> type
> TAbstractClass = class
> function GetLocation (system: TObject): TPoint; virtual;
abstract;
> end;

Wow, okay, that's a nasty one O.o Considering that the "AbstractError" is
in the System unit it's safe to assume that the compiler is getting
confused there.
Would you please open a bug report with this as a full example?

But I'm glad that you found the issue...

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

Re: [fpc-pascal] AbstractError in 3.1.1

[Sven Barth via fpc-pascal]

Am 12.10.2017 10:37 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
>
> > On Oct 12, 2017, at 12:59 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > AbstractError() is the name of the function the compiler uses to
replace abstract methods with (so that they generate an exception when
called). Thus something very strange is going on with your installation :/
>
> Is there anything I can do to track it down? It has been there for 6
months now preventing me from upgrading (I was using 3.1.1 until I got this
bad version and went back to 3.0.2). If I start removing parts of the
program piece by piece I may be able to figure it out but that’s obviously
a last resort and I’ve avoided it for 6 months now. ;)

Could you try whether a test program with an abstract method that you call
compiles correctly?

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

Re: [fpc-pascal] AbstractError in 3.1.1

[Sven Barth via fpc-pascal]

Am 12.10.2017 04:34 schrieb "Ryan Joseph" :
>
> I just built the ppcx64 trunk version 3.1.1 so I could try the memory
management operator overloads we talked about but I’m getting a compiler
error in my project that doesn’t make sense.
>
> On the last line of one unit (literally at end.) I get: error: identifier
idents no member “AbstractError”. What does this mean? There is just the
last line of the unit so presumably it occurred higher up but I don’t have
any other information to go on.

AbstractError() is the name of the function the compiler uses to replace
abstract methods with (so that they generate an exception when called).
Thus something very strange is going on with your installation :/

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

Re: [fpc-pascal] FPC attributes / annotations support

[Sven Barth via fpc-pascal]

Am 11.10.2017 14:45 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> Bringing a discussion from the Lazarus mailing list to here.
>
>
> On 2017-09-24 09:13, Michael Van Canneyt via Lazarus wrote:
> > It's called Attributes. FPC has it too, but it is not yet in trunk.
>
> Is there a timeline when FPC might support attributes/annotations in
trunk?

I do hope to look at it soonish(TM), but no real timeline. Hopefully before
3.2.0 :D

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

Re: [fpc-pascal] Const params question

[Sven Barth via fpc-pascal]

Am 11.10.2017 15:28 schrieb "Ryan Joseph" :
>
>
>
> > On Oct 11, 2017, at 5:01 PM, Michael Van Canneyt 
wrote:
> >
> > No, you need constref then.
>
> Ok, so constref/var are the same in terms of copying. The docs say const
reduces stack size? I never label my parameters with const but maybe it’s
worth it some cases.
>

This is basically only the case for managed parameters like strings and
interfaces as such don't need an implicit try...finally-block in case of
const and constref to correctly reset their reference count in case of an
exception

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

Re: [fpc-pascal] where's the glyph?

[Sven Barth via fpc-pascal]

Am 11.10.2017 13:13 schrieb :
>
> Hi,
>
> LCL provides the usual Delphi equivalent components like TBitBtn and
TSpeedButton  but there do not seem to be any glyphs to go with them.
>
> Do I really have to make my own or are there some resources I have not
found ?

Lazarus/LCL questions are best asked on the lazarus mailing list (
http://lists.lazarus-ide.org/listinfo/lazarus ). While quite some of the
devs there read here as well, you'll get even more feedback regarding
Lazarus/LCL topics there.

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

Re: [fpc-pascal] Resource compilation

[Sven Barth via fpc-pascal]

Am 11.10.2017 08:11 schrieb "Martok" <list...@martoks-place.de>:
>
> Am 25.09.2017 um 14:24 schrieb Sven Barth via fpc-pascal:
> > The RC language itself isn't *that* difficult. Main difficulty would be
to
> > essentially implement a C-preprocessor-compatible preprocessor.
> As I have just discovered, the installer provides a (rather antique) gcc
on
> Windows and depends on build-essential on (all?) *nix platforms, so we
don't
> even need to do that - piping through "gcc -E -xc" should be all we need.
> That just leaves a reader for fcl-res.

The point of our own resource compiler would be to avoid external
dependencies. While me might ship with a gcc on Windows I nevertheless
consider it as an external dependency and thus a preprocessor written in
Pascal would be preferred.

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

Re: [fpc-pascal] compiler option for $J directive

[Sven Barth via fpc-pascal]

Am 11.10.2017 05:12 schrieb "Mr Bee via fpc-pascal" <
fpc-pascal@lists.freepascal.org>:
>
> 2017-10-10 13:28 GMT+07:00 Marco van de Voort :
>>
>>
>> Since it is already largely uploaded, no. We are only waiting on some
>> targets.
>
>
> I thought such a minor fix that don't break any codes could be included.

It doesn't matter whether it's minor. Building has already started and we
definitely won't start that again for something like this.

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

Re: [fpc-pascal] compiler option for $J directive

[Sven Barth via fpc-pascal]

Am 11.10.2017 07:00 schrieb "Mr Bee via fpc-pascal" <
fpc-pascal@lists.freepascal.org>:
>
> 2017-10-10 16:21 GMT+07:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:
>>
>> They were used mainly back at TP times to have procedure local static
variables (cause that is how they behave as inside procedures).
>
> Can we make the {$J-} as default in fpc and objfpc mode for the next
major release?

The default of $J will change in *no* existing mode as that will break
backwards compatibility. It doesn't matter whether it's a major release or
not.

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

Re: [fpc-pascal] alternative name fpc cross

[Sven Barth via fpc-pascal]

Am 10.10.2017 15:21 schrieb "turro75" :
>
> Well,
>
> I think my problem is easier
> when I compile fpc for arm-android target I get ppccrossarm and units
> arm-android (with binutils arm-linux-android-*)
>
> when I compile fpc for arm-embedded target I get ppccrossarm and units
> arm-embedded (with binutils arm-none-eabi-*)
>
> both are able to create binary as I need.
>
> So the last crosschain created overwrites the previous (the ppcrossarm
> executable).
> Is there a way to instruct  fpc.cfg to use an alternative name (i.e.
> ppcrossarmdroid or ppcrossarmembed) when fpc invokes the right compiler?

You can use the same binary for both as long as both compile for the same
ABI (EABI vs. HardFloat vs. OABI).

Alternatively you can supply the -V option for the fpc binary. Used as
"-Vxyz" the compiler driver will call -xyz.

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

Re: [fpc-pascal] getting cross with the cross compiler

[Sven Barth via fpc-pascal]

Am 10.10.2017 08:08 schrieb :

> $make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64
INSTALL_PREFIX=/usr
> Makefile:2914: *** The only supported starting compiler version is 3.0.0.
You are trying to build with 3.1.1..  Stop.
>
> BTW is  that msg  is correct? I just built with 3.0.2 , it seems that the
version block is not specific enough or the message missed a version bump.

Yes, the message is correct as you're trying to build trunk with a trunk
compiler (the Makefile even says you're trying to use 3.1.1). Only a
release compiler (currently 3.0.0 or 3.0.2) is supported.

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

Re: [fpc-pascal] compiler option for $J directive

[Sven Barth via fpc-pascal]

Am 10.10.2017 08:49 schrieb :
> BTW why would anyone want
> {$WRITEABLECONST ON}
>
> writable constants is an oxymoron and goes against the whole philosophy
of strict types which is central to Pascal.

They were used mainly back at TP times to have procedure local static
variables (cause that is how they behave as inside procedures).

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

Re: [fpc-pascal] compiler option for $J directive

[Sven Barth via fpc-pascal]

Am 08.10.2017 22:24 schrieb "leledumbo via fpc-pascal" <
fpc-pascal@lists.freepascal.org>:
>
> > There is my old feature request about it
> > https://bugs.freepascal.org/view.php?id=30344 :) You can monitor it.
>
> No one seems to care to implement it, so if you badly need it:  sj.patch
> 
> Apply in compiler directory (please checkout r37430 at least), I only svn
> diff there, not in the top level directory (I have modifications to
certain
> packages).
>

Applied in r37437. Thank you for the patch.

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

Re: [fpc-pascal] Obtain file size?

[Sven Barth via fpc-pascal]

Am 07.10.2017 21:08 schrieb "Paul Nance" :
>
> I've always (since Turbo Pascal and now with Free Pascal) used FILESIZE.
It works like a charm.
> Even if you do it in assembly its done the same as its done in pascal.

FileSize() has the disadvantage that you need to open the file. But what if
you don't have permissions for that? Permissions to retrieve the file size
when the file is closed are usually available on the other hand, but for
this another mechanism must be used.

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

Re: [fpc-pascal] Managed properties idea

[Sven Barth via fpc-pascal]

Am 07.10.2017 17:15 schrieb "Marcos Douglas B. Santos" <m...@delfire.net>:
>
> On Fri, Oct 6, 2017 at 4:17 PM, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
> > Am 06.10.2017 20:52 schrieb "Marcos Douglas B. Santos" <m...@delfire.net>:
> >> > And reference counting like in e.g. C++ "shared  pointers", that can
> >> > wrap any
> >> > class, without any additional feature (in Pascal we may get this with
> >> > "management operators").
> >>
> >> I don't know about "management operators". Could you explain more about
> >> them?
> >
> > Operators for records that are called when initializing, finalizing and
> > copying that record. See $fpcdir/tests/test/tmoperator[1-10].pp
>
> I saw... Looks like that now a record is a hybrid made by a record plus a
class.
> Thanks for the info.

Records can have methods and operator overloads already since 2.6.0, only
the management operators are a new addition to trunk.

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

Re: [fpc-pascal] Obtain file size?

[Sven Barth via fpc-pascal]

Am 07.10.2017 01:13 schrieb "James Richters" :
>
> I am wondering how to get the file size reported by the OS for a
particular file without opening it.  I tried to search for ‘Free Pascal
File Size’  and variations but all I get are things like this:
>
>
>
> https://www.freepascal.org/docs-html/rtl/system/filesize.html
>
>
>
> which is not what I’m looking for.
>
>
>
> I’ve been looking through the sysutils reference here:
>
> https://www.freepascal.org/docs-html/rtl/sysutils/index-5.html
>
>
>
> and I see disk size, but not file size…
>
>
>
> Could someone please point me in the right direction?

TSearchRec contains a Size field so you can use FindFirst with the specific
filename instead of a pattern (don't forget FindClose then ;) ) to have a
cross platform solution.
Otherwise you'd need to use system specific mechanisms (e.g.
GetFileAttributeEx on Windows, stat on *nix).

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

Re: [fpc-pascal] getting cross with the cross compiler

[Sven Barth via fpc-pascal]

Am 07.10.2017 11:11 schrieb "Karoly Balogh (Charlie/SGR)" <
char...@scenergy.dfmk.hu>:
>
> Hi,
>
> On Sat, 7 Oct 2017, Sven Barth via fpc-pascal wrote:
>
> > > So where is my cross compiler ??
> > >
> > > Thanks for any help and suggestions.
> >
> > A single compiler binary can always compile for all supported targets of
> > that processor. So as long as all the units are available you simply
> > need to pass "-Twin64" as additional parameter to compile for
> > x86_64-win64.
>
> Sigh. :) Any reason why Windows is different? No other OS has different
> target arguments for different CPUs, because the CPU type already
> specifies if its for 32 or 64bit... (fix me?)

I had asked the same some time ago and the historic reason was that
especially the system unit was considered too different to have both of
them be the same target... I don't agree either, but that's how it is... :/

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

Re: [fpc-pascal] getting cross with the cross compiler

[Sven Barth via fpc-pascal]

Am 07.10.2017 10:57 schrieb :
>
> Hi,
>
> I am having trouble getting fpc to cross-compiler for win64 target.
>
> I'm using fedora 26 which supplies 3.0.2
>
> I used instructions here to create the cross compiler using trunk fpc
since the fedora fpc-src does not seem to have the full Makefile structure:
>
>
http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux#Free_Pascal
>
> I have a simple test file:
>
> {$MACRO ON}
> program Hello;
> begin
>   Writeln('Hello world, from FPC ', FPC_FULLVERSION, '!');
> end.
>
>
> This builds fine using the stock fpc 3.0.2 with linux target.  However,
the supposed cross-compiler seems to be trying to build for linux.
>
> $/usr/lib/fpc/3.1.1/ppcrossx64  /back/coredata/hello.pas
> Free Pascal Compiler version 3.1.1 [2017/10/06] for x86_64
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target OS: Linux for x86-64
> Compiling /back/coredata/hello.pas
> Fatal: Can't find unit system used by Hello
> Fatal: Compilation aborted
>
>
> $/usr/lib/fpc/3.1.1/ppcrossx64  -iTO
> linux
>
>
>
> So where is my cross compiler ??
>
> Thanks for any help and suggestions.

A single compiler binary can always compile for all supported targets of
that processor. So as long as all the units are available you simply need
to pass "-Twin64" as additional parameter to compile for x86_64-win64.

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

Re: [fpc-pascal] Managed properties idea

[Sven Barth via fpc-pascal]

Am 06.10.2017 20:52 schrieb "Marcos Douglas B. Santos" :
> > And reference counting like in e.g. C++ "shared  pointers", that can
wrap any
> > class, without any additional feature (in Pascal we may get this with
> > "management operators").
>
> I don't know about "management operators". Could you explain more about
them?

Operators for records that are called when initializing, finalizing and
copying that record. See $fpcdir/tests/test/tmoperator[1-10].pp

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

Re: [fpc-pascal] Finding long file names

[Sven Barth via fpc-pascal]

Am 05.10.2017 01:49 schrieb "James Richters" :
>
> I'm trying to use findfirst()/findnext to obtain a list of files.  Here's
my code:
> Searchfile:=Tap_Drive+Tap_Path+'\'+Tap_SubDirectory+'\*.TAP';
> If FindFirst(Searchfile, FAAnyfile-FAHidden, FileDirInfo)=0 then
> ..
>
> It finds most files, even ones with really long file names, however it
can't find files with periods in the file name,
> So it will find:
> This is a TEST.Tap
>
> But it will not find:
> This.is.a.TEST.tap
>
> If I change my search string to:
> Searchfile:=Tap_Drive+Tap_Path+'\'+Tap_SubDirectory+'\*.*';
>
> Then it DOES find the files with more than one period in them... along
with everything else.
>
> I could filter them out myself I suppose, but that seems to defeat the
way findfirst is supposed to work.
>
> Any ideas how to make this work?  Is there a better method to use than
findfirst() ?
>
> I notice that if I use Extractfileext() with This.is.a.TEST.tap it
correctly returns '.tap' as the extension.  Maybe findfirst is an obsolete
way of listing the files?Or maybe it just never got fixed to handle
valid files with more than one period?
>
> Any thoughts on this?

I can't reproduce it here. Would you please provide a self contained, small
example plus information about the OS, filesystem and compiler as well as a
list of filenames to test with?

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

Re: [fpc-pascal] Managed properties idea

[Sven Barth via fpc-pascal]

Am 05.10.2017 05:04 schrieb "Ryan Joseph" :
> I’ve been wanting to learn how to contribute to the compiler for years
now but maybe this is an easy enough project to start with. I don’t know if
this is  a problem people have though but I assume it may be since
Objective-C had a system like for memory management and properties. What do
you think? How do most FPC programmers handle memory these days?

The way to go in Object Pascal are reference counted interfaces (aka
COM-style interfaces). After all one should program against an interface
anyway and that reference counted interfaces are automatically handled by
the compiler is an added bonus.

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

Re: [fpc-pascal] Syntax to select constant or variable with function call

[Sven Barth via fpc-pascal]

Am 25.09.2017 08:13 schrieb :
> I have 2 arrays that are not [0..255],  one is [1..14] the other is
[0..15] is there a way I could expand this scheme to use those arrays as
well?   The For loop would need to adjust to the size of the arrays somehow.

See what I wrote yesterday :)

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

Re: [fpc-pascal] Resource compilation

[Sven Barth via fpc-pascal]

On 24.09.2017 22:55, Graeme Geldenhuys wrote:
> On 2017-09-24 19:02, Sven Barth via fpc-pascal wrote:
>>> system if you want to use it as a linker, fpc does not provide it.
>> Exactly.
> 
> Exactly my point! Why? Why does the official FPC installer for Windows
> give a more workable solution out of the box (1), but official
> installers for other platforms don't?

Because on non-Windows systems (especially the *nix ones) we rely on
their package distributions systems and it's up to the package
maintainers to set up the packages accordingly for their distribution so
that they pull in the required packages. Such a system does not exist on
Windows however so we bundle everything there.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax to select constant or variable with function call

[Sven Barth via fpc-pascal]

On 24.09.2017 21:07, James Richters wrote:
> Thank you for explaining how to achieve this.  
> I am curious about the meaning behind the prefixes you used:
>>  TVGA256Array = Array[0..255] of VGARGBRec;  
>>  PVGA256Array = ^TVGA256Array;
> Do the T and P in front of VGA256Array have a special meaning or 
> significance?   I see things like that all the time, but never really 
> understood why there are these designations.

"T" and "P" are simply the typical Hungarian notations in Pascal for
ordinary types and pointer types respectively.

> I should have mentioned that not all my arrays are [0..255], Most are, but I 
> have some that are [0..15] and one that is [1..14] Is there a way to 
> implement a variable size array and somehow use the array minimum and maximum 
> element in the for loop?

If you use open array parameters you can do that. E.g.

=== code begin ===

program tdynarr;

const
  Array1: array[0..3] of LongInt = (1, 2, 3, 4);
  Array2: array[2..6] of LongInt = (1, 2, 3, 4, 5);

{ Important: a dynamic array type (aka "TArray = array of LongInt") for
the array parameter will only work with 0 based array constants (in this
case Array1) }
procedure DoArray(aArr: array of LongInt);
begin
  Writeln(Low(aArr), '..', High(aArr));
end;

begin
  DoArray(Array1);
  DoArray(Array2);
end.

=== code end ===

Please note that an open array is always zero based so the output of the
above example will be:

=== output begin ===

0..3
0..4

=== output end ===

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

Re: [fpc-pascal] Resource compilation

[Sven Barth via fpc-pascal]

Am 24.09.2017 18:14 schrieb "Giulio Bernardi" :
>
> I think that what Sven meant is that fpc's Windows installers include
binutils,
> while this is not true for other platforms: that is, you need to have ld
on your
> system if you want to use it as a linker, fpc does not provide it.

Exactly.

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

Re: [fpc-pascal] Resource compilation

[Sven Barth via fpc-pascal]

On 24.09.2017 17:15, Graeme Geldenhuys wrote:
> On 2017-09-24 13:50, Sven Barth via fpc-pascal wrote:
>> You are aware that FPC supports resources on basically all platforms?
> 
> I know that. What I meant is that FPC only ships with a Windows resource
> compiler - ability to compile RC files to RES files. All other platforms
> you have to find your own Resource Compiler. So on a clean system with a
> fresh FPC install, only under Windows will you have the ability to
> compile source code that references .rc files.

Because it's only Windows that we provide a setup for. If someone would
provide an FPC implemented resource compiler we'd include it.

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

Re: [fpc-pascal] Resource compilation

[Sven Barth via fpc-pascal]

On 24.09.2017 12:12, Graeme Geldenhuys wrote:
> On 2017-09-23 21:31, Martok wrote:
>> the $R directive accepts resource scripts (RC) and compiles the RES
>> file from it
>> on demand.
> 
> Also note that that is only true for Windows. FPC doesn't include a
> resource compiler for any other platforms. So if no resource compiler
> exists, you will get a compilation error until you make other plans.
> Another FPC limitation that really should be resolved.

You are aware that FPC supports resources on basically all platforms?
After all it was introduced for Lazarus back before 1.0 or so.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Booleans vs sets

[Sven Barth via fpc-pascal]

Am 22.09.2017 12:56 schrieb "Ryan Joseph" :
>
> Got it, thanks guys.
>
> Btw, how can I know what the size in bytes these 2 options are?

You could use SizeOf(YourType) and output the values in a simple test
program :)

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

Re: [fpc-pascal] Inclocked/declocked

[Sven Barth via fpc-pascal]

Am 12.09.2017 06:54 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Sep 12, 2017, at 2:35 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > I've rechecked and the thing is as follows:
> > - the IncLocked call happens each time you assign a dynamic array to
> > another dynamic array variable or a by-value parameter (this also
> > includes being part of a record, but not a class instance or TP-style
> > object)
> > - the DecLocked call happens each time the array is cleared (as long as
> > the reference count is > 0 this only means a decrement of the count)
> > which happens if you assign Nil, assign a different array (the
> > destination array is "cleared") or if the array variable goes out of
scope
> >
> > The two routines are also used in context of Ansi- and UnicodeString
> > variables as well as reference counted interfaces (aka COM-style
> > interfaces).
> >
> > In contrast to what I wrote earlier the compiler does however not ensure
> > a unique array if you only change an element, so given the following
> > example:
>
> I removed the dynamic arrays from the my code and replaced with static
arrays which fixed the performance problem I was having.
>
> It’s still not clear when this was being called (how could I track in the
debugger?) but I consider this a pretty serious bug and I wouldn’t use
dynamic arrays in high performance code.

Dynamic arrays are a fairly high level construct. The general advice for
them is not to repeatedly grow (or shrink) them by miniscule amounts, but
mainly by twice the current length. (Don't know if you've been doing that)

> If I had to guess I would say it was from SetLength but 16%? When I
replaced with static arrays and used ReAllocMem instead this didn’t happen
so what are those 2 functions doing to eat up so much CPU?

The Inc-/DecLocked routines perform a locked increment/decrement, so
they're blocking the memory bus for all cores (simply spoken), thus leading
to a higher CPU utilization. On e.g. i386 there is an optimisation to only
do that locking if IsMultiThread is True (some other platforms might
benefit from that optimization as well :/ ).
Additionally they are the leave routines of the dynamic array management
code, so the time would be really used up there if not for the locking.

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

Re: [fpc-pascal] Inclocked/declocked

[Sven Barth via fpc-pascal]

On 11.09.2017 11:46, Ryan Joseph wrote:
> 
>> On Sep 11, 2017, at 4:20 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> They're used for the reference counter of the array (or string or 
>> interface). The reference counter changes each time you assign an array or 
>> pass it to a by-value parameter or if you change a value (cause the 
>> compiler/RTL needs to make sure that the reference to the array is unique 
>> then).
>>
>>
> 
> Maybe this is relevant to my poor performance then but perhaps it’s just the 
> way the time profiler works? It’s telling me the program is spending  16% in 
> system_delocked which seems extreme.
> 
> See if I have a dynamic array and call arr[0] := xxx then those functions 
> will be called (or FPC_DYNARRAY_ASSIGN)? I also have a dynamic array in an 
> object which is passed a function parameter, but not by value so that doesn’t 
> fit your description.

I've rechecked and the thing is as follows:
- the IncLocked call happens each time you assign a dynamic array to
another dynamic array variable or a by-value parameter (this also
includes being part of a record, but not a class instance or TP-style
object)
- the DecLocked call happens each time the array is cleared (as long as
the reference count is > 0 this only means a decrement of the count)
which happens if you assign Nil, assign a different array (the
destination array is "cleared") or if the array variable goes out of scope

The two routines are also used in context of Ansi- and UnicodeString
variables as well as reference counted interfaces (aka COM-style
interfaces).

In contrast to what I wrote earlier the compiler does however not ensure
a unique array if you only change an element, so given the following
example:

=== code begin ===

program tarrtest;

procedure Test(aArg: array of LongInt);
var
  i: LongInt;
begin
  for i in aArg do
Writeln(i);
end;

var
  ia1, ia2: array of LongInt;
begin
  ia1 := [1, 2, 3];
  ia2 := ia1;
  ia1[1] := 5;
  Test(ia1);
  Test(ia2);
end.

=== code end ===

The output will be

=== output begin ===

1
5
3
1
5
3

== output end ===

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

Re: [fpc-pascal] Where and Why is there a memory leak?

[Sven Barth via fpc-pascal]

Am 07.09.2017 03:48 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Sep 6, 2017, at 10:20 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > You're missing that FHook was declared as IHook, not THook.
> >
>
> In terms of memory why does it matter how it was declared? The memory was
allocated in Create() so the declaration is just relevant for the
assignment of the new memory. Is FPC doing something magic behind the
scenes?

a) since it's an interface it doesn't *have* a Free method
b) COM interfaces are reference counted and the compiler (both Delphi and
FPC) does automatic reference counting with them (that's the purpose of
TInterfacedObject, it calls Free on itself once the reference count reaches
0)

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

Re: [fpc-pascal] Where and Why is there a memory leak?

[Sven Barth via fpc-pascal]

Am 06.09.2017 17:03 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 8:03 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > I couldn't call .Free because FHook was a interface reference type of
type IHook, not THook.
>
> But TInterfacedObject is a class isn’t it? Then you call FHook :=
THook.Create; so a I’d expect a Free(). What am I missing?
>
> type
>  THook = class(TInterfacedObject, IHook)
>  private
>procedure DoIt;
>  end;

You're missing that FHook was declared as IHook, not THook.

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

Re: [fpc-pascal] Where and Why is there a memory leak?

[Sven Barth via fpc-pascal]

Am 06.09.2017 10:31 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
> type
>   IHook = interface
> ['{4BCAEDD8-92D8-11E7-88D3-C86000E37EB0}']
> procedure DoIt;
>   end;
>
> type
>   THook = class(TInterfacedObject, IHook)
>   private
> procedure DoIt;
>   end;
>
>   procedure THook.DoIt;
>   begin
> writeln(ClassName + ' did it');
>   end;

I think THook needs to derive from TAggregatedObject, cause that couples
the reference counting to that of the controlling instance.
See here:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Implementing_Interfaces

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

Re: [fpc-pascal] implements

[Sven Barth via fpc-pascal]

Am 06.09.2017 10:34 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > There is NO need to make Hook public, because you can always get access
to that functionality via the Supports() call and get a reference to IHook.
>
> The Supports() call is the key takeaway here.
>
> For the sake of discussion can you see why it makes sense that “hook.”
syntax would be implied because the class does indeed supposedly implement
the interface? Everything about the syntax says that the methods in IHook
should be in TBaseClass so I can’t help but feel like it was an omission or
not fully finished. It would be messy to implement probably because you
would risk a number of name collisions with existing methods.

No it's definitely by design. If you use alias clauses ("procedure
IMyIntf.Foobar = Blubb") then you also won't have the interface's method in
your class, but only the alias. The method can only be accesssed by the
interface's method name by using an interface instance not the class
instance. The "implements" clause is just an advanced variant of that in
that it allows you to use a complete class (though you're still able to
implement selected methods of the interface in the base class which aren't
delegated then).

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

Re: [fpc-pascal] implements

[Sven Barth via fpc-pascal]

Am 02.09.2017 10:38 schrieb "Ryan Joseph" :
>
>
> > On Sep 2, 2017, at 3:27 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > Please search the internet about Interfaces and probably Design
Patterns too. Have ever heard the phrase: "Code to an Interface, not an
Implementation".
> >
> > Interfaces are so much more than simply "adding methods to a class".
>
> I understand interfaces just fine but I don’t understand why you want a
class to appear as if it implements an interface but then having to call
methods on a 2nd class. It separates the code (which is nice) but then
gives you an annoying extra step of typing hook.XXX for every method. It
just feels broken and not complete as a feature.
>
> Furthermore if you know that a class implements an interface but you need
to call another variable (like hook) then how do you know the name of the
variable??? I use interfaces often but that would break them for me in most
cases.

As Graeme said: the point is to code against interfaces, not classes. Don't
pass around or work with the TBaseClass instance, instead only with the
IHook interface. And this is what the implements feature is for.

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

Re: [fpc-pascal] implements

[Sven Barth via fpc-pascal]

Am 02.09.2017 06:34 schrieb "Ryan Joseph" :
>
> I think I asked this some years ago but I came across it again I just
don’t get what the point of this is. There is an “implements” property but
it seems like yet another half-baked feature from Delphi that wasn’t
implemented completely or is broken. What’s the point of implementing an
interface like this on TBaseClass if you need to access all the methods by
using the property name (“hook” in this case) when you could just add an
instance of THook in TBaseClass? It adds so much noise and clutter in the
language and for what? The only reason it makes sense is if you could call
“base.DoIt” and omit the .hook every time you’re typing but that was
overlooked for some reason. Why??
>
>
> type
>   IHook = interface ['IHook']
> procedure DoIt;
>   end;
>
> type
> THook = class (IHook)
> procedure DoIt;
> end;
>
> procedure THook.DoIt;
> begin
> writeln(ClassName+' did it');
> end;
>
> type
> TBaseClass = class (IHook)
> private
> m_hook: IHook;
> public
> property Hook: IHook read m_hook implements IHook;
> constructor Create;
> end;
>
> constructor TBaseClass.Create;
> begin
> m_hook := THook.Create;
> end;
>
>
> base: TBaseClass;
>
> base := TBaseClass.Create;
>
> base.DoIt; // CANT DO THIS
> base.hook.DoIt; // MUST DO THIS

Because you must use the interface and not the class instance:

=== code begin ===

var
  base: TBaseClass;
  hook: IHook;
begin
  base := TBaseClass.Create;
  hook := base;

  hook.DoIt; // will call base.hook.DoIt
end;

=== code end ===

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

Re: [fpc-pascal] TP compatibility: procedural type

[Sven Barth via fpc-pascal]

Am 29.08.2017 18:48 schrieb "Anton Shepelev" :
> I  now  see  from  other  replies that the -Mtp mode
> helps compile TP programs in FPC but not vice versa,
> which  makes me wonder why pointer arithmetics is so
> limited in -Mtp that one must use Inc  and  Dec  in-
> stead of the direct '+' and '-' operators.

Because this is disabled by default in that mode. You can change that with
{$PointerMath On} (
https://freepascal.org/docs-html/current/prog/progsu112.html#x120-1210001.3.29
), like you can enable many other features in the more restricted modes,
but you need to do that explicitly, as there might be code breakages due to
this.

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

Re: [fpc-pascal] TP compatibility: procedural type

[Sven Barth via fpc-pascal]

Am 29.08.2017 14:26 schrieb "Anton Shepelev" :
>
> Karoly Balogh to Anton Shepelev:
>
> >>According  to Borland's official language guide to
> >>Turbo Pascal 7.0,
> >>
> >>  To be used as procedural values, procedures and
> >>  functions must be declared with a 'far' directive
> >>  or compiled in the '{$F+}' state.
> >>
> >>whereas Free Pascal in -Mtp seems  to  accept  any
> >>non-system  procedure  or function as a value of a
> >>procedural type. Is it an instance of TP incompat-
> >>ibilty or am I missing something?
> >
> >It's  documented,  that Free Pascal ignores far and
> >near directives because they were for  16bit  code,
> >and have no meaning in 32bit or 64bit code:
> >
> >  https://www.freepascal.org/docs-html/user/usersu82.html
> >
> >Therefore  it's  logical that the compiler also ig-
> >nores their absence.
>
> Ignoring them in the sense of not affecting the gen-
> erated machine code is perfectly OK, but not requir-
> ing their presence in the source, to make  the  pro-
> gram  compilable  in  Turbo Pascal, seems wrong when
> Free Pascal is in Turbo Pascal mode.  A program that
> Free  Pascal compiles successfully in TP mode should
> work with the actual Turbo Pascal compiler.   Is  it
> not  the  purpose of these modes?  Do they guarranty
> only forward-compatibility?

The modes are for the case have code written for other compilers (TP,
MacPas, Delhi, ISO) work in FPC (as good as reasonably possible). We do
however *not* guarantee that code written in one of these modes with FPC
compiles or runs with the corresponding compiler.

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

Re: [fpc-pascal] TP compatibility: procedural type

[Sven Barth via fpc-pascal]

Am 29.08.2017 11:10 schrieb "Anton Shepelev" :
>
> Hello, all.
>
> According  to  Borland's  official language guide to
> Turbo Pascal 7.0,
>
>   To be used as procedural  values,  procedures  and
>   functions  must be declared with a 'far' directive
>   or compiled in the '{$F+}' state.
>
> whereas Free Pascal in -Mtp seems to accept any non-
> system  procedure or function as a value of a proce-
> dural type.  Is it an instance of TP  incompatibilty
> or am I missing something?

That would probably be only relevant on i8086. All the other targets don't
have the distinction in "near" and "far", so it's not necessary to
artificially restrict everything.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 29.08.2017 08:35 schrieb "Michael Schnell" <mschn...@lumino.de>:
>
> On 28.08.2017 08:04, Sven Barth via fpc-pascal wrote:I don't understand
why we will have no more the right to use it under x64 OS...
>>
>>
>> Because Microsoft declared it as deprecated. That means that should
Microsoft ever bring out a 64-bit only OS ...
>>
> In fact this still is a (mere) portability problem. Supposedly in such a
64-bit only OS, 32 bit executables will not lose "extended" but will not be
able to be started at all.
>
> In fact I suppose there will be possibilities to run them in a virtual
machine. E.g. Virtual Box already can build up an invisible "one window"
virtual machine for a single running program.
>

The point here was if the FPU is used in a x64 process, which *is*
possible, but disabled by default in the compiler.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 28.08.2017 00:32 schrieb "Ched" <
charles.edouard.des.vastes.vig...@gmail.com>:
>
> Hello,
>
> I agree that the extended type is not portable and not as fast as double.
>
> But sometimes, we absolutely need numerical precision, so we have to
assume the costs in terms of runtime and possibly nonportability. When the
algorithms are nearly optimal, there is no room for software enhancement.
So, the programmers, not the OS makers !, has to do the choices about
accuracy, runtime and hardware configuration. For my numerical problems, I
absolutely need "full" extended, not just doubles.
>
> As the 18-19 digits extended type is availables in Freepascal for the
common Intel processors, I don't understand why we will have no more the
right to use it under x64 OS...

Because Microsoft declared it as deprecated. That means that should
Microsoft ever bring out a 64-bit only OS they can simply disable the FPU
handling in their kernel (e.g. saving the FPU state during a context
switch) and then you are doomed and they did even warn you about this,
cause they declared the x87 as deprecated from the beginning on Win64.

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

On 27.08.2017 19:27, Marco van de Voort wrote:
> In our previous episode, Sven Barth via fpc-pascal said:
>> Am 27.08.2017 00:10 schrieb "Marco van de Voort" <mar...@stack.nl>:
>>> The GTK headers also use a 0/1 boolean, and for that the boolean8/16/32
>>> types were created. I couldn't quickly find docs, so I filed a bug for
>> that.
>>
>> Please note that there is no Boolean8 as that one is simply Boolean. But
>> there is also a Boolean64 and QWordBool ;)
> 
> Boolean can be packed in ISO mode, Boolean8 has an explicit size so
> shouldn't :-)

Even the Boolean16/32/64 types are bitpacked down to one bit, so that's
definitely no reason :P

> Seriously, without searching for something pedantic to say, I thought that
> an alias was added for orthogonality. Maybe it should.

*shrugs* If you think so...

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

Am 27.08.2017 00:10 schrieb "Marco van de Voort" :
> The GTK headers also use a 0/1 boolean, and for that the boolean8/16/32
> types were created. I couldn't quickly find docs, so I filed a bug for
that.

Please note that there is no Boolean8 as that one is simply Boolean. But
there is also a Boolean64 and QWordBool ;)

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

On 26.08.2017 13:43, Michael Van Canneyt wrote:
> 
> 
> On Sat, 26 Aug 2017, Sven Barth via fpc-pascal wrote:
> 
>>>
>>> I did read it.
>>>
>>> I think the programmer *must* worry about the details and must
>>> definitely
>>> NOT use the booleans for anything C related. That was my point.
>>>
>>> Attempting to cater for C code using BOOL or whatever type is misplaced.
>>> C does not have a boolean type.
>>>
>>> The standard says for "if" :
>>>
>>> "In both forms, the first substatement is executed if the expression
>>> compares unequal to 0."
>>>
>>> Treat it as such.
>>
>> And I say that the programmer does not need to care about it if the one
>> that translated the interface used the correct type.
> 
> And this "if" is the cliff on which the ship crashes and sinks...

But this "if" is also the case for a bunch of other translation cases.
There are for example some WinAPI translations that have a "var"
parameter for pointers while they should be by-value parameters cause
they can take "Nil". It's always possible for the translator to screw up
and one needs to take care by hand that it works correctly...

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

On 26.08.2017 12:57, Michael Van Canneyt wrote:
> 
> 
> On Sat, 26 Aug 2017, Sven Barth wrote:
> 
>>>
>>> Sorry for being naive. Why not simply use a boolean ?
>>>
>>> I thought all this BOOL mess was just meant to be able to interface
>>> with C
>>> libs slightly easier.
>>>
>>> Instead of
>>>
>>> If (SomeCfunction()<>0) then
>>>   DoSomethingStupid;
>>>
>>> it allows you to write - in appropriate cases - the following:
>>>
>>> if (SomeCfunction()) then
>>>   DoSomethingStupid;
>>>
>>> I don't think we should promote BOOL and friends too much. They are a
>> convenience (which IMHO should not have been introduced in the first
>> place).
>>>
>>> Promoting them to first-class Pascal citizens is IMHO a bad idea.
>>
>> Did you read the article that had been linked? That's an important point
>> that is raised in there.
> 
> I did read it.
> 
> I think the programmer *must* worry about the details and must definitely
> NOT use the booleans for anything C related. That was my point.
> 
> Attempting to cater for C code using BOOL or whatever type is misplaced.
> C does not have a boolean type.
> 
> The standard says for "if" :
> 
> "In both forms, the first substatement is executed if the expression
> compares unequal to 0."
> 
> Treat it as such.

And I say that the programmer does not need to care about it if the one
that translated the interface used the correct type. Also I very much
prefer to use "True" and "False" instead of some "INT_TRUE" or
"INT_FALSE", because that would show that FPC is not up to the job to
correctly handle this.
Please also note that I'm only talking about cases where there is indeed
a definition of a boolean type on the C side of things (e.g. the Windows
API with its BOOL as well as TRUE and FALSE definitions and GTK for
which the Boolean16, -32 and -64 types were introduced).

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

Am 26.08.2017 09:50 schrieb "Michael Van Canneyt" <mich...@freepascal.org>:
>
>
>
> On Sat, 26 Aug 2017, Sven Barth via fpc-pascal wrote:
>
>> Am 26.08.2017 07:25 schrieb <nore...@z505.com>:
>>>
>>>
>>> What about the BOOL issue..
>>>
>>> We know that Boolean in fpc/delphi is not compatible with a C bool
>>>
>>> But it gets worse than that: even fpc/delphi's bool is not always
>>
>> compatible (but is sometimes).
>>>
>>>
>>> For example:
>>> http://blog.delphi-jedi.net/2008/09/25/bool-boolean-and-integer/
>>>
>>> When one must use Integers to do boolean related programming tasks, it
>>
>> makes me want to quit programming ;)
>>>
>>>
>>
>> In FPC you can use the types Boolean16, Boolean32 and Boolean64 to get a
>> type that behaves like Boolean, but has a different size.
>
>
> Sorry for being naive. Why not simply use a boolean ?
>
> I thought all this BOOL mess was just meant to be able to interface with C
> libs slightly easier.
>
> Instead of
>
> If (SomeCfunction()<>0) then
>   DoSomethingStupid;
>
> it allows you to write - in appropriate cases - the following:
>
> if (SomeCfunction()) then
>   DoSomethingStupid;
>
> I don't think we should promote BOOL and friends too much. They are a
convenience (which IMHO should not have been introduced in the first place).
>
> Promoting them to first-class Pascal citizens is IMHO a bad idea.

Did you read the article that had been linked? That's an important point
that is raised in there.
These types as well as the Byte-, Word-, Long- and QWordBool types are
mainly for interfacing with C-based interfaces, either on Windows or *nix
and there they should definitely be used so that a Pascal user of them can
simply use True and False and does not need to worry about the details (but
of course the correct type needs to be used as the article shows).

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Sven Barth via fpc-pascal]

Am 26.08.2017 07:25 schrieb :
>
> What about the BOOL issue..
>
> We know that Boolean in fpc/delphi is not compatible with a C bool
>
> But it gets worse than that: even fpc/delphi's bool is not always
compatible (but is sometimes).
>
> For example:
> http://blog.delphi-jedi.net/2008/09/25/bool-boolean-and-integer/
>
> When one must use Integers to do boolean related programming tasks, it
makes me want to quit programming ;)
>

In FPC you can use the types Boolean16, Boolean32 and Boolean64 to get a
type that behaves like Boolean, but has a different size.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 24.08.2017 23:26 schrieb "Tomas Hajny" <xhaj...@hajny.biz>:
>
> On Thu, August 24, 2017 22:25, Ralf Quint wrote:
> > On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:
> >>
> >> Am 23.08.2017 02:16 schrieb "Paul Nance" <pwna...@gmail.com
> >> <mailto:pwna...@gmail.com>>:
> >> >
> >> > Turbo Pascal also had a BCD unit.
> >>
> >> Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
> >> operators as well operator overloads.
> >>
> > And where would such gem be hiding? It's not in neither my Lazarus
> > 1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...
>
> Good point... It's in package rtl-objpas. I can see it included in the
> standard FPC 3.0.2 installation, but it's missing in 3.0.4 at the moment,
> because it got lost in the transition from fpcmake to fpmake apparently.
> Fortunately, that should be rather easy to fix. :-)

Hmm? It's mentioned in both the trunk and the branches/fixes_3.0.0
rtl-objpas fpmake.pp file and that wasn't changed since the branch if
3.0.0. So when the unit is indeed missing in 3.0.4rc1 then that needs to be
looked at.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 25.08.2017 01:33 schrieb "Ralf Quint" :
>
> On 8/24/2017 2:45 PM, Ched wrote:
> > And under "modern" Windows, the extended type, which is fully
> > supported by the FPU, is *degraded* to double. So, I can't do high
> > precision computation with fpc even if the native hardware permits
> > such computations. I'm glued to XP as the full capabilities of the FPU
> > were on the hands of programmers, years ago.
> It's not a problem of "modern" Windows, but a problem of any 64bit x86
> OS that in that "long" mode the FPU does NOT support the extended data
> type (80 bits, 10 bytes). In 32bit mode, the FPU is using the "old" x87
> FP unit on the chip, in 64bit mode, it is using the SSE FP unit, which
> doesn't have those 80 bit registers, it's 64 bit only (and several times
> faster).
> So that you can use that with your Windows XP version is likely due to
> the fact that this is a 32bit version, not XP Professional 64 (or
> Windows Server 2003 64 for that matter).
>
> There are apparently some ways to enable the FP calculation to use the
> x87 FPU and therefor the possibility of those 80 bit registers on Inter
> chips (so far), but for one, this runs significantly slower that the SSE
> FPU, and then this is apparently not supported by (all) AMD CPUs, so you
> are limiting yourself also on which systems your code can run...

Plase note that all non-Windows 64-bit systems have no problems with
enabling the FPU and even Windows needs to handle it due to 32-bit software
requiring it.
The only x86_64 OS we support that doesn't have Extended enabled (by
default) *is* Win64.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 24.08.2017 23:46 schrieb "Ched" <
charles.edouard.des.vastes.vig...@gmail.com>:
>
> And under "modern" Windows, the extended type, which is fully supported
by the FPU, is *degraded* to double. So, I can't do high precision
computation with fpc even if the native hardware permits such computations.
I'm glued to XP as the full capabilities of the FPU were on the hands of
programmers, years ago.

Please note that this is only true for the 64-bit variants of Windows with
64-bit software. 32-bit software on those systems can use the FPU without
any problems (in fact even 64-bit software can, but since Microsoft
declared it as deprecated for the 64-bit mode it might happen in the future
that it is no longer supported).

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 23.08.2017 02:16 schrieb "Paul Nance" :
>
> Turbo Pascal also had a BCD unit.

Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
operators as well operator overloads.

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

Re: [fpc-pascal] Inline ASM code

[Sven Barth via fpc-pascal]

Am 24.08.2017 08:32 schrieb "LacaK" :
>
> Hi *,
>
> I need store result of floating point calculation (in my example
arctan()) in memory pointed by some variable. See this code:
> var a: single; pa: PSingle;
>   asm
>   fild dy
>   fild dx
>   fpatan
>   fstp a
>   fwait
>   end;
>   pa^ := a;
>
> It works, but is there any way how to store result directly to "pa^" in
assembler ?
> I have tried:
>   ...
>   fpatan
>   fstp pa^ ... fstp (pa) ... but this does not compile ... I need
store to memory location pointed by pa "variable"
>   fwait
>   end;
>

You need to retrieve the value of pa into a register and then store at that
address. Something like this:

=== code begin ===
mov edx, pa
fstp [pa]
=== code end ===

Note 1: not tested
Note 2: you might want to check which register you can use for that
Note 3: I hope you keep the global and the assembler function in the same
unit, because inter-unit access to globals changes when dynamic packages
are enabled for a target

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

On 23.08.2017 20:38, Marcos Douglas B. Santos wrote:
> On Wed, Aug 23, 2017 at 3:25 PM, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
>> On 23.08.2017 19:57, Marcos Douglas B. Santos wrote:
>>> Would we have any problem of memory leaks using Interface helper with
>>> COM interfaces (refcount)?
>>> I mean, the "type helper" has constructor/destructor to create/release
>>> something?
>>
>> It doesn't need to. A type helper is essentially syntactic sugar for a
>> class method with the extended parameter as first type.
> 
> So, is this work?
> 
> === code begin ===
> 
> type
>   IFoo = interface
> function Execute: IFoo;
>   end;
> 
>   TFooHelper = type helper for IFoo
> procedure Something;
>   end;
> 
>   TFoo = class(TInterfacedObject, IFoo)
>   public
> function Execute: IFoo;
>   end;
> 
> var
>   F: IFoo;
> begin
>   F := TFoo.Create;
>   F.Execute.Something;
> end;
> 
> === code end ===

Yes, this should work.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

On 23.08.2017 19:57, Marcos Douglas B. Santos wrote:
> On Wed, Aug 23, 2017 at 2:45 PM, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
>> Am 23.08.2017 19:39 schrieb "Marcos Douglas B. Santos" <m...@delfire.net>:
>>>
>>> Wait a minute. Now I realize that procedure IShellLinkHelper.Save is a
>>> real implementation not by a class, but by a "interface helper".
>>> It's like default methods in Java(?) that we have code inside an
>>> interface...
>>
>> I don't know about Java, but the C# equivalent would be extension methods.
>> And yes, that's the point: the implementation is not part of the interface
>> implementer, but the user of the interface can add some implementation.
>> (Same for class, record and primitive types helpers)
> 
> Would we have any problem of memory leaks using Interface helper with
> COM interfaces (refcount)?
> I mean, the "type helper" has constructor/destructor to create/release
> something?

It doesn't need to. A type helper is essentially syntactic sugar for a
class method with the extended parameter as first type.

Take this for example:

=== code begin ===

type
  TInterfaceHelper = type helper for IInterface
procedure Something(aArg: String);
  end;

// is more or less equivalent to

  TInterfaceHelper = class
class procedure Something(aExtended: IInterface; aArg: String);
  end;

=== code end ===

Sidenote: for primitive types and records the hidden Self parameter of
the helper is a "var" parameter as the extended type can be changed.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 16:01 schrieb "Anthony Walter" :
>
> As to what they are useful for, consider the following:
>
> type
>   // IShellLink is define by Microsoft
>   IShellLinkHelper = record helper for IShellLink
>   public
> procedure Save(const Target, Description, Link: string);
>   end;
>
> procedure IShellLinkHelper.Save(const Target, Description, Link: string);
> var
>   P: IPersistsFile;
> begin
>   SetPath(Target);
>   SetDescription(Description);
>   if Self is IPersistsFile then
>   begin
> P := Self as IPersistsFile;
> P.Save(Link, True);
>   end;
> end;
>

And I just noticed: it's "type helper" if you want to extend an interface,
not "record helper" ;)

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 19:40 schrieb "Anthony Walter" :
>
> Sven, multiple helpers would be greatly appreciated, especially
considering everyone wants to add their own helpers for types like string.

At least in FPC modes they can use inheritance to solve this (see below) or
by putting their units after the SysUtils unit (at least if they don't
want/need the helper provided in the SysUtils unit).

=== code begin ===

type
  TMyStringHelper = type helper(TStringHelper) for String
// whatever
  end;

=== code end ===

Note: Delphi supports inheritance only for class helpers, but FPC supports
it also for record and type helpers.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 19:39 schrieb "Marcos Douglas B. Santos" :
>
> On Wed, Aug 23, 2017 at 11:00 AM, Anthony Walter  wrote:
> > Marco, it doesn't work that way.
> >
> > Type helpers simply allow you to extend an existing type with new
methods
> > and/or properties. When you declare a type helper you extend all
instances
> > of said type given that:
> >
> > A) You 'use' the unit declaring the type helper in some other unit.
> > B) No other unit you're using also defines a type helper for that same
type.
> > Only one type helper per type allowed.
> >
> > As to what they are useful for, consider the following:
> >
> > type
> >   // IShellLink is define by Microsoft
> >   IShellLinkHelper = record helper for IShellLink
> >   public
> > procedure Save(const Target, Description, Link: string);
> >   end;
> >
> > procedure IShellLinkHelper.Save(const Target, Description, Link:
string);
> > var
> >   P: IPersistsFile;
> > begin
> >   SetPath(Target);
> >   SetDescription(Description);
> >   if Self is IPersistsFile then
> >   begin
> > P := Self as IPersistsFile;
> > P.Save(Link, True);
> >   end;
> > end;
>
> Wait a minute. Now I realize that procedure IShellLinkHelper.Save is a
> real implementation not by a class, but by a "interface helper".
> It's like default methods in Java(?) that we have code inside an
interface...

I don't know about Java, but the C# equivalent would be extension methods.
And yes, that's the point: the implementation is not part of the interface
implementer, but the user of the interface can add some implementation.
(Same for class, record and primitive types helpers)

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 16:01 schrieb "Anthony Walter" :
>
> Marco, it doesn't work that way.
>
> Type helpers simply allow you to extend an existing type with new methods
and/or properties. When you declare a type helper you extend all instances
of said type given that:
>
> A) You 'use' the unit declaring the type helper in some other unit.
> B) No other unit you're using also defines a type helper for that same
type. Only one type helper per type allowed.
>

To be more precise: the last helper in scope simply wins. There is no error
if multiple ones are in scope. Also one can cheat a bit by having one's own
helper inherit from another helper of the same type ;)
Though I should mention that it's on my list to implement support for
multiple helpers. I just need to be sure about the resolution rules :)

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 16:59 schrieb "Marcos Douglas B. Santos" :
>
> On Wed, Aug 23, 2017 at 11:07 AM, Anthony Walter  wrote:
> > Here is another example:
> >
> > type
> >   TDay = (Monday = 0, Tuesday, Wednesday, Thursday, Friday, Saturday,
> > Sunday);
> >
> >   TDayHelper = record helper for TDay
> > function AsByte: Byte;
> > function ToString: string;
> >   end;
>
> I didn't know that helpers could be used in enums too. Great.

Helpers for primitive types are supported since 3.0.0.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 16:58 schrieb "Marcos Douglas B. Santos" :
>
> On Wed, Aug 23, 2017 at 11:00 AM, Anthony Walter  wrote:
> > Marcos, it doesn't work that way.
> >
> > Type helpers simply allow you to extend an existing type with new
methods
> > and/or properties. When you declare a type helper you extend all
instances
> > of said type given that:
> >
> > A) You 'use' the unit declaring the type helper in some other unit.
> > B) No other unit you're using also defines a type helper for that same
type.
> > Only one type helper per type allowed.
> >
> > As to what they are useful for, consider the following:
> >
> > type
> >   // IShellLink is define by Microsoft
> >   IShellLinkHelper = record helper for IShellLink
> >   public
> > procedure Save(const Target, Description, Link: string);
> >   end;
>
> Anthony,
>
> I understood. In fact, this is a great feature for whose work with
> interfaces a lot.
> We can have small interfaces but add some methods in just some places,
> extending such interfaces.
>
> Is this compatible with Delphi?

Interface helpers are only supported by FPC. But the other helpers (class,
record, primitive types) are Delphi compatible.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 09:42 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 22 Aug 2017, Anthony Walter wrote:
>
>> I just wanted to point out that revision 37023 Sven added type helper
>> support for interfaces.
>>
>> Good job and thank you Sven!
>>
>
> I'm having trouble understanding why this could be useful (apart from
completeness).
> The only thing I can come up with is adding properties:
>
>   Property SomeProp : TSomeType Read GetSomeProp Write SetSomeProp;
>
> where GetSomeProp and SetSomeProp are part of the interface.
>
> Any other examples ?

It's the same as for the other kinds of helpers: being syntactic sugar.
E.g. if I have an interface that has two methods that both return a string,
but more often than not I need a combination of both results. The previous
solution would have been a global function, now I can also do a helper with
a method.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 02:04 schrieb "Anthony Walter" :
>
> I just wanted to point out that revision 37023 Sven added type helper
support for interfaces.
>
> Good job and thank you Sven!

You're welcome. I wanted to add them for some time already :)

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 22.08.2017 18:11 schrieb "Peter" :
>
> Hi James,
>
> Its unlikely that 999.999 has an EXACT representation in floating point.
>
> 999.999002  maybe the closest value at your chosen precision.
>
> Extended type has more precision, but still probably won't be exact.

Additionally Extended is not cross platform.

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 22.08.2017 00:02 schrieb "James Richters" :

The others already wrote about floating point precision, so I won't repeat
that.

> The reason I noticed this is because I have some conditional statements
like
> If Draw_GX_Min<>99.999 then
> Something

*DON'T* compare floating point numbers like that. Instead use SameValue()
from the Math unit which has an additional epsilon value (with a default
value) that defines a lower and upper bound from your desired value to
compare to.

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

Re: [fpc-pascal] TStringHelper missing

[Sven Barth via fpc-pascal]

Am 21.08.2017 13:51 schrieb "Sven Barth" <pascaldra...@googlemail.com>:
>
> Am 21.08.2017 08:23 schrieb "Michael Van Canneyt" <mich...@freepascal.org
>:
> >
> >
> >
> > On Mon, 21 Aug 2017, Ryan Joseph wrote:
> >
> >> I’m trying to split a string by a delimiter and see there is a type
helper called TStringHelper (
https://www.freepascal.org/docs-html/rtl/sysutils/tstringhelper.html). The
compiler version I’m using is "Free Pascal Compiler version 3.1.1
[2017/04/22] for i386” but when I include SysUtils the methods are not
found.
> >>
> >> For example:
> >>
> >> var
> >>  str: string;
> >>  parts: TStringArray;
> >>
> >> parts := str.Split(' ‘);
> >>
> >>
> >> What am I doing wrong?
> >
> >
> > Try
> >
> > var
> >   Str : AnsiString;
> > or
> >   Str : WideString;
> >
> > I believe the compiler has some trouble finding the helper if you use
the
> > 'string' alias. I think there is even a bugreport about it.
> > Sven Barth can confirm/deny this.
>
> I thought that was fixed? Except of course if $H- is used (which is the
default in all modes except the Delphi ones) cause then String = AnsiString.

String = ShortString in case of $H- of course -.-

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