Re: [fpc-pascal] Partial text search in a dictionary

[Jürgen Hestermann]

Am 2017-05-15 um 13:14 schrieb Torsten Bonde Christiansen:
> however I was hoping someone might know of an implementation that 
works more or less out of the box.


To me it was very seldom that an existing solution
severed all my needs. Either not all requirements were
complied from the beginning or, even worse, I invested time
using an existing "solution" only to find out much later
that some detail does not work so I had to write my own solution anyway.
I wasted time in understanding an (often poorly
documented) existing routine, fighting with bugs in it
and then had to write it more or less from cratch anyway.

If I understand your requirements correctly it should not be
too much work to write your own solution.
You would also have the freedom to exactly adapt it to your needs
without fiddling with parameters and adjustments of an existing
library which are superfluous for your purpose.

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

Re: [fpc-pascal] machine readable grammar of object pascal?

[Jürgen Hestermann]

Am 2017-05-08 um 12:31 schrieb Marco van de Voort:

In our previous episode, Michael Van Canneyt said:

This is not something invented by FPC.
It is something inherited from Turbo Pascal.

And Delphi up to D4 iirc.

Delphi inherited it from Turbo Pascal.
Actually, it was a hack.
Const defines end up in the global data segment
so writable local constants work like global variables
but are only accessable from the declaring function.

There should have been a different syntax for this
but Borland did not add one.
Now we have this syntax anomaly 'till the end of time...

This shows that before adding new "features" one should
think twice (or three times).

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

Re: [fpc-pascal] Record operator for assignment

[Jürgen Hestermann]

Am 2017-05-08 um 05:47 schrieb nore...@z505.com:
> It's similar to this feature:
> x,y,z := 1, 12, 7
> It's neat to be able to assign multiple variables on a single line. But 
necessary? mandatory?

It's not even neat.
It would bloat the Pascal language unneccesarily (as many other additions have 
done in the past).

I definitely prefer

x :=  1;
y := 12;
z :=  7;

where I see much better which value is assigned to which variable.
Look at this:

a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u := 
3,5,1,7,33,82,7,14,9,0,-1,1,13,14,17,8,2,9,15,88,62;

would that be readable code?

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

Re: [fpc-pascal] WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-20 um 10:25 schrieb Graeme Geldenhuys:
> On 2017-04-14 09:41, Jürgen Hestermann wrote:
>> I hate Java Script and use NoScript to block it.
> You don't need a browser add-on for that. Simply go to (Firefox)
> about:config and search for JavaScript. Double click the
> "javascript.enabled" preference and it will toggle between enabled
> true/false.

But NoScript has comfortable functions do allow scripting
for certain web pages or even only parts of them
in case I am forced to use scripting on "special" cases.
I can do a white-listing this way.
It seems that about:config cannot distinguish between
special web pages.



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

Re: [fpc-pascal] Get value of PPChar ?

[Jürgen Hestermann]

Am 2017-04-16 um 19:45 schrieb fredvs:
>> And how you'll need to use it will depend upon the function's documentation
> With audio libraries there is a law: NO doc (other that the C header) and NO
> demos.
> So you must guess and explore all by your self.

Now that's a useful working mode!
No bugs will ever exist because no code
behaviour can violate the documentation!

How programming has degraded...

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-15 um 03:54 schrieb Ryan Joseph:
> I think you’re confusing Java for JavaScript. JavaScript doesn’t allow 
execution of arbitrary code and as far as I know it’s still the only language that 
can manipulate the DOM on the browser to perform actions on the client side like 
changing the properties of HTML elements.

Well, it's not exactly the same as running native programs but nearby.
For example, see https://www.veracode.com/security/javascript-security .

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-14 um 15:12 schrieb Michael Van Canneyt:
>> I want to keep control about what is executed on my computer.
> So you are running an open source OS ?

Unfortunately not (yet).
I am working on getting rid of windows
but some programs not available on Linux
prevented me from doing this step for now.

Nevertheless, the point is not to just run
open source programs (and OS's).
I install a new OS very seldom
and these OS's are under public observation.
We know quite a lot about Windows and what it is doing
in the background so I am no so much concerned about it (yet).
I disabled updates so I don't get unexpected changes in the background.
And I use Win 7 and 8.1 but not 10.

Same applies to programs.
I cannot wade through all the code even if it's open source.
I have to rely on the fact that popular programs are under
public ovservation and that unexpected behaviour will be known soon.

For web pages this is totally different.
With scripting you install and run completely unknown code
hundreds of times a day. An infected or otherwise malicious
web page will not become visible at once because they can
change very often and there are many of them.
Therefor I use NoScript to prevent me from such code.
90% of these web pages using scripting are crap anyway.
Scripting is mainly used to annoy the user with add popups etc.

Serious web pages don't need scripting IMO.
They should provide information and that is possible without it.

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-14 um 13:53 schrieb Michael Van Canneyt:
>> Why is it scripting needed to display a calendar?
> To display a popup menu, for example.
> Or completion when typing in an edit: when you invite someone, it's handy
> when calendar suggests the contact name.

I doubt that you can do this only when allowing the execution of
arbitrary code (although I don't know very much about current HTML standards).

In the end Scripting is like downloading executable files
with each and every click on a web page.
I do not want this.
I want to keep control about what is executed on my computer.

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-14 um 11:03 schrieb Michael Van Canneyt:
> On Fri, 14 Apr 2017, Jürgen Hestermann wrote:
>> Am 2017-04-13 um 10:20 schrieb Michael Schnell:
>> > So at the moment HTML5 and Java script is the way to go, but WebAssembly should 
recreate Action Script versatility performance in a more "Standard" way.
>> I hate Java Script and use NoScript to block it.
>> I can't understand why scripting is needed for a web page.
>
> Simple: to improve the user experience. Things like google calendar would be 
impossible without it.

Why is it scripting needed to display a calendar?

I am not against improving HTML but allowing arbitrary code
on a web site is of no use (for the user) IMO.
It's just a security hole.

Code can be executed on the server if needed.
On the clients only what the HTML-language provides shoud be allowed.
And executing arbitrary code should not be part of this language.

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

Re: [fpc-pascal] WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-13 um 10:20 schrieb Michael Schnell:
> So at the moment HTML5 and Java script is the way to go, but WebAssembly should 
recreate Action Script versatility performance in a more "Standard" way.

I hate Java Script and use NoScript to block it.
I can't understand why scripting is needed for a web page.

Once I could do even my home banking without scripting
but meanwhile scripting spreads over all the internet.
For security reasons this is a desaster and
I never found anything useful with scripting.

The most annoying thing with scripting is, that you potentially
download arbitrary code with every click.
A browser should only display information but never execute
arbitrary code from a web site.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-13 um 13:17 schrieb MARCOU Gilles:
> Regarding this code:
>> SetLength(Array,Length(Array)+1);
>> Array[High(Array)] := …
> as I understood from (http://wiki.freepascal.org/Dynamic_array),
> SetLength will create a copy of the array and free the memory of the shorter 
array.
> In this case, a lot of memory operations and copy operations are performed 
thus
> degrading the performances of the code. Then it would be unwise to use such 
strategy:
> better allocate the size of the array correctly at the beginning of the run,
> or resize the array by block, to decrease the frequency of such operation:

Yes, that's my knowledge about dynamic arrays too.
Although it *can* happen that the array is not copied
(see answer mail from Sven) in general it will (is forced to)
allocate a new (larger) memory chunk and copy the data over to it.
This is IMO unavoidable if the existing memory area cannot be extended.

There are 2 strategies against it:

1.) If you already know the correct size at the end of an operation you can 
simply create the array with the final size in the first place.

2.) If you know that the array will be extended many times but you do not know 
in prior what the final size is,
then you can extend the array in larger slices (16, 32 or whatever).
Then, if the final size is reached, you can remove empty elements with
SetLength(Array,FinalSize);

But very often the performance degrade of Setlength is overvalued.
If the Length variation is done only seldom (compared to other code)
then it's not worth thinking about such optimizations.

Also, I often have dynamic arrays of pointers (strings or other managed types).
In this case the array elements consists of pointers and only the pointers will 
be copied
but not the data they point to.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 16:30 schrieb Ryan Joseph:
>> Array[High(Array)] := whateveryouwant;

> SetLength(Array,Length(Array)+1);
> Array[High(Array)] := …
> In the real world is anyone actually going to type that out every time?

Yes, I do this. Typing is not much work for me.
My main focus is on *readable* code (effort for writing is of low priority).
And the 2 lines show very clear what realy happens.

I can also omit the second line and set a value later
while with an Add-function I have to specify a value
for the new array element even if I just want to extend the array only.
I have finer control about what happens.

> I’d bet most of us have an array class we use and ignore dynamic arrays all 
together because we all need basic operations like “add” and “remove”.

I never use classes.
I like dynamic arrays very much.


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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 16:36 schrieb Ryan Joseph:
> Why magic? It seems silly the operator += doesn’t exist

Well, are we using Pascal or C? ;-)


> or even a basic operation set like “add”, “remove”, “insert” that every array 
implementation in every language has.
> Aren’t those just function around the existing dynamic array implementation 
in the compiler?

I aggree that these functions could be added.
I always create such functions myself but I need to
respect the type of my arrays and rewrite these functions
for each new type.
If they were available as standard routines it would avoid these rewrites.

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 16:47 schrieb Michael Van Canneyt:
>> Type MyType = record
>>   A : Integer;
>>   B : array of char;
>>   C : array of Float;
>>   end; // of record
>>  ArrayA = array of MyType;
>>  ArrayB = array of ArrayA.
>>
>> What would be the DefaultValue for
>> ArrayB.Fill(DefaultValue);
>> ?

> I would think Nil is the only option here,  ArrayB is an array of arrays

Yes, but that's not what Ryan and others want to achieve.
As far as I understand, ArrayB.Fill should fill all the
lowest (non-managed) types like Integer, Char and Float.
Otherwise it would not be "filling" but "clearing" because
some memory allocation is lost.

So you would need multiple DefaultValues but I don't see how this can be done.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 16:17 schrieb Ryan Joseph:
> SetLength resizes the array in memory and “clear” means setting all values to 
default() for that type.

"clear" is not very clear to me ;-)
IMO SetLength(array,0) is clearing too.

The function you want should be called "Fill".
For example a function

Array.Fill(DefaultValue);

But what happens to a multi-dimensional (dynamic) array?
For example, how to handle this case:

Type MyType = record
  A : Integer;
  B : array of char;
  C : array of Float;
  end; // of record
 ArrayA = array of MyType;
 ArrayB = array of ArrayA.

What would be the DefaultValue for

ArrayB.Fill(DefaultValue);

?
I don't see how this can be achieved in a solid and easy to unterstand 
Array.Fill routine
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 15:46 schrieb Ryan Joseph:
> I agree. Dynamic arrays only advantage is they are managed by the compiler 
but they’re missing obvious functionality like adding/removing elements so they’re 
usually pretty useless.
> Why was the functionality of appending an element to the end never added? 
That’s one the most basic operations for arrays.

It exists:

SetLength(Array,Length(Array)+1);

You will get an additional element (filled with zeros).
Then you can set

