Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 05.11.2015 15:46, Mattias Gaertner wrote:

For example a sorted TStringList with the 'Objects' as the
position.
The list is seldom edited so editing does not need much speed.
Fast search is important. As long as there are only 20 types the
structure is irrelevant. But when we extend the list for all types of
the FPC packages the list gets big.


Yes, I'll change the array to TAvlTree, indexed by type/alias name and 
an order/position number. Seems to be a little bit cleaner than casting 
TObject to a number.


On 05.11.2015 16:23, Mattias Gaertner wrote:

The 500 is for codetools an xtConstOrdInteger.
It is FindExprTypeAsString that returns 'Integer' for xtConstOrdInteger.


We needed "xtConstOrdSmallInt", "xtConstOrdShortInt", 
"xtConstOrdInteger/xtConstOrdLongInt" and "xtConstOrdInt64" for it (e.g. 
500 would return xtConstOrdShortInt). It looks like an overkill for me, 
so let's keep the limitation for now with the knowledge that if the need 
arises, we could extend it.


On 05.11.2015 16:23, Mattias Gaertner wrote:

But what type should "i:=3.0" create? Single, Double, Extended,
> >glFloat?

>Yes, whatever: single, double, extended, glFloat - maybe create an IDE
>option for default integer/float/string/boolean types? The user then can
>decide what precision he wants to use by default. Do you think it is
>possible?

Yes, why not?


The question was a little bit confusing :) Yes, adding IDE options with 
default types for Integer+Real+String constants looks very useful to me. 
Boolean isn't needed, IMO, but maybe it should be added as well for the 
sake of completeness.


Ondrej


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Wed, 4 Nov 2015 08:23:26 +0100
Ondrej Pokorny  wrote:

> Fixed in r50217.
> 
> On 04.11.2015 02:14, Mattias Gaertner wrote:
> >> A problem could be with such code:
> >> >
> >> >var
> >> >i: SizeInt;
> >> >j: Integer;
> >> >begin
> >> >k:=i+j;
> >> >end;
> >> >
> >> >Because obviously on 32bit SizeInt=longint and Integer=longint, so there
> >> >won't be a deterministic way which type wins.
> > Left side wins.
> > It can't be perfect, but it should be deterministic.
> 
> SizeInt always wins - both if it is on left side or right side because 

I meant in doubt 'Left side wins'.
For example 'somethingA+somethingB' and both types are
longint it should return somethingA.
Since codetools do not yet support operator overloading it can't
resolve correctly 'someMatrix'+'someVector'. It should
deterministically return left side, because the important type usually
is at the beginning.


> Ok, I used just a simple "array of string". It's not the fastest/best 
> for adding items one-by-one but there are not so many types, so who 
> cares... It can be easily replaced if you don't like it.

The list is seldom edited so editing does not need much speed.
Fast search is important. As long as there are only 20 types the
structure is irrelevant. But when we extend the list for all types of
the FPC packages the list gets big.

 
> + I may have not added all predefined types in:
> function BooleanTypesOrderList: TTypeAliasOrderList;
> function IntegerTypesOrderList: TTypeAliasOrderList;
> function RealTypesOrderList: TTypeAliasOrderList;
> function StringTypesOrderList: TTypeAliasOrderList;

Thanks.


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Wed, 4 Nov 2015 05:42:57 +0100
Ondrej Pokorny  wrote:

>[...]
> > Many libs has such types. I have not counted, but I guess the FPC
> > sources has hundreds of them. Probably some of them conflict each other.
> > So something better than a TStringList should be used.
> 
> Could you tell which one to use?

For example a sorted TStringList with the 'Objects' as the
position.


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Thu, 5 Nov 2015 07:36:53 +0100
Ondrej Pokorny  wrote:

> On 03.11.2015 20:26, Mattias Gaertner wrote:
> > Of course there are some hard coded defaults in codetools. For example
> > "i:=3" can be any integer type.
> 
> It would be nice if integer constants were able to resolve their type:
> 
> 3 -> ShortInt
> 180 -> SmallInt
> etc etc.
> 
> This would be good for:
> var
>b: Byte;
> begin
>i := b + 500;
> end;

