Re: [fpc-devel] Wrong docs: not initialized global variables

[Ondrej Pokorny]

On 24.03.2018 23:33, Ondrej Pokorny wrote:


Another question about this sentence in FPC docs: "Managed types are
always initialized: in general this means setting the reference
count to
zero, or setting the pointer value of the type to Nil."

Does it mean I can assume a local string variable is always
(=whenever
the routine is called) initialized to ''? I.e. that TestB always
returns
'a'?


For managed types this is indeed guaranteed. Otherwise there'd be 
exceptions upon the first use of the variable as the RTL would assume 
that the value is valid.


OK, thanks. My assumption was that setting local managed types to nil 
is guaranteed only once at the first routine call. And that it is an 
implementation detail if it is niled at the second call or reused from 
the first call.


I probably mixed it up with the Result variable (what Maciej wrote about).


I found the source of my assumption, I get a compiler warning in this case:

program StringsTest;
function Test: string;
var S: string;
begin
  S := S + 'a';
  Result := S;
end;
begin
  Writeln(Test);
end.

Emits:
StringsTest.lpr(5,8) Warning: Local variable "S" of a managed type does 
not seem to be initialized


Why do I get the compiler warning when the variable is indeed guaranteed 
to be initialized to nil/empty string?


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

Re: [fpc-devel] Wrong docs: not initialized global variables

[Ondrej Pokorny]

On 24.03.2018 23:00, Sven Barth via fpc-devel wrote:
Ondrej Pokorny > schrieb 
am Sa., 24. März 2018, 20:49:


This is not correct. Global simple variables are always
initialized. At
least in Delphi it is so:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi)

"If
you do not explicitly initialize a global variable, the compiler
initializes it to 0."


So, Delphi *does* document it. Okay, in that case the documentation 
needs to be updated, cause up to now the assumption has been that this 
is an implementation detail.


