Re: [fpc-devel] Let's Encrypt cert and mantis.freepascal.org

[Michael Van Canneyt]

On Tue, 2 May 2017, Dimitrios Chr. Ioannidis via fpc-devel wrote:


Hi,

  is it possible to add the domain mantis.freepascal.org in the let's 
encrypt cert or change the subversion bugtrack:url property from 
mantis.freepascal.org to bugs.freepascal.org ?


Changed the bugtraq:url. Revision 36062.

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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Michael Van Canneyt]

On Mon, 1 May 2017, Nikolai Zhubr wrote:


01.05.2017 11:46, Florian Klämpfl:
[...]

And I'm still getting just an address anyway...



3.0.x is broken in this regard (stack back trace on x86-64 elf targets), 

see other threads on the
fpc mailing lists regarding this. This is why we discussing a quick as 

possibile 3.0.4 release.

Ah, ok. Couldn't find any mentions of the issue (bad googling or 
whatever) but anyway I'll probably have to wait for 3.0.4 then.


You don't need to wait:

Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK. 
And 3.0.0 is OK in this aspect for all platforms.


So you can continue to work.

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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Michael Van Canneyt]

On Mon, 1 May 2017, Nikolai Zhubr wrote:


Hello all,

I'm having some trouble to get BacktraceStrFunc to find line numbers.
This is with fpc 3.0.0 on linux x86_64 (Centos 7 if it matters).
If I compile the following example with

#fpc -gl tt.pas

I only get this output:

Started...
Exception:   $00455540
Done.

Evidently line info is somehow not present here.
Am I doing smth wrong or maybe lineinfo is not yet implemented for x86_64?


No, but the units that we distribute do not have debug information included.
So if the error is in the RTL, then there is no debug information.

If I run your program with a RTL compiled with debug info, I get:

home: >./st
Started...
Exception:   $0046F571  CHECKINDEX,  line 56 of 
../objpas/classes/lists.inc
Done.

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

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

[Michael Van Canneyt]

On Thu, 27 Apr 2017, Marco van de Voort wrote:


In our previous episode, Michael Van Canneyt said:

>>> 1) Why not call it 3.0.4?
>> I would also think that we should aim at a quick 3.0.4 then.
> +1

Just a linux i386 version (where the problem is acute) or all platforms ?


I assume it touches all ELF targets, so FreeBSD should go too.

I think it is best to take a few weeks to merge whatever else can be useful
for 3.0.4 (and I'm open to suggestions) and then just release a normal 3.0.4


I think probably a lot of package fixes can be merged. 
Especially fcl-passrc related, there have been a large amount of bugfixes

recently.

Maybe some RTL related fixes as well, although here I would be very careful.

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

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

[Michael Van Canneyt]

On Thu, 27 Apr 2017, LacaK wrote:




The only alternative would be to advise *nix users to use the 3.0.0
release instead.
3.0.0 has (IMO serious) bug involving calculations with currency 
datatype on some platforms (Win64, Arm): 
http://bugs.freepascal.org/view.php?id=28748




Bart

my two cents:

1) Why not call it 3.0.4?

I would also think that we should aim at a quick 3.0.4 then.

+1


Just a linux i386 version (where the problem is acute) or all platforms ?

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

Re: [fpc-devel] tbits.NotBits

[Michael Van Canneyt]

On Thu, 13 Apr 2017, Andrea Mauri wrote:


any answer?
I asked in the wrong place?
where should I ask?


You asked in the right place. I just didn't notice your first mail.

I am not sure that what you did is supported.

b.notbits(b)

I am not sure that you can pass the same instance to b.

Can you test with 2 separate instances ?

Michael.


Il 31/03/2017 14:10, Andrea Mauri ha scritto:

one more thing.
there is a method like clearall to set all bits to 1?
clearall is much more faster then a simple iteration along all bits

Il 31/03/2017 14:07, Andrea Mauri ha scritto:

I didn't understand how TBits.NotBits works.
Consider the following code:


  b:= TBits.Create(NRECORDS);
  b.NotBits(b);

or more clear:

  b:= TBits.Create(NRECORDS);
  b.Clearall;
  b.NotBits(b);

I supposed that all bits of b will be 1. What I obtain is that all bits
are 0.

fpc 3.0.0 win64

Am I missing something?
Thank you.
Andrea Mauri

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


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

Re: [fpc-devel] Discussion about "Dynamic packages"

[Michael Van Canneyt]

On Wed, 12 Apr 2017, Bishop via fpc-devel wrote:


I had some fears concerning idea development of "Dynamic packages" in 
FreePascal and possible performance penalties of programs from these changes. This why i
start this discussion and try wrote some of my ideas or/and proposal that, as i 
think, can help make FreePascal better.

At first I would like to designate a circle of tasks which in principle can 
effectively decide by means of system of dynamic packets. Lets remember for what
DLL`s and SO`s was be created. It was for memory saving (by sharing code and 
static conts parts from many applications in memory). Now there is so many 
memory
even on phones, that this almoust have no sence (its still work for things like 
LibC, ZLib and so.). But this kind of libraries better make with C-style
interface (or use COM/CORBA interfaces like in DirectX if it`s realy needed). 
Yes, sometimes someone make libraries for C++ only, but it because of a dominant
position of this language. Pascal didn`t have it. So, as i think, dynamic 
packages can be usefull only for something like plugin system in editors like 
3Ds
Max, Photoshop and etc. But Sven Bart wrote that "Package libraries can however 
only be used by a binary compiled with the same compiler as they rely on quite
a bit of compiler magic.", so they be usefull only for projects that target to 
have plugins writed in pascal only. I try to say, that there is not so many
situations that we realy need this system. I dont say that we dont need it at 
all, no. But disadvantages from this system must no effect on all other 
projects.
This why i have some propositions.

Во время моего общения с Sven Barth он писал "With dynamic packages you can 
share classes, strings, memory, etc. between the modules (the main binary and the
different package libraries)". Let's look at the most widespread operating 
systems. This will be Windows and Unix-family. In Windows every application starts
from ntdll.dll and walk via kernel32.dll and only after that go to 
"main"-function in EXE file. So kernel32.dll always loaded. And its already 
have not bad
memory manager (Process heap functions group). Why dont use it? It allow share 
memory with C code too (and strings with pascal code). Its already exist in
application memory. In Linux if application use shared libraries it use 
libdl.so witch need libc.so. So we already have libc heap. As i know in FreeBSD 
and
Solaris situation same.

And the second of my proposal it make dynamic packages like 2nd way in compiler 
(like it maked in MSVS where we can select link CRT staticaly or dunamicaly).
Add some switch to compiler (and have 2 compiler variants of RTL, now we have 
this in RTL source with {$IFDEF FPC_3_0_0} macro) that will allow generate or 
not
generate compiler magic for dynamic packages. They need in not so many cases, 
but all this indirect memory accesses make all applications slow (memory, first
of all memory latency, in bottleneck of all today computers).


Dynamic Packages will in each case be optional, they will not be not mandatory.

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

Re: [fpc-devel] Compiler bug in macro handling?

[Michael Van Canneyt]

On Wed, 12 Apr 2017, Giuliano Colla wrote:


Hi honourable fpc developers!

I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux 
environment)


The following snippet of code:

{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
 if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
  else V_PIU0 := Negativa;

 gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.

But if I change the code into:

 if HDCOUNT0 >= COUNT0 then V_PIU0 := False
  else V_PIU0 := True;

 (which IMHO should be identical) it compiles without complaining.

Am I doing something wrong or it is a bug?


Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}

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

Re: [fpc-devel] LineInfo

[Michael Van Canneyt]

On Tue, 4 Apr 2017, Sven Barth via fpc-devel wrote:


Am 04.04.2017 08:52 schrieb "Martok" :



Does it is possible that the LineInfo trace (-gl option) are broken

(no output)

in 3.0.2 version on Linux (at least)?


Hm. Indeed. I can reproduce the issue :/

AFAIR lineinfo.pp only works with Stabs? Didn't the default change to

Dwarf?

AFAIK -gl automatically picks the correct one depending on the debug info
that's used for the main program. (At least that's what I assumed up until
now...)


That is so. 
But I thought of this and tried with -gs and -gd (or whatever the DWARF option was)

I got the issue with both kinds.

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

Re: [fpc-devel] LineInfo

[Michael Van Canneyt]

On Mon, 3 Apr 2017, Marco Borsari via fpc-devel wrote:


Does it is possible that the LineInfo trace (-gl option) are broken (no output)
in 3.0.2 version on Linux (at least)?


Hm. Indeed. I can reproduce the issue :/

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

Re: [fpc-devel] Math and numlib

[Michael Van Canneyt]

On Tue, 14 Mar 2017, Werner Pamler wrote:

Thanks - unfortunately I've just uploaded a patch for unit typ 
implementing IsNaN and IsInfinity according to Michael's suggestion. But 
I think I'll withdraw the patch and replace it with one for a cleaned up 
typ unit.


How about cleaning up also spe? It contains a large number of functions 
which are contained in math as well, but with a terrible name (e.g., 
"spesih(x)" instead of "sinh(x)"). In theory, of course, this will break 
existing code although I am absolutely sure that nobody ever has used 
these functions.


Another idea: Errors in spe (and probably everywhere else) terminate the 
program with a RunError. This is not up to date any more. How about 
throwing an exception? Or, maybe, I could add a procedure 
"NumLibError(ErrCode: Integer)" which by default throws an exception 
with a message corresponding to the ErrCode, or, if compiled with 
$DEFINE RUNTIME_ERRORS, terminates the program like before with a 
RunError(ErrCode).


Better make this a normal variable; not a define.

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

Re: [fpc-devel] Math and numlib

[Michael Van Canneyt]

On Mon, 13 Mar 2017, Werner Pamler wrote:


Hi everybody - my first post here...

At the moment I am spending some time with fpc's numlib and writing a 
wrapper for a more versatile fitting procedure. Are there any problems 
to add the unit math to the uses clause of some numlib units? I want to 
use the value NaN (not-a-number) which is defined in numlib, but there 
is no way to check whether a value is "equal" to NaN. In math, however, 
there is a function IsNaN(). And my feeling is that these special 
numbers NaN and Infinity are implemented in math in a more general way 
than in numlib. An idea would be to remove NaN and Infinity from the 
numlib unit "typ" to replace them by the math values.


You can use the routines from the system unit for this.

http://www.freepascal.org/docs-html-3.0.0/rtl/system/textended80rec.html
http://www.freepascal.org/docs-html-3.0.0/rtl/system/tdoublerec.html
http://www.freepascal.org/docs-html-3.0.0/rtl/system/tsinglerec.html

function SpecialType.

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

Re: [fpc-devel] Management operators : Copy and Clone confusion...

[Michael Van Canneyt]

On Sat, 21 Jan 2017, Florian Klämpfl wrote:


Am 19.01.2017 um 10:44 schrieb Michael Van Canneyt:


At the risk of writing nonsense:

I would think that a method name should give a clue as to what it actually does.
In that sense AddRef/Clone seems better to me ?


Even if it is used by types not being ref. counted? Ref. counted types are only 
a sub-set of managed
types.


(unless Copy does something else besides increasing the ref count ?)

AddRef is clear to anyone, I think.


For non-ref. counted types?


I didn't know it is used for non-ref. counted types as well. 
For those types, there is no difference between copy/clone then?


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

Re: [fpc-devel] Management operators : Copy and Clone confusion...

[Michael Van Canneyt]

On Thu, 19 Jan 2017, Maciej Izak wrote:


Hi,