The 500 is for codetools an xtConstOrdInteger.
It is FindExprTypeAsString that returns 'Integer' for xtConstOrdInteger.

> this code creates "i: Byte;" in r50230.
> I still think it is better than the behavior before r50230 that created 
> "i: Integer;" for:
> 
> var
>b: Byte;
> begin
>i := b + 1;
> end;
> 
> Because adding a constant out of the bounds of one operand is much less 
> common than within its bounds (IMO).

Fine with me.

 
> > But what type should "i:=3.0" create? Single, Double, Extended,
> > glFloat?
> Yes, whatever: single, double, extended, glFloat - maybe create an IDE 
> option for default integer/float/string/boolean types? The user then can 
> decide what precision he wants to use by default. Do you think it is 
> possible?

Yes, why not?
 
> The integer predefined setting should be preferred to the resolved type 
> in case there is no well-defined variable. E.g.:
> i := 10 + 5;
> Should create the user-defined default integer type ("i: integer" by 
> default) and not "i: Byte".

Yes.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 03.11.2015 20:26, Mattias Gaertner wrote:

Of course there are some hard coded defaults in codetools. For example
"i:=3" can be any integer type.


It would be nice if integer constants were able to resolve their type:

3 -> ShortInt
180 -> SmallInt
etc etc.

This would be good for:
var
  b: Byte;
begin
  i := b + 500;
end;

this code creates "i: Byte;" in r50230.
I still think it is better than the behavior before r50230 that created 
"i: Integer;" for:


var
  b: Byte;
begin
  i := b + 1;
end;

Because adding a constant out of the bounds of one operand is much less 
common than within its bounds (IMO).



But what type should "i:=3.0" create? Single, Double, Extended,
glFloat?
Yes, whatever: single, double, extended, glFloat - maybe create an IDE 
option for default integer/float/string/boolean types? The user then can 
decide what precision he wants to use by default. Do you think it is 
possible?


The integer predefined setting should be preferred to the resolved type 
in case there is no well-defined variable. E.g.:

i := 10 + 5;
Should create the user-defined default integer type ("i: integer" by 
default) and not "i: Byte".


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Tue, 3 Nov 2015 19:37:04 +0100
Ondrej Pokorny  wrote:

> On 03.11.2015 17:34, Mattias Gaertner wrote:
> > codetools use only a simple heuristic to calculate the type of a
> > binary operator.
> > The function TFindDeclarationTool.CalculateBinaryOperator needs to be
> > extended for Alias types (e.g. 'integer' instead of longint) and for
> > ranges (e.g. if the operands do not fit into an integer).
> 
> Maybe you are talking about the same, but just to be sure: IMO using 
> hard-coded alias types is not a good idea (theoretically the user can 
> redefine them).

No, I meant that 'integer' is defined as
type integer = longint;
For the compiler 'integer' is just an alias for longint.
But codetools should use the alias as much as possible instead of the
underlying base type.
Maybe I should have used 'SizeInt' as an example. SizeInt can be
longint or int64. When a function returns SizeInt codetools should
declare the variable as SizeInt instead of the current base in order to
help creating cross platform code.


> Instead the type evaluation should go to the end type 
> (e.g. from Integer to *longint*) and then the end types should be 
> compared. The comparison can then be done with a hard-coded table (you 
> need it only for the basic types, so it is OK and safe) and the type 
> that wins, will be used as the result type (obviously the originally 
> used alias).
> 
> E.g.:
> 
> procedure Test;
> var
>I: Integer;
>S: SmallInt;
> begin
>Res := I + S;
> end;
> 
> Something like:
> 1.)
> I = (Integer -> longint)
> S = SmallInt
> 2.)
> ResultBasicType = Compare(longint, SmallInt) -> longint -> I
> 3.)
> ResultType = ResultBasicType -> I -> *Integer*

That would fail with the following example:

var
  i: SizeInt;
  j: SmallInt;
begin
  k:=i+j;
end;

The result should be SizeInt, not Integer.

