EpikTimer v1.0.1 released

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

EpikTimer v1.0.1 released

Graeme Geldenhuys-6
Hi,

I've spoken to Tom and he agreed. We moved the EpikTimer repository to
Github. The Lazarus-CCR version will be deleted by Tom in due time.

I applied some of my changes to code in Github (more changes recently
discussed in this mailing list will follow soon), fixed the "etdemo"
project to be compilable again, updated the demo to use FPC Resources
instead of the old *.lrs files.

I've also bumped the version number and created a new release. Hopefully
this will resolve the issue about people downloading the 2006 old
archive version.

I've also updated the Free Pascal Wiki page with the latest information.

Wiki Page:
  http://wiki.freepascal.org/EpikTimer

Source code:
  git clone https://github.com/graemeg/epiktimer.git

Release downloads:
  https://github.com/graemeg/epiktimer/releases


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
On 05/24/2014 01:55 PM, Graeme Geldenhuys wrote:
> I've spoken to Tom and he agreed. We moved the EpikTimer repository to
> Github. The Lazarus-CCR version will be deleted by Tom in due time.
>
While I am happy about your move to do an "official release of
EpikTimer. I'd like to add that IMHO it would be appropriate to have the
file "epiktimer.pas" that is independent of Lazarus and makes sense to
be use in not Lazarus based projects in the fpc RTL svn.

I did not check the latest release, yet, but I suppose there are some
more files (that allow for "visible" placing of a TEpikTimer Instance on
a form). Same should come as a Lazarus package.

Thanks for your work,
-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Reinier Olislagers
On 26/05/2014 11:14, Michael Schnell wrote:
> While I am happy about your move to do an "official release of
> EpikTimer. I'd like to add that IMHO it would be appropriate to have the
> file "epiktimer.pas" that is independent of Lazarus and makes sense to
> be use in not Lazarus based projects in the fpc RTL svn.

I don't understand exactly what you are trying to say. Is this:
- a request to Graeme
- a promise that you are going to provide a patch to the FPC RTL
- a remark
- something else

Thanks,
Reinier

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
>
> I don't understand exactly what you are trying to say. Is this:
> - a request to Graeme
> - a promise that you are going to provide a patch to the FPC RTL
> - a remark
> - something else
Sorry for being unclear.

I meant this as a general request to the "powers" of the fpc (rtl)
project with svn write access to allow Greame, Tom (or maybe myself) to
include the TEpikTimer class  in the next release of the official RTL.
(And maybe help with doing so)

In the Lazarus Forum I am trying to discuss some improvements in
EpikTimer, I would like to introduce before that move. (I already did
and tested this with the pre-release file that had been provided on
"Lararus CCR").

Thanks for listening,
-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Reinier Olislagers
On 26/05/2014 12:12, Michael Schnell wrote:
> On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
> I meant this as a general request to the "powers" of the fpc (rtl)
> project with svn write access to allow Greame, Tom (or maybe myself) to
> include the TEpikTimer class  in the next release of the official RTL.

Well, the normal procedure for doing this is to submit a patch if you
want something to be added to FPC.

If you need help with that, you could put up your modified code on a
public repository.

An example is somebody who modified Lazarus to use/create other widgetsets:
https://github.com/x2nie/LiteZarus

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
On 05/26/2014 12:42 PM, Reinier Olislagers wrote:
> Well, the normal procedure for doing this is to submit a patch if you
> want something to be added to FPC.

Thanks for your hints.

As I locally do use svn, I suppose I will be able to do a patch for a
not yet existing file :)

I can't do a patch that will have the file integrated in the make
process, though.

Anyway before doing this I'd like to do some more improvements and
tests. (including trying to use )

A big

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Reinier Olislagers
On 05/26/2014 12:42 PM, Reinier Olislagers wrote:
> Well, the normal procedure for doing this is to submit a patch if you
> want something to be added to FPC.

Thanks for your hints.

As I locally do use svn, I suppose I will be able to do a patch for a
not yet existing file :)

I can't do a patch that will have the file integrated in the make
process, though.

Anyway before doing this I'd like to do some more improvements and tests
(including trying to use vDSO).