Array[High(Array)] := whateveryouwant;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-12 um 15:05 schrieb nore...@z505.com:
> Since fillchar is not a general way to clear an item

Define "clear". There are many things that can be named "clearing" (see below).


> I've never been a fan of things like fillchar as it seems like a reinvention 
of something more like Clear() and mistakes can easily be made when you use 
complex function like this:
> fillchar(something, something * something, 0)
> instead of a more simpler:
> Array.Clear
> or
> Clear(array)

It's true that the wording "char" is not ideal.
Instead you can use FillByte ( 
http://www.freepascal.org/docs-html/rtl/system/fillbyte.html )
which does the same (it has just another name).

FillByte does what it says: It fills a given memory area with bytes (which you 
can define).
Because of the nature of certain types it can damage i.e. managed types
so you have to know what you do (you have to know about the memory usage of the 
used type).

If you have a static array things are completely different as for dynamic 
arrays.
If you have a static array the memory it occupies is static (never changes) and
in one continuous block.
Dynamic arrays are completely different although their syntax is (nearly) the 
same.
So what should Array.Clear do in case of a static and in case of a dynamic 
array?

Clearing a static array can only mean filling it with bytes.
But do they have to be zero in all cases?
Array of integer may require different bytes than array of char.
In the end you as the programmer have to decide what is appropiate.
Array.Clear would not be able to guess what you intend.

Clearing a dynamic array can mean to free all memory it occupies
or fill its used memory with bytes.
Again you have to decide what to do
and which bytes should be used (if you fill everything).


> To me, fillchar doesn't actually say anything sensible about what the code is 
doing...

Well, if you use FillByte (instead of FillChar) then nothing can be clearer. It 
just fills memory with a chosen byte.


> "Clear" or "Default" (I think delphi is implementing something like this in 
later versions) says exactly what the code is doing.

What exactly does it do when "clearing" a dynamic array?
There are multiple ways to "clear" it.


> FillChar is some obscure old 1970's/80's pascal function that really doesn't 
tell what you are doing, unless you are an old pascal programmer who knows it from 
long ago.

It's true that those who grow up with it know that FillChar is actually a 
Fillbyte.
The first versions of FillChar just excepted the char type as the fill byte.


> I'm skeptical of these old ways of doing things.. Imagine a newcomer to pascal who did 
not program in the 1980's... He sees "fillchar" in the program...
> Does that code even tell this learner of pascal what is happening? What's a 
"char" have to do with an array that may not have anything to do with chars?

That applies to all Pascal functions.
You need to lookup what they actually do.
In case of FillChar/FillByte it is quite easy to unterstand.

Much more problematic are things that the compiler does
"under the hood" which is often not well documented.
If you don't know how the compiler handles dynamic arrays
you have a real problem as you cannot predict performance
nor do you know exactly how to handle them.
But that has nothing to do with FillChar...

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-04 um 16:54 schrieb Ryan Joseph:
>> var arr : array of array of Integer;
>> begin
>> SetLength(arr, 10, 10);
> “then the first array stores a pointer to each sub array.”
> Could you illustrate this is code?
> I don’t think I’m understanding this exactly like it’s represented in memory.
> There’s only one “sub array” in this 2x2 array so how does that look in 
memory?

Why 2x2?
SetLength(arr,10,10) creates a 10x10 array.

I am trying to show the memory allocation for the 10x10 array as a "graphic":

arr --> arr[0],arr[1],arr[2],arr[3],arr[4],arr[5],arr[6],arr[7],arr[8],arr[9]
  |  |  |  |  |  |  |  | |  |
  V  V  V  V  V  V  V  V V  V
arr[0,0],   .  .  .  .  .  . .arr[9,0],
arr[0,1],   .  .  .  .  .  . .arr[9,1],
arr[0,2],   .  .  .  .  .  . .arr[9,2],
arr[0,3], arr[9,3],
arr[0,4], arr[9,4],
arr[0,5], arr[9,5],
......

arr is a single pointer (that points to arr[0]).
arr[0] to arr[9] are (10) pointers located in a continuous memory block each 
pointing to
arr[0,0],
arr[1,0],
arr[3,0], and so on...
arr[0,0] is a single integer.
arr[0,0] to arr[0,9] are (10) integers located in a continuous memory block.
The same applies for
arr[1,0] to arr[1,9],
arr[2,0] to arr[2,9],
arr[3,0] to arr[3,9], and so on.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-04 um 15:40 schrieb Ryan Joseph:
> I’m glad I asked because of arrays of pointers is bad news for performance.

I don't think that you will notice a performance issue with dynamic arrays 
(though it highly depends on the sizes and levels you use...)

> Does SetLength on a single level dynamic array not even allocate a continuous 
block of memory?

Yes, it does (as explained in all the other mails).
A (dynamic) array of integer will be allocated as a single block by SetLength.
So if you only have one level of a dynamic array as in

var MyArray : array of integer;

then SetLength(MyArray,1000) will allocate a single block of 1000 integers.
But with

var MyArray : array of array of integer;

SetLength(MyArray,1000);

will allocate a single block of 1000 pointers (to an array of integer each).
Then, SetLength(MyArray[0],1000) will allocate one (!) block of 1000 integers.
SetLength(MyArray[1],1000) will allocate another block of 1000 integers and so 
on

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-04 um 15:18 schrieb Jürgen Hestermann:
> var MyArray : array of array of integer;
>
> you can do:
>
> SetLength(MyArray,3);
> SetLength(MyArray[0],2);
> SetLength(MyArray[1],3);
> SetLength(MyArray[2],4);
>
> So MyArray[0] points to an array of 2 integers,
> MyArray[1] points to an array of 3 integers and
> MyArray[2] points to an array of 4 integers.

The syntax of dynamic and static arrays are the same
although they should differ (because the involved pointers).
Therefore it is confusing and misleading.

For dynamic arrays
MyArray[0] should be MyArray^[0] and
MyArray[0,1] should be MyArray^[0]^[1]
and so on...

This would make it possible to distinguish between the pointer
(MyArray) and the data it points to (MyArray^).
Also MyArray^[0]^[1] would be a pointer while
MyArray^[0]^[1]^ would be the (static) array of integers.

But as you seldom access the pointers themself (they
are managed by the compiler) and because this automatic
derefencing of pointers for managed types has been defined
decades ago we have to live with this now...

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-04 um 13:55 schrieb Ryan Joseph:
> Doesn’t iterating the array default the purpose of FillChar?
> The goal was the most efficient way clear the array with zero’s.
> Even if the array if nested 3 levels deep (anArray[x][y][z])
> it should (I hope) be a contiguous block of memory that was allocated 
(correct me if I wrong please).

No. If you have a dynamic array of multiple levels it
does not generate a continuous block for all levels.
Only the last level (if it is an array of integer or other non-managed type) is 
just that.
A (dynamic) array of array if an array of pointers.
Only for static arrays all levels are a continuous block.

The first level of a multiple level (dynamic) array is an array of pointers 
(array of array).
So you have a continuous block of pointers on the first level.

Each (!) second level array also is an array of pointers (array of array).

Only the last level is an array of integer (or whatever).

Therefore, for a 3x3x3 array you have 3 pointers on the first level.
Each of these pointers (MyArray[x]) again points to an array of 3 pointers.
And on the last level (MyArray[x,y]) each pointer points to an array of integer.
So you have 3x3=9 continuous blocks of 3 integers which can be located anywhere 
in memory.

BTW:
Each level of nested dynamic arrays can have individuell size.
On a 2-dimensional array

var MyArray : array of array of integer;

you can do:

SetLength(MyArray,3);
SetLength(MyArray[0],2);
SetLength(MyArray[1],3);
SetLength(MyArray[2],4);

So MyArray[0] points to an array of 2 integers,
MyArray[1] points to an array of 3 integers and
MyArray[2] points to an array of 4 integers.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-04 um 12:51 schrieb Mark Morgan Lloyd:
> On 02/04/17 10:00, Jonas Maebe wrote:
>> Allocating new memory via setlength also clears the memory (+ the
>> overhead of allocating the memory).
> Jonas, is it still the case that if SetLength() results in existing data 
being moved that the original- which might be e.g. an unencrypted password- isn't 
cleared?

Only formerly not existing elements are overwritten via fillchar.
Already existing data is not changed of course (otherwise you would
loose them).
If you have a (dynamic) array of 5 elements and you extend it
to 7 elements via Setlength(MyArray,7) then only the last 2 (new) elements
are cleared (because otherwise they would contain garbage).

This is (and must be) independend from moving data or just extending the 
existing array.
If the existing elements are moved (because the allocated memory cannot be 
extended)
then they are not cleared (but moved).
Only formerly not existing elements are filled with zeros and
they are never moved because they did not exist before the SetLength command.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-01 um 19:42 schrieb wkitt...@windstream.net:
> consider this: when using a string var and writing to a binary file...
> you reuse the string var for each value written...
> if you don't clear the string var between fills then the binary will
> contain "garbage" in the unused positions of the string var...
> you can see this "garbage" when you view the binary file in hex mode...
> the "garbage" being older longer string data than the current string 
data in the var...

> this var may be a global throwaway string var...

This can only happen for older string types where the actual length
can differ from the reserved memory (maximum string length).
With managed strings, this should never be possible as it would write
only the bytes of the current length.

I also don't see how this applies to an array of integers.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-01 um 15:09 schrieb Ryan Joseph:
> Because the array is being iterated and I need to know which values 
are set.
> Basically I have a dynamic array I grow to a certain size and this 
process happens in a loop.
> The options are to allocate/free the array every cycle or clear 
memory and allocate the array once.


If you just need to reuse the same array and only need to zero its elements
then of course fillchar would be the fastest approach (it saves the memory
reallocation step).

But this works only for standard array element types (like integer etc.).
Managed types have to be reset element by element.

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

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

I am wondering what the purpose of filling all
array elements with zero's could be.
If I want to discard all elements I would simply delete
the whole array (setlength(MyArray,0) ).

But when should it be useful to keep all elements and
just overwrite them all with zero's (which is also very time consuming)?
If the exisiting values are no longer valid then why not
simply delete these elements?
It's the fastest way to get rid of them.
If elements were zero before overwriting them with zero's
I cannot even distinguish between original and overwritten elements.

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Jürgen Hestermann]