Of course there are some hard coded defaults in codetools. For example
"i:=3" can be any integer type. In TP/Delphi/LCL applications
"integer" is used so often it is a good default.
Same for "String".
But what type should "i:=3.0" create? Single, Double, Extended,
glFloat?
It would be nice if codetools could guess the "usual" type from the
surrounding code or if it can be set via an IDE/project/package option.


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 03.11.2015 20:26, Mattias Gaertner wrote:

procedure Test;
>var
>I: Integer;
>S: SmallInt;
>begin
>Res := I + S;
>end;
>
>Something like:
>1.)
>I = (Integer -> longint)
>S = SmallInt
>2.)
>ResultBasicType = Compare(longint, SmallInt) -> longint -> I
>3.)
>ResultType = ResultBasicType -> I ->*Integer*

That would fail with the following example:

var
   i: SizeInt;
   j: SmallInt;
begin
   k:=i+j;
end;

The result should be SizeInt, not Integer.


No, the result will be SizeInt, because (SizeInt -> LongInt) wins over 
SmallInt and the result thus will be SizeInt (as the original type alias 
of /*i*/) and not Integer.


A problem could be with such code:

var
  i: SizeInt;
  j: Integer;
begin
  k:=i+j;
end;

Because obviously on 32bit SizeInt=longint and Integer=longint, so there 
won't be a deterministic way which type wins.


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Michael Ring]

Thank you for the fix, just tried it on fresh trunk, works!

Michael

Am 03.11.15 um 17:34 schrieb Mattias Gaertner:

On Tue, 3 Nov 2015 17:24:02 +0100
Ondrej Pokorny  wrote:


On 03.11.2015 17:08, Mattias Gaertner wrote:

Fixed.

How did you find it from the description?

I didn't. I tested on OS X.


You are a wizard :)
Sorry for introducing the bug in my code. But I know how it happened: it
was introduced by CodeTools variable completion:

procedure TIDECommands.PostponeUpdateEvents;
begin
FDontExecuteUpdateEventsUntil := GetTickCount64 + 500;
end;

codetools use only a simple heuristic to calculate the type of a
binary operator.
The function TFindDeclarationTool.CalculateBinaryOperator needs to be
extended for Alias types (e.g. 'integer' instead of longint) and for
ranges (e.g. if the operands do not fit into an integer).



Should I report it in the bug tracker?

Yes.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 03.11.2015 17:34, Mattias Gaertner wrote:

codetools use only a simple heuristic to calculate the type of a
binary operator.
The function TFindDeclarationTool.CalculateBinaryOperator needs to be
extended for Alias types (e.g. 'integer' instead of longint) and for
ranges (e.g. if the operands do not fit into an integer).


Maybe you are talking about the same, but just to be sure: IMO using 
hard-coded alias types is not a good idea (theoretically the user can 
redefine them). Instead the type evaluation should go to the end type 
(e.g. from Integer to *longint*) and then the end types should be 
compared. The comparison can then be done with a hard-coded table (you 
need it only for the basic types, so it is OK and safe) and the type 
that wins, will be used as the result type (obviously the originally 
used alias).


E.g.:

procedure Test;
var
  I: Integer;
  S: SmallInt;
begin
  Res := I + S;
end;

Something like:
1.)
I = (Integer -> longint)
S = SmallInt
2.)
ResultBasicType = Compare(longint, SmallInt) -> longint -> I
3.)
ResultType = ResultBasicType -> I -> *Integer*

Reported:
http://mantis.freepascal.org/view.php?id=28953

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

Probably the best approach is:

1.) Compare base types with the table.
1a.) If they are equal, goto 2.
1b.) If they differ, set winner according to table and go to 3.

2.) Compare aliases with the table, set winner.

3.) Use the original alias of the winner as result.

About the table:
We need one table for integer and one for floating-point types.
The integer table could look like ['int64', 'sizeint', 'integer', 
'smallint'] (but with all integer types and probably a good idea to 
allow the user to modify and enhance it - e.g. a simple TStringList).

The winner is the one closest to the left (top - smallest index).

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 03.11.2015 20:34, Ondrej Pokorny wrote:

A problem could be with such code:
var
   i: SizeInt;
   j: Integer;
begin
   k:=i+j;
end;
Because obviously on 32bit SizeInt=longint and Integer=longint, so 
there won't be a deterministic way which type wins.


