Re: [Lazarus] Rescan FPC sources crashes Lazarus

2011/3/25 patspiper <[hidden email]>:
> Hi,
>
> Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is not
> the case if the IDE includes only its basic packages.
>
> Can anybody reproduce?
>
> Stephano

I don't know if it is relationed, but here happens that, at random,
when the auto-completion menu should appear (e.g. ctrl+space) lazarus
will go on access violation with the popup: "ok to kill / cancel to
ignore" (or vice versa). But ignoring is still possible to save, close
and reopen lazarus without problems.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 03/25/2011 07:40 PM, Mattias Gaertner wrote:

> On Fri, 25 Mar 2011 17:42:51 +0200
> patspiper<[hidden email]> wrote:
>
>> Hi,
>>
>> Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is
>> not the case if the IDE includes only its basic packages.
>>
>> Can anybody reproduce?
> Can you find out, what package is the trouble maker?

It turned out to be a package I had converted from Delphi and installed
in the IDE. It has System.IsMultiThread:=true in the initialization
section. Commenting this out eliminated the crash.

What does this property do, and what are the effects of commenting it
out? The cross platform package uses threads and apps that use it must
use -dUseCThreads (in Linux).

Re: [Lazarus] Rescan FPC sources crashes Lazarus

> On 03/25/2011 07:40 PM, Mattias Gaertner wrote:
> > On Fri, 25 Mar 2011 17:42:51 +0200
> > patspiper<[hidden email]> wrote:
> >
> >> Hi,
> >>
> >> Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is
> >> not the case if the IDE includes only its basic packages.
> >>
> >> Can anybody reproduce?
> > Can you find out, what package is the trouble maker?
> It turned out to be a package I had converted from Delphi and installed
> in the IDE. It has System.IsMultiThread:=true in the initialization
> section. Commenting this out eliminated the crash.

It is set by the RTL, when switching from single threaded to multi
threaded and back. Only read this, do not set it.

> What does this property do, and what are the effects of commenting it
> out? The cross platform package uses threads and apps that use it must
> use -dUseCThreads (in Linux).

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 25 March 2011 19:40, Mattias Gaertner <nc-gaertnma@****> wrote:
>>
>> Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is
>> not the case if the IDE includes only its basic packages.
>>
>> Can anybody reproduce?
>
> Can you find out, what package is the trouble maker?

Just curious, but what does a "IDE installed package" and "rescanning
the FPC source code tree" have to do with each other? That seems like
some IDE dependencies that shouldn't exist in the first place?

Re: [Lazarus] Rescan FPC sources crashes Lazarus

> On 25 March 2011 19:40, Mattias Gaertner <nc-gaertnma@****> wrote:
> >>
> >> Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is
> >> not the case if the IDE includes only its basic packages.
> >>
> >> Can anybody reproduce?
> >
> > Can you find out, what package is the trouble maker?
>
> Just curious, but what does a "IDE installed package" and "rescanning
> the FPC source code tree" have to do with each other? That seems like
> some IDE dependencies that shouldn't exist in the first place?

The scan uses multi threading, which was broken by the installed
package.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

I was reading the thread and replying before I read the whole thread.
Indeed that installed package did do something it was not supposed to
do.

In all fairness, how are all developers supposed to know that? Isn't
there a better way that FPC could hide such functionality (not
allowing a developer to set a RTL controlled variable they are not
supposed do). That should really be filed as a bug against FPC. They
[fpc] should rather use some singleton class with a read-only
property, or simply a function (function IsRTLMultiThreaded: boolean;)
or something, not just a global read-write variable - that's just
sloppy!

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 25.03.2011 22:19, Graeme Geldenhuys wrote:

> On 25 March 2011 23:08, Mattias Gaertner<nc-gaertnma@net****> wrote:
>>
>> The scan uses multi threading, which was broken by the installed
>> package.
>
> I was reading the thread and replying before I read the whole thread.
> Indeed that installed package did do something it was not supposed to
> do.
>
> In all fairness, how are all developers supposed to know that? Isn't
> there a better way that FPC could hide such functionality (not
> allowing a developer to set a RTL controlled variable they are not
> supposed do). That should really be filed as a bug against FPC. They
> [fpc] should rather use some singleton class with a read-only
> property, or simply a function (function IsRTLMultiThreaded: boolean;)
> or something, not just a global read-write variable - that's just
> sloppy!