It has always been so in Delphi - at least since I learnt it. The Delphi 
7 docs (I can't find older docs online) state it as well: 
http://docs.embarcadero.com/products/rad_studio/cbuilder6/EN/CB6_ObjPascalLangGuide_EN.pdf 
on page 5-38 "If you don’t explicitly initialize a global variable, the 
compiler initializes it to 0." (Docs are at 
http://docs.embarcadero.com/products/rad_studio/ )



Another question about this sentence in FPC docs: "Managed types are
always initialized: in general this means setting the reference
count to
zero, or setting the pointer value of the type to Nil."

Does it mean I can assume a local string variable is always (=whenever
the routine is called) initialized to ''? I.e. that TestB always
returns
'a'?


For managed types this is indeed guaranteed. Otherwise there'd be 
exceptions upon the first use of the variable as the RTL would assume 
that the value is valid.


OK, thanks. My assumption was that setting local managed types to nil is 
guaranteed only once at the first routine call. And that it is an 
implementation detail if it is niled at the second call or reused from 
the first call.


I probably mixed it up with the Result variable (what Maciej wrote about).

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

Re: [fpc-devel] Wrong docs: not initialized global variables

[Maciej Izak]

2018-03-24 20:49 GMT+01:00 Ondrej Pokorny :

> Does it mean I can assume a local string variable is always (=whenever the
> routine is called) initialized to ''? I.e. that TestB always returns 'a'?
>
> function TestB: string;
> var B: string;
> begin
>   B := B + 'a';
>   Result := B;
> end;
>
> Until now I though that the above code is unsafe and I always initialized
> all local variables (also managed) before use. I assumed the initialization
> to empty string does not need to happen at every routine call.
>

Please note that string/dynamic array as Result is exception (it works like
*var* parameter). IMO this is the ugliest Pascal behavior ever:

=== example begin ===
function test1: string;
begin
  Result := Result + 'a';
end;

function test2: TArray;
begin
  SetLength(Result, Length(Result) + 1);
end;

begin
  writeln(test1); // print a
  writeln(test1); // print aa
  writeln(test1); // print aaa
  writeln(test1); // print 
  writeln(Length(test2)); // print 1
  writeln(Length(test2)); // print 2
  writeln(Length(test2)); // print 3
  writeln(Length(test2)); // print 4
end.
=== example end ===

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

Re: [fpc-devel] Wrong docs: not initialized global variables

[Sven Barth via fpc-devel]

Ondrej Pokorny  schrieb am Sa., 24. März 2018, 20:49:

> This is not correct. Global simple variables are always initialized. At
> least in Delphi it is so:
> http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If
> you do not explicitly initialize a global variable, the compiler
> initializes it to 0."
>

So, Delphi *does* document it. Okay, in that case the documentation needs
to be updated, cause up to now the assumption has been that this is an
implementation detail.

-
>
> Another question about this sentence in FPC docs: "Managed types are
> always initialized: in general this means setting the reference count to
> zero, or setting the pointer value of the type to Nil."
>
> Does it mean I can assume a local string variable is always (=whenever
> the routine is called) initialized to ''? I.e. that TestB always returns
> 'a'?
>

For managed types this is indeed guaranteed. Otherwise there'd be
exceptions upon the first use of the variable as the RTL would assume that
the value is valid.

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

[fpc-devel] Wrong docs: not initialized global variables

[Ondrej Pokorny]

Due to the "Multiple variable initialization" thread I took a look into 
FPC documentation: https://www.freepascal.org/docs-html/ref/refse24.html


There it says:

By default, simple variables in Pascal are not initialized after their 
declaration. Any assumption that they contain 0 or any other default 
value is erroneous: They can contain rubbish.


This is not correct. Global simple variables are always initialized. At 
least in Delphi it is so: 
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If 
you do not explicitly initialize a global variable, the compiler 
initializes it to 0."


-

Another question about this sentence in FPC docs: "Managed types are 
always initialized: in general this means setting the reference count to 
zero, or setting the pointer value of the type to Nil."


Does it mean I can assume a local string variable is always (=whenever 
the routine is called) initialized to ''? I.e. that TestB always returns 
'a'?


function TestB: string;
var B: string;
begin
  B := B + 'a';
  Result := B;
end;

Until now I though that the above code is unsafe and I always 
initialized all local variables (also managed) before use. I assumed the 
initialization to empty string does not need to happen at every routine 
call.


Ondrej

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

Re: [fpc-devel] Multiple variable initialization

[Florian Klaempfl]

Am 24.03.2018 um 20:21 schrieb Ondrej Pokorny:
> 
> Anyway, my favorite example of non-pascalish syntax within FPC are the
> +=, -= etc. operators. I really don't understand how they made it into
> FPC if so many FPC developers are stubbornly against simple and helpful
> extensions :)

The were added in ~1996 when I maintained FPC by applying patches to a
source tree on my hd :) But to be honest, I am not sure if I accepted
the patch today :)

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

Re: [fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

On 24.03.2018 18:40, Jonas Maebe wrote:
The C-syntax is indeed consequent, and that is what I referred to: the 
assignments work the same way as elsewhere in the program, so multiple 
initialisations are just as clear as single initialisations there. In 
Pascal, you have a special syntax for initialised variables/constants, 
and hence extending it to work on multiple variables/fields does not 
have the advantage that you subconsciously immediately know what 
happens based on your knowledge of the rest of the language.


I still don't understand how anybody can think that the syntax "var A, 
B: Integer = 0;" is unclear and doesn't immediately recognize that 0 is 
applied both to A and B. Honestly it would never come to my mind if you 
haven't raised this question.


As you Jonas said, Pascal syntax for initialization of 
variables/constants is a special one after all and therefore you do need 
to know it. Explaining/documenting the fact that you can initialize 
multiple variables/constants at once is one extra sentence. Just one 
sentence. In a documentation that you need to read anyway because the 
initialization syntax is unusual.


Anyway, my favorite example of non-pascalish syntax within FPC are the 
+=, -= etc. operators. I really don't understand how they made it into 
FPC if so many FPC developers are stubbornly against simple and helpful 
extensions :)


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

Re: [fpc-devel] Why debugger does not "step in"?

[Jonas Maebe]

On 24/03/18 19:46, Martin Frb wrote:

On 24/03/18 19:34, Jonas Maebe wrote:
https://bugs.freepascal.org/view.php?id=14399 

Will your fix (2018-01-13 16:59) be in 3.0.6? Or 3.2 only?


3.2


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

Re: [fpc-devel] Why debugger does not "step in"?

[Martin Frb]