But this is a similar issue like the one from this report (check all 
different IFDEFs for the "biggest" type)...

http://bugs.freepascal.org/view.php?id=28317
So probably not to be solved.

Otherwise IMO the comparison of base types and using the aliases from 
the definitions is the cleanest way to do it.
What if I use my own aliases that won't be supported by CodeTools or if 
I redefine the usual aliases (I know, bad idea, but still)? The "compare 
base types - use aliases" approach will still work.


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Tue, 3 Nov 2015 20:34:30 +0100
Ondrej Pokorny  wrote:

> On 03.11.2015 20:26, Mattias Gaertner wrote:
> >> procedure Test;
> >> >var
> >> >I: Integer;
> >> >S: SmallInt;
> >> >begin
> >> >Res := I + S;
> >> >end;
> >> >
> >> >Something like:
> >> >1.)
> >> >I = (Integer -> longint)
> >> >S = SmallInt
> >> >2.)
> >> >ResultBasicType = Compare(longint, SmallInt) -> longint -> I
> >> >3.)
> >> >ResultType = ResultBasicType -> I ->*Integer*
> > That would fail with the following example:
> >
> > var
> >i: SizeInt;
> >j: SmallInt;
> > begin
> >k:=i+j;
> > end;
> >
> > The result should be SizeInt, not Integer.
> 
> No, the result will be SizeInt, because (SizeInt -> LongInt) wins over 
> SmallInt and the result thus will be SizeInt (as the original type alias 
> of /*i*/) and not Integer.

Good.

 
> A problem could be with such code:
> 
> var
>i: SizeInt;
>j: Integer;
> begin
>k:=i+j;
> end;
> 
> Because obviously on 32bit SizeInt=longint and Integer=longint, so there 
> won't be a deterministic way which type wins.

Left side wins.
It can't be perfect, but it should be deterministic.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Tue, 3 Nov 2015 21:06:45 +0100
Ondrej Pokorny  wrote:

> Probably the best approach is:
> 
> 1.) Compare base types with the table.
> 1a.) If they are equal, goto 2.
> 1b.) If they differ, set winner according to table and go to 3.
> 
> 2.) Compare aliases with the table, set winner.
> 
> 3.) Use the original alias of the winner as result.
> 
> About the table:
> We need one table for integer and one for floating-point types.
> The integer table could look like ['int64', 'sizeint', 'integer', 
> 'smallint'] (but with all integer types and probably a good idea to 
> allow the user to modify and enhance it - e.g. a simple TStringList).
> The winner is the one closest to the left (top - smallest index).

Many libs has such types. I have not counted, but I guess the FPC
sources has hundreds of them. Probably some of them conflict each other.
So something better than a TStringList should be used.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 04.11.2015 02:25, Mattias Gaertner wrote:

About the table:
>We need one table for integer and one for floating-point types.
>The integer table could look like ['int64', 'sizeint', 'integer',
>'smallint'] (but with all integer types and probably a good idea to
>allow the user to modify and enhance it - e.g. a simple TStringList).
>The winner is the one closest to the left (top - smallest index).

Many libs has such types. I have not counted, but I guess the FPC
sources has hundreds of them. Probably some of them conflict each other.
So something better than a TStringList should be used.


Could you tell which one to use?

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

Fixed in r50217.

On 04.11.2015 02:14, Mattias Gaertner wrote:

A problem could be with such code:
>
>var
>i: SizeInt;
>j: Integer;
>begin
>k:=i+j;
>end;
>
>Because obviously on 32bit SizeInt=longint and Integer=longint, so there
>won't be a deterministic way which type wins.

Left side wins.
It can't be perfect, but it should be deterministic.


SizeInt always wins - both if it is on left side or right side because 
it has a higher rank than Integer. So it is now completely deterministic.
(Under "not deterministic" I ment that "k:=i+j" and "k:=j+i" return 
different types, which is the case of "left side wins".)


On 04.11.2015 05:42, Ondrej Pokorny wrote:

On 04.11.2015 02:25, Mattias Gaertner wrote:

