Florian Klaempfl schrieb:
Am 06.09.2010 14:30, schrieb Michael Schnell:
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar).
And? Those variables aren't used very often.
Paul Ishenin schrieb:
Generics need to replay tokens with their position for debugging purposes.
I.e. the tokens have to be stored and replayed with their original
positions. Most probably the current_filepos should not be modified
during replay (in contrast to normal token scanning)?
The
06.09.2010 14:52, Florian Klaempfl wrote:
Am 06.09.2010 05:29, schrieb Hans-Peter Diettrich:
5) Some (parser) procedures modify current_tokenpos/filepos temporarily,
and restore the old values later. What's the purpose of such changes?
To get correct file positions in debugging code and error
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
>
>>> I have no real idea, how in such a model the initialization of the
>>> threadvars has to be implemented. That's why I try to assign all
>>> state-related variables to a definite object, whose reference can be
>>>
Florian Klaempfl schrieb:
I have no real idea, how in such a model the initialization of the
threadvars has to be implemented. That's why I try to assign all
state-related variables to a definite object, whose reference can be
easily copied (or moved?) into any created thread.
In case of curre
Florian Klaempfl schrieb:
So every temporary change of current_tokenpos should be considered
wrong? According to your above description I'd make current_tokenpos a
read-only property of the scanner...
I'am not sure what e.g. generics do with it.
Me 2 :-(
Therefore my questions about the val
Am 06.09.2010 14:30, schrieb Michael Schnell:
>
>> What's the problem with using threadvars
> As discussed some days ago, the current implementation of Threadvars is
> quite slow (doing a libc call on each access to a threadvar).
And? Those variables aren't used very often. And if needed, it can
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar). This
_could_ be improved but I think this only makes sense when removing the
dependency of the RTL to the libc pthre
On Monday 06 September 2010 13:54, Michael Van Canneyt wrote:
> Marco handles the build process for 2.4.2. Since he's waiting for some
> documentation fixes, maybe there is still time; It's a relatively
> innocent fix, little risk of breaking things.
I'm already torturing him on #lazarus-dev irc
On Mon, 6 Sep 2010, zeljko wrote:
On Monday 06 September 2010 13:25, Michael Van Canneyt wrote:
On Mon, 6 Sep 2010, zeljko wrote:
On Monday 06 September 2010 12:20, zeljko wrote:
Hi,
I've created patch & test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be
On Monday 06 September 2010 13:25, Michael Van Canneyt wrote:
> On Mon, 6 Sep 2010, zeljko wrote:
> > On Monday 06 September 2010 12:20, zeljko wrote:
> >> Hi,
> >> I've created patch & test program for long time issue
> >> http://bugs.freepascal.org/view.php?id=13722
> >> Would be nice if someone
On Mon, 6 Sep 2010, zeljko wrote:
On Monday 06 September 2010 12:20, zeljko wrote:
Hi,
I've created patch & test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be nice if someone can review and apply if patch is ok (patch & test
uploaded).
Michael commited :)
On Monday 06 September 2010 12:20, zeljko wrote:
> Hi,
> I've created patch & test program for long time issue
> http://bugs.freepascal.org/view.php?id=13722
> Would be nice if someone can review and apply if patch is ok (patch & test
> uploaded).
Michael commited :) nice ... Is there any way to s
Hi,
I've created patch & test program for long time issue
http://bugs.freepascal.org/view.php?id=13722
Would be nice if someone can review and apply if patch is ok (patch & test
uploaded).
tnx
zeljko
___
fpc-devel maillist - fpc-devel@lists.freepasc
On 6 September 2010 10:27, Henry Vermaak wrote:
>
> The install is crazy, it basically installs a whole mingw/msys system
Replied on fpc-other.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net
Replied on fpc-other.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 5 September 2010 18:36, Florian Klämpfl wrote:
> Am 05.09.2010 19:04, schrieb Graeme Geldenhuys:
>> but rather features and
>
> Indeed. And the features of git gui are just ridiculous. It misses even
> basic stuff like good explorer integration.
>
>> usability.
>
> Yes, unfortunatly, git gui is
On 6 September 2010 10:04, Florian Klaempfl wrote:
>
> Yes, I forgot that you don't like easy to use software.
I'm using FPC and Lazarus, aren't I? ;-)
> Oh really? Strangly enough other software works fine on my system :)
Nothing strange really. Windows behaviour is so random, nobody can
pre
Am 06.09.2010 09:47, schrieb Graeme Geldenhuys:
> On 5 September 2010 19:36, Florian Klämpfl wrote:
>>
>> Indeed. And the features of git gui are just ridiculous. It misses even
>> basic stuff like good explorer integration.
>
> That's a matter of opinion I guess. I much prefer stand-alone tools,
On 5 September 2010 19:36, Florian Klämpfl wrote:
>
> Indeed. And the features of git gui are just ridiculous. It misses even
> basic stuff like good explorer integration.
That's a matter of opinion I guess. I much prefer stand-alone tools,
so I think they hit the nail on the head. I hate shell or
Am 06.09.2010 05:22, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>>> Right, that's how it *should* be designed. But try to find out why the
>>> code generation is added, when variables like current_filepos or
>>> current_tokenpos are moved into TModule (current_module) :-(
>>
>> Why
21 matches
Mail list logo