Am 2017-02-21 um 22:12 schrieb James Richters:
> I have a freepascal Windows console application that I recently ported over 
from DOS Turbo Pascal.   I am have a small settings file that I write to disk that 
keeps getting corrupted.  It happens only occasionally, but it’s always this one 
file, no others.Do I need to do something specific to force windows to write 
the file to disk and not have it in some kind of cache or buffer?   I am using the 
following code to write the file:
>Assign(BitFile,'BitSave.pax');
>ReWrite(BitFile);
>WriteLn(BitFile,XADJ:1:8);
>WriteLn(BitFile,YADJ:1:8);
>WriteLn(BitFile,ZADJ:1:8);
>WriteLn(BitFile,WADJ:1:8);
>WriteLn(BitFile,AADJ:1:8);
>WriteLn(BitFile,TADJ:1:8);
>WriteLn(BitFile,VADJ:1:8);
>WriteLn(BitFile,UADJ:1:8);
>WriteLn(BitFile,CurrentTool);
>WriteLn(Bitfile,P_Value[4]);
>Close(BitFile);
> The above only happens when I make a change to one of the settings, and the 
system is never having any issue at that time, yet upon occasion I will have an 
error opening the file and when I inspect it, it’s just a long string of [nul].   
I am not leaving the file open, I’m assigning it, writing to it, then closing it, 
so there should be no opportunity for data to be lost.  I am having the same issue 
on about 8 different computers, most of which are running solid state hard drives. 
It’s always just this one file that is affected, nothing else.  No other process 
ever uses this file, so it must be my freepascal program that is leaving the file 
in a vulnerable state.
> My understanding was the Close(file); would save the file all the way to disk 
and flush any buffers that were holding it, but I’m wondering if that was only 
true for DOS and there is some other windows cache or buffer that also needs to be 
instructed to flush to truly save the file all the way to disk and close it.

How is "Bitfile" declared?
According to http://wiki.freepascal.org/Text
it should be either

var BitFile : TextFile;

or

var BitFile : Text;

Also, I am not sure whether "Close" is equivalent to "CloseFile" and  "Assign" is 
equivalent to "AssignFile".
I remenber that I had some issues using the old (TP7) notations but I am don't 
remember the details.

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

Re: [fpc-pascal] uses myunit in '../src/myunit.pas' ?

[Jürgen Hestermann]

Am 2017-02-14 um 16:02 schrieb Tim Veldhuizen:

On 14/02/17 20:00, fredvs wrote:

It is a difficult task to speak with gurus.

Nah, it's not. They are also people... I think.. Actually, I've never seen 
proof that they all are, so some may actually be chimps. :)
Anyway, some are standing on such a high pedestal that they feel everyone is 
beneath them. I speak from personal experience (yes, I've been egocentric and 
ignorant before and yes, I met someone who was worse.. much worse). But then I 
guess true wisdom is to know the extent of one's own ignorance. :)
So just ask. Yeah sometimes you may get a rude response. I've had a few. So 
what. Their attitude is their problem, getting your question answered is yours. 
They help you with your answer, you help them with their attitude. You learn 
through the experience, they don't.

That makes me always nervous.

Don't be. Who are they to judge you? You think they never took the easy way out 
and ask a mailing list or forum instead of using google? At least I will admit 
I have once or twice. (Oh sorry guys, no I don't claim to be a guru, sorry 
sorry, yes yes, you are the masters. Bow, bow, kneel, kneel ;) )

Sadly, sometimes when I do not find a solution, I ask it here.

Perhaps the reason why you're not finding a solution, is because it seems to me 
you have a preference for a non-standard solution (at least in this 
occurrence). As a result, you may be searching in the wrong direction and 
hence, you're not finding any clear answers. (Unless I misunderstood 
something). But I don't fully understand your situation. I don't know what 
you've learned so far and what knowledge and experience you have. So I won't 
judge.

But, trust me, it is always scared.
I hope that I will not annoy you anymore (but where to ask then).

On the contrary; I found it quite amusing. ;)


Very well and eloquently written and exactly my opinion too! ;-)

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

Re: [fpc-pascal] KeyDown routine and Ctrl+Q

[Jürgen Hestermann]

Am 2017-02-09 um 14:42 schrieb Vojtěch Čihák:


Strange. I tested in Linux+Qt and in Delphi7 (under Wine) and both have ssCtrl 
in Shift when I press Ctrl (i.e. Key=17).



Well, I looked at Shift in the debugger and I could swear that
it showed me an empty set [].
But now I can't reproduce it anymore and I always get [ssCtrl] too.
So you seem to be right that in both cases Shift=[ssCtrl].


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

Re: [fpc-pascal] KeyDown routine and Ctrl+Q

[Jürgen Hestermann]

Am 2017-02-08 um 23:26 schrieb Vojtěch Čihák:
> when you press CTRL+Q you will obtain two OnKeyDown events. The first with 
Key=17 (it is CTRL) and the second with Key=81 (Q). Both events will have ssCtrl 
in Shift.

Yep, it makes sense for OnKeyDown.
Thanks for the explanation.

I don't know why I was under the impression that it
did not work. It works now just the way I coded
it from start. I may have got bewildered by some other
problem I got with my code...

BTW:
When Ctrl is pressed, then Shift is empty (which is expected).
Only on the second key Q Shift contains ssCtrl.

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

[fpc-pascal] KeyDown routine and Ctrl+Q

[Jürgen Hestermann]

I use a KEYDOWN routine in my main TFORM to check for the key Ctrl+Q:

-
procedure TForm1.FormKeyDown(Sender : TObject;
 var Key: Word;
 Shift  : TShiftState);
begin // TForm1.FormKeyDown
case key of
   VK_Q :
  begin
  if Shift=[ssCtrl] then
 begin
 
-

But when I type "Ctrl+Q" then "Key" is 17 instead of VK_Q (81).

If I now use 17 to trigger the "Q" key, then it is also triggered
when I just type the Ctrl-key (without any other key)!

This is all a bit weird.
How can I detect that "Ctrl+Q" is pressed without
getting fooled by any other key?

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

fpc-pascal@lists.freepascal.org

[Jürgen Hestermann]

Am 2017-02-05 um 20:26 schrieb Sven Barth:


> Is that a valid identifier?
> Here
> http://wiki.lazarus.freepascal.org/Identifiers
> it says:
> Rules for identifiers:
> Must begin with a letter from the English alphabet or an underscore (_).
> Can be followed by alphanumeric characters (alphabetic characters and 
numerals), or the underscore (_).
> May not contain special characters, such as:
>
>  ~ ! @ # $ % ^ & * ( ) + ` - = { } [ ] : " ; ' < > ? , . / | \

http://freepascal.org/docs-html/current/ref/refse4.html#x16-150001.4



Strange!
Why was it added to use reserved words as an identifier?
What is the use of that?
It seems http://wiki.lazarus.freepascal.org/Identifiers needs an update too.

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

fpc-pascal@lists.freepascal.org

[Jürgen Hestermann]

Am 2017-02-05 um 15:24 schrieb Howard Page-Clark:

var
  &begin: boolean;


Is that a valid identifier?
Here
http://wiki.lazarus.freepascal.org/Identifiers
it says:

Rules for identifiers:

 * Must begin with a letter from the English alphabet or an underscore (_).
 * Can be followed by alphanumeric characters (alphabetic characters and 
numerals), or the underscore (_).
 * May not contain special characters, such as:

 ~ ! @ # $ % ^ & * ( ) + ` - = { } [ ] : " ; ' < > ? , . / | \


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

Re: [fpc-pascal] for loop vs while loop

[Jürgen Hestermann]

Am 2017-02-01 um 12:49 schrieb Graeme Geldenhuys:
> Just curious (been in a discussion with somebody else). Is there a
> performance difference between a FOR loop and a WHILE loop?
> Not sure if it will make a difference, but the usage is with three
> nested loops, iterating over some 300,000 plus data points in total.

I think that in general a FOR loop *can* be faster than a WHILE loop
because the iterator variable will be held in a register (if possible)
and its start and end values will be calculated only once.

Also, because the iterator variable will be incremented (or decremented)
by a constant value it helps the compiler to speed it up further.

If the major time of the loop is needed for the loop body it will not make much 
difference of course.

Still it makes sense to always use a FOR loop if possible.

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

Re: [fpc-pascal] Deleting 'Nonexistent' files under windows

[Jürgen Hestermann]

Am 2017-01-25 um 11:08 schrieb Jürgen Hestermann:

I have written a file manager which uses the (Unicode) Windows API with \?\\ 
syntax
and I never had any problems deleting long paths (testet up to 35,000 
characters)


Sorry, the number of tested characters wasn't 35,000 but about 25,000.
Still enough to make sure it works in general.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Deleting 'Nonexistent' files under windows

[Jürgen Hestermann]

Am 2017-01-24 um 18:44 schrieb Bart:

I once created a folder and file using W API and \?\\ syntax for testing 
purposes.
This all went well, but Windows did not like it and would not let me
remove the file and folder.
I rewote my test program to remove them, but still Windows refused.
(The folder name ended in a space, you could not even browse to the
folder in Windows Explorer)


I have written a file manager which uses the (Unicode) Windows API with \?\\ 
syntax
and I never had any problems deleting long paths (testet up to 35,000 
characters)
or such which have whitespace somewhere.

Of course, you have to make sure, that whitespace is not removed by some
other functions before you use the name and you also need to make sure that
UTF-16 is used for the API function.

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

Re: [fpc-pascal] Array as result in function.

[Jürgen Hestermann]

Am 2017-01-20 um 07:52 schrieb Martin Schreiber:
> On Thursday 19 January 2017 22:50:36 fredvs wrote:
>> function array_in_out(arrayin: TArFloat): TArFloat;
>> begin
>> result := arrayin;
>> end;
> Do you change items of "arrayin" later? If so the items of the result array
> will be changed too, dynamic array assignment copies the data pointer only.
> http://www.freepascal.org/docs-html/current/ref/refsu15.html#x39-520003.3.1
> Use
> "
> function array_in_out(arrayin: TArFloat): TArFloat;
> begin
>  result:= copy(arrayin);
> end;
> "
> if the result array must be independent.

While the original Pascal language was clear and logical,
it has become ambiguous with managed types.

In this declaration

var X : int64;

"X" always means the 8 bytes that hold the integer.
"@X" always means the 4 bytes of the *address* where the 8 bytes start.
Here you are always aware what is meant:
Either the data or the address of the data (pointer).

In this declaration:

var A : array of int64;

"A" means the (elements of the) array if you index it as in "A[7]"
but it means the (4 byte) pointer to the first element if you use it
as function parameter or in assignments.

And even worse, *some* managed types (like strings) have "copy-on-write".

IMO this is all very confusing and leads to a lot of hard to spot bugs
but it cannot be changed anymore.

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

Re: [fpc-pascal] FPC clean room project

[Jürgen Hestermann]

Am 2017-01-02 um 06:23 schrieb Mr Bee:
> There's someone accusing that Free Pascal (and some parts of Lazarus) is just 
a reverse engineering of Delphi. Even he said some codes of FPC/Laz are taken from 
Delphi (and Kylix). This is a serious allegation.
> I know that isn't true. Or is it? ;)
> Can anybody elaborate on this? I'd like to debunk the allegation but I don't 
know where to start and the evidence for it.

I think the first "evidence" would be that Borland/Embarcadero did not initate 
any legal proceedings against FPC.
They would surely have done this in case it is true.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] performance when resizing a dynamic array

[Jürgen Hestermann]

Am 2016-12-04 um 14:09 schrieb Graeme Geldenhuys:
> On 2016-12-04 11:30, Martin Schreiber wrote:
>> That happens with every reallocmem() with FPC memory manager so using a
>> getmem() block instead of a dynamic array has no advantage in this
> Maybe a good old linked list implementation is the best performer then.
> Back to the Pascal of the 80's and 90's. :)

I think that it's not worth the hassle to use linked lists.
Whenever I thought that it would speed up things (i.e. inserting)
I always went back to dynamic arrays because of the following:

