On 05/26/2014 05:02 PM, Dmitry Boyarintsev wrote:
Using a threading for GUI control is generally bad idea. Most of
standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their
functions - do not use in multiple threads. Introducing threads to
handle GUI is potentially dangerous (due
On 05/26/2014 06:49 PM, Dmitry Boyarintsev wrote:
My fear here is that anonymous functions will be misused dramatically
once being available.
Very valid point !
This also holds for parallel loops (my current favorite encapsulation
for OpenMP or similar libraries): Users _will_ try to do GUI
On 05/26/2014 08:17 PM, Sven Barth wrote:
The former is already required out of Delphi compatibility while
TEpikTimer is not.
(For the record: I do hate this argument. Especially regarding the
latest moves of Delphi getting more and more incompatible to itself. fpc
can easily be both more
On 05/27/2014 06:45 AM, Graeme Geldenhuys wrote:
I also told Michael S. that if he does submit a patch to the FPC team (I
can't stop him), make sure it has a different name, so as not to
conflict with the official EpikTimer component.
In fact I do want the best possible stuff and not a fork. I
On Wed, 28 May 2014, Michael Schnell wrote:
On 05/26/2014 08:17 PM, Sven Barth wrote:
The former is already required out of Delphi compatibility while
TEpikTimer is not.
(For the record: I do hate this argument. Especially regarding the latest
moves of Delphi getting more and more
On 05/26/2014 01:29 PM, Graeme Geldenhuys wrote:
Plus EpikTimer (as a project) contains more than just a single .pas
unit. It has Lazarus package files, demos etc - those don't belong in
the FPC repository, and will only fragment tho EpikTimer codebase.
Which is really great !
But how to
On 05/26/2014 09:47 PM, fredvs wrote:
Hum, checksynchronize(), i do not realy understand how to use in the
thread/loop...
I am working on an ActiveNoUIi widget type to be usable with Lazarus.
Here you can use normal Lazarus compatible TTimers.
This already works nicely for me (Linux X86 32
On Wed, 28 May 2014 10:35:47 +0200
Michael Schnell mschn...@lumino.de wrote:
But how to decently provide a fully released version of EpikTimer to not
Lazarus enabled users of fpc ?
https://github.com/graemeg/epiktimer/releases
Download. Extract. Copy needed file(s). Profit.
Where is the
In fact I do want the best possible stuff and not a fork. I am just
trying to help (as I would like to use it in the said current project).
In that case some attention points:
- help implementing and testing fine grained timings on *nix. Now it only has a
special
case for linux.
- Seems
On 05/28/2014 01:47 PM, Reimar Grabowski wrote:
Where is the f** problem?
Supposedly none (as I already stated in the Lazarus list).
Thanks !
-Michael
(What I'd like to prevent is that here again the award for the best way
to avoid ubiquitous usage of community based code is close at
On 05/28/2014 02:00 PM, Marco van de Voort wrote:
In that case some attention points:
- help implementing and testing fine grained timings on *nix. Now it only has a
special
case for linux.
- Seems high precision is not used on anything but x86.
- Is rdtsc safe for CPUs that can vary clock
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
In fact I do want the best possible stuff and not a fork. I am just
trying to help (as I would like to use it in the said current project).
In that case some attention points:
- help implementing and testing fine grained
On 05/28/2014 04:26 PM, Henry Vermaak wrote:
- The rdtsc instruction needs to be protected from out of order
execution. Some people use cpuid, which is expensive. It looks like
the linux kernel uses mfence or lfence/mfence depending on CPU type.
... meaning the current version of
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
- Is rdtsc safe for CPUs that can vary clock of cores independently like
Core Mono? What if the process changed CPU to a different clocked core?
I've read that on recent CPUs, the TSC is unaffected by the actual clock
rate
In our previous episode, Henry Vermaak said:
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
- Is rdtsc safe for CPUs that can vary clock of cores independently like
Core Mono? What if the process changed CPU to a different clocked core?
I've read that on recent
On Wed, May 28, 2014 at 05:41:08PM +0200, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
On linux, The TSC gets calibrated and the synchronisation is tested, which
may result in the TSC clock source being marked as unstable and disabled.
In this case, it will fall
On Wed, May 28, 2014 at 04:31:53PM +0200, Michael Schnell wrote:
On 05/28/2014 04:26 PM, Henry Vermaak wrote:
- The rdtsc instruction needs to be protected from out of order
execution. Some people use cpuid, which is expensive. It looks like
the linux kernel uses mfence or
In our previous episode, Marco van de Voort said:
still to new a requirement to assume for general purpose code like RTL and
FCL, if you agree to clip real old stuff.
_EVEN_ if you agree to clip real old stuff (read: anything Pre core2 intel
like Pentium D and Core duo)
18 matches
Mail list logo
