On 06/26/2014 01:47 PM, Mattias Gaertner wrote:
I can rephrase it:
The LCL Application.QueueAsyncCalls can be called by any thread, and
executes the calls, when the main thread calls
Application.ProcessMessages. Therefore the calls are executed by the
main thread.
Of course I do know this. But
On 06/26/2014 02:41 PM, Sven Barth wrote:
Did you even look at the interface of TThread? There's a protected
instance function that calls a public class function with Self as
first parameter. If you use the second one and pass Nil as first
parameter it automatically uses the current thread.
On 06/26/2014 02:52 PM, Mattias Gaertner wrote:
On Thu, 26 Jun 2014 14:06:15 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Of course I do know this.
Make up your mind. Either I'm Not true at all or I wrote something
right.
Not true was, that my implementation
On 06/26/2014 03:54 PM, Mattias Gaertner wrote:
Application.ProcessMessages calls CheckSynchronize and calls the
queued async calls. Under nogui that's all.
Here the waiting and sleeping mechanism is lacking.
Application.ProcessMessages supposedly calls CheckSynchronize with the
Timeout set
On 06/24/2014 09:30 AM, Giuliano Colla wrote:
Widget Types are LCL related. It's the part which actually implements
virtual abstract methods in the Interfaces unit.
Yep.
So it seems perfectly suitable to individually define the functionality
of classes that share a common name.
I'm
On 06/23/2014 02:47 PM, Mattias Gaertner wrote:
. Therefore the nogui widget only needs a decent TTimer, preferably
with no extra dependencies like EpikTimer and no calibration.
I added some {$ifdefs} so that my code does not depend on any EpikTimer
related stuff.
Instead it then uses
On 06/25/2014 04:00 PM, Mattias Gaertner wrote:
'Runtime-packages' means something different:
http://wiki.freepascal.org/Lazarus_Packages#Design_Time_vs_Run_Time_package
I see.
Thanks for the Clarification.
I seem to remember that with Delphi the Term RuntimPackage had been used
the way I
On 06/25/2014 04:04 PM, Mattias Gaertner wrote:
Instead it then uses TThread.GetTickCount64. Do you think that is
appropriate at this point in time ?
Yes.
I just checked and found that with fpc vertsion 2.6.0-9, which is the
version I installed as a Debian Package for X86-64) TThread does
On 06/25/2014 05:14 PM, Sven Barth wrote:
The TThread extensions are only part of FPC 2.7.1.
Is it decent do base a Lazarus extension on same ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/23/2014 06:48 PM, Giuliano Colla wrote:
one must add a Mediator, aware of the new widgetset units, etc. But
currently duplicates aren't allowed. Meaning that a different
widgetset cannot contain units or classes with the same name of an LCL
counterpart.
As you never mention this term I
On 06/20/2014 10:11 PM, Chris Kelling wrote:
So the program can look at the port as a RS232 port (coms 1-4).
You could try to use SynaSer or some other library that supports serial
communication.
-Michael
--
___
Lazarus mailing list
On 06/21/2014 12:43 PM, Giuliano Colla wrote:
I'm trying to figure how to face my nonlcl widgetset project.
I don't understand what you mean by nonlcl widgetset project.
In fact I already do have a working draft of my ActiveNoGUI Widget
Type Project.
Here the goal is to provide another
On 06/22/2014 05:29 PM, Mattias Gaertner wrote:
On Sun, 22 Jun 2014 17:24:46 +0200
Giuliano Colla giuliano.co...@fastwebnet.it wrote:
Meaning that an appropriate IDE extension, and a TReader/TWwriter
extension, would one day permit to stream FpGui components which are
found not in a separate
On 05/28/2014 11:31 AM, hinsta...@yandex.ru wrote:
Why you need an example?
I am not doing a program but a tool, that maybe might become integrated
in Lazarus. Hence the code should be decently tested and verified to be
as good (low latency) as it gets for any architecture.
-Michael
--
On 06/23/2014 10:48 AM, Mattias Gaertner wrote:
This is definitely one of your worst hijacking.
Sorry this was not my intention (but just trying to be helpful). :-(
Am I wrong understanding that this thread is about creating a new Widget
Type (or something with a similar target) for Lazarus
On 06/23/2014 10:48 AM, Reinier Olislagers wrote:
You mean on a DataModule? I don't really understand the question...
(@Mattias: sorry if this is off-topic here.)
Imagine a new Widget Type (and Application) that does not provide any
GUI but (other than the current not GUI based Lazarus
On 06/23/2014 11:28 AM, Reinier Olislagers wrote:
Yes, what about a DataModule?
Of course a DataModule would do. But here I would need to make the IDE
automatically create a DataMoule as a would-be MainForm. No Idea if
this is possible/sensible/appropriate.
I suppose that is how the
On 06/23/2014 11:43 AM, Mattias Gaertner wrote:
If you implement the TTimer backend, then it will work.
I suppose additionally to the run-time code for TTimer I would need some
design-time code (or at lease parameters) and appropriate streaming
code for my new TTimer class.
-Michael
--
On 06/23/2014 11:41 AM, Mattias Gaertner wrote:
Why not put this in the existing nogui widgetset?
Maybe his in fact is a good idea.
I did not dare to suggest this, because I always in great fear to break
something, as I am not at all an expert with the Lazarus / LCL internals.
What is the
On 06/23/2014 10:54 AM, Mattias Gaertner wrote:
What do you mean with pseudo form?
A thingy supposedly working like TDataModule, that the IDE is able to
use as MainForm.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/23/2014 12:01 PM, Mattias Gaertner wrote:
So your nogui widgetset has that already.
I'll take a look...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 06/23/2014 11:58 AM, Mattias Gaertner wrote:
You can register a new project type that does that.
I'll try to fond out how to do that.
(That means that the Widget Type (i.e. the code that is $ifdef'ed by
the appropriate setting of the WidgetType variable) and the IDE code
itself does not
On 06/23/2014 11:41 AM, Mattias Gaertner wrote:
You instead promoted a LCL compatible non GUI.
I did not want to promote anything, but just to check if something I
already have could help or if I might benefit from something that might
be the outcome of this project.
-Michael
--
On 06/23/2014 11:48 AM, Giuliano Colla wrote:
No, this is about creating new Widget Types which don't use *any* of
the widgets LCL provides.
This is rather exactly the same with my current project (only that there
will not be any widgets in runtime at all either).
In short, LCL philosophy is to
On 06/23/2014 12:37 PM, Mattias Gaertner wrote:
Why does a program without GUI need a form?
Just as a curtsey to the users.
Of course at runtime it does not need a form.
But at design time Lazarus Users are accustomed to place TTimers on a
(would-be) Form instead of creating them in code.
On 06/23/2014 12:45 PM, Mattias Gaertner wrote:
The LCLBase provides some utility functions and an UTF-8 format (lfm)
with nicer error handling. That is all independent of the widgettype.
Sounds great.
-Michael
--
___
Lazarus mailing list
On 06/20/2014 02:15 PM, Lukasz Sokol wrote:
Henry just corrected me : that's not what this function is for: it's
to select int 0x80 vs sysenter... and I remember seeing somewhere on
lkml (long time ago) that 64bit x86 don't need it, (either they both
are equivalent or int 0x80 doesn't exist
On 06/23/2014 12:37 PM, Mattias Gaertner wrote:
Are you sure you need Epiktimer and hardware ticks for TTimer? That
sounds like overkill.
Using a hardware timer in user-space yields the lowest possible overhead
(preventing unnecessary user-space/system-space mode-switches).
If user space
On 06/23/2014 01:19 PM, Giuliano Colla wrote:
My plans are to rewrite the code,
Both the runtime code and a ind of GUI designer ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/23/2014 02:04 PM, Giuliano Colla wrote:
The first step will be to take care of GUI design. Runtime code will
come later on.
OK.
What is the benefit of providing an alternate GUI designer vs. using the
one that Lazarus offers ?
-Michael
--
On 06/23/2014 02:51 PM, Sven Barth wrote:
Because you'd need to link in that code then.
I don't see the what you mean by this.
vDSO is not really linked. In an initialization phase, the static
address of such a function is detected and when you want to call it, you
just do an indirect call.
On 06/23/2014 02:47 PM, Mattias Gaertner wrote:
preferably with no extra dependencies like EpikTimer and no calibration.
I of course do see your point.
With my first test I just wanted to try to find the optimum (lowest
possible overhead, not arch depending) way to do it and came across
On 06/18/2014 04:03 PM, Lukasz Sokol wrote:
I think this vdso time thing is so fresh, it'll be great if you
contact the maintainer (Andy Lutomirski) or the guy that wrote it
(Stefani Seibold)
I wrote to Andy and he replied very quickly.
Unfortunately it seems that ubiquitous availability for
On 06/20/2014 01:38 PM, Lukasz Sokol wrote:
Is it possible to call about any syscall (timing included) through (32bit)
exising vdso ?
I understand that is what __kernel_vsyscall is supplied for (and I
don't understand why it is nit supplied in 64 Bit).
And measure how it goes vs 'normal' way
On 06/20/2014 02:15 PM, Lukasz Sokol wrote:
Having a timer component, however, that can use this, could provide us
application writers to have a way to detectselect what we want, when
it comes to implementation.
IMHO a timer component that uses vdso's clock_gettime would be _very_
On 06/13/2014 04:58 PM, Michael Schnell wrote:
I suppose I need to upgrade before proceeding.
Off-Topic in this list, but maybe you might be able to help
On my PC (with rather old 32 Bit Suse) I installed the current released
version of Debian in Virtual Box. One virtual box machine holding
On 06/18/2014 10:21 AM, Mattias Gaertner wrote:
Stating the obvious: A 64bit Linux is supposed to run 64 bit programs.
Have you installed the 32bit libraries?
Should there not be a more speaking error message ?
No one bothered enough.
Do you suggest the Missing file is a library the 32 bit
On 06/18/2014 10:21 AM, Mattias Gaertner wrote:
Stating the obvious: A 64bit Linux is supposed to run 64 bit programs.
Have you installed the 32bit libraries?
After adding the 32 bit architecture to the package manager and
apt-getting ia32-libs, I get a decent error message about a missing
On 06/18/2014 11:27 AM, Michael Schnell wrote:
Keeping on trying...
In fact I do not need a GUI for this test. So I did a simpler testing
program without using the LCL (Results see the other mail)
-Michael
--
___
Lazarus mailing list
Lazarus
On 06/06/2014 12:25 PM, Michael Van Canneyt wrote:
if you do a vDSO implementation, please do not limit the
implementation to the clock_gettime, but implement all calls that
support it.
First testing results:
On Kernel 3.1.10 (32 bit):
- I do find the vDSO ELF structure (always at
On 06/18/2014 01:24 PM, Henry Vermaak wrote:
This is as documented in the vdso man page. i386 only exports those 3
functions. If your testing program is 32 bit, it won't give you the 64
bit vdso image, obviously.
I do know this. But I in fact hope that the Linux team is going to do
On 06/18/2014 01:31 PM, Lukasz Sokol wrote:
On 18/06/14 11:27, Michael Schnell wrote:
On Kernel 3.2.0 64 bit, using a 32 Bit testing program: - I do find
I guess it's because
http://kernelnewbies.org/Linux_3.15-DriversArch#head-293bf8d606065cc1e6324f65a017e79144467d3f
i.e. explicit time
On 06/18/2014 02:28 PM, Lukasz Sokol wrote:
I *think* what I pasted means, from 3.15 onwards...
maybe someone has a debian repository with such kernel (but I think it'll
require debian sid, i.e. unstable...)
see if any of bit.ly/1l2AyWt may be of any help ?
(long form link :
Checking with a 64 Bit program (after overcoming the shock that with 64
fpc Integer is 32 bit =-O ):
On Kernel 3.2.0 64 bit, using a 64 Bit testing program:
- I do find the vDSO ELF structure at (e.g. at 7FFF5D2C9000, the
location varies for any program start. This behavior is documented
On 06/18/2014 04:03 PM, Lukasz Sokol wrote:
I think this vdso time thing is so fresh, it'll be great if you contact the
maintainer
(Andy Lutomirski) or the guy that wrote it (Stefani Seibold)
I wrote a mail to Andy
Lets see what he says.
-Michael
--
On 06/18/2014 04:34 PM, Henry Vermaak wrote:
Why do you think this is funny? Those functions are not needed for x64,
and presumably no-one cared enough to add the time functions to x86
(until recently).
I don't know what these functions really do and why they are not
sensible with 32 Bit.
On 06/06/2014 12:25 PM, Michael Van Canneyt wrote:
if you do a vDSO implementation, please do not limit the
implementation to the clock_gettime, but implement all calls that
support it.
For a starter, I did a testing project that (without using any external
library) finds an verifies the
On 06/11/2014 09:46 PM, Graeme Geldenhuys wrote:
The easiest is to simply create a Github account, then go to the
EpikTimer repository in my account and click Fork. Github will do the
rest and give you instructions on how to checkout your forked version.
Thanks,
I created a github account
On Linux x86 32 Bits, using the current svn version, since two days,
while I still can create a new-application, after I just did save
project as and saved the two files, I can't compile any more but get
lots of error messages (seemingly when linking) starting with
Compile Project: Exit code
Am I correct to assume that a fork is similar to a branch and hence
the branches can share common files (e.g. updated demo/test projects).
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/12/2014 10:41 AM, Michael Van Canneyt wrote:
Sounds like a missing 'interfaces' unit in your project source.
On the contrary :-)
Silly me saved the project in a folder that contained a file
interfaces.pas that I did for another project ;-) .
Thanks for the pointers.
-Michael
--
I am not an expert with git. So I'll need some help.
For the beginning I created a folder in the git project folder and in
that I created symlinks to the files I want to add.
I created a new branch and did stage and a commit (seemed to haw worked).
Now I tried git push.
Here I (of course)
On 06/06/2014 06:06 PM, Timothy Groves wrote:
TMemo offers soft word wrapping. As far as I can tell through Google
searches, this is not possible in TSynEdit.
I seem to remember that there have been multiple requests for a
TMemo-like component that has soft word wrapping while in the
Sounds really great !
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 05/29/2014 12:39 AM, Graeme Geldenhuys wrote:
https://github.com/graemeg/epiktimer/releases
Graeme,
I am trying to base my future work on your git.
Unfortunately this version of EpikTimer.pas does not compile on Linux:
clock_gettime() is not found. (And the comment there says
On 06/06/2014 11:21 AM, Michael Van Canneyt wrote:
Just add unit linux to the uses clause under {$IFDEF LINUX}.
clock_gettime is in there, not in the baseunix/unix.
Thanks.
So I do have an example for this.
In the end I am willing to do an implementation of this using vDSO...
-Michael
--
On 06/06/2014 12:25 PM, Michael Van Canneyt wrote:
if you do a vDSO implementation, please do not limit the
implementation to the clock_gettime, but implement all calls that
support it.
I do see your point.
Right now I extracted (most of) the hardware depending stuff (i.e. the
On 05/29/2014 12:39 AM, Graeme Geldenhuys wrote:
https://github.com/graemeg/epiktimer/releases
I attached to that and will base all future on it.
Does it make sense that I directly to the repository ?
-Michael
--
___
Lazarus mailing list
On 05/29/2014 05:47 AM, Tom Lisjac wrote:
I'm having a little trouble understanding where new functionality is
needed for your use case.
Of course you are right that I don't exactly need it. In my source code
I use a {§ifdef to decide whether or not to create an instance (my
current
On 05/26/2014 05:23 PM, Graeme Geldenhuys wrote:
Like its always been done.
So it will be a ZIP file containing a directory with the source code and
an lpk file to allow using it as a Lazarus package.
This is OK for me, provided there is a documentation file that briefly
explains how to
On 05/27/2014 03:54 AM, Paul Breneman wrote:
Will EpikTimer work in a console app? If so, an example on the wiki
page would sure be appreciated. I need it now (for an Android Linux
console program)! :)
Soft answer: Yes
Long answer:
My current test-state of the interfaces.pas unit
On 05/24/2014 01:55 PM, Graeme Geldenhuys wrote:
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.
Great
On 05/26/2014 01:21 PM, Graeme Geldenhuys wrote:
fpc-devel is only for FPC related/included units. EpikTimer is not
included in FPC. I also believe that not everything must always be
included with FPC - that makes it harder to experiment and apply changes.
I see.
How do you suggest a not
On 05/26/2014 02:28 PM, Sven Barth wrote:
Why not simply instantiate a single instance and use that where
necessary instead of completely reworking the class?
I am not doing an application, but an enhancement to the LCL. Hence this
in any case would be an _additional_ instance.
The VMT is
On 05/22/2014 10:32 AM, Michael Schnell wrote:
Here I'd like to consider some suggestions (I of course can implement
this locally and we can later discuss a release for the fpc RTL or
whatever.
- function GetHardwareTicks could be a class function so I wold not
need to create an instance
(should we start a new mailing list thread ? )
Graeme,
While doing the said modifications I could not continue to have
function SystemSleep(Milliseconds: Integer):integer; Virtual;
function CalibrateCallOverheads(Var TimeBase:TimebaseData) :
Integer; Virtual;
function
On 05/21/2014 07:46 PM, Graeme Geldenhuys wrote:
...
(This was no FUD, as the _officially_released_ (ZIP) distribution really
suffers from the restriction I described. Don't be angry on me pointing
this out. No pun to the good work done.)
As I said, EpicTimer doesn't have a GUI dependency
On 05/19/2014 09:00 PM, Graeme Geldenhuys wrote:
Tom and I would welcome patches for EpikTimer.
I am not interested in EpicTimer in it's current stat, as it needs a GUI
based LCL Widget Type to be compiled, and my interest regarding timing
is the creation of the ActiveNoGUI widget type.
I
On 05/20/2014 05:18 PM, Felipe Monteiro de Carvalho wrote:
And most people using Lazarus are using it for desktop apps.
While this of course is true, one of the the strategical advantages of
fpc/Lazarus above Delphi is that it is inherently cross-platform:
multiple CPU archs, multiple OSes,
On 05/19/2014 07:54 PM, Graeme Geldenhuys wrote:
You are clearly using a very outdated version. That was fixed 2+ years
ago. Get the latest code from SubVersion instead of the ZIP download.
Right you are,
The files contained in the ZIP are dated at max at 10/2006.
I never came across any
On 05/19/2014 08:52 PM, Tom Lisjac wrote:
There's no question that the component needs an update as the current
zip on the Lazarus-ccr was packaged in 2006. SVN is more current and
Graeme and I will get together and roll any additional improvements
he's made into a new release.
Great !
If
On 05/19/2014 09:06 PM, Graeme Geldenhuys wrote:
Correction, it was fixed 4 years ago. :)
Seems more like 8 years :-) :-) :-)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 05/21/2014 11:26 AM, Sven Barth wrote:
Did you even take a look at the current state? The EpikTimer unit only
requires units from the FCL and the RTL. Additionally Graeme uses it
in his fpGui projects which doesn't provide a GUI based LCL widget
type either...
Sounds great.
Trying
On 05/21/2014 11:23 AM, Sven Barth wrote:
Graeme is right with four years. The dependency on LCL units was
removed on 18th May 2010.
I was just joking, nagging that a ZIP distribution had not been done
since that :-[ .
-Michael
--
___
Lazarus
On 05/21/2014 10:58 AM, Michael Schnell wrote:
vDSO seems like the way to go in Linux. Here the Kernel is supposed to
provide a fully user space function that accesses the hardware
provided by the arch or emulates it in the best possible way.
As a staring point:
In /usr/src/linux
On 05/21/2014 02:28 PM, Sven Barth wrote:
Search for Lazarus-CCR on SourceForge, select SVN at the top and
navigate to components/epiktimer.
Works.
Thanks,
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
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
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 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
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
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
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 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
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
On 05/15/2014 05:26 PM, Reimar Grabowski wrote:
OP:
I need to develop a game for all possible Operating Systems.
EpicTimer uses QueryPerformanceCounter for Windows. I did not check
into this, but I suppose this already is what he needs.
But it uses fpgettimeofday in Linux. This is what
On 05/15/2014 07:34 PM, Junior wrote:
I need precision, I'll be working with many timers in milliseconds.
(Windows 32 bits/64bits; Linux 32 bits/64bits; Android; MacOS; among
others)
No normal (not dedicatedtly realtime) OS provides decent millisecond
precision. The OS might stall any
On 05/14/2014 09:44 PM, Michael Van Canneyt wrote:
Hopefully you got rid of the fpgettimeofday, or else the component is
no better than using Now() :-)
Michael,
Even though I of course was aware of this, I did used fpgettimeofday to
implement TTimer with the ActiveNoGui WidgetType, as I did
--- sorry, previous mail seems to be digested by some scrambler ---
On 05/14/2014 09:44 PM, Michael Van Canneyt wrote:
Hopefully you got rid of the fpgettimeofday, or else the component is
no better than using Now() :-)
Michael,
Even though I of course was aware of this, I did used
On 05/15/2014 09:51 AM, Michael Van Canneyt wrote:
Of course in the end I need something that works for any CPU and OS.
There is nothing. EpikTimer pretends to fill this gap, but it does not.
Yep.
If necessary I could try to do something myself (i.e. an improved
version of
On 05/15/2014 11:18 AM, Michael Van Canneyt wrote:
fpGetTimeOfDay is used to implement Now(). This should not be changed.
Why not, If there are better ways ?
I did a quick search in the RTL sources and found that there is
GetTickCount64 that maybe could be used as a central cross-platform
On 05/15/2014 11:43 AM, Henry Vermaak wrote:
Only the speed can be improved by calling into the vDSO, not the
precision. You need to use clock_gettime() for nanosecond precision
I see.
Is clock_gettime not available via vDSO ? To me this seems even more
viable than for fpGetTimeOfDay.
On 05/15/2014 01:29 PM, Henry Vermaak wrote:
You seem a bit confused about some of these things, and people are
talking at cross purposes,
Right you are.
I e.g. was inappropriately ignoring the fact that the time of day can be
unaffectedly modified under the hood.
Now I know better.
On 05/15/2014 01:06 PM, Henry Vermaak wrote:
Yes, as I said earlier. It's in the man page, too. And in the kernel
source I pointed to.
Henry,
Thanks a lot for you patience !
So this (using vDSO to call clock_gettime in fact is what the OP was
searching for, and what would needed tp be
On 05/15/2014 01:45 PM, Leonardo M. Ramé wrote:
Can you add a What's new item in the home page or in the Wiki?.
Plus a What's old item for silly me ;-) .
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 05/15/2014 02:44 PM, Sven Barth wrote:
Nevertheless we could add vDSO support to the Linux unit so that users
can make use of it without the need to link to libc or implement it
themselves. :)
Hence fpGetTimeOfDay would need multiple implementations.
clock_gettime seems to be
On 05/12/2014 10:37 PM, Henry Vermaak wrote:
On linux, glibc (and others) will route gettimeofday() (and
clock_gettime() for certain clock IDs) via vDSO and no syscall will be
called, so it's very fast. I don't think the fpc rtl does this, though?
I checked with X86 32 Bit Linux: you are
On 05/13/2014 10:45 AM, Mark Morgan Lloyd wrote:
There's an obvious pitfall there: a poor implementation might /think/
that it's directly accessing the counters when in actual fact it's
being virtualised or fixed up by a signal handler.
Regarding just reading the performance-monitoring
On 05/13/2014 12:00 PM, Henry Vermaak wrote:
This doesn't have anything to do with vDSO, though. The standard
library doesn't use any assembler to read these registers. It calls
into a page that the kernel makes available to userspace that contains
certain functions where the overhead of a
On 05/11/2014 09:44 AM, Graeme Geldenhuys wrote:
Take a look at EpikTimer. It uses hardware timers where available, with
an easy to use API for the developer.
IO took a look.
Seemingly this is only available for X86 and X86_64.
In Windows, QueryPerformanceCounter is called. I supposed (I
On 05/12/2014 02:47 PM, Reinier Olislagers wrote:
The wiki page even explicitly mentions ARM.
Right. As it does a system call in Linux, this should be independent of
the CPU arch
Do you mean direct access to the hardware bypassing the OS? I thought
that wasn't possible in Windows?
I don't
401 - 500 of 1996 matches
Mail list logo