1.) Linked lists need a lot more memory (depending on how it is linked).

2.) You cannot see the number of elements directly in linked lists
(or you need to keep track of this which can be an annoying and error prone 
task).

3.) With dynamic arrays you can easily pick the n-th element without having
to run through the whole list from the beginning (or end).
Sorting is much easier with an array.
It keeps code simpler in any respect.

4.) When performance is an issue (when you have *very* many elements
(millions) *and* the size of each element is much larger than the
size of a pointer) then I always use an array of pointers (to data).
Moving around elements (i.e. when sorting) then only involves moving pointers.
Of course, you need to new() each element but then the allocated data is fixed
and only the pointer needs to be moved in case of changes.
Deleting (or inserting) can be done with move:

---
procedure DeleteIndexInFArray(const index  : SizeInt;
var FArray : FileArrayTyp);

begin // DeleteIndexInFArray
if indexhttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Underscores in numerical literals - grouping

[Jürgen Hestermann]

I am still not sure how exactly elastic tab stops work.
I put standard tabs (#9) in each line and the editor
aligns these tabs for adjacent lines?
What if an empty line is between such lines?
What if I want to start a new 'table' which is not
related to preceeding or following lines?

In this example (where 'Param1' should align with 'Param2')
-
if ProcedureA(FunctionA(Param1,
Param2),
  true,
  false,
  false,
  Shift=[ssAlt],
  ErrorCode) then
   ShowMessage('ERROR')
-
I would put tabs before 'ProcedureA', 'FunctionA', 'Param1', 'Param2', 'true', 
'false', etc. and 'ShowMessage'
and 2 extra tabs on the start of the second line (with 'Param2'), 1 extra tab 
for the following lines?

I found an interesting discussion discussion about elastic tabstops with some 
cons here:
http://softwareengineering.stackexchange.com/questions/137290/what-are-the-drawbacks-of-elastic-tabstops

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

Re: [fpc-pascal] Underscores in numerical literals - grouping

[Jürgen Hestermann]

Am 2016-11-21 um 15:46 schrieb Graeme Geldenhuys:

The age old rule
of programmer source code always being in a mono-spaced font is
ridiculous for this day and age.


Why?
I like monospaced fonts for code very much.

Code is not a novel or a newspaper where you read
a lot of text from top down to the end in a linear manner.
Instead, alignment is very important to make code more readable.
Monospaced fonts make it much easier to align code and
make a lot of things align 'automatically'.

I even align procedure headers like the following where all variables and
all types start at the same column
(which may not be visible in this email if you use proportional fonts ;-).
Please copy it to notepad or into Lazarus Editor in this case):

-
procedure TForm1.FunctionListGetHintSize(Sender : TBaseVirtualTree;
 Node   : PVirtualNode;
 Column : TColumnIndex;
 var R  : TRect);
-

and I align the 'MaskFilter' variable in such a for loop:

-
for i := Low (MaskFilter) to
 High(MaskFilter) do
-

and I like such an aligned declaration