A big problem with EpikTimer is that is _should_ be decently useful with
all archs and OSes.

This might be a nightmare to test.

-Michael

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Graeme Geldenhuys-6
In reply to this post by Michael Schnell
On 26/05/14 10:14, Michael Schnell wrote:
> file "epiktimer.pas" that is independent of Lazarus and makes sense to
> be use in not Lazarus based projects in the fpc RTL svn.

As I mentioned in the Lazarus mailing list. I don't believe everything
should always be dumped in the FPC repository. It adds the extra burden
for the FPC team to maintain it, makes it harder for the general public
to make/commit changes, others to experiment with new ideas etc. 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.

Of course you are welcome to submit a patch to the FPC team (I can't
stop you), but please change the name so as not to conflict with the
official EpikTimer component.

Regards,
  Graeme



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Tomas Hajny-2
In reply to this post by Michael Schnell
On Mon, May 26, 2014 13:12, Michael Schnell wrote:
 .
 .
> A big problem with EpikTimer is that is _should_ be decently useful with
> all archs and OSes.
>
> This might be a nightmare to test.

You don't need to do that - the new addition may be enabled selectively
for the CPU+OS combinations for which it has been already tested
successfully (and this approach is preferred over enabling it for
everything after testing just a small subset of all targets supported by
FPC). Additional targets would then get enabled later by the individual
target maintainers as appropriate.

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Sven Barth-2
In reply to this post by Michael Schnell

Am 26.05.2014 12:12 schrieb "Michael Schnell" <[hidden email]>:
>
> On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
>>
>>
>> I don't understand exactly what you are trying to say. Is this:
>> - a request to Graeme
>> - a promise that you are going to provide a patch to the FPC RTL
>> - a remark
>> - something else
>
> Sorry for being unclear.
>
> I meant this as a general request to the "powers" of the fpc (rtl) project with svn write access to allow Greame, Tom (or maybe myself) to include the TEpikTimer class  in the next release of the official RTL. (And maybe help with doing so)

I don't see a need for this in the FCL yet. At least not until the dust that you are whirling up has settled down as FPC has a quite slow release cycle.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Tomas Hajny-2
On 05/26/2014 02:06 PM, Tomas Hajny wrote:
> You don't need to do that - the new addition may be enabled
> selectively for the CPU+OS combinations for which it has been already
> tested successfully (and this approach is preferred over enabling it
> for everything after testing just a small subset of all targets
> supported by FPC). Additional targets would then get enabled later by
> the individual target maintainers as appropriate.

In fact I would like to use EpikTimer in my upcoming "ActiveNoGUI"
Lazarus WidgetType. "ActiveNoGUI" is especially useful with small
Gadgets that typically don't have X32 or X64 archs.

That is why I am after multi-arch support.

And that is why I feel that it makes sense to use EpikTimer in
"ActiveNoGUI" instead of directly including the timer related code. With
EpicTimer the "ActiveNoGUI" implementation itself would be automatically
arch and OS independent.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Sven Barth-2
On 05/26/2014 02:23 PM, Sven Barth wrote:
>
> I don't see a need for this in the FCL yet. At least not until the
> dust that you are whirling up has settled down as FPC has a quite slow
> release cycle.
>

I absolutely agree.

Nonetheless I feel that (a decently multi-arch enabled version) of
TEpikTimer does make sense in the FCL as a courtesy class  (in fact
TList is a "courtesy class" as well, as it does not support syntax candy
but just is provided directly for the user to use). Especially as the
multi-arch support of EpikTimer is really critical and it would be very
helpful to know that this issue  is managed by the fpc team.

Hence including it in the svn seems nice to me, especially regarding
that I'd like to use it in a Lazarus enhancement.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Sven Barth-2
On 26.05.2014 15:07, Michael Schnell wrote:

> On 05/26/2014 02:23 PM, Sven Barth wrote:
>>
>> I don't see a need for this in the FCL yet. At least not until the
>> dust that you are whirling up has settled down as FPC has a quite slow
>> release cycle.
>>
>
> I absolutely agree.
>
> Nonetheless I feel that (a decently multi-arch enabled version) of
> TEpikTimer does make sense in the FCL as a courtesy class  (in fact
> TList is a "courtesy class" as well, as it does not support syntax candy
> but just is provided directly for the user to use).

