On Friday 31 December 2004 14:24, [EMAIL PROTECTED] wrote:
Normally one never uses a fully qualified identifier.
So I'm not normal. ;) I *always* use them. Makes life easier.
Only when a possible name conflict exists, which
- Should be very rare, and avoided in the first place.
IBTD. I even
On Sunday 17 April 2005 10:45, Ales Katona wrote:
First of all Integer should be size independent, that is, xy bits
depending on the platform.
I second that.
Second, we should force people in a friendly way to use more
readible names like:
sint32, uint64, etc. than cardinal
No. Such stuff
On Monday 18 April 2005 07:22, Marco van de Voort wrote:
On Sunday 17 April 2005 10:45, Ales Katona wrote:
First of all Integer should be size independent, that is, xy bits
depending on the platform.
I second that.
It is now. It just happens to be the same.
:) Ok, good point.
On Monday 18 April 2005 07:29, Peter Vreman wrote:
On Sunday 17 April 2005 10:45, Ales Katona wrote:
First of all Integer should be size independent, that is, xy bits
depending on the platform.
I second that.
This is useless. Your code
That doesn't matter. If I'd want the same code on
On Monday 18 April 2005 08:46, Jonas Maebe wrote:
They are, but ptrint and ptruint are just regular types. The compiler
cannot know they are properly defined in each RTL unit, and you can
override them to be something completely different. That's why it
gave and still gives a warning.
Yep.
On Monday 18 April 2005 09:02, Marco van de Voort wrote:
That's why Pascal has range types. Define the range you need,
and don't use just some type which has the range you think
you will need.
I actually tried this in a major app at work.
Well, and I actually do this in a
On Monday 18 April 2005 10:32, Marco van de Voort wrote:
On Monday 18 April 2005 09:02, Marco van de Voort wrote:
I typically use enums. They suffer from the same to-disk problem
though, but that can be remedied using the proper directives.
Well, I don't think I will ever use enums
Hi,
consider this piece of code:
-- 8 -- snip --
type
tA = array[0 .. 5] of byte;
tB = array[0 .. 5] of byte;
var
A : tA;
B : tB;
begin
FillChar (A, SizeOf (A), 0);
B := A; // -- should by type error!
A := tA(B);
end.
-- 8 -- snip --
On Monday 25 April 2005 12:10, Florian Klaempfl wrote:
Vinzent Hoefler wrote:
consider this piece of code:
-- 8 -- snip --
type
tA = array[0 .. 5] of byte;
tB = array[0 .. 5] of byte;
var
A : tA;
B : tB;
begin
FillChar (A, SizeOf (A), 0);
B
On Monday 25 April 2005 12:10, Florian Klaempfl wrote:
Just a small reprise on this matter:
It's simply a thing to make life easier especially for beginners.
Easy to shoot theirselves in the foot? ;-) There's already a language
well known for this type of easyness.
I
don't know a real
On Sunday 22 May 2005 10:17, Tomas Hajny wrote:
At 11:46 22-5-2005, you wrote:
What's about Go32v2 or some other DOS port?
Will it supported in 2.0.x branch?
There is no maintainer for go32v2. Unless there is an user that
steps forward to be the maintainer for go32v2 there will be no
Ok, first status on the matter:
Tonight I've spent some time with the sources and my Win2K machine. For
me it seems as the Makefile(.fpc)'s are not yet up to date for the
go32v2 target (object files didn't get deleted on cleanall, some unit
paths were missing, that sort of stuff) [FYI: I
On Wednesday 25 May 2005 14:51, Tomas Hajny wrote:
First of all - make sure you don't use Win32 versions of the GNU
tools (especially make.exe etc.) when trying to build for the GO32v2
target under WinXX. The best is to change your PATH setting within
the given session. Then the existing
On Wednesday 25 May 2005 12:50, Florian Klaempfl wrote:
Our policy is to work and develop patches in the 2.1.x branch. As
soon as they work, we merge them back to 2.0.x using the mechanisms
of svn. But patches against 2.0.x are ok as well because I don't
think that currently much people are
On Thursday 26 May 2005 15:04, Michael Preslar wrote:
Is select() no longer supported in the 2.0 branch?
Try fpselect in baseunix.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms of _working_ lines of code? :-
Vinzent.
--
public key:
On Thursday 02 June 2005 13:22, Jamie McCracken wrote:
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer then :)
No, that's a common
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice as fast,
the maximum
On Thursday 02 June 2005 14:24, Jamie McCracken wrote:
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing my application.
I typically spend 80% of my development time
On Thursday 02 June 2005 14:44, Jamie McCracken wrote:
My point is to to reduce or remove *redundant* syntax that serves no
useful or productive purpose (to the programmer).
Well applied redundancy is a good thing.
Forward declarations are redundant - they exist purely for the
benefit of
On Thursday 02 June 2005 15:16, Uberto Barbini wrote:
If the goal is this, I'd prefear a way to declare objects
autocreated:
varauto:
strlist: TStringList;
begin
//some stuff
end;
[...]
It could be a problem to pass parameters to the constructor.
Yes, exactly. So why bother the
On Friday 03 June 2005 10:47, Jamie McCracken wrote:
It makes it more clear IMO not less. having all that interface code
and having to jump between it and the implementation does not aid
legibility.
It encourages reading code instead of interface specifications. Often
there is a big
On Thursday 02 June 2005 16:12, Marco van de Voort wrote:
Begin..End is redundant - you have to indent them to make em
readable anyways.
No. This makes the code more readable like normal english text. It
states much more clearly what it intents, at least much more than
just indenting
On Friday 01 July 2005 00:12, L505 wrote:
As I have indicated, I am very happy to have 83-88 lines of Pascal
code on my screen versus even 70 or 55.
Doesn't matter. One function at a time is enough to see. ;-)
I have 72x30 (yes, that's width height in chars). All function not
fitting into
On Thursday 07 July 2005 21:27, Marcel Martin wrote:
Vinzent Hoefler a écrit :
Personal note: Maybe there was a reason why Borland Pascal didn't
do range checks on Inc/Dec.
Yes, there is always a good reason for a bug :-)
Any sufficiently advanced bug cannot be distinguished from
On Friday 08 July 2005 10:49, Gerhard Scholz wrote:
Beside, v is word or byte, depending on a compiler-$if elsewhere, so
I would have to write:
inc ( {$ifdef big} smallint {$else} shortint {$endif }v, delta ) ;
Not very clear readable.
Agreed. It's not readable at all. So don't do that,
On Friday 08 July 2005 12:24, Gerhard Scholz wrote:
- Original Message -
From: Vinzent Hoefler [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Friday, July 08, 2005 1:24 PM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
OTOH, ...
new abbreviation
On Friday 08 July 2005 12:39, Tom Verhoeff wrote:
On Thu, Jul 07, 2005 at 07:47:03AM +, Vinzent Hoefler wrote:
operators. So especially with the added overflow check I think,
Inc and Dec are pretty useless functions, because the don't do
anything you can't accomplish by using
On Friday 04 November 2005 09:25, Micha Nelissen wrote:
Marc Weustink wrote:
If the generic is precompiled (which is maybe necesary if you
need access to privates) then I fear some runtime logic has to be
added to call the correct procedure. IE. something like
case TypeInfo(Data) of
On Friday 04 November 2005 13:00, Micha Nelissen wrote:
Combining some of the wiki ideas, and has no evil characters
:-).
I don't understand the fuzz about using . It's not even close to
being C(++)-ish, because it was used for describing discrete range
types _at least_ in Ada's generics
On Friday 04 November 2005 13:27, Marco van de Voort wrote:
[]
The evil is in
- using characters instead of modifiers.
- worse, recycling already used characters.
Alright, I completely understand at least the first part, so perhaps
they should simply not be overused. :-)
Just for the fun
On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote:
Its working so far, but using multiple tasks, there are some strange
effects (exceptions,hangs).
From the freepascal documentation:
Although it is not forbidden to do so, it is not recommended to use
system-specific threading
On Tuesday 21 March 2006 04:37, Michalis Kamburelis wrote:
I'm concerned with using DivMod in cases when Dividend is 0. DivMod
declaration is
procedure DivMod(Dividend: Integer; Divisor: Word; var Result,
Remainder: Word);
which means that it doesn't allow for Result and Remainder to
On Wednesday 17 May 2006 20:50, Marco van de Voort wrote:
Having to check and guard each and every string operation is also not
really productive. KR tried that :-)
And I thought they did it the other way around. Leaving the check as an
exercise to the coder. ;-)
Vinzent.
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
How can I zero-pad using Format ?
RTFM. :-)
SysUtils.Format ('%.4D', Some_Int);
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Tuesday 20 June 2006 11:39, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
How can I zero-pad using Format ?
RTFM. :-)
SysUtils.Format ('%.4D', Some_Int);
Sounds like I found a case where 'C' is more intuitive than pascal
On Thursday 13 July 2006 12:31, Jose Manuel wrote:
The error code is: 193 0x00C1 N/A %1 is not a
valid Win32 application.
But that doesn't make sense.
[...]
I guess FPC is creating the DLL with no relocation section in it.
Another issue is that meaningless error. It should be
On Monday 17 July 2006 15:03, Micha Nelissen wrote:
No these are separate things. The C compiler vendors do not provide a
common platform resulting in a differing mess that has to be held
together with scripts.
Of course they don't. Unlike some other languages where such things are
On Monday 17 July 2006 15:33, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Of course they don't. Unlike some other languages where such things
are standardized quite clearly, (most) consistency, dependency and
linking issues are beyond the scope of the official C-standard.
I'm not talking
Hi,
some questions:
1) Is there some good reason why the support for the inline keyword can
be turned on and off explicitely by the {$INLINE} directive?
2) Can I check somehow if inlining is enabled during compilation?
{$IFOPT INLINE} didn't work. ;)
2a) If the answer to 2) is no, can we
On Wednesday 27 September 2006 20:50, ik wrote:
Let me give you an example of a real bug that allow attackers to gain
root access using X-server, and I hope you will understand why such
checking can be a good thing.
It *can*. But as usual the pros and cons should be weighted properly.
On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote:
At my workplace we've standardized on using three scope prefixes:
p_ for function parameter, m_ for members/fields, and g_ for global.
I know that discussion, I lost it at work already, but apart from C
where every identifier is sort of
On Thursday 05 October 2006 08:13, Michael Van Canneyt wrote:
On Thu, 5 Oct 2006, Joost van der Sluis wrote:
Now I'm thinking about using an interface, to avoid double code.
But I don't know what effect that has on run-time performance. I
mean, the idea was to make if faster ...
An
On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote:
Daniël Mantione wrote:
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas
resulting in
On Thursday 12 October 2006 12:16, Andrea Mauri wrote:
Dear all,
this is my first mail to this mailing list, I'm not sure this is the
correct one to post this topic.
I noticed a strange behavior of the format function. I'm not sure it
can be considered as a bug.
If I use
format('%.3f',
On Thursday 12 October 2006 13:46, Micha Nelissen wrote:
Jonas Maebe wrote:
can still be one (meaning that it's a negative zero). And for some
fpu calculations this even matters.
Like ?
Divide by signed zero. That decides if the result is positive or
negative infinity. :D
Vinzent.
On Tuesday 17 October 2006 09:03, Jonas Maebe wrote:
On 17 okt 2006, at 10:44, Daniël Mantione wrote:
procedure intRTLEventSetEvent(AEvent: PRTLEvent);
var p:pintrtlevent;
begin
p:=pintrtlevent(aevent);
pthread_mutex_lock(@p^.mutex);
pthread_cond_signal(@p^.condvar);
On Tuesday 17 October 2006 09:46, Jonas Maebe wrote:
On 17 okt 2006, at 11:22, Vinzent Hoefler wrote:
The pthread_cond_wait() function atomically unlocks the
mutex argument
and waits on the cond argument.
So the mutex should already be unlocked afterwards.
If you would
On Tuesday 17 October 2006 10:03, Micha Nelissen wrote:
Windows events do not have this problem since they are stateful.
To be more precise: Windows signals are persistent, not transient like
Unix signals are.
Vinzent.
___
fpc-devel maillist -
On Thursday 19 October 2006 08:31, Marc Weustink wrote:
The case shows that users can do this. There is no language construct
that forbids it. So optimizing this with a smart linker may break
such code.
Yes, it may. So what?
There's hell a lot of code that is generally possible within the
On Thursday 19 October 2006 09:39, Marc Weustink wrote:
The only thing guaranteed by the language is that if you follow its
definitions, it will compile.
No. That's syntax. I'm talking about semantics.
Vinzent.
___
fpc-devel maillist -
On Tuesday 07 November 2006 09:17, Micha Nelissen wrote:
Chris Cheney wrote:
Of course, the efficient way to build a sorted list is to set
Sorted to False and to sort the list after all the items have been
added.
It doesn't matter in O-time: both are O(n log n). Nevertheless, you
On Tuesday 07 November 2006 12:42, Ales Katona wrote:
If you want a Timer a polling mechanism has to take place which
looks if something happened on some timer for example,
Is that so?
OnTimer is ready to be fired (you can't call callbacks in threads,
I can't call callbacks in threads?
On Tuesday 07 November 2006 14:47, Michael Schnell wrote:
Well, for me it would have saved me some time which I wasted in
creating threads that implement timing events by simply sleeping
for a particular time.
IMHO this should be done following the Delphi paradigms to be nice to
Delphi
On Tuesday 07 November 2006 15:17, Ales Katona wrote:
So eg: if you want to do something every 1000ms, you could put a
TThread based timer in, and make it Sleep(1000) and then call the
code, but you must be sure that your main thread cannot have
conflicts if this code is called at any time
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which works in it's own thread and then calls some
callback in it's own thread,
I even call the callback of another thread. :P
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in multi-threaded or even interrupt.
That is not true ! (See my other post.)
Well, a timer is, even though the Delphi implementation of a so-called
TTimer object
On Wednesday 08 November 2006 09:27, Ales Katona wrote:
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Michael Schnell wrote:
As for general use, you can't do a Timer this way.
Right
On Wednesday 08 November 2006 10:01, Michael Schnell wrote:
But doing a function call (or hence using a callback) does not change
the thread context you are running in and thus you are still the same
thread. IOW: code lines are not _dedicated_ to a thread context.
Oh that, of course. Seems
On Wednesday 08 November 2006 10:14, Michael Schnell wrote:
If you take a look the start of this thread, I mentioned that after
implementing Delphi/Lazarus like behavior for the main thread without
the need for a GUI, I'd like to enhance the concept by optionally
having an TApplication object
On Wednesday 08 November 2006 10:26, Ales Katona wrote:
This is an old problem, and not fixable by wishing it. If you want a
good async. timer, sure make one, but don't expect it to work safely
by magic.
I'm sure I won't, I'm paranoid. :)
That's what I ment, it won't simply just work
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote:
Sorry for all the confusion, I'm trying to clarify what I actually mean
(or what I would *expect* from such a timer object):
I don't see how async timers can be useful for software (maybe to
control hardware perhaps, but only the
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
Vinzent Hoefler wrote:
So, the semantics would be about the same as in a signal (apart
from the softer timing), but you would have much less
restrictions in the handler's implementation compared to a real OS
signal, which acts
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote:
Vinzent Hoefler wrote:
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
is totally impossible to work? To implement something less crude
you
It works,
Oh wonder. A couple
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote:
Vinzent Hoefler wrote:
but it's not realtime by any definition.
First, I never said real-time in that context and second: it sure
can
I concluded that from your quote:
meta-quote
Timing events allow for a handler
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote:
Vinzent Hoefler wrote:
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very
common misconception. which I still refuse as being a correct
answer
On Thursday 09 November 2006 08:22, Michael Schnell wrote:
Yes, of course, this still *is* nothing more than an event loop,
...
A decent event loop should use an OS API to free the processor until
the next event is scheduled:
That's why I wrote the example in Esterel.
Give me that API and
On Friday 19 January 2007 13:12, Marco van de Voort wrote:
There is one dangerous caution against overzealous inifile use: with
lessened privileges (a situation that is going to become more
frequent under Vista, iow, user has no admin rights), apps can't
write to program files/ with the
On Friday 19 January 2007 13:23, Michael Van Canneyt wrote:
HKEY_USER keys is not desirable or feasible (roaming profiles etc). A
config directory can be made read/write for all users.
A registry key can be made that, too.
Vinzent.
___
fpc-devel
On Thursday 15 February 2007 13:06, Daniël Mantione wrote:
Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
program
Case_Test;
type
My_Range = 2000 .. 3000;
var
X : Integer;
begin
X := 2500;
case X of
Low (My_Range) .. High (My_Range) : WriteLn
On Thursday 15 February 2007 13:36, Daniël Mantione wrote:
Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
Well, fair enough, but why is that I can declare a
type
Foo = array[byte] of Something;
where the type name byte also indicates the range? Considering
that
type
On Thursday 01 March 2007 00:11, Jason P Sage wrote:
I've just performed more tests using the stock simpleipc - and the
SendMessage and GetMessage - though defined as STRING (Which I
thought had a max length) seems to be able to support huge
ansistrings.
Well, RTFS:
|unit simpleipc;
|
On Wednesday 04 April 2007 10:33, Sergei Gorelkin wrote:
I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on
InitializeCriticalSection and DeleteCriticalSection symbols.
If I had to guess, I'd say this is probably because those
On Wednesday 04 April 2007 12:59, Sergei Gorelkin wrote:
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing names.
Therefore, to make my code cross-platform, I have only to remove
Windows from uses clause - then
On Wednesday 04 April 2007 13:13, Micha Nelissen wrote:
Sergei Gorelkin wrote:
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing
names. Therefore, to
They shouldn't be exposed publicly in the system unit.
On Wednesday 04 April 2007 15:29, Sergei Gorelkin wrote:
That is exactly what I'm speaking about. Removing 'Windows' from
uses clause is essentially stopping using it :) And if the code
continues to compile and work after that, it is just fine.
Sorry, I always forget that most people are not
On Thursday 05 April 2007 09:16, Sergei Gorelkin wrote:
It appears that my way of thinking has been severely affected by
using IDEs. When putting mouse over identifier shows where it comes
from, prefixing seems redundant :)
Prefixing *is* redundant, that's the whole point of it, but it also
On Thursday 14 June 2007 06:42, Florian Klaempfl wrote:
Why do you need a plug in mechanism? You've the sources? When you
have the sources, 90 per cent of the use of a plugin are gone.
Well, we'd call that non-intrusive change. ;)
You'd just need to compile the plug-in, and not a changed
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
Maybe other way to detect SSE support exists...
CPUID?
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
Maybe other way to detect SSE support exists...
CPUID?
To be more precise, the way recommended by Intel:
To make this check, execute the CPUID instruction with an argument of 1
On Wednesday 22 August 2007 19:18, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Why is calling via a procvar very much slower than a normal call ?
It's just an extra memory fetch (hopefully in cache) ?
Jonas meant that each pixel is drawn separately. The procvar is not
the issue.
On Thursday 18 October 2007 12:55, Michael Schnell wrote:
I think it is better to send a RTF document than a ODT document:
* it is smaller
* more programs can read it
* no need to download and install plug-ins for a seizable minority
of people without open office or ODT-plug-in
Hi all,
after we had that quite heated discussion in core, I decided to take
matters into my own hand and come up with some useful proposal. But now
I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate.
The thing is that I don't know if those are actual bugs, design
On Monday 03 December 2007 09:20, Graeme Geldenhuys wrote:
On 03/12/2007, Marco van de Voort [EMAIL PROTECTED] wrote:
That is an open door that has been kicked in by all vendors. The
problem is
I kind-of understand that... Borland tried to encapsulate the whole
threading thing in a
On Monday 10 December 2007 12:54, Michael Schnell wrote:
IMHO the parallel idea is hard to implement, as the compiler needs
to heavily support it.
Nonetheless, this was what this wiki page was about: Proposals for
parallel *language* constructs (especially WRT to the C-centric OMP
spec).
On Tuesday 11 December 2007 10:04, Michael Schnell wrote:
Andrew Haines wrote:
Hi,
Is it possible to make this work:
if X 3 or 10 then ...
of course it would be shorthand for: if (X3) or (X10) then
The or operator is stronger than the operator by definition.
This can't
On Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
Something like: Create a group of 4 threads named 0,1,2,3 and execute
a procedure/method?
for i := 0 to 3 do
Handle[i] := tThreadId(BeginThread (Func {tThreadFunc},
On Friday 14 December 2007 09:37, Felipe Monteiro de Carvalho wrote:
On Dec 13, 2007 7:55 PM, Mattias Gaertner [EMAIL PROTECTED]
wrote:
Has someone already created a unit for light weight threads?
I don't know much on the subject, but Is TThread heavy? What are the
disadvantages of using
On Friday 14 December 2007 10:20, Florian Klaempfl wrote:
I think some thread pool class is more important, it would be
basically the same as above
for i := 0 to 3 do
Handle[i] := TTask(ThreadPool.QueueTask(Func {tThreadFunc},
@FuncArg[i]));
for i
On Friday 14 December 2007 11:46, Mattias Gaertner wrote:
For many parallel algorithms you don't
need events, priority or synchronize. But you need to easily and fast
start a set of threads with IDs 0..N.
Ok, so you're mostly caring about the thread creation overhead, it
seems.
So yes,
On Wednesday 20 February 2008 17:01, Jeff Duntemann wrote:
Good luck and thanks for the reports. I'll have to look into why Lulu
downloads don't work.
Well, JFTR, the download at the original site worked for me just like
any other. No problems.
And for the content: It was a pleasure reading
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
I did not yet use the preprocessor in Pascal but a standard way to
access memory mapped ports in C is something
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
You mean like ADA? Indeed, I
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote:
Then use bitpacked records:
If you'd document them properly?
-- 8 --
type
TX = 1 .. 4;
TY = 0 .. 3;
type
Foo = bitpacked record
A : TX;
B : TY;
end {record};
var
X : Foo;
begin
X.A := 1;
X.B := 2;
On Wednesday 27 February 2008 11:45, Florian Klaempfl wrote:
Vinzent Hoefler schrieb:
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
Vinzent Hoefler wrote:
If I mean to set the write buffer water mark of the SDRAM
controller
register, I'd rather write
On Wednesday 27 February 2008 12:33, Daniël Mantione wrote:
Too many Ada-features have crept into Pascal over the years. ;)
You can look at it that way, but Ada wasn't the blueprint for Pascal
extensions.
Well, in the early days, it was quite the other way around, yes. Ada is
derived
On Wednesday 27 February 2008 12:56, Jonas Maebe wrote:
On 27 Feb 2008, at 12:17, Vinzent Hoefler wrote:
Free Pascal Compiler version 2.0.0 [2005/09/09] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
test.pas(6,10) Error: Identifier
On Wednesday 27 February 2008 12:21, Daniël Mantione wrote:
Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
Well, TP didn't, and until now I found no real documentation on it
(it sure wasn't mentioned in *my* copy of the programmer's manual).
That is correct, but the last version of TP
1 - 100 of 114 matches
Mail list logo