-
function  FileCompareName (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareDate (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareSize (Datei1,Datei2 : PFileTyp) : SizeInt;
function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInBranch  (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirName   (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareFilesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareBytesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInDir(Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirName  (Dir1,Dir2 : PTreeTyp) : SizeInt;
-

much more than a non-aligned:

-
function  FileCompareName (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareDate (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareSize (Datei1,Datei2 : PFileTyp) : SizeInt;
function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
-

You can see imeditately that many functions have the same parameters and all 
result in a SizeInt.
In the non-aligned version this is harder to spot.

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

[fpc-pascal] FindFirstFileNameW missing from Windows unit

[Jürgen Hestermann]

The subject says it allready:

Is there a reason that the Windows API function FindFirstFileNameW
is not defined in the Windows unit?
I had to define it myself to use it but I think it should be available directly.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A serious Memleak using delegates/implements

[Jürgen Hestermann]

Am 2016-10-07 um 13:29 schrieb stdreamer:
> Erm knifes are easy to use as well but cutting your self with one is your 
problem to solve.

Today many industrial (and household) machines are a lot safer than decades ago.
This has changed because so many people got (heavily) injured.
Therefore these machine were made safer.
Why not do the same in the programming world?

In the past Pascal was created with the spirit:
Make it clear, logical and consistent,
avoid traps.
It seems this spirit is gone today.

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

Re: [fpc-pascal] String concatenation failure (again)

[Jürgen Hestermann]

Am 2016-08-02 um 20:12 schrieb José Mejuto:
> Check the length of the string I think you have a NULL char at the end of 
every string, so only the first one (up to #00 char) is displayed.

Yes, you are right.
When I change the code


for i := Low(Liste) to High(Liste) do
   S := S+Liste[i]+LineEnding;


to


for i := Low(Liste) to High(Liste) do
   S := S+pchar(Liste[i])+LineEnding;


then it works okay.
The Win-API call retrieves the ending null byte too
so it ends up in my array of strings.

Strange is that it already worked with FPC 2.x.
Of course I had to convert UTF16 to UTF8 manually
but I don't have the old code anymore.
It could be that I had to use pchar in that case too which
would explain why it worked before (I then removed
"unneccessary" convertion routines and it seems
I removed the pchar calls too).

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

Re: [fpc-pascal] String concatenation failure (again)

[Jürgen Hestermann]

Am 2016-08-02 um 12:25 schrieb Jürgen Hestermann:
> --
> type MyStringType = string;
> var S : MyStringType;
> Liste : array of MyStringType;
> i : SizeInt;
>
> begin
> [..] // "Liste" is setup with many string entries (which are also shown 
correctly with Ctrl+F7 (evaluate/modify)
> S := '';
> for i := Low(Liste) to High(Liste) do
>S := S+Liste[i]+LineEnding;
> SetLength(Liste,0);
> ShowMessage(S);
> end;
> --

I just tested a bit more and it seems that the problem
is located in the way the strings are fed into "Liste"
which is done like this from a Windows API function:

--
if FindNextFileNameW(H,Laenge,@Pfad[1]) then
   begin
   SetLength(Liste,Length(Liste)+1);
   Liste[High(Liste)] := copy(Pfad,1,Laenge);
   end;
--

where "Pfad" is a "widestring" (because of the Windows W-function),
"H" is of type "hwnd" and "Laenge" is "SizeInt".

I would expect that with the new string encoding handling
widestring will be converted automatically to "MyStringType"
(which is string in my case). This assumption is  encouraged
by the fact that "Liste" is shown with the correct list of all strings
in the evaluate window when debugging.

The interesting thing is, that *one* (the first) string
from "Liste" is added to "S" (but all others are missing).

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

[fpc-pascal] String concatenation failure (again)

[Jürgen Hestermann]

I just came accross another issue of string concatenation within my program
that worked okay before FPC 3 but fails after updating to FPC 3.
I had not used this function since the update so I found the problem
only now (by accident):

--
type MyStringType = string;
var S : MyStringType;
Liste : array of MyStringType;
i : SizeInt;

begin
[..] // "Liste" is setup with many string entries (which are also shown 
correctly with Ctrl+F7 (evaluate/modify)
S := '';
for i := Low(Liste) to High(Liste) do
   S := S+Liste[i]+LineEnding;
SetLength(Liste,0);
ShowMessage(S);
end;
--

"S" now always consists of only one line
even when "Liste" has many more.
The for-loop is passed multiple times
as expected but only the first pass adds
a line to "S".

Any idea why this code no longer works?


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

Re: [fpc-pascal] which "managed" result types require extra work?

[Jürgen Hestermann]

Am 2016-06-28 um 01:13 schrieb David Emerson:
> The source of my confusion -- and I suspect that of many others -- is that I 
always assumed a function result was treated like a local variable within the 
function, rather than a parameter to the function.
> Since managed types are automatically initialized when they are local 
variables, I assumed a function result was the same.
> Unfortunately, the documentation does not make this sufficiently clear in 
describing managed types. I guess I should file a documentation bug.

Exactly my opinion too.
Especially, because it behaved differently with Free Pascal versions prior to 3!

And it does not behave like a function parameter, it behaves like a *var* 
parameter.
All other types of parameters behave differently!
And while a var parameter can *only* be assigned to a variable (so that it is 
clear
that an existing variable is used) a function result can also be used in an
expression which makes it silently mutate into a global variable! What a mess!

And for local variables I can easily set a default value in the declaration but 
not for the function result.
I have to remind me not to forget this in the code.

It is so logical that managed types are managed (therefore the wording!).
That a function result can inherit old values from prior calls is just the same 
as for
local constants of TP.  But in TP it was at least documented and it was 
predictable.
Now everybody ostracizes such behaviour but instead intruduces the same
for function results.

I used this behaviour of managed types over many years.
Now we all (most of us) had to find out the change the hard way (by debugging).
Many may not even have found this yet because their functions with managed type 
results are used seldomly.
That's quite ignorant C style (where you also have nothing to rely on but need 
to check every compiler (version)).
So yes, "modern" Pascal is no longer the "old" Pascal, but has it become 
better? Meanwhile I doubt this.

And what about perfomance? In most of the cases I am now initializing
what is already initialized. Very strange.


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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Jürgen Hestermann]

Am 2016-06-26 um 14:27 schrieb Karoly Balogh (Charlie/SGR):
> There's no exception. At least not specifically for Result. It is simply
> variable passed by reference from the caller side, therefore it's not
> initialized inside the function.

You mean when I have the following:

--
function X : ansistring;
begin
end;

var S : ansistring;

S := X;
--

Then S is a dangling pointer to nowhere?


> And this is A., consistent with other var
> parameters B., apparently also how Delphi does it. Actually, since managed
> types are always passed by reference, this is not really a surprise, nor
> an exception.

Of course it is a surprise because the documenation says that managed types are 
always initialized.
If I use a var parameter I am forced to use a variable (declared somewhere 
else) but
the function result can also be used in expressions without any (direct) 
assignment to a variable.
So it must behave like a locally declared variable IMO.

If I use an intermediate variable like:

--
function X : ansistring;
var X1 : ansistring;
begin
Result := X1+'A';
end;
--

then it is initialized while here

--
function X : ansistring;
begin
Result := Result+'A';
end;
--

I get garbage?
That's a very strange behaviour and no longer Pascal, it's C with all its funny 
side effects.

> var
>   a: ansistring;
> a:=some_function(a);

When you have a parameter then of course it depends
on how the parameter is declared.

The Result variable within a function is different
and not a parameter. You cannot feed in any data here.
I would consider this more like an out parameter
but in case of managed types an initialization
must take place somewhere (IMO in the function like
for all other local variables too, where else?).

And it is definitly a change with FPC 3 because all my programs relied
on that managed types are initialized and suddenly they are not anymore.
I am wondering what other surprises lurk here and there which I have just not 
found out.

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Jürgen Hestermann]

Am 2016-06-26 um 14:13 schrieb Sven Barth:
> But also no word that it is true either, cause you're not declaring a 
variable for the Result.

Of course I am declaring a variable:

function X : String;

Now the (local) variable "Result" is of type "String".
I use it in the same way as any other local variable.
And because it is a manged type I could rely on the documentation
which says that managed types are initialized (with zero length/nil).
"Result" is used in the same way as a (local) variable.
What should make me think that it is different?

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Jürgen Hestermann]

Am 2016-06-26 um 01:19 schrieb Karoly Balogh (Charlie/SGR):
> No. Local variables are not initialized by default. Managed type or not,
> doesn't make a difference.

This is not true.
Local variables of managed types are of course initialized!
If you declare

var S : String;

then it is of course initialized to nil.
Otherwise the (random) pointer stored in S would be used
to change the reference counter when you assign:

S := '';

The only exception (at least since FPC 3) is the function result
which is totally unexpected.
Why such an exception?

And it is not even documented (at least not within FPC)!
Which I find a bit strange because it is very important to know.
Omitting such information in the documentation is not good.
Here
http://www.freepascal.org/docs-html/ref/refsu15.html
it says:

"When declaring a variable of a dynamic array type, the initial length of the array 
is zero."

but no word about that this is not true when this array is a the result of a 
function.

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Jürgen Hestermann]

Am 2016-06-25 um 09:23 schrieb Maciej Izak:
> 2016-06-25 5:19 GMT+02:00 Michalis Kamburelis :
> They were never guaranteed to be initialized to nil.
> Result has special logic for string, dynamic array, method pointer and 
variant (well documented ;) ):
> "For a string, dynamic array, method pointer, or variant result, the effects are 
the same as if the function result were declared as an additional var parameter following 
the declared parameters. In other words, the caller passes an additional 32-bit pointer that 
points to a variable in which to return the function result."
> 
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Program_Control#Handling_Function_Results

Does that mean that we now need to read the whole documenation of Free Pascal 
*and* also the whole documentation of Delphi?
And what version of Delphi?
Where is this documented within Free Pascal?

This has definitely changed with Free Pascal 3 as my programs suddenly did not 
work anymore and I had to add Setlength() all over my code.
Before we could rely on that managed types where always initialized (well, 
that's the purpose of managed types, no?).
It took me quite a while to find out why my programs failed as I did not expect 
such a (hidden) change.

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

Re: [fpc-pascal] Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

[Jürgen Hestermann]

Am 2016-06-21 um 17:16 schrieb Sven Barth:
> It was decided some time ago when mode Delphi was switched to H+ (due to 
Delphi compatibility) that mode ObjFPC won't be switched, cause for that mode we 
value backwards compatibility higher than the user not having to write a switch.

This is quite short-sighted:

It's not only the work of writing a compiler switch.
You also have to *know* (think) about it.
There are so many compiler switches and if we end up
with the situation that all new users have to spend a
day to make their program work as the grandious feature
list of some FPC page told them then something is wrong.

Those who are already familiar with all the details have
much less work to just add a compiler switch to their
existing projects (if needed) and it would be necessary
only once on a certain FPC version when this default
changes.

Now we need to tell each new user that he has to change
the (default) settings to get a "modern" Pascal compiler
because "out of the box" it is a very old one.

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

Re: [fpc-pascal] Type helper for array

[Jürgen Hestermann]

Am 2016-06-09 um 20:18 schrieb Sven Barth:
> Am 09.06.2016 17:57 schrieb "Vojtech Cihák" :
> > aBuffer.Clear;
> > Is it possible to do this without helper?
>
> You can always set the array to Nil

IMO SetLength(aBuffer,0) would the most natural way to clear the array.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String theory

[Jürgen Hestermann]

Am 2016-05-10 um 17:48 schrieb Tony Whyman:

I don't think this is what I meant as StringCodePage is a unicode string 
function. I am looking at the single byte string types.

On 10/05/16 14:15, Bart wrote:

It already is [part of the string type.
See the StringCodePage function.




Codepages are not restricted to Unicode.
They can be others too (although it should only be used if unicode is no option 
for some reason).
Ansistring is single byte and can contain non-unicode codepages.
From
http://wiki.freepascal.org/FPC_Unicode_support
:


 
---
 Shortstring

The code page of a shortstring is implicitly CP_ACP and hence will always be 
equal to the current value of DefaultSystemCodePage.


 PAnsiChar/AnsiChar

These types are the same as the old PChar/Char types. In all compiler modes 
except for /{$mode delphiunicode}/, PChar/Char are also still aliases for 
PAnsiChar/AnsiChar. Their code page is implicitly CP_ACP and hence will always 
be equal to the current value of DefaultSystemCodePage.


 PWideChar/PUnicodeChar and WideChar/UnicodeChar

These types remain unchanged. WideChar/UnicodeChar can contain a single UTF-16 
code unit, while PWideChar/PUnicodeChar point to a single or an array of UTF-16 
code units.

In /{$mode delphiunicode}/, PChar becomes an alias for PWideChar/PUnicodeChar 
and Char becomes an alias for WideChar/UnicodeChar.


 UnicodeString/WideString

These types behave the same as in previous versions:

 * /Widestring/ is the same as a "COM BSTR" on Windows, and an alias for 
UnicodeString on all other platforms. Its string data is encoded using UTF-16.
 * /UnicodeString/ is a reference-counted string with a maximum length of 
high(SizeInt) UTF-16 code units.


 Ansistring

AnsiStrings are reference-counted types with a maximum length of high(SizeInt) 
bytes. Additionally, they now also have code page information associated with 
them.

The most important thing to understand about the new AnsiString type is that it both 
has a declared/static/preferred/default code page (called /declared code page/ from 
now on), and a dynamic code page. The declared code page tells the compiler that when 
assigning something to that AnsiString, it should first convert the data to that 
declared code page (except if it is CP_NONE, see RawByteString 
 below). The 
dynamic code page is a property of the AnsiString which, similar to the length and 
the reference count, defines the actual code page of the data currently held by that 
AnsiString.
---

with

CP_ACP: this value represents the currently set "default system code page". See #Code 
page settings  for 
more information.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-18 um 11:33 schrieb Sven Barth:


Am 18.04.2016 07:58 schrieb "Jürgen Hestermann" mailto:juergen.hesterm...@gmx.de>>:
> And why was a directive implemented to use 0-based indices
> even for strings but none for 1-based indices in dynamic arrays?
> IMO the latter would be much more desired.

The usual reason: Delphi compatibility. If Delphi wouldn't have that directive, 
we wouldn't have that either, because most others are content with the indices 
as they are.



Seems that whenever something goes into the wrong
direction then always Delphi is the culprit. ;-(

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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-18 um 09:53 schrieb Marco van de Voort:

Limits like in

for i:=0 to someexpression.count-1

are evaluated as expression before using the result to for. If count=0 this
would become for i:=0 to $, so you need to guard this with a if
count>0 then.



Well, for 1-based arrays it would be

for i := 1 to someexpression.count

(without the annyoing -1).
In general I can make sure that somexpression.count is zero or larger
when I use it to determine an index for my array.
The same would be

for i := low(array) to high(array)

which is very common and where I would not need to use an unsigned integer.




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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-16 um 19:39 schrieb Dmitry Boyarintsev:
> The problem is with using "unsigned" as an index (rather than zero- vs one- 
based arrays)
> Take a while loop as an example, where index can change multiple times.
> Current solution:
> while i>=0 do
>   if cond then dec(i);
>   dec(i);
> end;
> Unsigned index solution
> while i>=0 do
>   if cond then if i>0 then dec(i);
>   if i>0 then dec(i);
> end;
> Without these checks, unsigned integer would loop over to $ and will 
continue.

That looks to my like an very artifical example.
I never came over a loop where I (conditionally)
decremented the index twice.
But of course, if you have such a case, then you
can only use signed intergers.

But in all the following cases I could used an unsigned
integer (when having 1-based arrays):

1.) for i := low(array) to high(array)

2.) repeat or while loops where the index is in- or
decremented by a maximum of 1 (which IMO is the case
in 99,9% of all such loops).

3.) When storing an array index into a variable for later use.

Nevertheless, using unsigned integers was only one aspect
of 1-based arrays. The main one for me was, that it is
much more intuitive and therefore less error prone.
I already often had errors when calculating indices for 0-based arrays.

And why was a directive implemented to use 0-based indices
even for strings but none for 1-based indices in dynamic arrays?
IMO the latter would be much more desired.

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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-16 um 18:36 schrieb Marco van de Voort:
>> Yes, but I could store indices in DWORD if they would be 1-based
>> and would not risk an exception if the index is "not valid" (which
>> would be 0 in this case while it's -1 for 0-based indices).
> You would have to check everywhere before decrementing. This can be annoying
> in loops. (it is that way in M2 btw, where the basetype is unsigned. Not
> happy with that)

I don't know what you mean.
A For-loop has it's limits anyway.
And when decrementing 'manually' I would stop if INDEX=0.
For 0-based arrays I would stop if INDEX=-1?
What would be different?
For 1-based arrays I would never get an index<0
because it stops at zero.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-15 um 20:35 schrieb Sven Barth:


Am 15.04.2016 18:37 schrieb "Jürgen Hestermann" mailto:juergen.hesterm...@gmx.de>>:
>
> Another advantage of having 1-based indeces in dyn. arrays
> would be that you could store indeces in unsigned integers
> while with 0-based indices high() may give -1.

Indices in Pascal are always signed.



Yes, but I could store indices in DWORD if they would be 1-based
and would not risk an exception if the index is "not valid" (which
would be 0 in this case while it's -1 for 0-based indices).
I would not be forced to make sure it is an signed integer where I store it.

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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Another advantage of having 1-based indeces in dyn. arrays
would be that you could store indeces in unsigned integers
while with 0-based indices high() may give -1.

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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-15 um 10:26 schrieb Graeme Geldenhuys:
>> Is there also a switch
>> {$OneBasedDynArrays On}  ?
>> No more confusion about first and last element index.
> You really should be using low() and high() instead. ;-)

So why do we need {$ZeroBasedStrings On} at all? ;-)

Of course, when you simply want to traverse all elements
from the first to the last you can use low() and high().
But I would not use this for strings as

for i := 1 to Length(S)

is IMO more readable than

for i := low(s) to high(S)

(where it's unclear, whether high() means the highest
*possible* or the highest *current* index).

And I often need to calculate or store indices.
Then I have to take into account where counting starts and ends
which is unintuitive in dynamic arrays (not Pascal like).
When I set

INDEX := 2;

then I always have to remind me that this means that it's the
3rd index in dynamic arrays while it's the 2nd one in strings.

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

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-14 um 23:22 schrieb Graeme Geldenhuys:
> On 2016-04-14 19:27, Sven Barth wrote:
>> We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is
>> used (it's a local switch).
> Wow, learnt something new again. Never new that existed.

Me too.
Though I will not use it.

Is there also a switch
{$OneBasedDynArrays On}  ?
I would love it.
No more confusion about first and last element index.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Bls: Bug in FPC 3.0.0

[Jürgen Hestermann]

Am 2016-03-06 um 17:00 schrieb Serguei TARASSOV:
> You're right there are many language specific forums but English 
became these
> standard "in fact". I see the trend of last 10 years when Russian 
developers

> who lived in Russia write yours blogs in English only.
> Sad but c'est la vie...

Why is this sad?

I like it that there is meanwhile a common sense
about which language to use as an international language
and that more and more people all over the planet
know at least a little bit English so that I can
communicate with them.

I would even vote for dropping other foreign languages at school
and invest the saved time to improve English.
This way a global communication will become much easier.
Those who like other languages can learn them in their spare time
if they want and have talent but it should not be forced on everybody.

If the audience is restricted to one country only then of course the
native language of these people can/should be used.
But with globalisation this becomes more and more unlikely.

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

Re: [fpc-pascal] Please someone explain this to me

[Jürgen Hestermann]

Am 2016-02-15 um 18:21 schrieb Andreas Schneider:
> Am 2016-02-14 12:42, schrieb Jürgen Hestermann:
>> Here we differ:
>> I expect that a documentation *fully* explains
>> a behaviour of a certain function (or something else),
>> not just some part of it.
> IMHO that would be insane. To a programmer (like you and me) the RTL and the 
Compiler are just interfaces. Therefore the documentation describes the contract. 
I need not and should not need to know the inner workings. All I need to know is 
the required inputs to get a specific output.
> The more of the internals you guarantee, the less you can change later on 
which might even make platform portability impossible.

Fully agree, exactly what I was trying to say.


> So again - in my opinion - internals are best left out of documentation. 
Therefore *fully* explaining the behavior would be wrong.

I would differentiate between "details" and "internals". Of course, the exact coding 
("internals") should not be part of the documentation.
But the "details" - which I would name the behaviour under all (even rare) 
circumstances - should be fully documented.
There should be no doubt what I can expect and what not.

But in this forum very often when someone complains about missing or incomplete 
documentation he gets the advice to look into the code which IMO is insane 
because

1.) the code may change over time
2.) it can have bugs (which I would rely on)
3.) it is often hard to understand if I don't know about the surrounding 
concepts and other things.