On 24/03/18 19:34, Jonas Maebe wrote:
https://bugs.freepascal.org/view.php?id=14399 

Will your fix (2018-01-13 16:59) be in 3.0.6? Or 3.2 only?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Why debugger does not "step in"?

[Jonas Maebe]

On 24/03/18 19:30, Martin Frb wrote:

On 24/03/18 17:58, Gennady Agranov wrote:
>>> It isn't a method of an "interface"? interfaces indeed have this 
issue.


It is the case - thanks!

Is it "nothing can be done about it" case?

Is there an already submitted bug? 


Not sure if there is a bug report. I am not even sure if this is:
- an issue in gdb
- an issue with the debug info generated by fpc


https://bugs.freepascal.org/view.php?id=14399


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

Re: [fpc-devel] Why debugger does not "step in"?

[Martin Frb]

On 24/03/18 17:58, Gennady Agranov wrote:
>>> It isn't a method of an "interface"? interfaces indeed have this 
issue.


It is the case - thanks!

Is it "nothing can be done about it" case?

Is there an already submitted bug? 


Not sure if there is a bug report. I am not even sure if this is:
- an issue in gdb
- an issue with the debug info generated by fpc

From very far memory fpc generates some kind of "jump table" 
(actually it may be a bit more than a jump table) for each class that 
implements an interface.
Calling a method of an interface first calls the code in that table, and 
then goes to the actual method.
gdb somehow thinks that the code in the table can not be stepped, and 
skips the entire call.


Maybe fpc could add debug info, not sure what is available in each of 
the stabs/dwarf2/3 standards that could be used to tell gdb.


Btw, have you tried dwarf 3? I never tested, so maybe / But be 
aware, dwarf3 has other instabilities (gdb crashes)

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

Re: [fpc-devel] Multiple variable initialization

[Michael Van Canneyt]

On Sat, 24 Mar 2018, Ozz Nixon wrote:


As an extension, it makes sense - but I would make it a forced command line
switch and obscure $modeswitch.


Modeswitched and command-line options only go so far.

The problem with this approach is that, if I see someone elses code, 
I still have the confusing code in front of my eyes.


Same with Generics and whatnot. 
It's correct that I don't use have to use them, but I am confronted 
with the ugly-as-hell syntax in other people's code all the time.


No amount of modeswitches can stop this proliferation of ugly constructs...

Michael.


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

Re: [fpc-devel] Multiple variable initialization

[Ozz Nixon]

As an extension, it makes sense - but I would make it a forced command line
switch and obscure $modeswitch. So the code can easily be ported to other
pascal compilers, or versions of FPC down the road. I spend 8 to 12 hours a
day porting Delphi (versions) of code to FPC. And the XE series really made
a mess of the language. I spend hours in FPC's core code, as I am making my
script engine compatible with FPC's code (to be the interpreter for FPC
source)...

I agree, especially from a script world, I would expect to see:
var a,b,c,d,e:String='';

as it looks like a script engines extension to:
const a,b,c,d:String='';

// and in Delphi $J+ aka {$WRITEABLECONST ON} making constant read/write -
you have basically produced what you are asking for. So, maybe FPC already
supports this?

* Now side note, you can define variable types in JavaScript (wrote my own
ECMA compliant script engine in 2000 (DXJavaScript) for Delphi):
var x = new Number(0);
var y = new String("Hello World!");

Of course, x and y are JavaScript objects at their core - so they can be
any type later in the code. But, JavaScript does support type definition in
the code. Number==Float==Integer.

Ozz


On Sat, Mar 24, 2018 at 1:13 PM Ondrej Pokorny  wrote:

> On 24.03.2018 16:51, Florian Klaempfl wrote:
> > Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny:
> >> Is there a reason why multiple variable initialization is forbidden?
> >>
> >> program Test;
> >> var
> >>A: Integer = 0;// allowed
> >>B, C: Integer = 0; // not allowed
> >> begin
> >> end.
> >>
> >> Will a patch be applied that allows it?
> > As the first one is supported, I see no logical reason the second
> > shouldn't be supported, of course assigning 0 to B and C.
>
> Good to know there's somebody with the same point-of-view. Thanks :)
>
> Ondrej
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Ralf Quint]