in patch/feature proposed in http://bugs.freepascal.org/view.php?id=30687
we have Copy/Clone operators naming convention proposed by Florian (my
initial idea was AddRef/Copy).

I'd like to say that Copy/Clone naming convention is terrible in practical
usage. :( As the main author I have many troubles and I have always
confusion >.< I always must to check which is for adding reference and
which one is for copying...

For example Paul Ishenin said in previous discussion ("ANN: Management
operators - final patch") : I know Florian insisted on Copy and Clone names
but still for my taste it would be the best to have conformity between
compiler and RTL.

In current FPC implementation of management operators "Copy" operator is
*always* used for increasing reference count and "Clone" operator is used
to create copy... In this area I have objections for my own patch.

Maybe someone have other ideas? Maybe we could back to AddRef/Copy which is
RTL compatible and is more "real life" friendly?


At the risk of writing nonsense:

I would think that a method name should give a clue as to what it actually does.
In that sense AddRef/Clone seems better to me ?
(unless Copy does something else besides increasing the ref count ?)

AddRef is clear to anyone, I think.

If I see "Clone", I immediatly think of an object whose properties are a copy of
the original, but which otherwise has nothing to do with the original.

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

Re: [fpc-devel] FPC 3.0.2rc1 available

[Michael Van Canneyt]

On Tue, 27 Dec 2016, Чернов Дмитрий wrote:


Guys, excuse me, but I want to remind about new version of the ENet library 
headers for FPC.
http://bugs.freepascal.org/view.php?id=27891
This RC contains old version of these headers, AFAIK.


That is on purpose.

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Wed, 7 Dec 2016, Sven Barth wrote:


Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" <mich...@freepascal.org>:




On Wed, 7 Dec 2016, Sven Barth wrote:


Trying to generate the exact same information as Delphi is IMHO not the


right path.



What is needed is an API that gives you the info contained in the


internal structures.

That's what the RTTI unit is there for. It provides a higher level API to
the type information than typinfo does.



I was hoping to avoid the RTTI unit, it has a horrible, Horrible, HORRIBLE
interface in my opinion. (probably again some misguided .NET clone

attempt)

I can't really comment on that since I had left Delphi before that was
introduced.


But no matter:
If the info is there, I can write my own interface which is more to my

liking.

I don't care about Delphi compatibility in these matters. What matters is
that the concept is there, the exact API I will creatre form myself.


The typinfo unit will definitely expose all the information as well (the
RTTI unit will probably simply use the data that typinfo provides).


That's what delphi also does, as far as I can see.

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Wed, 7 Dec 2016, Michael Van Canneyt wrote:




On Wed, 7 Dec 2016, Sven Barth wrote:


Trying to generate the exact same information as Delphi is IMHO not the

right path.


What is needed is an API that gives you the info contained in the

internal structures.

That's what the RTTI unit is there for. It provides a higher level API to
the type information than typinfo does.


I was hoping to avoid the RTTI unit, it has a horrible, Horrible, HORRIBLE
interface in my opinion. (probably again some misguided .NET clone attempt)

But no matter:
If the info is there, I can write my own interface which is more to my 
liking.

I don't care about Delphi compatibility in these matters. What matters is
that the concept is there, the exact API I will creatre form myself.


Hmh. That should read 'create for myself', obviously.

Michael.

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Wed, 7 Dec 2016, Maciej Izak wrote:


2016-12-07 8:49 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>:


I am not sure this is possible. The structures exposed in the typinfo
interfacee mimic the info the compiler generates in the binary.

If the compiler generates different info than Delphi, you cannot retrieve
it in a delphi-compatible way.

Trying to generate the exact same information as Delphi is IMHO not the
right path.

What is needed is an API that gives you the info contained in the internal
structures.



I think it is possible but solution proposed by Sven is good enough :). As
was mentioned in my previous message to Sven:

100% agree I don't have problem with a little Delphi incompatible RTTI, the
bigger picture is more important than small details, but quote from Jonas
Maebe ([fpc-devel] Attributes
thread): "some people wanted it to be Delphi compatible, other people did
not mind if it was not. Both categories of people were in the core team."

Delphi incompatible info was mentioned as serious problem for merging RTTI
branch into trunk.


I am one of the people who do not mind if it is not compatible. 
As I said:


Trying to generate the exact same information as Delphi is IMHO not the right 
path.

If the RTTI unit is there, people who want Delphi compatibility can and should 
use that.

People with a more low-level mindset (such as me) will be able to work
around the low-level details.

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Wed, 7 Dec 2016, Sven Barth wrote:


Trying to generate the exact same information as Delphi is IMHO not the

right path.


What is needed is an API that gives you the info contained in the

internal structures.

That's what the RTTI unit is there for. It provides a higher level API to
the type information than typinfo does.


I was hoping to avoid the RTTI unit, it has a horrible, Horrible, HORRIBLE
interface in my opinion. (probably again some misguided .NET clone attempt)

But no matter:
If the info is there, I can write my own interface which is more to my liking.
I don't care about Delphi compatibility in these matters. What matters is
that the concept is there, the exact API I will creatre form myself.


or second option:

compiler hinting directive "experimental" for TypInfo.TAttributeData.

Good

temporary deal for all (I think)...

anyway any option is much better perspective than ignoring RTTI.pas for
long long long time...



No-one is ignoring RTII. I have contacted Joost on multiple occasions to
merge his work into trunk. I get a lot of questions about it. But I cannot
do the work myself. If I could, I would. I am waiting for the attributes
since a long time.



I've now added that to the list of my near term projects, together with
interface RTTI.


Great. Then there is some chance it will happen in the near future.
I hope you still have a lot of vacation/workfree days left :-)

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Tue, 6 Dec 2016, Maciej Izak wrote:


2016-12-06 17:46 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>:


The Delphi TypInfo unit also exposes the attributes.



My message was unclear - I mean that we can hide incompatible part of
TypInfo. Type TAttributeData is located in TypInfo (sooner or later that
part of TypInfo will be corrected - but IIRC for that "Invoke" function is
needed). RTTI.pas is rather fine (need to check).


I am not sure this is possible. The structures exposed in the typinfo
interfacee mimic the info the compiler generates in the binary.

If the compiler generates different info than Delphi, you cannot retrieve 
it in a delphi-compatible way.


Trying to generate the exact same information as Delphi is IMHO not the right 
path.

What is needed is an API that gives you the info contained in the internal 
structures.


or second option:

compiler hinting directive "experimental" for TypInfo.TAttributeData. Good
temporary deal for all (I think)...

anyway any option is much better perspective than ignoring RTTI.pas for
long long long time...


No-one is ignoring RTII. I have contacted Joost on multiple occasions to
merge his work into trunk. I get a lot of questions about it. But I cannot
do the work myself. If I could, I would. I am waiting for the attributes
since a long time.

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

Re: [fpc-devel] Improved RTTI compromise

[Michael Van Canneyt]

On Tue, 6 Dec 2016, Maciej Izak wrote:


Hi,

I was thinking about extended RTTI, and important RTTI.pas module (good
start point with attributes is waiting 3 years). Seems that the only real
reason why we don't have yet RTTI.pas in trunk is incompatibility of
generated type info (as Jonas said: TAttributeData vs TAttrData, no
TAttrEntry).

Current situation seems like big lock for many developers and development.
I see 3 solutions:

1. TAttributeData with additional compiler hinting directive "experimental"
2. Moving TAttributeData into implementation section (and related functions
accessible through alias *.inc for RTTI.pas). Only usage of
attributes through RTTI.pas would be allowed.


The Delphi TypInfo unit also exposes the attributes.

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

Re: [fpc-devel] Raw ARC objects preview

[Michael Van Canneyt]

On Tue, 8 Nov 2016, Jonas Maebe wrote:


On 08/11/16 21:44, Maciej Izak wrote:


One person from FPC core team suggested me to switch to C++/C# instead
of discussing with them.


Please quote me correctly.

I did not make this suggestion.

I said I am surprised that people feel the need to change pascal to look and
act like C++ or C#. This surprise not only concerns you, but many others.

I have voiced it many times on the mailing lists:
Why not simply use those languages if you want the features of those languages?

The "You" is meant impersonal in this question.

I also did ask for your personal motivation to use Pascal anyway - despite the
heavy discussions you experience with the core team, which must indeed be
demotivating - but in no way I meant the question as a suggestion to switch.

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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Paul van Helden wrote:


Specially when they are as invasive as yours. You are in essence
converting pascal to a C++ clone with this MO patch. Is it so bad that this
is discussed thoroughly first ?



+1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and
the next 10 years' Christmases rolled together!

I disagree that modernizing Pascal is making it into a C++ clone.


It depends on how you do it.

What is being introduced with management operators is RAII. 
(Resource Acquisition Is Initialization)

This concept (using copy/clone constructors etc.) comes from C++.

Javascript doesn't have it. Python also not (to my knowledge). 
And these are so-called 'modern' languages.


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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Maciej Izak wrote:


2016-10-26 11:56 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


As long as it's really a separate mode (plus maybe modeswitches for

selected features, that other modes might profit from) I don't see a
problem with adding an Oxygene mode.



Indeed. This is the reason modes were invented.



This is obvious. I won't touch the holy OBJFPC mode ;). Ever. 
I am worried about the speed of reviewing patches and integrations. For example:

Management operators are key feature for many elements in Oxygene mode.
Today I am 28 years old. I think that maybe before my 40th birthday FPC
team decide to merging Management Operatos into trunk -,- . If Oxygene
patch is next, which relay on MO... 80th birthday?


I am happy to report that you are wrong. They are currently under discussion.
Some valid concerns were raised.

By the looks of it, they may be integrated before long.

Please understand:

Free Pascal is a team project. 
This means you cannot expect to have all patches integrated here-and-now.


Specially when they are as invasive as yours. 
You are in essence converting pascal to a C++ clone with this MO patch. 
Is it so bad that this is discussed thoroughly first ?


I understand your youthful impatience, just have a little more patience :-)

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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Sven Barth wrote:


Am 26.10.2016 00:58 schrieb "Maciej Izak" :

Many users likes more modern Pascal (for example oxygene mode is also one

of NewPascal targets), FPC core team likes more old fashioned Pascal... I
do not believe that core team would accept oxygene mode/patch. Anyway...

As long as it's really a separate mode (plus maybe modeswitches for
selected features, that other modes might profit from) I don't see a
problem with adding an Oxygene mode.


Indeed. This is the reason modes were invented.

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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Tue, 25 Oct 2016, Maciej Izak wrote:


Hi,

I'd like to take over work on closures/anonymous methods:

http://newpascal.org/compass.html (point #5).

Patch/hg repository from original author has gone away but I have made
copy. My working repository is here:

https://github.com/maciej-izak/freepascal/commits/closures

I sent here original patch.

I will rework this functionality according to all suggestions from Jonas
and Sven (reference to all informations avaible in NewPascal "compass"
listed above).

any objections?


None, on the contrary. Glad that someone is taking it up.

One remark only: you should keep it independent of (or orthogonal to) 
the work you did on management operators. 
One should not depend on the other...


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

Re: [fpc-devel] GetLongOpts won't set flag when long option is found

[Michael Van Canneyt]

On Mon, 10 Oct 2016, grouchysmurf wrote:


Hi.

I've  been  playing  with GetLongOpts recently and I *think* I found a
bug  though  this may be as well a required behaviour but I decided to
report it anyway.

GetLongOpts fails to set a flag even when directly told to so.

Consider following code [1].

When  executed  with  '-o'  it  sets  flag  as expected. When one uses
'--option' instead flag is not set.

In getopts.pp, line #397:

 if longind<>nil then
  plongint(longind)^:=indfound+1;
 if pfound^.flag<>nil then
  begin