Also, the documentation is very important for the programmer as it lets him 
think about what he is coding (and only the programmer knows what he had in 
mind when he coded something). I often found that my code was imcomplete or 
otherwise misconcepted as I tried to explain it to someone else.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Jürgen Hestermann]

Am 14.02.2016 um 12:56 schrieb Florian Klaempfl:
> No really. It is not a matter of +1 vs. inc but how it is compiled: as
> add or lea. And the decision add vs. lea is not straight forward. It
> depends on the surrounding code and the exact core.

After reading this (especially the comments)
http://stackoverflow.com/questions/1658294/whats-the-purpose-of-the-lea-instruction
the speed also seems to be dependend on the specific processor used 
(even whithin the same family)
which makes such benchmarks somewhat arbitrary (if the compiler does not 
take it into account).


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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Please someone explain this to me

[Jürgen Hestermann]

Am 2016-02-14 um 12:28 schrieb Michael Van Canneyt:
> There is a difference between learning the language, which implies knowing
> what routines are available to you, and understanding how a particular 
routine works in detail. The latter requires you to study the source code.
> For the former, you don't need the details: the documentation is the better
> alternative.

Here we differ:
I expect that a documentation *fully* explains
a behaviour of a certain function (or something else),
not just some part of it.

It's not neccessary to know *how* things are coded but
the underlying idea and what the programmer can rely on.
The code can even differ from the documenation in case of bugs!
So what does it help to look into the code?

If a documenation satisfies the above requirement then
there is no need to look into the code *in any case*.

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

Re: [fpc-pascal] Please someone explain this to me

[Jürgen Hestermann]

Am 2016-02-11 um 14:21 schrieb Sven Barth:
> If they are just learning the language then they shouldn't poke around in the 
core units anyway. That's what the documentation and help is for.
> Back when I started learning TP I didn't have the internet and I didn't have 
the sources of the units. I only had the help and it was definitely enough, so no 
I'm not even remotely convinced by your argument.

Strange that suddenly the documentation should be used
while in the past everybody else is telling me (and others)
to look into the code to understand it.

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

Re: [fpc-pascal] Happy tickets benchmark

[Jürgen Hestermann]

Am 2016-02-13 um 21:59 schrieb Paulo Costa:
> On my PC with Windows 8.1, fpc 2.6.4 32bits, when I changed the line:
> inc(TicketsCount);
> to:
> TicketsCount := TicketsCount + 1;
> the results improved from:
> C:\tmp\tests>HappyTickets.exe
> Found 4816030 tickets. Elapsed time, msec: 323
> to
> C:\tmp\tests>HappyTickets.exe
> Found 4816030 tickets. Elapsed time, msec: 262

How can this happen?
As far as I remember, INC was introduced
to speed up this kind of calculation,
not to slow it down.
The compiler should be able to optimize
INC much easier than +1 within a (potentially)
complicated expression.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Jürgen Hestermann]

Am 2016-02-02 um 18:39 schrieb Maciej Izak:

Is possible to close thread on mailing list?

-,-


Simply do not open (and delete) mails with "IfThen" in subject.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Jürgen Hestermann]

Am 2016-02-02 um 11:41 schrieb Mark Morgan Lloyd:
> Michael Van Canneyt wrote:
> Yes, and that's why to get the desired semantics it's more appropriate to use 
 if then else  rather than  iif()  etc.
> Please correct me if I'm wrong, but my understanding is that in all cases 
where parameters are passed to a procedure or function
> they are evaluated and placed on the stack before the code is called. However 
the  if then else  statement never, under any circumstances,
> executes code in the untaken statement/block, and it is that which is the required 
behaviour for an "inline if" expression.

Yes, I fully agree.
If the behaviour is/will be exactly the same as "if .. then ... else" then it 
should
also get a name that shows this clearly.
Therefore, I would still vote for "IfThenElse(.. , .. , ..)".
"InlineIf(.. , .. , ..)" would be ok too but not as clear as "IfThenElse".

If "IIF" in other languages is more of a function in these languages (so both 
branches are evaluated in all cases)
then I would not use the same name in Pascal but implement a different 
behaviour.
Would this be possible in other languages:

var c : char;
s : string;

c := IfThenElse(Length(s)=0,' ',S[1]);

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Jürgen Hestermann]

Am 2016-02-01 um 19:45 schrieb Dmitry Boyarintsev:

No matter what the language is, developers still want to write C... for the 
shortness of script


Such people should simply use C.
Pascal <> C
and I am glad that this is true.


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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Jürgen Hestermann]

Am 2016-02-01 um 16:27 schrieb Michael Van Canneyt:
> Never, and if Delphi didn't have it, I would oppose its introduction as well. 
It is a result of a 'whatever goes' attitude.
> Why not introduce C syntax, while we're at it ? Or Perl, or Javascript or 
whatever just happens to be the fashion of the day ? The compiler can probably 
handle it, I'm sure we'll find someone crazy enough to take the task on.
> This 'whatever goes' attitude is really a disease that should be weeded out.
> So you trying to introduce it in a system identifier/intrinsic is IMHO a 
double
> insult to plain common sense.

I fully agree!
Every *addition* to the language should be thought over carefully
with respect to the spirit of the Pascal language.
In case of doubt just don't implement it (yet).
Such things are cast in stone forever and one wrong
quick shot can bite many people over many years.


If it cannot be avoided to add yet another (superfluous) function to the Pascal 
language
(and in case someone cares) my thoughts about System."IfThen" are:

1.) It should not have the same name as IfThen from other (Pascal) units. At 
least the language itself should be as unambiguous as possible.
2.) It should consist of letters only (no operators like &). This would be 
totally confusing as it would break a long Pascal tradition and would make code 
less readable.
3.) It should have a speaking name that describes what it realy does.

From the above I would vote for "InlineIf" or eve better "IfThenElse".
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Pascal Lexical Diagrams

[Jürgen Hestermann]

Am 2016-01-30 um 20:44 schrieb Michael Van Canneyt:

I can only concur with what Ewald writes.


Are the Latex sources for the documenation
available somewhere for download?

I would like to check why the syntax diagrams
created with the syntax.sty
are incorrect and how they can be improved.

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

Re: [fpc-pascal] Pascal Lexical Diagrams

[Jürgen Hestermann]

Am 2016-01-30 um 10:45 schrieb Anthony Walter:
> I've been working on writing Javascript to generate lexical language diagrams 
for the getlazarus.org learning center portal.
> With my script I'm able to render these diagrams which will be appear under 
the Free Pascal language Lexical topic:
> http://cache.getlazarus.org/images/lexical-diagrams.png
> Hopefully they are clear enough in their schematic design such they're 
understandable. I'll be adding code examples and brief summaries to each diagram 
which will likely be of aide.

The look of the diagrams is very good.

Some things that I think can be improved:

1.) Direction of lines:
The lines should have arrows to denote the direction in which a diagram has to 
be followed. This would allow recursive definitions.
Example: http://i.stack.imgur.com/SOq3x.gif
It would also avoid the somewhat irritating use of words like [repeat] and 
[open symbol] which are only needed because of the missing arrows.

2.) \n
I think \n is not used in Pascal (it's more a C convention). Instead it should be named 
"line ending" or something like that. Also, especially new users may not know 
what \n means (unless they come from C).

3.) String literal:
Why does (char literal) appear twice? There can be any number of (char 
literals) so I think it would be clearer to have a simple recursive loop:

  />-'[any character other than "line ending"]'->-|
->->-(char literal)->-|->-
  \---(//)[line ending]->-\
->--->-({)---(})->-|->-
   \->-((*)--(*))--/

5.) Identifier:
Same here, instead of the [repeat] word arrows should be used.


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

Re: [fpc-pascal] Methods for autoupdating fpc programs?

[Jürgen Hestermann]

Am 2015-10-04 um 19:11 schrieb mic...@gmail.com:

But that makes no sense to me. If the OS is designed to potentially remove
running programs (or parts of it) from memory it cannot allow overwriting
the file on disk in any case. When it does so, it cannot remove parts from
memory because it may not be available on disk anymore. So it must disallow
the disk change from the beginning, otherwise it may not be able to remove
anything.


http://askubuntu.com/questions/44339/how-does-updating-running-application-binaries-during-an-upgrade-work

http://unix.stackexchange.com/questions/49299/what-is-linux-doing-differently-that-allows-me-to-remove-replace-files-where-win

http://superuser.com/questions/251129/moving-a-file-while-its-in-use-how-does-it-work



In these links I didn't find any explanation that tell me if (and if yes, why) 
it *sometimes* does not work.

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

Re: [fpc-pascal] Methods for autoupdating fpc programs?

[Jürgen Hestermann]

Am 2015-10-04 um 15:41 schrieb Mark Morgan Lloyd:

Michael Van Canneyt wrote:

On Sun, 4 Oct 2015, Graeme Geldenhuys wrote:


On 2015-10-04 13:16, Mattias Gaertner wrote:

Replacing a running program by simply copying can result under Linux in
'text file busy'.


Then consider me luckily. :) In my 15 years of using Linux and 4 years
of FreeBSD I have never seen that error.


I see it nearly every day, when I recompile a fastcgi process that is still in 
use by Apache.

But I was also surprised to see it. I'm still not sure what the exact cause is, 
because it works sometimes, and sometimes not.


It generally happens if the OS (almost any OS) decides that constrained 
resources means that a segment can usefully be removed from memory, and further 
decides that it's a read-only segment so rather than writing it to swap it 
will- if it needs it again- reread it from the original binary.



