On Sat, Mar 26, 2011 at 09:47:24PM +0100, Sven Barth wrote:
cannot replace a variable, see var parameter problem or assembler code.
What about the following solution:
* add a variable in the implementation section of system.pp that will be
the real workhorse for should the RTL be
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
On 25 March 2011 23:36, Sven Barth pascaldra...@googlemail.com 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
Graeme Geldenhuys schrieb:
[fpc] should rather use some singleton class with a read-only
property,
A class is not required, FPC supports unit-level properties as well :-)
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 26 March 2011 11:15, Hans-Peter Diettrich DrDiettrich1@ wrote:
A class is not required, FPC supports unit-level properties as well :-)
True, though that is a language feature I have never seen used by
anybody in the wild. :)
--
Regards,
- Graeme -
On Sat, 26 Mar 2011 11:06:48 +0200
Graeme Geldenhuys graemeg.li...@gmail.com 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
On 03/26/2011 12:28 PM, Mattias Gaertner wrote:
On Sat, 26 Mar 2011 11:06:48 +0200
Graeme Geldenhuysgraemeg.li...@gmail.com wrote:
On 25 March 2011 23:55, Mattias Gaertnernc-gaertnma@ wrote:
If you don't know the purpose of a variable, why change it?
Well you know programmers,
On Sat, 26 Mar 2011 12:43:58 +0200
patspiper patspi...@gmail.com 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
On 03/26/2011 12:55 PM, Mattias Gaertner wrote:
On Sat, 26 Mar 2011 12:43:58 +0200
patspiperpatspi...@gmail.com 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
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
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
Graeme Geldenhuys schrieb:
On 26 March 2011 11:15, Hans-Peter Diettrich DrDiettrich1@ wrote:
A class is not required, FPC supports unit-level properties as well :-)
True, though that is a language feature I have never seen used by
anybody in the wild. :)
I used it several times, just
On Fri, Mar 25, 2011 at 11:19:48PM +0200, Graeme Geldenhuys wrote:
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
On Sat, Mar 26, 2011 at 11:12:18AM +0200, Graeme Geldenhuys 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.
On Sat, Mar 26, 2011 at 11:55:28AM +0100, Mattias Gaertner wrote:
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
On Sat, Mar 26, 2011 at 11:36:26AM +0200, Graeme Geldenhuys wrote:
A class is not required, FPC supports unit-level properties as well :-)
True, though that is a language feature I have never seen used by
anybody in the wild. :)
They apparantly you don't use unices. Since errno and cerrno
Am 26.03.2011 10:15, schrieb Hans-Peter Diettrich:
Graeme Geldenhuys schrieb:
[fpc] should rather use some singleton class with a read-only
property,
A class is not required, FPC supports unit-level properties as well :-)
True, but the issue with them is: you cannot use them to create a
On 26 March 2011 16:22, Marco van de Voort marcov@*** wrote:
We will probably jump of the cliff.
Wow, you are really sad!
The trouble is that you always tend to focus on the tiniest little detail
And setting a value of a global variable allows an application to
crash... Oh that's
Florian Klaempfl schrieb:
A class is not required, FPC supports unit-level properties as well :-)
True, but the issue with them is: you cannot use them to create a fool
proof read-only property without using a function because there is no
unit level encapsulation aka private/protected on
Am 26.03.2011 19:36, schrieb Hans-Peter Diettrich:
Making IsMultiThreaded a function is a no-no: it is used in really
speed critical code paths and using an inline function neither because
it's used mostly in assembler code
Simple solution: the variable continues to exist, under a different
On 26.03.2011 20:07, Florian Klämpfl wrote:
Am 26.03.2011 19:36, schrieb Hans-Peter Diettrich:
Making IsMultiThreaded a function is a no-no: it is used in really
speed critical code paths and using an inline function neither because
it's used mostly in assembler code
Simple solution: the
On 26.03.2011 22:01, Mattias Gaertner wrote:
On Sat, 26 Mar 2011 21:47:24 +0100
Sven Barthpascaldra...@googlemail.com wrote:
On 26.03.2011 20:07, Florian Klämpfl wrote:
Am 26.03.2011 19:36, schrieb Hans-Peter Diettrich:
Making IsMultiThreaded a function is a no-no: it is used in really
Florian Klämpfl schrieb:
Simple solution: the variable continues to exist, under a different
name. The property only implements Delphi compatibility :-)
Possible, but I fear this is also only half of a solution: a property
cannot replace a variable, see var parameter problem or assembler
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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
2011/3/25 patspiper patspi...@gmail.com:
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
On Fri, 25 Mar 2011 17:42:51 +0200
patspiper patspi...@gmail.com 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?
On 03/25/2011 07:40 PM, Mattias Gaertner wrote:
On Fri, 25 Mar 2011 17:42:51 +0200
patspiperpatspi...@gmail.com 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
On Fri, 25 Mar 2011 20:51:40 +0200
patspiper patspi...@gmail.com wrote:
On 03/25/2011 07:40 PM, Mattias Gaertner wrote:
On Fri, 25 Mar 2011 17:42:51 +0200
patspiperpatspi...@gmail.com wrote:
Hi,
Clicking on Tools/Rescan FPC sources crashes the IDE. However, this is
not the case if
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
On Fri, 25 Mar 2011 22:57:43 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
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
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
On 25.03.2011 22:19, Graeme Geldenhuys wrote:
On 25 March 2011 23:08, Mattias Gaertnernc-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
32 matches
Mail list logo