pfound^.flag^:=pfound^.value;
internal_getopt:=#0;
exit;
  end;

I  do  believe  that  the exit should be there but again, maybe that's
just me.


I will look at it, at least I can reproduce the problem.

Can you please post a bugreport, so it will not be forgotten ?

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

Re: [fpc-devel] Overflow in TMemoryStream?

[Michael Van Canneyt]

On Mon, 12 Sep 2016, Michael Van Canneyt wrote:



So it looks like a 32 vs. 64 bit issue.

from the method Realloc :

   NewCapacity := (5*FCapacity) div 4;  // 5*FCapacity can cause 
overflow


Changing this to
  NewCapacity:=FCapacity + (FCapacity div 4)

Will probably fix the issue.


I have committed a patch. Please test and report if it is fixed.
I don't have a 32-bit system available to test on...

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

Re: [fpc-devel] Overflow in TMemoryStream?

[Michael Van Canneyt]

On Sun, 11 Sep 2016, Martok wrote:


Hi,

yes, I can confirm this as an overflow, but on its own, it should be safe. Above
430MB, the stream doesn't grow by a quarter but just by however much was
requested, luckily the branch fails before the wrong capacity could be set.

Test:
type
 TMS2 = class(TMemoryStream) end;
var
 ms: TMS2;
 ds: Int64;
begin
 ds:= 100*1000*1000;
 ms:= TMS2.Create;
 ms.SetSize(ds);
 WriteLn(ds:15,' ', ms.Size:15, ' ', ms.Capacity:15);
 inc(ds, ds div 10); // grow by less than 25%
 ms.SetSize(ds);
 WriteLn(ds:15,' ', ms.Size:15, ' ', ms.Capacity:15);
end.

with ds=100M, prints:
 1   1   13840
 11000   11000   125005824<< grew by 1/4*100M

with ds=500M, prints:
 5   5   52816
 55000   55000   550002688<< bug, grew by 1/10*500M


Output on linux 64-bit

cadwal: >tms
  1   1   13840
  11000   11000   125005824
cadwal: >tms
  5   5   52816
  55000   55000   625004544 This is 1/4
cadwal: >tms
  86900   86900   869003264
  95590   95590  1086255104

So it looks like a 32 vs. 64 bit issue.

from the method Realloc :

NewCapacity := (5*FCapacity) div 4;  // 5*FCapacity can cause overflow

Changing this to
   NewCapacity:=FCapacity + (FCapacity div 4)

Will probably fix the issue.

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

Re: [fpc-devel] TBufferedFileStream

[Michael Van Canneyt]

On Sun, 4 Sep 2016, José Mejuto wrote:


El 04/09/2016 a las 14:04, Michael Van Canneyt escribió:


The second powerful reason is that I was not aware about TBufStream :)

It's even documented.
http://www.freepascal.org/docs-html/current/fcl/bufstream/index.html


Hello,

Sure :) But I'm not aware about all the gems in fpc code :)


TBufStream does support seek ? And SetSize ?

Seek: yes. Setsize not.


I was asking looking at code:

function TWriteBufStream.Seek(const Offset: Int64; Origin: TSeekOrigin): 
Int64;

begin
 if (Offset=0) and (Origin=soCurrent) then
   Result := FTotalPos
 else
   BufferError(SErrInvalidSeek);
end;

Maybe I'm missing something ?

On the SetSize side I think there is a missing check, SetSize can make the 
file smaller, so think in a 1 Kb file, you read the first byte so the buffer 
will be filled with the 1 Kb data, now you SetSize to 1 byte and read another 
byte, this read will return 1 byte success read which is out of the bounds of 
the file.
I know this is a terrible border case and the solution could be just 
invalidate buffer when a SetSize is called.



The TBufStream class has 2 descendents: one for reading, one for writing.
This means the implementation is much more simple, and for most
usecases, this is sufficient.


That's more or less what I was using in other programs, with my own class (I 
should read more docs).



My code like TBufStream inherits from TStream. Which is the advantage
of inherit from TOwnerStream ?

TOwnerStream is only useful if you have a second stream which you use as a
source. It will free it for you. This is useful when chaining streams.


Oh! I see, I'm using the typical Create(Stream,Owned=true)


I will add your implementation to the bufstream unit. It offers more
functionality, but works only on files.

It's - as usual - a tradeoff.


Not exactly, it is possible to add my original implementation TCacheStream 
which works over any TStream and create a TBufferedFileStream (for Delphi 
compat.) inheriting from it, but it will not have the same inheritance chain.


What's the best for fpc ? A generic stream cache, a inheritance compatible 
TBufferedFileStream ? Or maybe both ? Or None ? :)


Generic stream cache. 
If you can rework your implementation to replace TBufStream, that would be absolutely superb !


We can keep the 2 descendents for backwards compatibility.

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

Re: [fpc-devel] TBufferedFileStream

[Michael Van Canneyt]

On Sun, 4 Sep 2016, José Mejuto wrote:


El 04/09/2016 a las 7:15, Michael Van Canneyt escribió:


In the other hand a cache system is powerful than a buffered system if
you are writing something like a filesystem over a TFileStream where
you may need to jump here and there to read data, file allocation
tables, attributes, and so on, in this case a cache with multiple
pages instead just one improves the result (avoid multiple reads in
the same zones).


And why did you not use the bufstream unit of FPC ?

The TBufStream stream implemented there works with any other stream, not
just files.



Hello,

In fact I wrote my code over TStream but in Delphi the class is inherited 
from TFileStream so I take my "TStreamFilter" and adapt it to inherit from 
TFileStream just as Delphi do.


The second powerful reason is that I was not aware about TBufStream :)


It's even documented.

http://www.freepascal.org/docs-html/current/fcl/bufstream/index.html


TBufStream does support seek ? And SetSize ?


Seek: yes. Setsize not.

The TBufStream class has 2 descendents: one for reading, one for writing.
This means the implementation is much more simple, and for most usecases, 
this is sufficient.




My code like TBufStream inherits from TStream. Which is the advantage of 
inherit from TOwnerStream ?


TOwnerStream is only useful if you have a second stream which you use as a
source. It will free it for you. This is useful when chaining streams.

I will add your implementation to the bufstream unit. 
It offers more functionality, but works only on files.


It's - as usual - a tradeoff.

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

Re: [fpc-devel] TBufferedFileStream

[Michael Van Canneyt]

On Sat, 3 Sep 2016, José Mejuto wrote:


El 03/09/2016 a las 22:15, Michael Van Canneyt escribió:


Added to the bugtracker implementation of TBufferedFileStream, there
is one compatibility issue note in the bug entry.

http://bugs.freepascal.org/view.php?id=30549


Nice. I have assigned this to myself.

Out of curiosity:
Why do you think this is needed ? Is the caching provided by most of the
operating systems not enough ?


Hello,

1) Delphi compatibility (It is available in Delphi).

2) TFileStream basically is a frontend for FileRead and FileWrite (Talking 
about Windows) and once you invoke one of those you enter in multithread 
contention, thread swapping, and maybe kernel mode (I'm not sure) so if you 
read or write small pieces of data from files the performance is very poor. 
Typical example is TFileStream.GetByte which I'm using in a parser, because 
the file could be very big, and I don't want to read everything in a 
TMemoryStream, performance of cache/buffered and regular is dramatically 
different:


--
CACHE 100 byte sequential reads in 46 ms.
FILE 100 byte sequential reads in 2200 ms.
--

And this result is with the system cache hot (in fact the full file is in 
system cache).


In the other hand a cache system is powerful than a buffered system if you 
are writing something like a filesystem over a TFileStream where you may need 
to jump here and there to read data, file allocation tables, attributes, and 
so on, in this case a cache with multiple pages instead just one improves the 
result (avoid multiple reads in the same zones).


And why did you not use the bufstream unit of FPC ?

The TBufStream stream implemented there works with any other stream, not just 
files.

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

Re: [fpc-devel] TBufferedFileStream

[Michael Van Canneyt]

On Sat, 3 Sep 2016, José Mejuto wrote:


Hello,

Added to the bugtracker implementation of TBufferedFileStream, there is one 
compatibility issue note in the bug entry.


http://bugs.freepascal.org/view.php?id=30549


Nice. I have assigned this to myself.

Out of curiosity:
Why do you think this is needed ? 
Is the caching provided by most of the operating systems not enough ?


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

Re: [fpc-devel] Managed types and reference counts revisited

[Michael Van Canneyt]

On Wed, 17 Aug 2016, Adriaan van Os wrote:

Thanks for the clarification. I suggest the doc page 
 to be changed 
accordingly.


And also the test program there.


And what do you want to see changed ? 
The test program shows the actual behaviour of the compiler ?


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

Re: [fpc-devel] Update of ENet headers

[Michael Van Canneyt]

On Wed, 3 Aug 2016, Чернов Дмитрий wrote:


Hi again.
 
Year ago, I've proposed ENet headers, translated to Free Pascal, for adding to 
the standard distrubution.
Recently I updated the headers, details are here:
http://bugs.freepascal.org/view.php?id=27891#c93969
 
It would be nice to see updated headers in the current FPC trunk.Anyway thanks.


I have looked at it, will apply as soon as possible.

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

Re: [fpc-devel] NowUTC in FPC

[Michael Van Canneyt]

On Mon, 1 Aug 2016, Denis Kozlov wrote:


On 01/08/2016 07:59, Michael Van Canneyt wrote:
But that would create duplicated code of LocalTimeToUniversal, 
UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils.


So what ? It is essentially A+B*C or some variant of that.


I try to avoid code duplication, which unnecessarily increases maintenance 
efforts.


One must weigh always weigh the advantages over the disadvantages.
Consistency and design of the API have also their purpose.

If I didn't care about that, I would simply have added it to dateutils.
As it is now, dateutils is 100% portable. By introducing a dependency on the
OS, this is no longer true, and I think that should be avoided.


Since you seem reluctant, no problem, I will do it myself.


I'm asking for guidance to make sure I do it the right way.


In that case, just copy the implementation of the functions involved.


Is it really so bad to include DateUtils in RTL?


Yes. It was specially removed to keep the RTL as small as possible.

To move it back for the sake of some multiplications and additions is not an
option IMHO.

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

Re: [fpc-devel] NowUTC in FPC

[Michael Van Canneyt]

On Mon, 1 Aug 2016, Denis Kozlov wrote:


On 30/07/2016 17:45, Michael Van Canneyt wrote:

I don't see why you cannot perform simple additions in sysutils.
But that would create duplicated code of LocalTimeToUniversal, 
UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils.


So what ? It is essentially A+B*C or some variant of that.

Since you seem reluctant, no problem, I will do it myself.

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

Re: [fpc-devel] NowUTC in FPC

[Michael Van Canneyt]

On Sat, 30 Jul 2016, Denis Kozlov wrote:


On 30/07/2016 11:10, Michael Van Canneyt wrote:
I had a look at it. Please modify the patch first, see comments in 
bugreport.


The reason why I put UniversalTime (a.k.a. NowUTC) function in DateUtils is 
because of the dependency on LocalTimeToUniversal, UnixToDateTime, 
IncMilliSecond functions.


As far as I can see, these perform almost the same function as EpochToLocal in
sysutils/unix.

You can perfectly do these additions manually.



I presumed that DateUtils cannot (or must not) be added to the uses section 
of SysUtils.


Indeed it cannot.



What would you recommend?


I don't see why you cannot perform simple additions in sysutils.

The reverse, introducing system dependent system calls in dateutils, is a
much worse solution. DateUtils is for simple date/time calculations, not for
performing OS calls.

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

Re: [fpc-devel] NowUTC in FPC

[Michael Van Canneyt]

On Sat, 30 Jul 2016, Denis Kozlov wrote:


Can somebody take a look and apply the patch please?


I had a look at it. 
Please modify the patch first, see comments in bugreport.


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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Maciej Izak wrote:


2016-07-28 16:37 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Are there additional benefits I have missed ?



Using nilable (I think nilable is better than nullable) records is terrible
without default field:

=== code begin ===

var
 n: TNilable;
 x: TRec;
begin
 {

  ... let say that n is assigned somewhere, assume that n.HasValue = true

 }
 // to change any field in nilable n  you need to...
 x := n.Value;



OK, you convinced me for this one :-)