You know the answer, Graeme...

But I agree that this could be done better. Keep the IsMultiThread
variable for Delphi compatibility, but use a private variable for the
real stuff and set the Delphi compatible one together with the real one
internally.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

> On 25 March 2011 23:08, Mattias Gaertner <nc-gaertnma@net****> wrote:
> >
> > The scan uses multi threading, which was broken by the installed
> > package.
>
> I was reading the thread and replying before I read the whole thread.
> Indeed that installed package did do something it was not supposed to
> do.
>
> In all fairness, how are all developers supposed to know that?

If you don't know the purpose of a variable, why change it?
The documentation and comment do not say that you should set it.

> Isn't
> there a better way that FPC could hide such functionality (not
> allowing a developer to set a RTL controlled variable they are not
> supposed do). That should really be filed as a bug against FPC. They
> [fpc] should rather use some singleton class with a read-only
> property, or simply a function (function IsRTLMultiThreaded: boolean;)
> or something, not just a global read-write variable - that's just
> sloppy!

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 25 March 2011 23:55, Mattias Gaertner <nc-gaertnma@****> wrote:
>
> If you don't know the purpose of a variable, why change it?

Well you know programmers, especially 'newbie' ones... They sometimes
do just as dumb things as end-users. ;-)

> The documentation and comment do not say that you should set it.

I haven't checked the documentation, but does it also say you
shouldn't set it. :)

> AFAIK when writing your own thread manager you must set it.

Still no excuse for a global variable. Simply registering that thread
manager with some RTL class could automatically return True if the
function IsRTLMultiThreaded(): boolean is called. Global variables are
renowned for being "unsafe" and so 80's style of developing...
improved alternative do exist now.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 25 March 2011 23:36, Sven Barth <[hidden email]> wrote:
>
> You know the answer, Graeme...
>
> But I agree that this could be done better. Keep the IsMultiThread variable
> for Delphi compatibility,

And if Delphi jumps off a cliff so will all FPC developers? Well, I will NOT.

While we can't help for the Delphi developers being stupid, we could
try and learn from their mistakes and make FPC better! I'm pretty sure
many here would agree, that we all choose to use FPC with the hopes
that it is BETTER than Delphi, not just a damn second rated clone
(always being one step behind Delphi).

There are many new designs and improved programming styles or design
patterns that reduce (or totally eliminate) the need for such unsafe
global variable usage.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

> On 25 March 2011 23:55, Mattias Gaertner <nc-gaertnma@****> wrote:
> >
> > If you don't know the purpose of a variable, why change it?
>
> Well you know programmers, especially 'newbie' ones... They sometimes
> do just as dumb things as end-users. ;-)

Yes, but this is no reason to make the RTL child safe. It's a tool not
a toy.

> > The documentation and comment do not say that you should set it.
>
> I haven't checked the documentation, but does it also say you
> shouldn't set it. :)

I think the better question is: Has he read some documentation? And if
yes, which one make him believe to set it.

> > AFAIK when writing your own thread manager you must set it.
>
> Still no excuse for a global variable. Simply registering that thread
> manager with some RTL class could automatically return True if the
> function IsRTLMultiThreaded(): boolean is called. Global variables are
> renowned for being "unsafe" and so 80's style of developing...
> improved alternative do exist now.

lol.
Changing a time critical variable to a function just to prevent
vandalism by newbies. For a moment I really thought you were serious. :)

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 03/26/2011 12:28 PM, Mattias Gaertner wrote:

> On Sat, 26 Mar 2011 11:06:48 +0200
> Graeme Geldenhuys<[hidden email]> wrote:
>
>> On 25 March 2011 23:55, Mattias Gaertner<nc-gaertnma@****> wrote:
>>> If you don't know the purpose of a variable, why change it?
>> Well you know programmers, especially 'newbie' ones... They sometimes
>> do just as dumb things as end-users. ;-)
> Yes, but this is no reason to make the RTL child safe. It's a tool not
> a toy.
>
>
>>> The documentation and comment do not say that you should set it.
>> I haven't checked the documentation, but does it also say you
>> shouldn't set it. :)
> I think the better question is: Has he read some documentation? And if
> yes, which one make him believe to set it.
>
>
>>> AFAIK when writing your own thread manager you must set it.
>> Still no excuse for a global variable. Simply registering that thread
>> manager with some RTL class could automatically return True if the
>> function IsRTLMultiThreaded(): boolean is called. Global variables are
>> renowned for being "unsafe" and so 80's style of developing...
>> improved alternative do exist now.
> lol.
> Changing a time critical variable to a function just to prevent
> vandalism by newbies. For a moment I really thought you were serious. :)

I have to partially agree with Graeme on this point, especially that
this package was ported from Delphi. The symptoms were on the surface
unrelated to the cause. I had to debug for quite a while until I
stumbled upon the culprit IsMultiThread assignment buried deep within
10-15 units. A compile time 'read only' error would have saved me a lot
of grief.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

>[...]
> >>> AFAIK when writing your own thread manager you must set it.
> >> Still no excuse for a global variable. Simply registering that thread
> >> manager with some RTL class could automatically return True if the
> >> function IsRTLMultiThreaded(): boolean is called. Global variables are
> >> renowned for being "unsafe" and so 80's style of developing...
> >> improved alternative do exist now.
> > lol.
> > Changing a time critical variable to a function just to prevent
> > vandalism by newbies. For a moment I really thought you were serious. :)
> I have to partially agree with Graeme on this point, especially that
> this package was ported from Delphi. The symptoms were on the surface
> unrelated to the cause. I had to debug for quite a while until I
> stumbled upon the culprit IsMultiThread assignment buried deep within
> 10-15 units. A compile time 'read only' error would have saved me a lot
> of grief.

The joke was to use a function.
A read only property would be nice and a separate procedure to set it.
But I don't know if this is compatible. A function is not compatible
too.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 03/26/2011 12:55 PM, Mattias Gaertner wrote:

> On Sat, 26 Mar 2011 12:43:58 +0200
> patspiper<[hidden email]> wrote:
>
>> [...]
>>>>> AFAIK when writing your own thread manager you must set it.
>>>> Still no excuse for a global variable. Simply registering that thread
>>>> manager with some RTL class could automatically return True if the
>>>> function IsRTLMultiThreaded(): boolean is called. Global variables are
>>>> renowned for being "unsafe" and so 80's style of developing...
>>>> improved alternative do exist now.
>>> lol.
>>> Changing a time critical variable to a function just to prevent
>>> vandalism by newbies. For a moment I really thought you were serious. :)
>> I have to partially agree with Graeme on this point, especially that
>> this package was ported from Delphi. The symptoms were on the surface
>> unrelated to the cause. I had to debug for quite a while until I
>> stumbled upon the culprit IsMultiThread assignment buried deep within
>> 10-15 units. A compile time 'read only' error would have saved me a lot
>> of grief.
> The joke was to use a function.

I was inprecise when I mentioned 'this point'. I was alluding to the
very early posts in this thread, and in particular the read only issue.
My bad.
> A read only property would be nice and a separate procedure to set it.
> But I don't know if this is compatible.
Too bad. It could save others a lot of frustration.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 26 March 2011 12:55, Mattias Gaertner <nc-gaertnma@net****> wrote:
>
> The joke was to use a function.

And my point was that anything (not necessarily a function) is better
that a global read-write variable that could cause something as
serious an an application crash.

> A read only property would be nice and a separate procedure to set it.

Exactly what I was trying to get across.

> But I don't know if this is compatible.

Compatible with what? In the event that somebody implements a new
Thread Manager? And how often does that really happen? If you mean
being able to query the RTL to see if Multii-threading is enabled,
then simply being able to read a property or function that returns a
boolean is perfectly compatible with a boolean global variable.

Re: [Lazarus] Rescan FPC sources crashes Lazarus

On 26 March 2011 12:43, patspiper wrote:
> A compile time 'read only' error would have saved me a lot of grief.

And not to mention that debugging global variables are notoriously
hard. Yes MSEide supports the ability to notify the developer if
something like a global variable changes, but I believe Lazarus IDE
doesn't.