On 2014-05-20 04:44, Tom Lisjac wrote:
>>
>> Maybe EpikTimer should move to the Git repo of Lazarus-CCR so others
>> could easily clone and share their feature branches (say via Github).
>>
>>
> Fully agree... great idea!
I'll let you take care of that then I don't have access to create a
new
> Tom and I would welcome patches for EpikTimer.
>
> Maybe EpikTimer should move to the Git repo of Lazarus-CCR so others
> could easily clone and share their feature branches (say via Github).
>
>
Fully agree... great idea!
-Tom
>
> --
> ___
> Lazarus
On 2014-05-19 18:54, Graeme Geldenhuys wrote:
> On 2014-05-19 11:03, Michael Schnell wrote:
>> Obviously I can't _use_ EpricTimer there, as it uses (IMHO
>> inappropriately) (graphics-) stuff that is not implemented in a non-GUI
>> project.
>
> You are clearly using a very outdated version. That
On 2014-05-19 09:03, Michael Schnell wrote:
> On 05/18/2014 08:10 PM, Graeme Geldenhuys wrote:
>> {$IFDEF Windows}
>> begin
>>QueryPerformanceCounter(Result);
> Did you check that this is a low overhead function ?
You are welcome to test yourself. Google Search will show you that that
is the r
On Mon, May 19, 2014 at 11:54 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> On 2014-05-19 11:03, Michael Schnell wrote:
> > Obviously I can't _use_ EpricTimer there, as it uses (IMHO
> > inappropriately) (graphics-) stuff that is not implemented in a non-GUI
> > project.
>
> You
2014-05-19 14:27 GMT-03:00 Junior :
> It seems that Brook was a stolen from another project.
>
> In https://groups.google.com/forum/?hl=pt-BR&fromgroups#!
> topic/lazarus-br/8FQND1qoAd8 (mailing list of the Silvio). There was a
> confusion about the project Brook Framework, and says the project th
On 2014-05-19 11:03, Michael Schnell wrote:
> Obviously I can't _use_ EpricTimer there, as it uses (IMHO
> inappropriately) (graphics-) stuff that is not implemented in a non-GUI
> project.
You are clearly using a very outdated version. That was fixed 2+ years
ago. Get the latest code from SubVe
It seems that Brook was a stolen from another project.
In
https://groups.google.com/forum/?hl=pt-BR&fromgroups#!topic/lazarus-br/8FQND1qoAd8
(mailing list of the Silvio). There was a confusion about the project
Brook Framework, and says the project that was stolen here:
http://www.yanniel.in
On 19/05/2014 14:11, Koenraad Lelong wrote:
> ### TCodeToolManager.HandleException: "unit not found: Classes" at
> Line=26 Col=10 in "/home/koenraad/development/lazarus/lcl/lclclasses.pp"
> TDesigner.InvokeComponentEditor ERROR: Unable to find method. Please fix
> the error shown in the message win
Hi,
I tried fpcup to get a "user" version of lazarus. With that I mean a
version of lazarus where adding packages is more easy than with a
packaged version of lazarus.
But I'm exeriencing a problem.
I ran fpcup and all seems OK, but when I make a simple project, form
with a button, I can't do
On 05/19/2014 10:19 AM, Michael Schnell wrote:
I obviously would like to use an improved version of EpricTimer there ...
Obviously I can't _use_ EpricTimer there, as it uses (IMHO
inappropriately) (graphics-) stuff that is not implemented in a non-GUI
project. So I will need to extract some
On 05/19/2014 11:02 AM, Michael Van Canneyt wrote:
.
function HardwareTicks: TickType; assembler; asm DW 0310FH end;
OK. Found it.
Lets see how to do something arch independent
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepas
On Mon, 19 May 2014, Michael Schnell wrote:
On 05/19/2014 10:19 AM, Michael Van Canneyt wrote:
The register is already used for tick counts.
Please let me know where.
For TTimer in AvtiveNoGu I now use TThread.GetTickCount64 (or
SysUtils.GetTickCount64)-
I did ASM stepping into same an
On Mon, 19 May 2014, Reinier Olislagers wrote:
On 18/05/2014 09:08, Michael Van Canneyt wrote:
On Sat, 17 May 2014, Tom Lisjac wrote:
No mystery here either. You never miss an opportunity to criticize
EpikTimer for reasons I've never been able to understand.
Nevertheless, I have named the
On 05/19/2014 10:19 AM, Michael Van Canneyt wrote:
The register is already used for tick counts.
Please let me know where.
For TTimer in AvtiveNoGu I now use TThread.GetTickCount64 (or
SysUtils.GetTickCount64)-
I did ASM stepping into same and it does a syscall. (Linux X86/32)
-Michael
-
On 18/05/2014 09:08, Michael Van Canneyt wrote:
> On Sat, 17 May 2014, Tom Lisjac wrote:
>> No mystery here either. You never miss an opportunity to criticize
>> EpikTimer for reasons I've never been able to understand.
>
> Nevertheless, I have named the reasons explicitly every time.
>
> It is s
On Mon, 19 May 2014 10:21:44 +0200
Reinier Olislagers wrote:
> Saw this
> r45063
> lhelp: fixed building lhelp under fpc 2.6.4
>
> ---
> branches/fixes_1_2/components/chmhelp/packages/idehelp/lazchmhelp.pas
> 2014/05/17 18:55:25 45062
> +++
> branches/fixes_1_2/components/chmhelp/packages/ideh
Saw this
r45063
lhelp: fixed building lhelp under fpc 2.6.4
---
branches/fixes_1_2/components/chmhelp/packages/idehelp/lazchmhelp.pas
2014/05/17 18:55:25 45062
+++
branches/fixes_1_2/components/chmhelp/packages/idehelp/lazchmhelp.pas
2014/05/17 18:57:08 45063
@@ -283,6 +283,9 @@
// Exi
On 05/19/2014 10:19 AM, Michael Van Canneyt wrote:
But I am eagerly awaiting your vDSO implementation.
Still hoping for Tom ...
But if EpicTimer is not improved I might be willing to test this for
ActiveNoGui.
-Michael
--
___
Lazarus mailing li
On 05/19/2014 09:49 AM, Michael Van Canneyt wrote:
If the result of my continued hammering is that now someone will
actually contribute
improvements,
Similar as with ActiveNoGui :-) :-) :-) .
I obviously would like to use an improved version of EpricTimer there as
a very handy in cross-pla
On Mon, 19 May 2014, Michael Schnell wrote:
On 05/18/2014 09:08 AM, Michael Van Canneyt wrote:
Your component is probably perfectly suited for Intel 32-bit.
(At least) For Linux I doubt this. vDSO or even direct access to the CPU
register (if really possible) seem more appropriate than
On 05/18/2014 09:08 AM, Michael Van Canneyt wrote:
Your component is probably perfectly suited for Intel 32-bit.
(At least) For Linux I doubt this. vDSO or even direct access to the CPU
register (if really possible) seem more appropriate than doing a syscall..
I suppose a version of EpicT
On 05/18/2014 08:10 PM, Graeme Geldenhuys wrote:
{$IFDEF Windows}
begin
QueryPerformanceCounter(Result);
Did you check that this is a low overhead function ?
{$ELSE}
do_syscall(syscall_nr_clock_gettime,TSysParam(CLOCK_MONOTONIC),TSysParam(@ts))
It seems that a syscall is not necessary with
On 05/18/2014 08:10 PM, Graeme Geldenhuys wrote:
And that is exactly what my local copy of EpikTimer does for over a year
alread - just one of many improvements I've made to my copy of
EpikTimer, but sadly never got around to sharing the code (which I'll do
shortly).
Thanks a lot !
If the code
On Sun, 18 May 2014, silvioprog wrote:
http://leonardorame.blogspot.com
Hello Leonardo,
I'm flattered with your comment.
We can add a new file, called "WHATS_NEW.txt", and it can be rewritten in all new
versions, showing "what's new" in this released
version.
What do you think of t
On Sun, 18 May 2014, Graeme Geldenhuys wrote:
On 2014-05-18 00:49, Tom Lisjac wrote:
I'm adding some clarification and context to your ongoing comments about
EpikTimer in this and other threads.
What Michael also keeps forgetting, is that EpikTimer gives a unified
timing interface, which is
26 matches
Mail list logo