Michael.



that will change nothing, just look below. Just harder to usage pure
non-pascalish clone of C# struct (finally C# has pointers as
nonstandard/unsafe type so feature with direct dereference is disabled by
design).

=== code begin ===

procedure SomeTest(x : Integer);
begin
end;

Var
 A : TNullable;
begin
 SomeTest(A.Value); // AV error here!
end.

=== code end 

A^ is shortcut for A.Value but has advantage = direct dereference to
Instance.


Here I am not convinced.

This is an artifact of your implementation: you use a pointer. 
There is no need to use a pointer. One can just as well do


TNullable  = Record 
Private

  Fvalue : T;
  IsNotNull : Boolean;
Public
  // all the rest, including
  Property Value : T Read GetValue Write SetValue;
  Property IsNull : Boolean Read GetIsNull;
end;

Then you will not have this problem; 
GetValue will always return a 'Default' value.


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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Dmitry Boyarintsev wrote:


On Thu, Jul 28, 2016 at 10:37 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:


[+] Default field (even if it is only syntactic sugar)



can-o'worms:
Wasn't there a discussion to have multiple default fields depending on the
type?


[-]  Multiple default fields: definite nono, since this compromises type safety.

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Maciej Izak wrote:


2016-07-28 14:59 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Because with the exception of the ^ operator, I see no need for any special
constructions to achieve a "nullable type", except maybe some implicit
constructor/destructor ?



procedure with var parameter is special case, we need somehow to perform
backward compatibility and strong typing is the must. In the fact
TNullable is proxy type to field of ^Integer type. ^ operator
exist to make life easier in comparison to C# implementation.

"default field" is not necessary for nullable types but is extremely useful
addition, more options and optimization for end user.


Can you please explain this, because as far as I can see from your
explanation, all that it does is make 2 assignment operators and maybe a
typecast operator unnecessary ?

(in which case it falls under the category syntactic sugar, like "for ..
in", which is fine for me)

Are there additional benefits I have missed ?


We can exclude
completely possibility of usage ^ operator for nullable types (^ for
nullable type is just my invention). In that case calling functions like
test1 will be impossible. Just pure copy of Nullable types from C# -,- . So
you are right - ascetic version of nullable type need only management
operators (aka implicit constructor/destructor). Presented nullable type is
not "pure" copy of C# implementation, presented above implementation has
Pascal spirit and optimizations impossible to achieve in other languages.


Well, I think this addition is not necessary, maybe even dangerous.
I can live with the 'ascetic' version :-)

Since the following:

Procedure SomeTest(Var X : Integer);

begin
  X:=1; 
end;


Var
  A : TNullable;

begin
  SomeTest(A^);
end.

Will lead to a crash on a null value, I don't think this is a very good idea to 
add.
We should protect users from crashes, not expose them to it :-)

So, currently balance for me, if I understood everything correctly:
[+] Implicit constructor/destructor.
Good for simulating 'managed' types.
[+] Default field (even if it is only syntactic sugar)
[-] ^ dereference magic: a no-no :)

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Maciej Izak wrote:


2016-07-28 13:30 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Assume a is null before the call to test1:

  test1(a);



That won't compile.




1. What happens if this procedure is empty, i.e. no write is performed ?
   (or it is performed conditionally)
   On return, is a null or not ?



You are not able to call test1 in presented form (you will get error:
Incompatible types).


In that case, I do not understand at all what you are in fact trying to achieve 
:/

Because with the exception of the ^ operator, I see no need for any special
constructions to achieve a "nullable type", except maybe some implicit
constructor/destructor ?

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Maciej Izak wrote:


2016-07-28 12:40 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


I don't see how you can solve nullable var parameters in native code.



I'd like to present how TNullable works in my implementation (compilable
and runable program ;)


Yes, I remember you demonstrate it. But I think there are some caveats.



=== code begin ===
procedure Test1(var x: Integer);
begin
 x := 1;
end;


Assume a is null before the call to test1:

  test1(a);

1. What happens if this procedure is empty, i.e. no write is performed ?
   (or it is performed conditionally)
   On return, is a null or not ?

2. Assume your variable is null before the call to Test1.
   What is the value on entry into Test1 ? i.e. what happens if

   begin
 if X=0 then
   x:=1
 else
   X:=23;
   end

3. How do you detect an actual write ?

4. What happens if Test1 is an external C procedure ?

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Thu, 28 Jul 2016, Sven Barth wrote:


Am 27.07.2016 23:27 schrieb "Jonas Maebe" :

Before continuing, I think it would be a good idea to look at what the

desired concept is exactly (transparent proxy objects/references, thin
wrappers that allow to specify some default behaviour, nullable types, ...
?) already exists in other programming language (not C++ -- everything is
just meta-programmed using templates there) and how things work there at
least from a specification standpoint.

The main features that Maciej wants to achieve - at least as far as I can
see it - is ARC without changing TObject (basically the approach that one
would choose in C++) and Nullable types.
For the later I've found that C# and also Oxygene implement this, however
they don't do this based on the type, but the variable.

=== code begin ===

var
 x: nullable Integer;

=== code end ===

Pointer types (in Oxygene these are only object references, in FPC that
would also include the managed strings and dynamic arrays) are inherently
nullable ("nullable Pointer" or "nullable TObject" wouldn't be any
different from regular "Pointer" and "TObject") this also introducing "non
nullable", though I don't think we'd need this for now.
I haven't checked in detail, but there is probably a check for Nil plus an
exception if a Nil-nullable is assigned to a non-nullable variable
(something like "as" basically).

So we /could/ solve the Nullable topic by using the approach Oxygene has
chosen, maybe only with an exception of var-parameters (as internally it
would probably be represented by a automatically generated container
record).


I don't see how you can solve nullable var parameters in native code.

There is no way you can detect a write to the address, necessary to set
the not-null flag.

So I would conclude that "nullable" support is incompatible with var params.

Assuming that is the case, the "default property in record" approach invented by 
Izak seems IMHO more powerful than


var
  x: nullable Integer;

If you consider that

 X : TNullable;

makes X a different type from 'integer', the fact that you cannot pass it in a 
var
parameter (expecting Integer) simply follows from the strict type checking rule 
of pascal.

I find that easier to explain than explaining that a non-nullable defined as
 x: nullable Integer;
("which is after all an integer") cannot be used in var parameters.

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Wed, 27 Jul 2016, Jonas Maebe wrote:


On 27/07/16 22:47, Sven Barth wrote:

Am 27.07.2016 21:04 schrieb "Maciej Izak" >:



In that case SmartPtr/SmartObj/Nullable type has no sense for me. The

basic purpose is excluded. You can do that today by using for example
proxyobject._.foo();


What is the basic purpose? I did not see any explanation of that in the 
original mail. It only said that it is vital to the smart pointers/ARC 
objects and nullable types implementation.


As far as I understand I think Izak wants (needs) 2 things:

- "Default" property for a property of records.
  I think that this feature by itself presents little difficulty.

  This is enough to implement "nillable" types, except for 1 thing.
  (second point)

- The ability to pass properties as var arguments.

  I think this feature is not doable. The closest you can come to this is:

  tmp:=A.Prop;
  try
MyProcedureVarArgument(tmp);
  finally
A.Prop:=Tmp;
  end;

  But this presents obvious timing problems: A.Prop is written only on return 
of the function.

  Failing that, Izak tries to simulate the 'address' of the default property
  of a record.

IMHO The first can be done, the solution to the second is a bad idea.

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Wed, 27 Jul 2016, Jonas Maebe wrote:



Michael Van Canneyt wrote on Wed, 27 Jul 2016:


Why not introduce an address operator ?

operator @ (T : MyType) : Pointer;


It's only needed because Maciej wants the proxy type to behave differently 
from all other existing types. The solution is not to add functionality to 
make that easier, but to fix the inconsistencies.


Then I didn't understand what exactly you think is inconsistent ?

Knowing the purpose, what do you think can be done ?

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Wed, 27 Jul 2016, Jonas Maebe wrote:



Michael Van Canneyt wrote on Wed, 27 Jul 2016:


On Wed, 27 Jul 2016, Maciej Izak wrote:



TNullable = proxy record
...

looks good for me, even better than pure record, the context is more 
clear.


Yes. Exactly what Jonas wanted to achieve, I suppose.


A bitpacked or packed record still behaves like a regular record. If does not 
behave like a record, it should not be called a record.


Well, it can be a special kind of type helper.

Symply extend the syntax for type helper with a new word.



Additionally, the @@/@ operator thing is inconsistent with how e.g. 
ansistrings or dynamic arrays work: @ansistringvar does not get you the 
address of the first character, but of the variable itself. Similarly, there 
is no @@ansistringvar to get the address of the ansistring variable itself 
rather than of the first character, even though the 'value' of an ansistring 
starts at that first character.


Procedure variables in Turbo Pascal (and Delphi) are the only type for which 
this approach was ever was used, and given that they didn't use it anymore 
later on may indicate that they also thought it was not a very good idea in 
hindsight. Let alone that we would also start accepting @@@-expressions 
(https://github.com/maciej-izak/PascalSmartPointers/blob/master/tests/tdefault21.pp 
).


Why not introduce an address operator ?

operator @ (T : MyType) : Pointer;

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Wed, 27 Jul 2016, Maciej Izak wrote:


2016-07-27 13:11 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Instance: ^T; default;



";" between default and type will not work.


Sorry, typo :/



TNullable = proxy record
...

looks good for me, even better than pure record, the context is more clear.


Yes. Exactly what Jonas wanted to achieve, I suppose.

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Wed, 27 Jul 2016, Maciej Izak wrote:



3. "default" need to be transparent and usable with existing code base,
some compiler magic is part of my further compiler development (I mean here
"Storage Modifiers" and ARC objects in DelphiNextgen mode). With current
approach is possible to pass record with default field as var/out/constref
parameter. With property that is impossible.


This is probably the only good argument.



Question: can "default" only be used in "record" or also in "object" and
"class"?



Current implementation allows "default" only for "records".


I don't think that for classes this should be allowed.

Imagine:

TSomeClass = Class
  Property SomeProp : TSomeClass; default;
end;

Var
  A,B : TSomeClass;

begin
  A:=B;  // What to do ? Set A, or A.SomeProp ?
end;

For records, this construct is simply not possible.


@@ operator is very simple way to determine where you point. In any other
case we have casting hell. See below (and more below). @@ exist rather as
fulfillment to pa := @a; form tdefault7.pp (anyway is necessary for untyped
pointers). You might not like @@ operator but @@ is part of long tradition.
In practice works like a charm and is very clear.


I agree and think @@ is indeed better.





Since normally in Pascal the
result type of an expression is *not* determined by the left hand side
of an assignment that's rather confusing (yes, there are exceptions, but
that doesn't mean that one needs to add a new one).



That is also by design. That is because you can't declare as "default
field" nor "normal field" the field of owner type, so as logical
consequence the syntax needs to be allowed (I mean here pa := @a; form
tdefault7.pp). In daily usage it works very well and any other compiler
behavior is irrational.


? A compiler always behaves rational.

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

Re: [fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

On Tue, 26 Jul 2016, Maciej Izak wrote:


Hi,

Finally I have a working implementation (not published yet) of Smart
Pointers/ARC objects and Nullable (Nilable?) types. I think is worth to
discuss a little about new "default modifier" (which is strictly related to
mentioned structures). If needed I can correct details.

As you know (or not) all is based on new modifier - "default" for fields.
Overriding operators like "." or "^" is complicated and not obvious in
Pascal world.

The "default" modifier is inspired by "default" modifier for indexed
properties. All of my work is (I hope so) natural for Pascal language. All
FPC tests pass fine (phew!). The idea is quiet simple:

"If all fails - try to use default field".

Example implementation of SmartPointers and SmartObjects available at:

https://github.com/maciej-izak/PascalSmartPointers (see OUTPUT on the end
of each of file)

Tests (very good way to see how it works. NOTE: I need to add few other
tests for functions with var/const/out, "for in do" loop and for arrays and
indexed properties - help with additional tests is welcome):

https://github.com/maciej-izak/PascalSmartPointers/tree/master/tests

The way how to obtain pointer can be a little confusing for most of Pascal
programmers. Anyway nothing new for Pascal language. In Pascal we have
little known @@ operator to get pointer to variable which handle pointer to
procedure/function. For records with "default field" @ means "get pointer
to default field" and @@ means "get pointer to record".


Very nice job indeed.

I can see a lot of potential in this for ORM implementations, where IS NULL
is always a difficult concept.

As for ARC: I think this is a difficult topic, which should better be
discussed in a separate thread.

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

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

[Michael Van Canneyt]

On Tue, 19 Jul 2016, Luiz Americo Pereira Camara wrote:


2016-07-19 5:47 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>:




On Tue, 19 Jul 2016, Dimitrios Chr. Ioannidis wrote:

Exception class:   EAssertionFailedError

Exception message: "Correct extended value" expected: <5,67> but was:
<6>
at   $0043241F  TTESTJSONDESTREAMER__TESTFLOAT4,  line 374 of
testjsonrtti.pp



I am aware of this.

However, this is only on i386, on 64-bit the code runs fine.
I have no idea why, the code should be CPU agnostic.

I have not yet had the opportunity to debug it on a i386 machine.



I just looked at it in this weekend.

After doing some tests and reading the docs i realized that is not a bug in
fpjsonrtti, nor a bug at all.

First write directly 4.56 to the property (of comp type). Reading it
directly gives a rounded value (5)

Than i read the docs:
http://www.freepascal.org/docs-html/ref/refsu6.html
"The Comp type is, in effect, a 64-bit integer and is not available on all
target platforms. To get more information on the supported types for each
platform, refer to the Programmer’s Guide. "

http://www.freepascal.org/docs-html/prog/progsu160.html#x204-2130008.2.5
"Comp

For Intel 80x86 processors, the comp type contains a 63-bit integral value,
and a sign bit (in the MSB position). The comp type uses 8 bytes of storage
space.

On other processors, the comp type is not supported.
"

It works in 64bit cpu because is testing other code:

{$ifdef CPUX86_64}
   AssertProp('ExtendedProp',TJSONFloat(5));
 {$else}
   AssertProp('ExtendedProp',4.56);
 {$endif}


Haha... I was thrown off by the ExtendedProp in the error reports.
That should be CompProp obviously. I will adapt the test code accordingly.

Many many thanks for spotting this !!

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

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

[Michael Van Canneyt]

On Tue, 19 Jul 2016, Sven Barth wrote:


value" expected: <4,56> but was: <5>

Exception class:   EAssertionFailedError
Exception message: "Correct value" expected: <4,56> but was: <5>
at   $00434358  TTESTJSONSTREAMER__ASSERTPROP,  line 761 of

testjsonrtti.pp

  Failure:
Message:   TTestJSONDeStreamer.TestFloat4: "Correct extended

value" expected: <5,67> but was: <6>

Exception class:   EAssertionFailedError
Exception message: "Correct extended value" expected: <5,67> but

was: <6>

at   $0043241F  TTESTJSONDESTREAMER__TESTFLOAT4,  line 374 of

testjsonrtti.pp



I am aware of this.

However, this is only on i386, on 64-bit the code runs fine.
I have no idea why, the code should be CPU agnostic.

I have not yet had the opportunity to debug it on a i386 machine.


Judging by the errors that is probably due to the compiler using Extended
for some evaluations. You'd need to force them to Double or Single to avoid
that.


Huh ? How can using a higher precision type lead to _less_ precision ???

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

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

[Michael Van Canneyt]

On Tue, 19 Jul 2016, Dimitrios Chr. Ioannidis wrote:


On 19/7/2016 10:54 πμ, Michael Van Canneyt wrote:



On Mon, 18 Jul 2016, Stéphane Wierzbicki wrote:





I have modified TJSONStreamer and TJSONDeStreamer class to handle 
ISO8601

dates by adding a new jsoDateTimeAsISO8601 option.
Where can I send these modifications ?


What version of FPC did you use ?

The latest version of TJSONStreamer and TJSONDeStreameruse this format
already, check the jsoLegacyDateTime option.


With fixes_3.0 branch rev. 34112 ( also in today's trunk ), the json 
testsuite reports two failures :


Number of run tests: 322
Number of errors:0
Number of failures:  2

List of failures:
  Failure:
Message:   TTestJSONStreamer.TestWriteFloat4: "Correct 
value" expected: <4,56> but was: <5>

Exception class:   EAssertionFailedError
Exception message: "Correct value" expected: <4,56> but was: <5>
at   $00434358  TTESTJSONSTREAMER__ASSERTPROP,  line 761 of 
testjsonrtti.pp

  Failure:
Message:   TTestJSONDeStreamer.TestFloat4: "Correct 
extended value" expected: <5,67> but was: <6>

Exception class:   EAssertionFailedError
Exception message: "Correct extended value" expected: <5,67> but 
was: <6>
at   $0043241F  TTESTJSONDESTREAMER__TESTFLOAT4,  line 374 of 
testjsonrtti.pp


I am aware of this.

However, this is only on i386, on 64-bit the code runs fine.
I have no idea why, the code should be CPU agnostic.

I have not yet had the opportunity to debug it on a i386 machine.

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

Re: [fpc-devel] Sven commit (r34087) breaks casting an object to an interface

[Michael Van Canneyt]

On Fri, 15 Jul 2016, Maciej Izak wrote:


Hi,

change in mentioned FPC trunk r34087 totally breaks sparta dockedformeditor
package (and probably many other things) see:

http://forum.lazarus.freepascal.org/index.php/topic,27211.msg216064.html#msg216064
http://bugs.freepascal.org/view.php?id=30377

please revert mentioned commit (what is sense for such change?).


Presumably, Sven has a reason for this change ?

For example, dynamic packages support may necessitate such a change.
(just a wild guess)

If the change is needed, the right approach is to fix the bug that this change 
causes.

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

[fpc-devel] OData and Office365 REST API support

[Michael Van Canneyt]

Hello,

Long overdue, I have finally committed the initial version of the odata
package in the FPC repository.

This package provides the base for OData integration in your applications.
OData is a standard adopted by the OASIS group: it describes data exchange
through REST APIs. OData V4 and OData V2 are supported.

The workings of the OData integration are demonstrated in the conversion of
the MS Office365 Unified REST API. (MS Graph).

This allows seamless integration of all Office365 components in your
application.

Additionally, the (huge) Sharepoint Online REST API (which uses V2 of
the OData protocol) has also been converted.

All this, with some sample programs and the conversion tool for OData
metadata files, is committed in FPC's subversion, revision 34097.

Suggestions, testing: all welcome.

Enjoy,

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

Re: [fpc-devel] overflow error in Fpopendir

[Michael Van Canneyt]

On Thu, 30 Jun 2016, Seth Grover wrote:



At +123 I can see that $eax/$ebx contains the correct descriptor, 51345.
However, when I print $bx in the debugger, it looks like a negative number,
as if it had overflowed a signed 2-byte integer, so the function errors
out. This causes the file descriptor to be leaked as well, since no
reference to is is retained in the pdir record.

I'm a little bit confused at this, as fd is defined as an "integer," which
I thought was going to always be a 32-bit signed value on this system.


No, it depends solely on the compiler mode.


However, the FPC documentation tells me that this can be changed based on
compiler switches, so maybe somewhere up in one of the other .inc files
there is some flag making "integer" behave as a signed 16-byte number?

I am inclined just to patch my copy of the FPC rtl and change the
definition of fd from "integer" to "longint," but I wanted to get your take
on it first.


Best is to use either THandle or cInt, probably the former. The latter may
not be defined in the system unit.

Nice catch !

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

Re: [fpc-devel] fpc svn trunk building fails

[Michael Van Canneyt]

On Sun, 5 Jun 2016, Karoly Balogh (Charlie/SGR) wrote:


Hi,

On Sun, 5 Jun 2016, Sandro Cumerlato wrote:


fpc svn trunk version 33910 building fails with error:
*..snip..*
   Compiling .\fcl-db\src\export\fpxmlxsdexport.pp
   Compiling .\fcl-db\src\sqldb\interbase\fbadmin.pp
The installer encountered the following error:
Compilation of "BuildUnit_fcl_db.pp" failed
make[2]: Leaving directory `C:/freepascal/fpc/trunk/packages'
make[1]: Leaving directory `C:/freepascal/fpc/trunk'


Actually, another issue is, since when does fpmake hide the compiler
output on failures? Because fbadmin.pp is obviously broken, so there
should be compiler errors. For a starter, it has the wrong unit name
(fbadmin2), but even with that fixed, it doesn't compile.

But there isn't a single line of error message in the fpmake output,
while there used to be (IIRC)...


I fixed the error; I implemented additional features in a copy named
fbadmin2.pp, and after verifying the implementation simply copied over 
the file, but forgot to change the unit name.


Rev 33913 contains a fix.

See also http://bugs.freepascal.org/view.php?id=30238

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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Mon, 30 May 2016, Maciej Izak wrote:


2016-05-30 15:40 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


This is not an argument.



Yes this is not an argument but reality. It blocks a lot of code.


Certainly.
I suffer from it myself from time to time, but such is life...


Expecting some kind of timeline is simply deceiving yourself.



No. That is kind of motivation and discipline.

no offence :)


None taken, simply because I don't understand what you mean with your last 
sentence... :)

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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Mon, 30 May 2016, Maciej Izak wrote:


2016-05-30 14:41 GMT+02:00 Sven Barth :