About the table:
>We need one table for integer and one for floating-point types.
>The integer table could look like ['int64', 'sizeint', 'integer',
>'smallint'] (but with all integer types and probably a good idea to
>allow the user to modify and enhance it - e.g. a simple TStringList).
>The winner is the one closest to the left (top - smallest index).

Many libs has such types. I have not counted, but I guess the FPC
sources has hundreds of them. Probably some of them conflict each other.
So something better than a TStringList should be used.


Could you tell which one to use?


Ok, I used just a simple "array of string". It's not the fastest/best 
for adding items one-by-one but there are not so many types, so who 
cares... It can be easily replaced if you don't like it.


+ I may have not added all predefined types in:
function BooleanTypesOrderList: TTypeAliasOrderList;
function IntegerTypesOrderList: TTypeAliasOrderList;
function RealTypesOrderList: TTypeAliasOrderList;
function StringTypesOrderList: TTypeAliasOrderList;

you are welcome to extend them.

Ondrej


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Tue, 3 Nov 2015 11:15:02 +0100
Michael Ring  wrote:

> Here's the info:
> 
> /usr/local/bin/fpc -i
> Free Pascal Compiler version 2.6.4
> 
> Compiler Date  : 2014/02/26
> Compiler CPU Target: i386

> 
> ---
> 
>LCL_PLATFORM=carbon
>CPU_TARGET=i386
>COMPILERSWITCH="--compiler=/usr/local/bin/fpc"
> 
>make clean all CPU_TARGET=$CPU_TARGET LCL_PLATFORM=$LCL_PLATFORM 
> OPT="-k'-framework' -k'ApplicationServices'" || exit 1

Fixed.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

On 03.11.2015 17:08, Mattias Gaertner wrote:

Fixed.


How did you find it from the description? You are a wizard :)
Sorry for introducing the bug in my code. But I know how it happened: it 
was introduced by CodeTools variable completion:


procedure TIDECommands.PostponeUpdateEvents;
begin
  FDontExecuteUpdateEventsUntil := GetTickCount64 + 500;
end;

if FDontExecuteUpdateEventsUntil is not declared and I complete it with 
Ctrl+Shift+C it creates an integer variable:


procedure TIDECommands.PostponeUpdateEvents;
var
  FDontExecuteUpdateEventsUntil: Integer;
begin
  FDontExecuteUpdateEventsUntil := GetTickCount64 + 500;
end;

I then moved the FDontExecuteUpdateEventsUntil declaration to the 
private section without checking the actual type of it.


If you complete without the addition, the type is correct:

procedure TIDECommands.PostponeUpdateEvents;
var
  FDontExecuteUpdateEventsUntil: QWord;
begin
  FDontExecuteUpdateEventsUntil := GetTickCount64;
end;

Should I report it in the bug tracker?

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Tue, 3 Nov 2015 17:24:02 +0100
Ondrej Pokorny  wrote:

> On 03.11.2015 17:08, Mattias Gaertner wrote:
> > Fixed.
> 
> How did you find it from the description? 

I didn't. I tested on OS X.

> You are a wizard :)
> Sorry for introducing the bug in my code. But I know how it happened: it 
> was introduced by CodeTools variable completion:
> 
> procedure TIDECommands.PostponeUpdateEvents;
> begin
>FDontExecuteUpdateEventsUntil := GetTickCount64 + 500;
> end;

codetools use only a simple heuristic to calculate the type of a
binary operator.
The function TFindDeclarationTool.CalculateBinaryOperator needs to be
extended for Alias types (e.g. 'integer' instead of longint) and for
ranges (e.g. if the operands do not fit into an integer).


> Should I report it in the bug tracker?

Yes.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Mattias Gaertner]

On Thu, 29 Oct 2015 00:55:46 +0100
Michael Ring  wrote:

> I today realized that current trunk does not work anymore after Rev 
> 50151, Lazarus starts and when I load a project I get a Range Check 
> Error and after this I cannot open source files.
> 
> Is this a known issue?

What FPC version?
What options did you use to compile the IDE?

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Michael Ring]

I today realized that current trunk does not work anymore after Rev 
50151, Lazarus starts and when I load a project I get a Range Check 
Error and after this I cannot open source files.


Is this a known issue?

Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus