Vincent Snijders wrote:
Andreas Berger schreef:
Andreas Berger wrote:
I have a problem compiling the compiler. After a lot of compilation
it attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
I downloaded todays snapshot and had the
I am using the v20 base compiler with the v21 source. It should create a
v21 compiler.
I get the same error compiling under DOS, Win98 and Win2K
Regards, Andreas
Lee, John wrote:
This is a known error - I get it too - but I only get when using the v2.1.1
compiler to start make. Do you get it
At 22:18 24-7-2006, you wrote:
I'm new to free-pascal, and have searched for a few hours without
finding an answer to my question. I hope someone on the list could
please help point me in the right direction.
I've been using a couple of encryption/decryption units that are
written in Pascal
This is a known error - I get it too - but I only get when using the v2.1.1
compiler to start make. Do you get it when starting with the v2.0.2 release
compiler released too? What about trying a snapshot of v20 compiler eg
base_go32_v20.zip or similar.
You can get more info with "opt=-va" on CL
On Tuesday 25 July 2006 14:51, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > Ok, there's a glitch: The read and write of self.ThreadId is
> > required to be atomic, so that a thread entering may either see "0"
> > or the owner's thread id when checking, otherwise it could be
> > possible, it s
Vinzent Hoefler wrote:
> Ok, there's a glitch: The read and write of self.ThreadId is required to
> be atomic, so that a thread entering may either see "0" or the owner's
> thread id when checking, otherwise it could be possible, it sees its
> own thread_id due to a partial update and *then* it
On Tue, 25 Jul 2006, Andreas Berger wrote:
In order to initialize threading under DOS I must create a separate unit
since I need the initialization and finalization clause. I thought of using a
cthreads.pp unit like in unix. However, the TThread implementation resides in
the TThread.inc file
On Tuesday 25 July 2006 14:18, Andreas Berger wrote:
> In order to initialize threading under DOS I must create a separate
> unit since I need the initialization and finalization clause. I
> thought of using a cthreads.pp unit like in unix. However, the
> TThread
> implementation resides in the TT
In order to initialize threading under DOS I must create a separate unit
since I need the initialization and finalization clause. I thought of
using a cthreads.pp unit like in unix. However, the TThread
implementation resides in the TThread.inc file which is an include in
the implementation sec
On Tue, 25 Jul 2006, Andreas Berger wrote:
What is this for? Although most threading implementations set this record, it
does not seem to be used by the system.
It is most definitely used by the system :-)
All systhrdh.inc(systhrd.inc) functions use it.
The only implementation that even
c
What is this for? Although most threading implementations set this
record, it does not seem to be used by the system. The only
implementation that even calls the functions set is the unix
implementation, and it does it internally.
Do I need to use this if I implement threading in DOS?
___
Andreas Berger schreef:
Andreas Berger wrote:
I have a problem compiling the compiler. After a lot of compilation it
attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
I downloaded todays snapshot and had the same problem. Then I comp
Andreas Berger wrote:
I have a problem compiling the compiler. After a lot of compilation it
attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
I downloaded todays snapshot and had the same problem. Then I compiled
using "make all" +
Am Dienstag, 25. Juli 2006 11:59 schrieb Vinzent Hoefler:
> On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
> > Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
> > > function Recursive_Mutex.Lock:...;
> > > begin
> > >// Owned by current thread?
> > >if CurrentThreadId <> s
On Tuesday 25 July 2006 08:46, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> >> Ehm, no.
> >
> > Ehm, yes. I was being ironic here. Of course, the action of
> > checking the counter and locking/unlocking the associated mutex
> > must be atomic.
>
> But here they are not associated, they're prote
On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
> Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
>
> > function Recursive_Mutex.Lock:...;
> > begin
> >// Owned by current thread?
> >if CurrentThreadId <> self.ThreadId then
> >begin
> > result := pthread_mutex_loc
That's the one!! Thanks.
Graeme.
On 7/25/06, Micha Nelissen <[EMAIL PROTECTED]> wrote:
Graeme Geldenhuys wrote:
> Hi,
>
> For the life of me I cant remember what the functions are called to
> enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
> know there was such functions
Graeme Geldenhuys wrote:
> Hi,
>
> For the life of me I cant remember what the functions are called to
> enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
> know there was such functions in Delphi)
InflateRect ?
Micha
___
fpc-pascal
Hi,
For the life of me I cant remember what the functions are called to
enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
know there was such functions in Delphi)
Regards,
Graeme.
--
There's no place like 127.0.0.1
___
fpc-pascal
[...]
coffee, pencil and stuff ;-)
off course, the local procedure "internalEnter" in Leave is a
copy'n'paste rubbish. Just remove ..
TCriticalSection.Leave;
begin
internal.lock;
try
if OwnerThread <> GetCurrentThreadID then begin //we are not
// allowed to leave, because we don't
Burkhard Carstens wrote:
>> I don't see the need for Owner_Check_Lock anymore ? :-)
>
> You have to prevent that 2 concurrent threads call lock simultanously,
No, why?
> so you have to take an internal lock before touching internal vars like
> self.ThreadID ?
No, why ? This is a common miscon
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
> Vinzent Hoefler wrote:
> >> Ehm, no.
> >
> > Ehm, yes. I was being ironic here. Of course, the action of
> > checking the counter and locking/unlocking the associated mutex
> > must be atomic.
>
> But here they are not associated, they're p
Am Montag, 24. Juli 2006 23:38 schrieb Vinzent Höfler:
> Vinzent Höfler wrote:
> > Hmm. So we'd need a mutex inside a mutex. Now I know why they call
> > it recursive. ;) So it'll be something like that:
> >
> > function Recursive_Mutex.Lock : ...;
> > begin
> >// Lock mutex inside mutex.
> >
Vinzent Hoefler wrote:
>> Ehm, no.
>
> Ehm, yes. I was being ironic here. Of course, the action of checking the
> counter and locking/unlocking the associated mutex must be atomic.
But here they are not associated, they're protected by owner_lock, as
you said.
>> Got confused a bit :-). Reread
On Tuesday 25 July 2006 07:46, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
> >> Vinzent Höfler wrote:
> >>> because we assume it's non-recursive, that was the whole point.
> >>> So we should *first* check the count and then may lock/unlock
Vinzent Hoefler wrote:
> On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
>> Vinzent Höfler wrote:
>>> because we assume it's non-recursive, that was the whole point. So
>>> we should *first* check the count and then may lock/unlock the
>>> mutex accordingly.
>> Note that these two actions must
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
> Vinzent Höfler wrote:
> > because we assume it's non-recursive, that was the whole point. So
> > we should *first* check the count and then may lock/unlock the
> > mutex accordingly.
>
> Note that these two actions must be atomic.
Oh, really?
27 matches
Mail list logo