Let me first finish the packages stuff as that will lead to a breaking
change in the RTTI binary format (PPTypeInfo instead of PTypeInfo,
necessary due to Windows' PE format) and I don't want to add any new RTTI
stuff before this is dealt with.


I do not want to grumble, but... Release date for packages? It is really
painful. Maybe you need some support? My work with smart pointers is almost
done and after smart pointers release I can put effort into packages. The
work of other developers outside FPC core team (also my work) is blocked
for more than half a year... or even more.


This is not an argument.

I will repeat: FPC is and remains a hobby project for the core team.

Expecting some kind of timeline is simply deceiving yourself.

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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Mon, 30 May 2016, tha...@thaddy.com wrote:


New feature. Belongs in 3.1.1.


And the implementation is contested, which is the reason why it doesn't get
merged to trunk.

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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Sun, 29 May 2016, Ondrej Pokorny wrote:


On 29.05.2016 10:33, Michael Van Canneyt wrote:

We're set to create the branch at the end of May, which is about now.
The last merges have been performed. I assume Marco will tag somewhere this
week, and then building starts.


Great!

Do you have a merge list on the net somewhere (like Lazarus has: 
http://wiki.freepascal.org/Lazarus_1.6_fixes_branch ) or do I have to check 
the SVN merge info manually to see what has been merged?


Marco maintains a merge list, but I don't know the URL offhand.

All in all, the best (and authoritative) source is svn mergeinfo :-)

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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Sun, 29 May 2016, Juha Manninen wrote:


Is there any estimate for FPC 3.0.2 release?
FPC 3.0.0 was released already at November 26, over half a year ago.
Fixes branches of both FPC and Lazarus have lots of important commits.
Lazarus 1.6.2 + FPC 3.0.2 would make a nice and solid combination.


We're set to create the branch at the end of May, which is about now.
The last merges have been performed. I assume Marco will tag somewhere this
week, and then building starts.

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

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

[Michael Van Canneyt]

On Mon, 23 May 2016, Jonas Maebe wrote:



Michael Van Canneyt wrote on Mon, 23 May 2016:


The typecase will not help you, since the result is an ansistring.
The result will still be crippled.


It would help when DefaultSystemCodePage is changed to UTF-8, as Lazarus 
does.


Should that not be multibytecodepage or so ?




The only solution for this is a unicode RTL.


That is incorrect, since as he wrote the unicodestring version of 
GetEnvironmentVariable() already exists in our RTL today. It's just that it's 
only used if you pass it a unicodestring argument, which won't be be the case 
in most Lazarus programs by default.


Aha. I didn't know we already had an overloaded version. I stand corrected !

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

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

[Michael Van Canneyt]

The typecase will not help you, since the result is an ansistring.
The result will still be crippled.

The only solution for this is a unicode RTL.

Michael.

On Mon, 23 May 2016, Denis Kozlov wrote:


P.S. A minor typo, GetEnvironmentVariableA should read
GetEnvironmentStringsA.


On 23 May 2016 at 13:31, Denis Kozlov  wrote:


Hi,

In FPC 3.0.0 and TRUNK for Windows:

SysUtils.GetEnvironmentVariable(String) uses GetEnvironmentVariableA
SysUtils.GetEnvironmentVariable(UnicodeString) uses

GetEnvironmentStringsW

GetEnvironmentVariableA produces a result crippled by ANSI/OEM. Can it be
replaced with a simple typecast of UnicodeString based function:

function GetEnvironmentVariable(const EnvVar: String): String;
begin
  Result := String(GetEnvironmentVariable(UnicodeString(EnvVar)));
end;

Denis




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

Re: [fpc-devel] Split advancedipc and advancedsingleinstance

[Michael Van Canneyt]

On Tue, 10 May 2016, Luiz Americo Pereira Camara wrote:


Hi,

I'm looking for a ipc to send log messages between processes.

Advancedipc recently added to trunk seems to do the job.

I noticed that TAdvancedSingleInstance lives in the same unit as the ipc
classes

Any chance to split  TAdvancedSingleInstance class into a separated unit so
no extra code for those that dont use it?

I can take the duty if is the case


Please do.

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

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

[Michael Van Canneyt]

On Mon, 25 Apr 2016, Maciej Izak wrote:


Finally I've decided to use Clone and Copy (as proposed by Florian). Should
I adjust RTL inner functions to this? I mean renaming FPC_COPY to FPC_CLONE
and FPC_ADDREF to FPC_COPY.


Are these the assembler names of existing functions ?

If so, the reason these have an assembler name is that they can be called directly 
from assembler code. So maybe it is better not rename them, I would think, since
we don't know what assembler code calls them. If you change them, then people 
that call these routines will not get any warning why their code suddenly behaves

differently ?

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

Re: [fpc-devel] HPack for HTTP2

[Michael Van Canneyt]

On Sun, 24 Apr 2016, José Mejuto wrote:


Hello,

Added entry in the bug tracker for HPack implementation for http2.


http://bugs.freepascal.org/view.php?id=30058

If somebody whats to add it somewhere in fpc/fcl code base. It is based in 
Twitter's HPack Java implementation.


It includes fpcunit test file and sample files.

There are still a bit of changes needed in the DynamicTable handling to gain 
a bit of speed, but corrently it seems to be valid for production code.


Thank you very much. I will add it to SVN asap. (i.e. tomorrow :))

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

Re: [fpc-devel] FPC implementation of attributes for language parts.

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Maciej Izak wrote:


2016-04-13 14:36 GMT+02:00 Sven Barth :


*I* won't add it.


I can do it after merging Joost's class attributes branch. No one really
won't this but it is the must. IFDEF hell is much more visible for
"constref/[ref] const" than in any other place... :(


But please, only in Delphi mode.

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

Re: [fpc-devel] FPC implementation of attributes for language parts.

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Maciej Izak wrote:


2016-04-13 13:03 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Sorry. This is simply very bad design.



I agree with many points. Frankly, I was surprised that they did something
like using attributes in that way. I try to understand and find something
positive.


Sometimes, there is nothing positive to be found, even with the biggest
microscope :-)

IMHO they are randomly copying recipes from C# and Java.
Which is IMHO nonsense, since those languages are based on virtual machines, 
where runtime and compile-time are blurred concepts...


A losing strategy on all accounts, you should always start from your own 
strength
and build on that.



I only like to see [ref] const as alternate syntax for constref, only for
Delphi mode. It is really problematic.


I suppose that in Delphi mode, we'll need to support it anyway :/

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

Re: [fpc-devel] FPC implementation of attributes for language parts.

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Maciej Izak wrote:


Moved from: "Initialize/Finalize management operators and Default
intrinsic". I'd like to keep Initialize/Finalize topic more clear ;P

Small introduction:

for selected language elements in Delphi is possible to use attributes. For
example in Delphi we have:

 TCustomAttribute = class(TObject)
 end;
 WeakAttribute = class(TCustomAttribute);
 UnsafeAttribute = class(TCustomAttribute);
 RefAttribute = class(TCustomAttribute);
 VolatileAttribute = class(TCustomAttribute);

which is used like this:

procedure Foo([ref] const X: TFoo); // AFAIK FPC equivalent is procedure
Foo(constref X: TFoo);

or like this for TObject field for ref. count for ARC:

[Volatile] FRefCount: Integer;


Sorry. This is simply very bad design.

1. We already have a syntax for this kind of thing, it is called modifiers.
   No need to introduce a second syntax. You just introduce extra modifiers.

2. You make the COMPILER dependent on USER-DEFINED classes.
   What kind of nonsense is that ?
   It is even worse than the enumerator syntax Borland/Embarcadero invented.

If the compiler needs to know about it and act on it (and it does for ARC), 
then it must be a keyword or modifier.


Attributes are meant for user-space information.

The compiler has no business with it, from the point of view of the compiler
the presence or non-presence of attributes is entirely irrelevant. It is
meant to be extracted easily by the user. No more, no less.

Attributes used like this are self-contained. You can use it or not, it
makes no difference to the compiler. This is an example of _good_ design.

If you use attributes to start controlling ARC or whatever other 
_language feature_, this is _bad_ design, because you link one 
feature to another, which simply is not related to it at all.





To clarify: I am not a big fan of the attributes syntax. But...

If attribute is used you already know that it has more "flag idea" (by
analogy to RTTI attributes, anyway it does not have to be just like a
flag), as in our example presented in "Initialize/Finalize management
operators and Default intrinsic" topic - is more visible whole context.
Introducing many new keyword is the waste and can collide with existing
keywords.


Clearly, you are missing something very important: Modifiers are _not_ keywords.
You can add as much modifiers as you want.  They will never interfere with the 
syntax.
That is the whole point of modifiers ?!

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 15:33 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Quite strange, Joost claimed the exact opposite :-)



Maybe different approach than in Delphi, or I miss something. But as far as
I can see, there is something like that:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/joost/classattributes/tests/test/tclassattribute4.pp?view=markup=date


I don't think Joost planned to support the same low-level API as delphi.

I remember discussions about that, but this is meanwhile some years ago.
The best source of information is still Joost.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 14:48 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


I really don't think you should delegate such things to attributes. You
make 2 completely unrelated language constructs suddenly related. A bad
design decision.



I think you are wrong. Attributes are not only dedicated to RTTI just look
at other languages: Delphi, C#, Java. Instead of extending language into
infinity you can use simple attribute with parameter. I don't see any
reason why don't use attributes to describe some compiler/RTL behavior? Any
attribute can be easier placed in many language structures without breaking
language syntax. That is much harder with new keywords.

Maybe that is not ideal but works excellent.


Nono.

You deviate from an important design principle: orthogonality.

By linking 2 concepts, any change in 1 concept risks to influence the other.
This is ALWAYS bad. If you implement things orthogonally, a change in 1
concept does not risk influencing the other.

So you will really, really have to provide better arguments than 'but works 
excellent'.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 15:06 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:


Attributes do not need Invoke ?



Of course they need Invoke. When
TRttiContext.GetType(TMyClassWithAttributes) is executed, deep inside
GetType is executed constructor for each attribute by Invoke. IMO mentioned
branch is far far from "ready to merge".


Quite strange, Joost claimed the exact opposite :-)



Maybe you thinking about attributes just as simple flags/marks without
constructors (not parameterized attributes), then you are right.


Yes. AFAIK this is what Joost had in mind. Maybe he used some trick to
parametrize, because AFAIK he needed/used it to implement a ORM
architecture; He used the attributes to specify in which DB field a
particular property needed to be stored.

But better ask Joost directly.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 14:33 GMT+02:00 Sven Barth :


[Note: this is less a "I don't want it", but a "I don't like it"]

phew!



Note: these attributes are on my TODO list.


Please don't do anything attribute related until I've merged Joost's class
attributes branch which lays the foundations for the attributes. I've
planned this for after the reintegration of my dynamic packages branch
which is currently WIP (the merge, not the branch ;) )


IIRC the branch is incomplete (for example RTTI in early stage and for
example TValue need to be improved). Extending these branch is also on my
TODO. :) Maybe the only target of mentioned branch is to allow attributes
of classes (which has no much sense without Invoke method and extended RTTI
- and that is absolutely unimplemented).


Attributes do not need Invoke ?

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Sven Barth wrote:


Am 12.04.2016 12:01 schrieb "Maciej Izak" :


another way is to introduce attributes for selected language elements in

Delphi compatible way. For example in Delphi we have:


  TCustomAttribute = class(TObject)
  end;
  WeakAttribute = class(TCustomAttribute);
  UnsafeAttribute = class(TCustomAttribute);
  RefAttribute = class(TCustomAttribute);
  VolatileAttribute = class(TCustomAttribute);


What I don't like about such a usage of attributes (aside from the syntax,
but that's an orthogonal problem) is that the compiler needs to be made
aware of each and every special attribute... (yes, it also needs to support
each keyword, but in the case of keywords it doesn't have to be somehow
defined in some units as well)
[Note: this is less a "I don't want it", but a "I don't like it"]


I really don't think you should delegate such things to attributes. 
You make 2 completely unrelated language constructs suddenly related. 
A bad design decision.


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

Re: [fpc-devel] Unicode paths

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Marco van de Voort wrote:


In our previous episode, Michael Van Canneyt said:

I guess the only way, as always, is to have two duplicate systems on
windows.  One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).



If argv/argc is known to be UTF8 encoded, then I see no problem with
keeping getopts ?


Getopts is not utf8 but shortstring, so ACS on Windows. Or do you plan to
redo it using utf8string or unicodestring?


I don't necessarily plan to do so, I was proposing it as a way out.

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

Re: [fpc-devel] Unicode paths

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Marco van de Voort wrote:


In our previous episode, Jonas Maebe said:

They are not supported, because we get the original command line data
using the ansi version of the API call (see setup_arguments() in
rtl/win/syswin.inc). If this is "fixed", then we also have to decide
what to do with the argv p(ansi)char (a good place would be to check
what Windows itself returns from the ansi API call when passing command
line arguments that contain characters that cannot be represented in the
ansi code page.


The central place of posix argv/argc in the command processing (including
getopts), also on nonposix systems is indeed a bit of a problem.

I guess the only way, as always, is to have two duplicate systems on
windows.  One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).



If argv/argc is known to be UTF8 encoded, then I see no problem with keeping 
getopts ?


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

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Mon, 11 Apr 2016, Ondrej Pokorny wrote:


What are the plans on releasing 3.0.2?
We'd like to release Lazarus 1.6.2 - it would be good if it was released with 
FPC 3.0.2 because of the Currency bug.


I also think so, we've already been merging the necessary fixes to fixes_3_x

Now we need someone to volunteer to be buildmaster.
I will ask the previous buildmaster if he is game... :-)

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

Re: [fpc-devel] Unicode paths

[Michael Van Canneyt]

On Mon, 11 Apr 2016, Mattias Gaertner wrote:


Hi,

Are there any plans to extend FPC to support Unicode file paths under
Windows?
Of course this also means the other tools, like fpcres, fpmake and
fppkg.
Would this require a new flag?


The rtl already support this. But none of the tools currently use unicode
names.

It would also require examining command-line parameters, I think, because I
am not sure these are currently unicodestring (or UTF8).

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Sat, 26 Mar 2016, C Western wrote:


On 26/03/16 09:19, Michael Van Canneyt wrote:

I have implemented a new property

  TStringsSortStyle = (sslNone,sslUser,sslAuto);

  Property SortStyle : TStringsSortStyle Read FSortStyle Write
SetSortStyle;

I assume the meaning is clear.

- Sorted is true if SortStyle is in [sslUser,sslAuto], so it reflects
actual state.

- Setting sorted to True is equivalent to setting SortStyle = sslAuto

- Setting sorted to false is equivalent to setting SortStyle = sslNone

- Find will work on one of those values, but it will raise an exception
if sortstyle = sslnone

- Add will put a new string on the 'correct' place if SortStyle=sslAuto

- Insert will raise an error (as it was) if SortStyle=sslAuto.

Michael.


I think you might have missed updating a file:

bootstrap/ppcx64 -Ur -gl -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix 
-Fix86_64 -FE. -FU/home/ctcmw/fpc/trunk.w/fpcsrc/rtl/units/x86_64-linux -Cg 
-dx86_64 -dDEBUG -dRELEASE -Fi../objpas/classes ../unix/classes.pp

stringl.inc(1447,29) Error: Identifier not found "SErrFindNeedsSortedList"


Correct. Committed the file.



On a related matter - is this insensitive to changes in the system/rtl sort 
order? I had a difficult to find problem recently where I had some code in an 
initialization section that prepared a sorted string list (or something like 
it). The use of this in the main program then broke when I added another 
package to the program (in fact fpSpreadsheet) that forced inclusion of 
cwstrings to the program, but implicitly after the initialization discussed. 
This was easily fixed by adding cwstrings at the top of the lpr file. I am 
not sure if this is something that can be more generally fixed, but if there 
is anything that can reduce the possibilities for confusion that would be 
good.


This is unrelated, and has to do with the fact that the stringlist by
default is sorted case-insensitively.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, David Jenkins wrote:




On 3/22/16 10:48 AM, Michael Van Canneyt wrote:



On Tue, 22 Mar 2016, David Jenkins wrote:

No one here holds Delphi up on a pedestal - least of all me.  My viewpoint 
is completely practical/funcitonal - I have to make our code base work 
with FPC/LCL and VCL.  Given the way we use find functionality (with a 
mixture of naturally sorted and automatically sorted lists) it has ceased 
to work with both (it did previously). I want to fix that as elegantly and 
as effectively as possible. Making suggestions for FPC improvement is a 
side effect - and as we both agree TStringList.Find can use some 
improvement.




I do not have a preference.


I have implemented a new property

 TStringsSortStyle = (sslNone,sslUser,sslAuto);

 Property SortStyle : TStringsSortStyle Read FSortStyle Write SetSortStyle;

I assume the meaning is clear.

- Sorted is true if SortStyle is in [sslUser,sslAuto], so it reflects actual 
state.

- Setting sorted to True is equivalent to setting SortStyle = sslAuto

- Setting sorted to false is equivalent to setting SortStyle = sslNone

- Find will work on one of those values, but it will raise an exception if 
sortstyle = sslnone

- Add will put a new string on the 'correct' place if SortStyle=sslAuto

- Insert will raise an error (as it was) if SortStyle=sslAuto.

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

Re: [fpc-devel] Bug #29037 StrToCurr raises exception for MinCurrency value on Win64

[Michael Van Canneyt]

On Thu, 24 Mar 2016, LacaK wrote:


Hi *,
can somebody please look at bug report #29037 and attached patch there ?


I am on it.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, Denis Kozlov wrote:


On 22/03/2016 17:56, Michael Van Canneyt wrote:

or better something concise like ltAuto,ltUser,ltNone.


It may make more sense to call it ListSortType (as opposed to ListType):
 TListSortType = (lstNone, lstAuto, lstManual);


I went for TStringsSortStyle



Something like this could work (prototype code):




===
function TStringList.GetSorted: Boolean;
begin
 Result := (FSortType = lstAuto);
end;


This should be
  Result in [lstAuto, lstManual];
I am in agreement with David Jenkins that Sorted should reflect the actual state; 
no matter how this state was reached.



begin
 if FSortType <> lstNonethen
   Result := FindSorted(S, Index);
 else
 begin
   Index := IndexOf(S);


I raise an exception here. Find is for sorted lists.

I have an implementation ready, as soon as all tests are done I will commit it.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, Michael Van Canneyt wrote:




On Tue, 22 Mar 2016, Jonas Maebe wrote:


Michael Van Canneyt wrote:


On Tue, 22 Mar 2016, David Jenkins wrote:


or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone


I think this idea is probably the best alternative.


I don't think "natural sort" is a good name, because it has a specific 
meaning (https://en.wikipedia.org/wiki/Natural_sort_order ). ltAssumeSorted 
or so seems better.


I had the same thought, and was thinking of ltUserSorted.


or better something concise like ltAuto,ltUser,ltNone.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, Jonas Maebe wrote:


Michael Van Canneyt wrote:


On Tue, 22 Mar 2016, David Jenkins wrote:


or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone


I think this idea is probably the best alternative.


I don't think "natural sort" is a good name, because it has a specific 
meaning (https://en.wikipedia.org/wiki/Natural_sort_order ). ltAssumeSorted 
or so seems better.


I had the same thought, and was thinking of ltUserSorted.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, David Jenkins wrote:



or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone


I think this idea is probably the best alternative.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, David Jenkins wrote:

No one here holds Delphi up on a pedestal - least of all me.  My viewpoint is 
completely practical/funcitonal - I have to make our code base work with 
FPC/LCL and VCL.  Given the way we use find functionality (with a mixture of 
naturally sorted and automatically sorted lists) it has ceased to work with 
both (it did previously). I want to fix that as elegantly and as effectively 
as possible. Making suggestions for FPC improvement is a side effect - and as 
we both agree TStringList.Find can use some improvement.


Yes.



And I am fine disagreeing.  My definition of 'bug' is again completely 
functional.  If I knowingly stick in a naturally sorted list into Find(), the 
code operates as expected without error, and I get the desired result.  Both 
user and producer operated as expected - by intention not by accident.  I do 
not see a bug there.


"by intention not by accident." 
Clearly this is not the case, given the warning in Delphi's help.


And as a component developer I have a different point of view.
A component should enforce correct behaviour and conditions.

The other weakness I see in the current traditional implementation (Delphi 
and FPC) is that the 'Sorted' flag is somewhat loosely coupled to the actual 
state of the list i.e. it can be in a sorted state and the flag does not 
reflect that at all.  To me it seems that the flag really means 'auto sort 
this please'.  Once it is enabled the code will sort and maintain sort.   But 
the code is also intended to support naturally sorted lists and not induce 
the overhead of auto sort.  In that situation the sorted property has nothing 
to do with the actual state of the list.  IMO better designed code would 
account for this.


No argument there.

Perhaps it should have been called TStringSortedList and enforced auto sort 
all the way through instead of purposely handling both sorted and unsorted 
lists.


That's not very handy, I switch sort on and off regularly. This approach
would require me to re-create classes and copy data.



As to our decision to use TStringList directly.  Whether we use it directly 
or create our own doesn't fix the code that we all agree is insufficiently 
robust, 'buggy', 'prone to allow bad use', or whatever label you want to use. 
So I find your concern touching but not applicable to the point at hand.


It is not so much concern, but wonder; see below.



Furthermore TStringList has provided exactly what we needed (and we have been 
careful to only pass sorted - natural or automatic - to it).  Why would we 
purposely rebuild the wheel.  Libraries exist for just this.


Yes and no, they are general purpose classes:
In general, I don't believe in the 'one size fits all' approach, and think
an argument can be made for custom classes in case of specialized needs.
(which is not to say that general purpose classes should not strive for the best
possible implementation)

In each case, there is no argument that the code can be improved.

We'll sort something out in the end.

Is your preference for an extra argument to Find() or an additional property ?

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Tue, 22 Mar 2016, David Jenkins wrote:




On 3/22/16 2:01 AM, Michael Van Canneyt wrote:

But you agree that if Find is called on an unsorted list, bogus data will
be returned ? Or, worse, an never-ending loop may occur ?
In short, as you say, an "error condition" can ensue without you knowing 
it.


That is a bug. So, in my opinion (and of some others), Find is implemented 
buggy in Delphi.


Consider the buggyness a given in what follows.

If we consider something a bug in Delphi, we do not copy the bug.

You happen to rely on this buggy behaviour. This is of course unfortunate.

I attempted to fix this bug using a not too invasive method.
Originally I simply wanted to raise an exception, but that was deemed too
invasive.

There are now several options:
1. I change the code to raise an exception instead (as was my original 
plan)

2. I change the code to resort to a linear search if sorted is false.
3. I introduce a boolean property that determines whether Find does any 
check.

   By default the check will be done, to warn people they're doing
   something stupid. If they override the check, we can assume they know 
what

   they are doing.
4. Combine 1 and 3.

Or,

5. You override sort so it does nothing. It is virtual.
   You can then set sorted to True, no sort will occur, and find will do 
it's job.


6. You use another TStringList where you change find to suit your needs.
   All it takes for you is to copy the implementation, you can keep the 
same
   name, and insert the unit after the classes unit in places where you 
need it.


It's your call which of the 5 methods is used.

But one thing is sure: we're not reverting the behaviour back to the buggy 
behaviour.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
#1 is what Zoe Peterson (my coworker) has suggested as well. Without that 
exception (as the code now is) there is no warning issued just an ambiguous 
return of False.  Which means that the code is still buggy as the user could 
assume that the Index value points to next insert spot and instead it is out 
of range and causes a crash.   Setting Index value to -1 would be a better 
indicator of bad usage than just returning False (with raising an exception 
still being the best warning).


Keep in mind though that being able to call find on a manually sorted list 
(Sorted <> true) is not buggy behavior (this is the Delphi compatibility that 
we are interested in maintaining).


Here we disagree.
It IS buggy behavior. Delphi is not sacrosanct, it does contain bugs like
any software. This is one of them.

(*
  This is not idle talk:
  I'm trying to report 2 serious bugs in Delphi Seattle, only to find that the
  bugtracker (ironically called quality :) ) is not working :/

  Well, it can happen to anyone, I guess.
*)

That aside: I will probably go for 1 or 4.

Michael.

PS. And if you allow me to express wonder:
Given that you are apparently the maker of beyond compare, 
I'm doubly surprised to see you use an all-purpose container class

as TStringlist, instead of writing your own...

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Mon, 21 Mar 2016, David Jenkins wrote:

I understand the need for the list to be sorted and agree that calling find 
on an unsorted list is an error condition.


I am not convinced that current change deals with that well.

For one, the Sorted flag and actual state of the list are not directly 
linked.  I can manually sort the list so that Find binary search will work 
just fine.  But Find will exit before the binary search can occur - without 
any indication why.


But you agree that if Find is called on an unsorted list, bogus data will
be returned ? Or, worse, an never-ending loop may occur ?
In short, as you say, an "error condition" can ensue without you knowing it.

That is a bug. 
So, in my opinion (and of some others), Find is implemented buggy in Delphi.


Consider the buggyness a given in what follows.

If we consider something a bug in Delphi, we do not copy the bug.

You happen to rely on this buggy behaviour. This is of course unfortunate.

I attempted to fix this bug using a not too invasive method.
Originally I simply wanted to raise an exception, but that was deemed too
invasive.

There are now several options:
1. I change the code to raise an exception instead (as was my original plan)
2. I change the code to resort to a linear search if sorted is false.
3. I introduce a boolean property that determines whether Find does any check.
   By default the check will be done, to warn people they're doing
   something stupid. If they override the check, we can assume they know what
   they are doing.
4. Combine 1 and 3.

Or,

5. You override sort so it does nothing. It is virtual.
   You can then set sorted to True, no sort will occur, and find will do it's 
job.

6. You use another TStringList where you change find to suit your needs.
   All it takes for you is to copy the implementation, you can keep the same
   name, and insert the unit after the classes unit in places where you need it.

It's your call which of the 5 methods is used.

But one thing is sure: we're not reverting the behaviour back to the buggy 
behaviour.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Mon, 21 Mar 2016, David Jenkins wrote:




On 3/21/16 2:55 PM, Michael Van Canneyt wrote:

We can introduce a property which disables the check, if you want.

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


However..  now that I've thought about it some more.  That change 
would be nice and all for us but doesn't it just muddle the picture even more 
for anyone else using the code?


I'm feeling tempted to argue against my side a little.  If the change is 
correct i.e. makes for better code or behavior then it should stay and we'll 
go ahead and take it out in our local files if we don't like it (we'll 
grumble at having to maintain a local patch be we already have a few of 
those).


