Michael Van Canneyt wrote / napísal(a):
On Mon, 2 Jun 2014, LacaK wrote:
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK wrote:
IMO very similar result you can get also with existing
implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's n
On Mon, Jun 2, 2014 at 10:38 AM, Michael Van Canneyt
wrote:
> While this is correct, the collection approach is much easier to use:
> With the metadataset, you must know which fields exist and type them
> correctly: FieldByName('XYZ').AsString
>
> With collections, the IDE codetools will tell you
On Mon, Jun 2, 2014 at 10:27 AM, LacaK wrote:
> (for SQLConnection which support schemas. I have used public method
> SetSchemaInfo not GetDBInfo)
It's not public in SqlConnection, it's public in SqlQuery.
Anyway, I don't see why avoid a dedicated method to do this instead of
3 steps which are n
On Mon, 2 Jun 2014, LacaK wrote:
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK wrote:
IMO very similar result you can get also with existing implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema.
Code
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK wrote:
IMO very similar result you can get also with existing implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema.
Code which I have attached uses only
On Mon, Jun 2, 2014 at 3:01 AM, LacaK wrote:
> IMO very similar result you can get also with existing implementation, when
> you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema. What I did was to copy and modify this method.
I have sent a patch: http://bugs.f
On 06/02/2014 11:49 AM, Marco van de Voort wrote:
In Windows I suppose syscalls usually are not done directly by the rtl,
No. Windows calls kernel32/user32, which then mostly calls nt.dll functions
I feel free to translate this to: "In Windows, the fpc rtl calls
kernel32/user32, ..."
Which
On 06/02/2014 11:49 AM, Marco van de Voort wrote:
Maybe, but is that relevant? We were talking about precision, not speed.
I have been talking about overhead (speed) all the time. This is my
intention to discuss the issue. Bus regarding time measurement of course
speed and precision is highly r
In our previous episode, Michael Schnell said:
> On 05/28/2014 05:41 PM, Marco van de Voort wrote:
> > . But that means you need to use OS timing functions, and not ASM.
>
> Meaning either syscalls or vDSO.
>
> As in Linux syscalls do a usermode->Kernelmode->usermode switch, they
> introduce a h
On 06/02/2014 11:06 AM, Sven Barth wrote:
Addendum: yes, the RTL calls the core DLLs of the Win32 subsystem like
kernel32.dll, but they are just that: the core DLLs of the Win32
subsystem. They don't implement any core OS functionality like
hardware/device management, because that is done by
Am 02.06.2014 10:38 schrieb "Michael Schnell" :
> In Windows I suppose syscalls usually are not done directly by the rtl,
but functions calls to a Kernel dll are done, so that that Windows.provide
dll might decide to stay in usermode if possible.
Addendum: yes, the RTL calls the core DLLs of the W
Am 02.06.2014 10:38 schrieb "Michael Schnell" :
> In Windows I suppose syscalls usually are not done directly by the rtl,
but functions calls to a Kernel dll are done, so that that Windows.provide
dll might decide to stay in usermode if possible.
On Windows the QueryPerfomanceCounter/Frequency cal
On 05/29/2014 01:17 AM, Graeme Geldenhuys wrote:
Then fork it on Github and start publishing your changes. I'll gladly
review the suggestions and merge it what works.
OK. (Of course only after I did as much testing as possible - in fact I
can't do by far enough.)
This discussion shows that the
On 05/28/2014 06:03 PM, Henry Vermaak wrote:
Blindly making assumptions about TSC stability can get you into
trouble. Microsoft advises against this, too:
http://msdn.microsoft.com/en-gb/library/windows/desktop/ee417693%28v=vs.85%29.aspx
As my Target is Linux, this does not help with the impl
On 05/28/2014 05:41 PM, Marco van de Voort wrote:
. But that means you need to use OS timing functions, and not ASM.
Meaning either syscalls or vDSO.
As in Linux syscalls do a usermode->Kernelmode->usermode switch, they
introduce a huger overhead.
In Windows I suppose syscalls usually are n
On 05/28/2014 06:09 PM, Henry Vermaak wrote:
an ifdef to call QueryPerformanceCounter/()clock_gettime() based on OS.
Things like this is why I'd rather use dVSO.
Calling the vDSO will certainly make things faster.
For me, the point is, that with vDSO, the Linux infrastructure will
handle the d
16 matches
Mail list logo