TList and TEpikTimer are two completely different things. The former is
already required out of Delphi compatibility while TEpikTimer is not.
Additionally container structures can be considered essential for
basically every software while a timing component is not...

> Especially as the
> multi-arch support of EpikTimer is really critical and it would be very
> helpful to know that this issue  is managed by the fpc team.

And you don't think we FPC developers have enough to do with the
remaining RTL and FCL on all those platforms we support?

>
> Hence including it in the svn seems nice to me, especially regarding
> that I'd like to use it in a Lazarus enhancement.

Then let it be put in Lazarus in components/epiktimer ... Lazarus
releases more often than FPC does.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Graeme Geldenhuys-6
Hi Sven,

You raised all the points which I already mentioned to Michael Schnell -
why I think EpikTimer should NOT be in the FCL.

 * FPC has too a slow release cycle
 * No need to burden the FPC team with supporting yet another component
 * It will reduce the possibility for experimentation and easy
   contributions from others.
 * EpikTimer contains more than just a single unit. The other files
   don't belong in FPC. So why fragment the project's source code.

I'm perfectly happy where EpikTimer is now. If anybody wants to use it
in a project, download and use it. If anybody wants to contribute, then
send a pull request or patches.

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.

Just my 2c worth.

Regards,
  Graeme


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Sven Barth-2
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 "stringent", more versatile and more platform
independent.)


> Additionally container structures can be considered essential for
> basically every software while a timing component is not...
(For the record: I do hate this argument. fpc (and even Delphi) can very
decently be used for embedded software and much more non-Desktop or
"special Desktop" (e.g. Gaming) purposes.)

>
> And you don't think we FPC developers have enough to do with the
> remaining RTL and FCL on all those platforms we support?
Of course you are right. I did not want to push anybody. I just see that
here the best possible multi-platform support is provided.
>
> Then let it be put in Lazarus in components/epiktimer ... Lazarus
> releases more often than FPC does.
>
Hmm.
While I personally in fact would like to _use_ it for a Lazarus
enhancement, I would be happy to see it usable without Lazarus.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
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 am just
trying to help (as I would like to use it in the said current project).
I of course would discuss any enhancements with the original creators
and am not at all inclined to break anything. .

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
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 decently provide a fully released version of EpikTimer to not
Lazarus enabled users of fpc ?

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Michael Van Canneyt
In reply to this post by Michael Schnell


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 incompatible to itself. fpc can easily
> be both more "stringent", more versatile and more platform independent.)
>
>
>> Additionally container structures can be considered essential for basically
>> every software while a timing component is not...
> (For the record: I do hate this argument. fpc (and even Delphi) can very
> decently be used for embedded software and much more non-Desktop or "special
> Desktop" (e.g. Gaming) purposes.)

It is not about environments for running programs.
The classes are on a completely different level.

Lists (and containers) are general purpose, almost language-level constructs.
Timers simply are not. They may be important to you, no argument there.

>> And you don't think we FPC developers have enough to do with the remaining
>> RTL and FCL on all those platforms we support?
> Of course you are right. I did not want to push anybody. I just see that here
> the best possible multi-platform support is provided.
>>
>> Then let it be put in Lazarus in components/epiktimer ... Lazarus releases
>> more often than FPC does.
>>
> Hmm.
> While I personally in fact would like to _use_ it for a Lazarus enhancement,
> I would be happy to see it usable without Lazarus.

It's just a source file. You cownload and compile at will.

Putting it in FPC means it puts an additional burden on FPC devs,  however you turn it.
This is a hobby project, still, so we put in what we feel is useful and can be maintained.
None seems willing to take it on, but you can stil download and compile at will.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Reimar Grabowski
In reply to this post by Michael Schnell
On Wed, 28 May 2014 10:35:47 +0200
Michael Schnell <[hidden email]> 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 f****** problem?

R.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: EpikTimer v1.0.1 released

Marco van de Voort
In reply to this post by Michael Schnell
> 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 high precision is not used on anything but x86.
- 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?


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12