My thought is that it doesn't make for better code or behavior while at the 
same time breaking Delphi compatibility.  Delphi compatibility isn't the 
golden standard but it seems any breakage should be for a good reason.


The reason for this behaviour is that find needs to be sure that the list is 
sorted.
If it thinks the list is not sorted, the result cannot be guaranteed to be
correct, and this is an error condition.

What I don't understand about these discussions is:

TStringList is just one possible implementation of TStrings. 
It is only there for your ease of use.


If you don't like it, you can use another one. You can find several. 
There is one in inifiles, the LCL probably also contains a couple.


If all APIs work with TStrings, then they don't care what TStrings
descendent you use. So you are free to use one that does whatever you want.

Anyone declaring an API that explicitly expects TStringList, is simply 
doing something wrong, in my view.


This is Object Pascal for a reason, after all.

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

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[Michael Van Canneyt]

On Mon, 21 Mar 2016, David Jenkins wrote:

I just ran across the change that checks Sorted at beginning of find and 
exits if Sorted = False.  This has caused some problems for us


a)  We have lists that are sorted manually and we'd like to continue keeping 
them sorted manually (and be able to call .insert()).  This means not setting 
the sorted flag.  But without setting 'sorted' we can no longer use find.  We 
are sharing code between VCL and FPC - delphi compatibility has been broken.


b) The change, in my opinion, hasn't solved the unpredictable response 
problem.  There is still nothing to indicate to a caller that they have 
called the function inappropriately i.e. they do not know why find has 
returned false.


Furthermore the documentation also indicates that if false is returned then 
'Index' will contain the position where the string should be inserted.  Index 
used to at least be within the range of FCount or 0.  Now the value 'Index' 
is even more indeterminte as the code exits before Index has been set to 
anything.  It has gone from possibly placing a string at a wrong location to 
possibly causing a crash with index out of range.


It could be argued whether this is worse but it certainly doesn't seem to 
have made the situation any better for people blindly misusing Find an 
unsorted list - while at the same time breaking Delphi compatibility and the 
option to manually keep lists sorted.


Thoughts?


We can introduce a property which disables the check, if you want.

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

Re: [fpc-devel] Feature announcement: Record management operators

[Michael Van Canneyt]

On Mon, 21 Mar 2016, Maciej Izak wrote:


2016-03-21 14:28 GMT+01:00 Sven Barth :


The RTL *must* be compileable with the latest release. You need to use
ifdefs to ensure that.

If a "make all" at the top level with a FPC 3.0.0 does not work then your
branch won't be merged. Simple as that...



So what should I do? Additional compiler $DEFINE RECORD_OPERATORS?
FPC_FULLVERSION seems not sufficient. The change for records RTTI is
required to adopt record operators, seems like I am locked. Or maybe should
I just continue my work in branch don't looking at trunk (just for fun).


No need for that.

You just need to {$IFNDEF VER3_0} all record operators code.

A make cycle compiles 3 times.

During a make cycle you must start with 3.0.0, this will compile the RTL
with 3.0.0 and this excludes record operators.

During the second compile, it will be with the latest compiler, so VER3_1_1,
which will include the record operators code, and all will be well.

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

Re: [fpc-devel] Implementing SHA256 Unit.

[Michael Van Canneyt]

On Sun, 20 Mar 2016, Jy V wrote:


On Sun, Mar 20, 2016 at 1:10 PM, Garry Wood  wrote:


Yes, the intent is to support https with TLS 1.0/1.1/1.2 so
AES_128_GCM_SHA256 will be included in the cipher suite.



Pure FreePascal code only ? no dependency with OpenSSL (or third party
libraries) ?
-> this would be absolute great news !


Work is in progress to get the ciphers in the FPC SVN.

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

Re: [fpc-devel] Implementing SHA256 Unit.

[Michael Van Canneyt]

On Sun, 20 Mar 2016, Garry Wood wrote:


I'm trying to write a sha256 implementation in pure pascal like sha1 and md5 
units.
With negative results.
Someone can helpme with this?


I recently ported the implementation from LibTimCrypt / wpa_supplicant (which 
are both from public domain implementations), you can find the unit here:

https://github.com/ultibohub/Core/blob/master/source/rtl/ultibo/core/crypto.pas

This is for our Ultibo embedded project but the code is pure pascal and should 
compile for any platform if you adjust the uses clause.

This has been validated against a number of test vectors available from 
different sources and seems correct although I can’t test on big endian CPU at 
present. The unit also includes ports of AES, DES, DES3 and RC4 ciphers as well 
as MD5 and SHA1.


Would it be OK to extract some of the routines and include them in Free Pascal
using the usual license ? We have several of these routines, but not all, it
would be nice to have a more complete set available by default.

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

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

[Michael Van Canneyt]

On Thu, 10 Mar 2016, Sven Barth wrote:


Am 10.03.2016 18:02 schrieb "Yury Sidorov" :


On 3/10/2016 1:06 PM, Jy V wrote:



This happens only on Win64 with FPC 3.0
Can somebody please check and confirm ?


compiled with official Lazarus 1.6 (SVN revision as displayed in the
about box: 51630)
console output of your program is:

  1.234500E+02* 1.E+002=
1.234500E+08



I've tested FPC trunk on win64 and it works correctly.

 1.234500E+02* 1.E+002=

1.234500E+04


Looks like my fix in r32054 also applies for this case. The bug affected

all targets where currency is 64-bit integer.

Then that indeed applies for Win64 as well.


Maybe time to start thinking about 3.0.2, then.
This is not a minor bug.

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

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

[Michael Van Canneyt]

On Thu, 10 Mar 2016, LacaK wrote:





This happens only on Win64 with FPC 3.0
Can somebody please check and confirm ?


compiled with official Lazarus 1.6 (SVN revision as displayed in the about 
box: 51630)

console output of your program is:

 1.234500E+02* 1.E+002= 
1.234500E+08


Are there tests for compiler ?


Yes, several thousands: a quick count says 5392.
you can find them in the tests directory of the fpc SVN repository.


Is it possible, that such bug is not noticed during preparation of release ?
(or is it such special case, that this was not covered by existing test?)


Presumably the implementation of the currency type predates the testsuite.

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

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

[Michael Van Canneyt]

On Thu, 10 Mar 2016, LacaK wrote:


Hi,
investigating bug #29760 I reduced bug to:

var
 c: currency;
 d: double;

begin
 c := 123.45;
 d := 100;
 writeln(c, '*', d, '=', c*d); // result of multiply is wrong = 12345
end.

This happens only on Win64 with FPC 3.0

Can somebody please check and confirm ?


If confirmed, then I think this is enough reason to start a 3.0.2 release :/

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

Re: [fpc-devel] Are LazUtils - XML units still necessary ?

[Michael Van Canneyt]

On Thu, 10 Mar 2016, Mattias Gaertner wrote:


On Wed, 9 Mar 2016 20:35:52 -0300
Daniel Gaspary  wrote:


Since FPC 3.00 has a new Unicode support I was wondering about that.

AFAIK, support to Unicode(Or only UTF8?) was the main reason to the
existence of the units Laz2_Dom, Laz2_XmlRead/Write, etc.


Both supports Unicode.
The main difference is they use UTF-8 strings instead of UTF-16
strings. This saves memory and avoid conversions when using UTF-8
strings in your application.
They also have some flags like xrfPreserveWhiteSpace, which preserves
indentation.


Meanwhile this is also possible in fcl-xml AFAIK.

I think the main difference is the use of UTF8 versus UTF16.

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

Re: [fpc-devel] The (near) future of strings

[Michael Van Canneyt]

On Mon, 7 Mar 2016, Marco van de Voort wrote:


In our previous episode, Michael Van Canneyt said:

/usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ

But only one is referenced in fpc.cfg :

#IFDEF NAMESPACED
/usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ
#ELSE
/usr/local/lib/fpc/4.0.0/x86_64-linux/XYZ
#ENDIF

where the -NS switch defines NAMESPACED


That is correct if the namespace switches was introduced with XE2. It would
fail for sources that used dotted notation and namespace, but don't assume
it for the RTL, iow pre XE2.


This is a non-argument, since that wouldn't work today either.
We need to draw a line somewhere, no need to be holier than the pope.

Lets try to target e.g. D7 and XE2+





Dotted, unicode
not dotted, unicode.

which is clear nonsense.


No, two rtls, both dotted, with namespace if needed. Which is the same as
what you propose, just kept physically apart.


If the above fails to satisfy you, no problem, all for it.
But I don't see the use of the dotted for old code.


That was just for simplicity's case.


Lets not forget that Delphi tries to hide a lot of the complexity by
always writing a complete config file and using that file when compiling.


I think a good first step would be building without storing the generated
files in the same dir as the source.


A matter of configuration, I would think.

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