On 3/24/2018 6:54 AM, Sven Barth via fpc-devel wrote:
Anthony Walter > schrieb am 
Sa., 24. März 2018, 14:51:


If you were going to patch I'd also consider allowing:

program Test;
var
B, C: Integer = 0, 1;  // sets B = 0, and C = 1
begin
end.


No, that is only confusing.

+1

Writing programs in Pascal should make them readable, not add more 
obfuscation methods.


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Jonas Maebe]

On 24/03/18 17:54, Ondrej Pokorny wrote:
Yes, both examples are much easier to read. You cannot convince me they 
are not.


Then there's not much point in discussing.


If you are talking about Ozz Nixon's post and the C-syntax:


I was.


int a, b, c;
int a=0, b=0, c=0;

What different syntax do you talk about? The syntax is consequent - it's 
about operator precedence. Comma is evaluated after the assignment ( 
http://en.cppreference.com/w/cpp/language/operator_precedence ) - this 
is well documented. A similar scenario for Pascal would be: var A = 0, B 
= 0, C = 0: Integer; But you know this is not Pascal syntax.


The C-syntax is indeed consequent, and that is what I referred to: the 
assignments work the same way as elsewhere in the program, so multiple 
initialisations are just as clear as single initialisations there. In 
Pascal, you have a special syntax for initialised variables/constants, 
and hence extending it to work on multiple variables/fields does not 
have the advantage that you subconsciously immediately know what happens 
based on your knowledge of the rest of the language.



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

Re: [fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

On 24.03.2018 16:51, Florian Klaempfl wrote:

Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny:

Is there a reason why multiple variable initialization is forbidden?

program Test;
var
   A: Integer = 0;    // allowed
   B, C: Integer = 0; // not allowed
begin
end.

Will a patch be applied that allows it?

As the first one is supported, I see no logical reason the second
shouldn't be supported, of course assigning 0 to B and C.


Good to know there's somebody with the same point-of-view. Thanks :)

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

Re: [fpc-devel] Why debugger does not "step in"?

[Gennady Agranov]

>>> It isn't a method of an "interface"? interfaces indeed have this 
issue.


It is the case - thanks!

Is it "nothing can be done about it" case?

Is there an already submitted bug?

Thanks,
Gennady

On 3/24/2018 4:42 AM, Martin Frb wrote:

On 24/03/18 02:24, Gennady Agranov wrote:

Hi,

I use FPC 3.0.4 / Lazarus 1.8.2

I am seeing the same behavior when I debug the program using Lazarus 
IDE under Win64 and Linux64


When I want to "step in" into my own function/procedure - GDB simply 
steps over...


If I set a breakpoint inside the function/procedure I want to "step 
in" and "run" - it would stop at this breakpoint. 


It isn't a method of an "interface"? interfaces indeed have this issue.

But if it is a normal procedure, then this is odd.  A few things you 
can try:


- On Windows, use an external linker (option -Xe)
- Try stabs vs Dwarf (Project Options > Debugging)
- Do NOT use smart linking
- Do NOT use any optimization -O...
- Try a diff version of gdb
- Try an older fpc (but keep all else the same). So you know if it is 
an issue with current fpc.


I also found a bug report 
https://bugs.freepascal.org/view.php?id=31599 that may or may not be 
related.


Someone recently reported they had the opposite problem, where the 
debugger would step in, when they actually stepped over. Not sure if 
related.

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



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

Re: [fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

On 24.03.2018 16:53, Jonas Maebe wrote:
> You'd also have to support it at least for record field initialisers 
and default parameters.


Oh yes, I'd also love to write

procedure Test(const A, B, C, D: Integer = 0);

instead of

procedure Test(const A: Integer = 0; const B: Integer = 0; const C: 
Integer = 0; const D: Integer = 0);


On 24.03.2018 16:53, Jonas Maebe wrote:
In the end, pretty much every extra language feature makes both the 
compiler and the language more complex. Therefore, I think the 
question for language extensions should never be "is there a good 
reason not to allow this", but "is it really necessary to allow this"? 
I.e., does it make things much easier to read, less error prone to 
write, and/or increase productivity a lot. I don't think the answer is 
"yes" for any of these questions as far as this extension is concerned.


Sorry I forgot to supply my real world example - I need to initialize 
local string parameters to empty strings:


procedure Test;
var
  A, B, C, D, E, F: string;
begin
  A := '';
  B := '';
  C := '';
  D := '';
  E := '';
  F := '';
// 
end;

becomes:

procedure Test;
var
  A, B, C, D, E, F: string = '';
begin
  // 
end;

Yes, both examples are much easier to read. You cannot convince me they 
are not.


On 24.03.2018 16:53, Jonas Maebe wrote:
> When seeing that compound initialisation/declaration statement for 
the first time, my first reflex was to interpret the initialisation as 
only applying to the final variable, no matter how useless that would 
make the language extension. As someone else posted, even languages that 
do allow multiple variables to be assigned in a single statement use a 
different syntax than the one to indicate that all variables have the 
same type.


Could you please tell me what post do you refer to? I probably missed it.

If you are talking about Ozz Nixon's post and the C-syntax:
int a, b, c;
int a=0, b=0, c=0;

What different syntax do you talk about? The syntax is consequent - it's 
about operator precedence. Comma is evaluated after the assignment ( 
http://en.cppreference.com/w/cpp/language/operator_precedence ) - this 
is well documented. A similar scenario for Pascal would be: var A = 0, B 
= 0, C = 0: Integer; But you know this is not Pascal syntax.


int a=b=0; is not supported in gcc

JavaScript: I am not aware you can declare type of variable in 
JavaScript. The operator precedence is the same as in C: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence 
so var a=5,b=1; is logical and well documented like in C.

Yes, the alternative syntax var a=b=1; is valid in JavaScript.

So in Pascal, var A, B, C: Integer = 0; makes perfect sense and 
undoubtedly means all three variables are initialized to 0


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

Re: [fpc-devel] Multiple variable initialization

[R0b0t1]

On Sat, Mar 24, 2018 at 10:53 AM, Jonas Maebe  wrote:
> In the end, pretty much every extra language feature makes both the compiler
> and the language more complex. Therefore, I think the question for language
> extensions should never be "is there a good reason not to allow this", but
> "is it really necessary to allow this"? I.e., does it make things much
> easier to read, less error prone to write, and/or increase productivity a
> lot. I don't think the answer is "yes" for any of these questions as far as
> this extension is concerned.
>

For the record the Oberon languages were designed with this philosophy
in mind, and language changes only ever removed functionality (which
did not happen often). Those languages never saw wide adoption but are
very interesting specimens of engineering.


I might agree with an addition similar to Python's tuple unpacking in
assignment, which would allow multiple assignment but require multiple
values:

var
  A, B: Integer = 0, 1;
  C, D: Integer = 0, 0;

However in some languages this is without good precedent or
justification within the language, and seems like an unnatural
bolted-on feature. Far more important I think is partial
initialization of arrays and records.

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

Re: [fpc-devel] Multiple variable initialization

[Jonas Maebe]

On 24/03/18 16:20, Ondrej Pokorny wrote:

On 24.03.2018 15:46, Alexander Grotewohl wrote:
The patch is to put them on separate lines. Preferably with meaningful 
comments for each. If FPC was changed at the whim of every programmer 
we'd end up with a huge mess that no longer resembles pascal.


Please tell me who decides about the borderline between whim and 
usefulness.


It's in the eye of the beholder. Personally, I don't think it's a good 
extension either. Variable lists followed by a type are a fundamental 
part of the language and appear everywhere (variable lists, field 
declarations, parameter lists). On the other hand, a single constant 
that initialises multiple variables in a single statement does not exist 
anywhere else in the language. Therefore, adding it in one place would 
definitely be the wrong way to go about it. You'd also have to support 
it at least for record field initialisers and default parameters.


When seeing that compound initialisation/declaration statement for the 
first time, my first reflex was to interpret the initialisation as only 
applying to the final variable, no matter how useless that would make 
the language extension. As someone else posted, even languages that do 
allow multiple variables to be assigned in a single statement use a 
different syntax than the one to indicate that all variables have the 
same type. Having to switch your frame of mind when reading one 
particular family of expressions is bad for productivity. Everything 
should be as consistent as possible.


In the end, pretty much every extra language feature makes both the 
compiler and the language more complex. Therefore, I think the question 
for language extensions should never be "is there a good reason not to 
allow this", but "is it really necessary to allow this"? I.e., does it 
make things much easier to read, less error prone to write, and/or 
increase productivity a lot. I don't think the answer is "yes" for any 
of these questions as far as this extension is concerned.



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

Re: [fpc-devel] Multiple variable initialization

[Florian Klaempfl]

Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny:
> Is there a reason why multiple variable initialization is forbidden?
> 
> program Test;
> var
>   A: Integer = 0;    // allowed
>   B, C: Integer = 0; // not allowed
> begin
> end.
> 
> Will a patch be applied that allows it?

As the first one is supported, I see no logical reason the second
shouldn't be supported, of course assigning 0 to B and C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

On 24.03.2018 15:46, Alexander Grotewohl wrote:
The patch is to put them on separate lines. Preferably with meaningful 
comments for each. If FPC was changed at the whim of every programmer 
we'd end up with a huge mess that no longer resembles pascal.


Please tell me who decides about the borderline between whim and usefulness.

E.g. FPC supports initializing local variables, which Delphi and (if I 
am not mistaken) ISO Pascal don't support:


procedure Test;
var
  A: Integer = 0;
begin
end;

Is it a whim as well? If FPC has this extension, why not to support

procedure Test;
var
  A, B: Integer = 0;
begin
end;

?

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

Re: [fpc-devel] Multiple variable initialization

[Ozz Nixon]

Actually (for clarity) JavaScript does allow multi-initialization, however,
does not require type:

var a=0,b=0,c=0; // all are zero
// and if your presetting to zero due to Pascal not pre-initializing
variables, javascript does, so:
var a,b,c; // all are zero

var a=b=c=1; // C and most JavaScript engines all three are 1
var a,b,c=2; // in certain JavaScript engines only initializes C ==2, a and
b are zero.

some Pascal Dialets do support
var a:=b:=c:=3; // all are 3

Ozz



On Sat, Mar 24, 2018 at 10:59 AM Mattias Gaertner 
wrote:

> On Sat, 24 Mar 2018 15:41:15 +0100 (CET)
> Michael Van Canneyt  wrote:
>
> > On Sat, 24 Mar 2018, Ondrej Pokorny wrote:
> >
> > > Is there a reason why multiple variable initialization is forbidden?
> > >
> > > program Test;
> > > var
> > >   A: Integer = 0;// allowed
> > >   B, C: Integer = 0; // not allowed
> >
> > I think this is confusing to read.
> > Are B and C both initialized, or only B ?
>
> The "integer" is applied to both. It would be inconsistent to apply the
> =0 only to C.
>
>
> > Javascript also does not allow this, I think, and for once with good
> reason.
>
> Since when is JS a role model for Pascal?
>
> Mattias
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

On 24.03.2018 15:41, Michael Van Canneyt wrote:

On Sat, 24 Mar 2018, Ondrej Pokorny wrote:


Is there a reason why multiple variable initialization is forbidden?

program Test;
var
  A: Integer = 0;    // allowed
  B, C: Integer = 0; // not allowed


I think this is confusing to read. Are B and C both initialized, or 
only B ?


It's not confusing at all. As Mattias said, Integer is both applied to B 
and C, so should be "= 0".


Javascript also does not allow this, I think, and for once with good 
reason.


Well I cannot think of a good reason to disallow it :) And nobody has 
given a good reason yet.


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

Re: [fpc-devel] Multiple variable initialization

[Mattias Gaertner]

On Sat, 24 Mar 2018 15:41:15 +0100 (CET)
Michael Van Canneyt  wrote:

> On Sat, 24 Mar 2018, Ondrej Pokorny wrote:
> 
> > Is there a reason why multiple variable initialization is forbidden?
> >
> > program Test;
> > var
> >   A: Integer = 0;    // allowed
> >   B, C: Integer = 0; // not allowed  
> 
> I think this is confusing to read. 
> Are B and C both initialized, or only B ?

The "integer" is applied to both. It would be inconsistent to apply the
=0 only to C.

 
> Javascript also does not allow this, I think, and for once with good reason.

Since when is JS a role model for Pascal?

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

Re: [fpc-devel] Multiple variable initialization

[Michael Van Canneyt]

On Sat, 24 Mar 2018, Ondrej Pokorny wrote:


Is there a reason why multiple variable initialization is forbidden?

program Test;
var
  A: Integer = 0;    // allowed
  B, C: Integer = 0; // not allowed


I think this is confusing to read. 
Are B and C both initialized, or only B ?


Javascript also does not allow this, I think, and for once with good reason.

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

Re: [fpc-devel] Multiple variable initialization

[Sven Barth via fpc-devel]

Anthony Walter  schrieb am Sa., 24. März 2018, 14:51:

> If you were going to patch I'd also consider allowing:
>
> program Test;
> var
>   B, C: Integer = 0, 1;  // sets B = 0, and C = 1
> begin
> end.
>

No, that is only confusing.

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

Re: [fpc-devel] Multiple variable initialization

[Anthony Walter]

If you were going to patch I'd also consider allowing:

program Test;
var
  B, C: Integer = 0, 1;  // sets B = 0, and C = 1
begin
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Request for applying patch #33124

[Jonas Maebe]

On 24/03/18 10:15, Ondrej Pokorny wrote:

On 22.03.2018 18:47, Jonas Maebe wrote:

On 22/03/18 16:14, Ondrej Pokorny wrote:

it's nothing serious, only a missing Cocoa header definition.


Those headers have been generated automatically. They should never be 
manually patched. Updated versions are indeed needed, but that will 
probably take quite a bit of work. I don't even know where the latest 
version of the header conversion tool is hosted, or which OS headers 
are the latest version it works with.


Is there a chance you could take a look at it and update the header 
definitions at some point?


I'm not sure. I've found the latest location of the parser though: 
https://github.com/genericptr/Framework-Parser


There's also a parsed version of the OS X 10.10 Cocoa headers: 
https://github.com/genericptr/MacOS_10_10


If they work for you and you can provide a patch, I can replace the 
current version of the headers in the FPC repository with these ones.



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

[fpc-devel] Multiple variable initialization

[Ondrej Pokorny]

Is there a reason why multiple variable initialization is forbidden?

program Test;
var
  A: Integer = 0;    // allowed
  B, C: Integer = 0; // not allowed
begin
end.

Will a patch be applied that allows it?

Ondrej

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

Re: [fpc-devel] Request for applying patch #33124

[Ondrej Pokorny]

On 22.03.2018 18:47, Jonas Maebe wrote:

On 22/03/18 16:14, Ondrej Pokorny wrote:

it's nothing serious, only a missing Cocoa header definition.


Those headers have been generated automatically. They should never be 
manually patched. Updated versions are indeed needed, but that will 
probably take quite a bit of work. I don't even know where the latest 
version of the header conversion tool is hosted, or which OS headers 
are the latest version it works with.


Is there a chance you could take a look at it and update the header 
definitions at some point? We need them for Cocoa updates in the LCL.


For now I solved it with this extension class:

  NSWindow = objcclass external(CocoaAll.NSWindow)
    function backingScaleFactor: CGFloat; message 'backingScaleFactor';
  end;

See 
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/cocoa/cocoaprivate.pp?root=lazarus=57240=57239=57240


But it means a lot of code noise in LCL sources (see the same revision) :/

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

Re: [fpc-devel] Why debugger does not "step in"?

[Martin Frb]

On 24/03/18 02:24, Gennady Agranov wrote:

Hi,

I use FPC 3.0.4 / Lazarus 1.8.2

I am seeing the same behavior when I debug the program using Lazarus 
IDE under Win64 and Linux64


When I want to "step in" into my own function/procedure - GDB simply 
steps over...


If I set a breakpoint inside the function/procedure I want to "step 
in" and "run" - it would stop at this breakpoint. 


It isn't a method of an "interface"? interfaces indeed have this issue.

But if it is a normal procedure, then this is odd.  A few things you can 
try:


- On Windows, use an external linker (option -Xe)
- Try stabs vs Dwarf (Project Options > Debugging)
- Do NOT use smart linking
- Do NOT use any optimization -O...
- Try a diff version of gdb
- Try an older fpc (but keep all else the same). So you know if it is an 
issue with current fpc.


I also found a bug report https://bugs.freepascal.org/view.php?id=31599 
that may or may not be related.


Someone recently reported they had the opposite problem, where the 
debugger would step in, when they actually stepped over. Not sure if 
related.

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