On Wed, Mar 18, 2015 at 2:04 PM, Graeme Geldenhuys
wrote:
> As per good unit test guidelines, tests should be independent of each
> other and not rely on results from earlier tests. The perfect candidate
> for parallelism. So what about the idea of running x amount of test
> suites in parallel? It
> So what about the idea of running x amount of test
> suites in parallel? It should at least give our multi-core CPU's
> something to do and maybe complete 2000+ tests in a shorter period. ;-)
>
> Thoughts?
I haven't got as many tests as that yet, but surely a parallel execution
will make a g
On 03/18/2015 06:57 PM, Coyo Stormcaller wrote:
Despite documentation and manuals, I have not figured out how to use TCP
sockets in Object Pascal, since there doesn't seem to be a primitive for
it, or any easy way to instantiate sockets and manipulate incoming
connections.
There is source code
Despite documentation and manuals, I have not figured out how to use TCP
sockets in Object Pascal, since there doesn't seem to be a primitive for
it, or any easy way to instantiate sockets and manipulate incoming
connections.
So my approach to sockets is to do it externally. A Bash shell scrip
On Wed, 18 Mar 2015, Graeme Geldenhuys wrote:
As per good unit test guidelines, tests should be independent of each
other and not rely on results from earlier tests. The perfect candidate
for parallelism. So what about the idea of running x amount of test
suites in parallel? It should at least
On 17 Mar 2015, at 22:32, Graeme Geldenhuys wrote:
> On 2015-03-17 18:49, Ewald wrote:
>> The docs state that it is called automatically upon destruction:
>
> Correct, and I knew that. But I was explicitly looking at the code
> Antonio supplied.
> [...]
> This is my interpretation of what is go
As per good unit test guidelines, tests should be independent of each
other and not rely on results from earlier tests. The perfect candidate
for parallelism. So what about the idea of running x amount of test
suites in parallel? It should at least give our multi-core CPU's
something to do and mayb
QueueAsyncCall takes two arguments - a pointer to a method and data.
The method declaration must be of the type:
TDataEvent = procedure (Data: PtrInt) of object;
My apps have loads of methods defined as above and would certainly fail
to compile if the PtrInt type was replaced with Ptruint. At
On Wed, 18 Mar 2015 15:29:14 +
Graeme Geldenhuys wrote:
> On 2015-03-18 15:23, Tony Whyman wrote:
> > PtrInt is used in that very useful method TApplication.QueueAsync
> > Call.
>
> Though I never used the QueueAsync() call myself, but looking at the
> declaration, shouldn't that data type
On 2015-03-18 15:38, Tony Whyman wrote:
> problem is not whether or not the parameter should be PtrInt or PtrUint,
> it is currently PtrInt and changing it means a lot of work for any
> application that uses it.
If the data you pass in is always positive pointer addresses (I would
assume this be
It's one I tend to use a lot as it's a nice platform independent way
scheduling processing in the next cycle round the message loop. The
problem is not whether or not the parameter should be PtrInt or PtrUint,
it is currently PtrInt and changing it means a lot of work for any
application that u
Mattias Gaertner wrote on Wed, 18 Mar 2015:
On Wed, 18 Mar 2015 14:53:50 +
Graeme Geldenhuys wrote:
Based on what the documentation says "introduction of ptrint type was a
mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0
and removed in a later release like 3.0.2 o
On 2015-03-18 15:23, Tony Whyman wrote:
> PtrInt is used in that very useful method TApplication.QueueAsync
> Call.
Though I never used the QueueAsync() call myself, but looking at the
declaration, shouldn't that data type be PtrUInt anyway? As far as I
understand Data points to data in memory,
On 2015-03-18 15:01, Mattias Gaertner wrote:
> TList stores arbitrary Pointers. To store an arbitrary integer you cast
> it with PtrInt. Is there an integer list?
Generics? [warning: I know nothing about generics]
Good point either way - thanks for the example.
Regards,
- Graeme -
--
fpGUI
Hmmm, PtrInt is used in that very useful method TApplication.QueueAsync
Call. Could cause a lot of problems in Lazarus apps if it was removed
now - or at least without a lot of planning and warning.
http://lazarus-ccr.sourceforge.net/docs/lcl/forms/tapplication.queueasynccall.html
On 18/03/15
On Wed, 18 Mar 2015, vfclists . wrote:
I have recently compiled projects which were converted from Delphi and it seems
to me that the passing a function as a parameter does not require the '@'
symbol. I suspect syntax
errors came because I wasn't compiling from the command line.
e.g
funct
On Wed, 18 Mar 2015, Nikolay Nikolov wrote:
On 18.3.2015 г. 16:53, Graeme Geldenhuys wrote:
Based on what the documentation says "introduction of ptrint type was a
mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0
and removed in a later release like 3.0.2 or 3.2.0?
htt
On 18.3.2015 г. 16:53, Graeme Geldenhuys wrote:
Based on what the documentation says "introduction of ptrint type was a
mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0
and removed in a later release like 3.0.2 or 3.2.0?
http://www.freepascal.org/docs-html/rtl/system/ptri
On Wed, 18 Mar 2015 14:53:50 +
Graeme Geldenhuys wrote:
> Based on what the documentation says "introduction of ptrint type was a
> mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0
> and removed in a later release like 3.0.2 or 3.2.0?
>
> http://www.freepascal.org/doc
Based on what the documentation says "introduction of ptrint type was a
mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0
and removed in a later release like 3.0.2 or 3.2.0?
http://www.freepascal.org/docs-html/rtl/system/ptrint.html
Regards,
- Graeme -
--
fpGUI Toolkit
I have recently compiled projects which were converted from Delphi and it
seems to me that the passing a function as a parameter does not require the
'@' symbol. I suspect syntax errors came because I wasn't compiling from
the command line.
e.g
function AFunction()
begin
end;
CallFunctionWithFu
Am 18.03.2015 11:52 schrieb "Maciej Izak" :
>
> 2015-03-17 23:35 GMT+01:00 Sven Barth :
>>
>> I won't commit it as long as I haven't made sure that it doesn't rely on
any implementation details. And that needs time...
>
>
> IMO the most important to fix is:
>
> http://bugs.freepascal.org/view.php?i
2015-03-17 23:35 GMT+01:00 Sven Barth :
> I won't commit it as long as I haven't made sure that it doesn't rely on
> any implementation details. And that needs time...
>
IMO the most important to fix is:
http://bugs.freepascal.org/view.php?id=24848
http://bugs.freepascal.org/view.php?id=25607
R
> https://github.com/dathox/generics.collections
Thanks. Git makes life easier.
--
Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
24 matches
Mail list logo