But that makes no sense to me. If the OS is designed to potentially remove 
running programs (or parts of it) from memory it cannot allow overwriting the 
file on disk in any case. When it does so, it cannot remove parts from memory 
because it may not be available on disk anymore. So it must disallow the disk 
change from the beginning, otherwise it may not be able to remove anything.

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: SizeInt documentation

[Jürgen Hestermann]

Am 2015-06-21 um 20:16 schrieb leledumbo:
>> A documenation of a type that has different meanings on different
>> platforms should tell about this.
>> That's what a documentation is for!
> Well, the user guide, programmer's reference or basically everything other
> than the API documentation mentions whenever something is platform specific.
> And they're hand written.

Then I don't understand what the web page
http://www.freepascal.org/docs-html/rtl/system/sizeint.html
realy is.
I thought it was an online documentation of the Free Pascal runtime library.
Is it not?
What is the API documentation you talk about?
Free Pascal cannot be documented without the OS-specific details.
Isn't the SIZEINT type a part of Free Pascal?
Then a documentation has to tell all details about it.
Otherwise it cannot be called documentation.
But what is then?


>> How should I know that these documentations are for *nix only?
> *nix units are not available on non-nix platforms, it's that simple.

When I search for "sizeint" in google I find
http://www.freepascal.org/docs-html/rtl/system/sizeint.html
What is unix-related here?
It is a general documentation of the SIZEINT type.
Not a single word about *nix.


> Going back to everything manual is NOT a solution (How many places must be
> modified when an API changes? How do you ensure the documentation and source
> be consistent?),

How is this ensured in the programmer's reference?

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: SizeInt documentation

[Jürgen Hestermann]

Am 2015-06-21 um 16:25 schrieb leledumbo:

but the documentation says that it is always Longint.
Can someone please correct this as it causes a lot of confusion.

fpdoc parser understands and interprets compiler directives, so it can't
display something that's defined differently for each platform.

Then something is wrong with how the documentation is "generated" (shouldn't it 
be written by a human?).
A documenation of a type that has different meanings on different platforms 
should tell about this.
That's what a documentation is for!



As you can see, we have *nix units documented online/downloadable but the 
others don't.

How should I know that these documentations are for *nix only?
They don't say this anywhere.



The description can be used to explain further, but the source cannot.
example:
http://www.freepascal.org/docs-html/rtl/system/ptruint.html
the source still displays 32-bitism (= DWord), but the description says
bitness neutral explanation ("size of a pointer" is CPU dependent).

That is totally missleading and makes the "documentation" useless.
It does not inform about all side effects which IMO is the purpose
of a documentation. Otherwise I can also guess (and try).
I would expect that the "source" part is manually written in the same
way as the "description" part.
What is the use of writing contradicting statements like these into a 
documentation:

"Unsigned integer type with same size as Pointer."
and
"type PtrUInt= DWord 
;"

What size is PtrUInt? The same as a pointer or DWord?
They differ on 64 bit systems.

Keep in mind that the documentation is for those people
who do *NOT* know (for sure) what these types mean.
All others would not read it anyway.

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

[fpc-pascal] SizeInt documentation

[Jürgen Hestermann]

The documenation in

http://www.freepascal.org/docs-html/rtl/system/sizeint.html

says:
---


 SizeInt

Signed integer type which fits for sizes


   Declaration

Source position: systemh.inc line 251

type SizeInt= LongInt 
;

---

which seems to be wrong. In Systemh.inc it is declared

---
{$ifdef CPU64}
  SizeInt = Int64;
{$endif CPU64}

{$ifdef CPU32}
  SizeInt = Longint;
{$endif CPU32}

{$ifdef CPU16}
  SizeInt = Integer;
{$endif CPU16}
---

but the documentation says that it is always Longint.
Can someone please correct this as it causes a lot of confusion.

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

[fpc-pascal] Managed types within records

[Jürgen Hestermann]

Hi,

when I have a record which has managed types (i.e. strings),
how are they handled by the compiler when I assign one record to the other?
Example:

---
type MyRecordType = record
  X : SizeInt;
  S : AnsiString;
  end;
var A,B : ^MyRecordType;

begin
new(A);
new(B);
A^.X := 7;
A^.S := 'String in A';
B^ := A^;
Dispose(A);
end;
---

What happens to the reference counter of S?
Is it updated correctly (assigned to zero with new,
incremented with B^:=A^ and decremented with dispose)?

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

Re: [fpc-pascal] File handling: the TFileStream or the classical way is faster and more efficient?

[Jürgen Hestermann]

Am 2015-05-27 um 09:38 schrieb Michael Schnell:

On 05/26/2015 06:25 PM, Jürgen Hestermann wrote:


If you copy thousands of files with only a few bytes each
then it may become very noticable, what "else" is done
(in additon to the pure OS copy of the files).


I don't think so. Opening the file is a tedious task for the OS. So I suppose 
the User-program/OS relation is not that different regarding the file size.


I have written a file manager that logs whole disks.
When I do this twice (so that all data is already in cache on the second run)
I can log (read the meta data like name, size, date, etc.) about 50,000 files
in one second on the second run (doing this on an SSD maybe nearly as fast
on the first run already, I have never tested it).
That means it only takes 20 nanoseconds per file to read and store the meta data
which does not sound much overhead to me.

When it now comes to reading the contents of these files this may take much 
longer dependent on their size.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] File handling: the TFileStream or the classical way is faster and more efficient?

[Jürgen Hestermann]

Am 2015-05-26 um 10:27 schrieb Michael Schnell:

As the work that needs to be done by the OS is a lot more than what is done by 
the fpc library, I suppose that there is no noticeable difference.

I think that depends on the size of the file(s).
If you copy thousands of files with only a few bytes each
then it may become very noticable, what "else" is done
(in additon to the pure OS copy of the files).


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

Re: [fpc-pascal] Truncate procedure unable to work under Linux, is this a bug?

[Jürgen Hestermann]

Am 2015-05-18 um 09:30 schrieb Michael Van Canneyt:

Function FileTruncate (Handle: THandle; Size: Int64) : boolean;
but even that does not work with files >2Gb on unix, because the underlying 
system call does not support it.



I don't know what happens on Windows.


On windows it should be possible, at least no restriction mentioned in
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365531%28v=vs.85%29.aspx
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Mode Delphi and functions as parameters.

[Jürgen Hestermann]

Am 2015-03-21 um 11:04 schrieb Constantine Yannakopoulos:

PS: I tend to always use the "()" notation when invoking functions with no 
arguments so it will be clear to a future reader that I'm invoking a function and not 
assigning some variable.


This should be the job of the langugage definition, not of the programmer:
Avoid ambiguity, do not base anything on assumptions.
That avoids bugs by making it very clear to the programmer what realy happens.

Saving one or 2 key keystrokes is of no use.
A clear language definition is what makes the essence of a programming language.

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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-10 um 17:40 schrieb Sven Barth:
> > It mutes the warning with the ID 5089 (the ID can be seen with -vq). So as 
long as the managed and unmanaged ones use the same warning ID (AFAIR they do) they 
will both be silenced.
> Ups, no, they are different. So at least if you use a current 2.7.1 or newer 
only the managed ones will be hidden.

Currently I use Lazarus 1.4RC1 with FPC Version 2.6.4.
Does this version already have different IDs for managed and non-managed types?


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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-10 um 18:52 schrieb Florian Klämpfl:
> Using dyn. arrays without initialization makes litte sense in real world 
programs,

Why this? I do this all the time.
I know that they *are* already initialized
so why should I do this again?

> so those warnings have their use.

Of what use are they?

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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-10 um 18:16 schrieb Lukasz Sokol:

On 10/03/15 16:08, Jürgen Hestermann wrote:

Then please tell me, what do you (or anybody else) gain from this warning?
Especially, as it claims something that is definitely not true (for managed 
types).
It may even misguide some to add initialisation code without need and
it distracts from the realy important messages.


Just googled this out:
(edit: meant this actually)
http://lazarusroad.blogspot.com.br/2012/07/does-it-matter-how-dynamic-arrays-are.html

and this immediately after:

http://lazarusroad.blogspot.co.uk/2012/07/cost-to-supress-warning-and-how-not-pay.html




I am not sure what these links should tell me.
I could not find any hint that omitting the warnings for managed types would do 
any harm.
Just the opposite. As I already suspected, people are adding code just to get 
rid of the warning
(or they have the time and leisure to disable these warnings for each project 
over and over again):
Cite from the second link:

"Although the performance impact is mostly negligible, is extra code anyway.
In my case i initialize the parameter explicitly so *out* would add redundant 
code.
There's an alternative to suppress the message: add the directive {%H-} in front of 
the variable that is being passed to the procedure."

Again I can't find any legimitation for having these warnings.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-10 um 10:08 schrieb Mattias Gaertner:

On Tue, 10 Mar 2015 08:48:49 +
Lukasz Sokol  wrote:


On 10/03/15 06:10, Jürgen Hestermann wrote:
[...]

Why not simply omit these messages (for managed types)?

Just because YOU don't need it, doesn't mean it's useless for everybody...

http://www.freepascal.org/docs-html/prog/progsu80.html#x87-860001.2.80

why not just use this to suppress the warning JUST where you DO know it's not 
needed?

(you can suppress warning by number too IIUC).

Yes.
For example in Lazarus 1.3+ you can right click the message and
click on "Hide with project option (-vm5089)".


Would this oppress these warnings for managed types only?
Or would I loose them for non-managed types too?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-10 um 09:48 schrieb Lukasz Sokol:

On 10/03/15 06:10, Jürgen Hestermann wrote:

Am 2015-03-09 um 19:24 schrieb DaWorm:

I would think this part answers that question:  "The warning means
that no value has been */explicitly/* assigned to these variables
(which */may indicate a logic error/* in the code), not necessarily
that they contain an unpredictable value." (emphasis mine)



No, it answer not the question. As I already wrote in my other mail:
Why am I forced to add superfluous (initialization) code just to get
rid of a warning that is completely useless (false). Managed types
*are* initialized so this warning just pollutes the message window
and distracts from the realy useful information.

Why not simply omit these messages (for managed types)?



Just because YOU don't need it, doesn't mean it's useless for everybody...



Then please tell me, what do you (or anybody else) gain from this warning?
Especially, as it claims something that is definitely not true (for managed 
types).
It may even misguide some to add initialisation code without need and
it distracts from the realy important messages.

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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-09 um 19:24 schrieb DaWorm:

I would think this part answers that question:  "The warning means that no value has 
been */explicitly/* assigned to these variables (which */may indicate a logic error/* in 
the code), not necessarily that they contain an unpredictable value." (emphasis mine)



No, it answer not the question.
As I already wrote in my other mail:
Why am I forced to add superfluous (initialization) code
just to get rid of a warning that is completely useless (false).
Managed types *are* initialized so this warning just pollutes the
message window and distracts from the realy useful information.

Why not simply omit these messages (for managed types)?

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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-09 um 18:31 schrieb Jonas Maebe:


On 09 Mar 2015, at 17:49, Jürgen Hestermann  wrote:


Am 2015-03-09 um 17:40 schrieb Jonas Maebe:

http://bugs.freepascal.org/view.php?id=24601#c75617 (and the comment below + 
use -vq to see warning numbers, and -vm to block a particular warning 
number).

Thanks for the answer.
But still: Why is there such a warning for managed types at all?

That is the same question you asked in your original mail and which is answered 
in the bug report comment I linked in reply.



Not quite. In the bug comment you wrote:

The warning is by design for all kinds of variables and regardless of their 
storage location (as noted by the original submitter, global/static variables 
of any kind are always initialised by 0/nil/...). The warning means that no 
value has been explicitly assigned to these variables (which may indicate a 
logic error in the code), not necessarily that they contain an unpredictable 
value.

But still there is the question *why* this design exists?
I think it is a bad design.
It should know that managed types *are* initialized and not raise a warning in 
this case.
Why generate a warning with an incorrect statement?
Am I forced to add (superfluous) initialization code or somehow suppress this 
kind of
warning just to get rid of this false warnings which are useless from the 
beginning?

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

Re: [fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

Am 2015-03-09 um 17:40 schrieb Jonas Maebe:


On 09 Mar 2015, at 17:25, Jürgen Hestermann wrote:


I get a warning that a local dynamic array variable is not initialized.
Aren't such managed types initialized by default?
On http://wiki.freepascal.org/Dynamic_array it says:

Actually, dynamic arrays are pointers with automatic dereferencing. They are 
initialized to *nil* automatically.

So why the warning?


http://bugs.freepascal.org/view.php?id=24601#c75617 (and the comment below + 
use -vq to see warning numbers, and -vm to block a particular warning 
number).




Thanks for the answer.
But still: Why is there such a warning for managed types at all?
Dynamic arrays are initialized by default so the warning text is simply wrong.
It IS initialized and the compiler knows this.

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

[fpc-pascal] Warning "Local variable seems to be not initialized" on dyn array

[Jürgen Hestermann]

I get a warning that a local dynamic array variable is not initialized.
Aren't such managed types initialized by default?
On http://wiki.freepascal.org/Dynamic_array it says:

Actually, dynamic arrays are pointers with automatic dereferencing. They are 
initialized to *nil* automatically.

So why the warning?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FileAge and timezone

[Jürgen Hestermann]

Am 2014-10-30 um 15:21 schrieb Michael Van Canneyt:

On Thu, 30 Oct 2014, Mattias Gaertner wrote: Under Linux I see UTC.

But on Windows it seems to return with timezone. See this bug:
http://bugs.freepascal.org/view.php?id=26963


Quite possible: like I said, it depends on the OS. The change to TDateTime 
should take care of that by converting it always to local time.
If you want it always in UTC for internal reasons, then additional functions 
need to be developed:
On linux that will be a No-op, on windows it will need to take care of some 
stuff...


On Windows it's UTC too.
The Windows API function "FindFirstFileW" gives
back a data structure where the dates are UTC times.
So to get local times you need to convert with "FileTimeToLocalFileTime".



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

Re: [fpc-pascal] Syserrormessage, parameter data type

[Jürgen Hestermann]

Am 2014-10-05 um 15:08 schrieb Michael Van Canneyt:


A typecast will be needed somewhere.


Yes, instead of assigning the two values as in

Integer_Type := DWord_Type;

MOVE could be used:

move(DWord_Type,Integer_Type,sizeof(DWord_Type));

This way no range check would trigger and no bit would be changed either.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syserrormessage, parameter data type

[Jürgen Hestermann]

Am 2014-10-06 um 07:55 schrieb Sven Barth:
> On 06.10.2014 07:20, Jürgen Hestermann wrote:
>>
>> Am 2014-10-05 um 20:21 schrieb Sven Barth:
>>> Please note that GetLastError is Windows-specific. The cross platform
>>> function in SysUtils is called GetLastOSError which does return Integer.
>> And why does a function SysErrorMessage exist that expects an INTEGER
>> and handes this over to FormatMessage which expects a DWORD?
>
> SysErrorMessage is the cross platform function while FormatMessage
> is the Windows specific implementation so the types returned/used
> by these two functions are already compatible.

This is incorrect.
SysErrorMessage expects an INTEGER while FORMATMESSAGEA is
declared to use a DWORD parameter (see code snippets at the bottom).


> GetLastOSError merely uses GetLastError on Windows (on Linux it
> is errno for example) and casts its DWORD result to Integer.

Again incorrect. GetLastOSError gives back an Integer and
the DWORD coming from GetLastError it directly assigned to
this integer-type Result. There is no type casting (see below).


> SysErrorMessage gets that Integer passed in and converts it to
> DWORD again for FormatMessage on Windows (on Linux it uses a
> resourcestring table indexed by the error number for example).

Again incorrect.
"Conversion" yes, but no type casting.
Therefore, if the DWORD is above 2^31 you will
get a range check error (if range check is enabled).
And in the other direction (INTEGER assigned to a DWORD)
you will get a range check error when the valus is <0.


When I use Alt+Up and Ctrl+Shift+Down to let me point
to the defintion and declaration of each function I find:

In SYSUTILSH.INC

function SysErrorMessage(ErrorCode: Integer): String;
const MaxMsgSize = Format_Message_Max_Width_Mask;
var   MsgBuffer: pChar;
begin
GetMem(MsgBuffer, MaxMsgSize);
FillChar(MsgBuffer^, MaxMsgSize, #0);
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM,
   nil,
   ErrorCode,
   MakeLangId(LANG_NEUTRAL, SUBLANG_DEFAULT),
   MsgBuffer, { This function allocs the memory }
   MaxMsgSize,   { Maximum message size }
   nil);
SysErrorMessage := StrPas(MsgBuffer);
FreeMem(MsgBuffer, MaxMsgSize);
end;


In SYSUTILS:

Function GetLastOSError : Integer;
begin
Result:=GetLastError;
end;

(Used when coding "SysErrorMessage(GetLastOSError)")

In FUNC.INC:

function GetLastError:DWORD; external 'kernel32' name 'GetLastError';


All these functions are used in this way under Windows.
I don't know whether some of these functions change their
parameter types under other OS's. But under Windows it
does definitely not work correctly.

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

Re: [fpc-pascal] Syserrormessage, parameter data type

[Jürgen Hestermann]

Am 2014-10-05 um 20:21 schrieb Sven Barth:

Please note that GetLastError is Windows-specific. The cross platform function 
in SysUtils is called GetLastOSError which does return Integer.

And why does a function SysErrorMessage exist that expects an INTEGER
and handes this over to FormatMessage which expects a DWORD?

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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Syserrormessage, parameter data type

[Jürgen Hestermann]

Am 2014-10-05 um 19:04 schrieb leledumbo:

But the current situation is wrong for *all* plattforms

FormatMessage doesn't exist on non-Windows platform. SysErrorMessage doesn't
call FormatMessage on Linux for instance.


Then it would make even less sense to use INTEGER in SysErrormessage.
The version that calls FormatMessage should use DWORD.
If it will be used on Windows only then there is no reason to use INTEGER
as an intermediate data type if DWORD is fed in and DWORD is handed over.
It makes not sense at all.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syserrormessage, parameter data type

[Jürgen Hestermann]

Am 2014-10-05 um 12:10 schrieb Michael Van Canneyt:

Not necessarily, because it is a cross-platform function and on other systems 
the error codes are not necessarily positive values.
Unfortunately, this kind of windows-api-creep is found throughout the RTL.

The proper procedure is probably to introduce TSysErrorCode which depends on 
the platform, and replace integer/dword with that.
Please file a bug-report, so we do not forget this.


But the current situation is wrong for *all* plattforms because the sequence 
DWORD-INTEGER-DWORD
does not work and when it becomes INTEGER-INTEGER-DWORD it doesn't work either.
The FormatMessageA call within SysErrorMessage expects DWORD too but an INTEGER 
is provided.

If GetLastError sometimes gives back a DWORD (Windows) and sometimes an INTEGER 
(Linux) then
the complete sequence GetLastError-SysErrorMessage-FormatMessageA needs to 
become platform
dependend to solve this. But as long as this is not the case at least one 
platform (Windows) would
work okay when the parameter in SysErrorMessage becomes DWORD too. In the 
current situation
it *never* works correctly (not even for Linux).

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

[fpc-pascal] Syserrormessage, parameter data type

[Jürgen Hestermann]

In my programs I use this code quite often:

SysErrorMessage(GetLastError);

But recently my program had a range check
error which let me have a look at the definiton
of the 2 functions GetLastError and SysErrorMessage.
GetLastError is from the WinAPI:

---
function GetLastError:DWORD; external 'kernel32' name 'GetLastError';
---

and SysErrorMessage is from SysUtils:

---
function SysErrorMessage(ErrorCode: Integer): String;
const MaxMsgSize = Format_Message_Max_Width_Mask;
var   MsgBuffer: pChar;

begin
GetMem(MsgBuffer, MaxMsgSize);
FillChar(MsgBuffer^, MaxMsgSize, #0);
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM,
   nil,
   ErrorCode,  <- 3rd Parameter
   MakeLangId(LANG_NEUTRAL, SUBLANG_DEFAULT),
   MsgBuffer, { This function allocs the memory }
   MaxMsgSize,   { Maximum message size }
   nil);
SysErrorMessage := StrPas(MsgBuffer);
FreeMem(MsgBuffer, MaxMsgSize);
end;
---

GetLastError yields a DWORD but SysErrorMessage expects an INTEGER.
Why? This raises a range check for all error codes >2^31.

A closer look at SysErrorMessage shows that the ERRORCODE will
not be used in this routine but only handed over to
FormatMessageA which expects a DWORD!

---
function FormatMessageA(dwFlags:DWORD;
lpSource:LPCVOID;
dwMessageId:DWORD;<- 3rd Parameter
dwLanguageId:DWORD;
lpBuffer:LPSTR;
nSize:DWORD;
Arguments:va_list):DWORD; external 'kernel32' name 
'FormatMessageA';
---

So if GetLastError gives a DWORD and FormatMessageA expects a DWORD
shouldn't SysErrorMessage use a DWORD too?



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

Re: [fpc-pascal] with statement using mulltiple objects

[Jürgen Hestermann]

Am 2014-09-14 12:08, schrieb Mattias Gaertner:
>>  > All seasoned programmers know that and try to avoid the with statement.
> The quote is from Marius, not from me.

Correct. I deleted the wrong reference. ;-(


>> Realy? I love it. Consider these two varianst of code from one of my 
programs:
>>
>> -
>> with TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^ do
>> begin
>> DirLogged := true;
>> DirHatFocus   := false;
>> SubDirsExpanded   := true;
>> [...]
>> -
>
> and
>
> -
> d:=TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]; // local var d
> d^.DirLogged := true;
> d^.DirHatFocus   := false;
> d^.SubDirsExpanded   := true;
> [...] -


Long-winded and still not the same clarity as in the with statement.

Do you also prepent *all* function and variable names
with the unit name they come from?
Do you realy *always* write

LazUTF8.UTF8Delete
instead of
UTF8Delete
?

Nested WITH statements and the unit concept share the
same problem but still the benefits outweigh the drawbacks IMO
(once you get used to it and keep possible problems in mind).


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