On Wed, 12 Sep 2012 20:44:21 +0200, Jonas Maebe
wrote:
Include an appropriate {$packenum xxx} directive in your source code.
There is no {$packenum c} (I'm not even sure whether the C standard says
anything about the size of enums),
Yes, it does say something about it:
|Each enumerated
On Fri, 14 Sep 2012 14:48:08 +0200, Krzysztof wrote:
I just quicky googled not allowed characters and wrote this simple
function:
Seems, you found one of the many (I'd suspect) wrong search results.
function IsValidFilename(const AFilename: String): Boolean;
var
c: set of Char = ['<','>'
On Fri, 14 Sep 2012 18:42:55 +0200, Jorge Aldo G. de F. Junior
wrote:
am i the only one seeing a security risk here ?
*scratching head* Which part? Care to elaborate?
I'd presume, you mean another than that I'm using Windows? ;)
I don't see how manually restricting the character set of an
On Fri, 14 Sep 2012 18:42:55 +0200, Jorge Aldo G. de F. Junior
wrote:
am i the only one seeing a security risk here ?
Now it dawns. You're thinking environment variables ("%")?
Vinzent.
--
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where
On Fri, 14 Sep 2012 18:53:53 +0200, Krzysztof wrote:
I need only basic checking, it not need to be 100% compability with OS
specification. My program asking user for playlist name and I'm saving
it in local folder with my own extension.
Then for von Neumanns sake simply try to save it where t
On Sat, 15 Sep 2012 11:20:53 +0200, Sven Barth
wrote:
On 14.09.2012 17:44, Graeme Geldenhuys wrote:
On 14/09/12 13:48, Krzysztof wrote:
I just quicky googled not allowed characters and wrote this simple
function:
Also in Windows (as far as I know), file names my not be longer than 255
cha
leledumbo <[EMAIL PROTECTED]>
>
> Jonas Maebe-2 wrote:
> >
> > Because there are easy ways around it (as you mention) and the work to
> > implement and maintain this would probably outweigh the usefulness.
> >
> Yes, it's easy but uncomfortable and needs more typing.
Well, sure, but printing
Mattias Gaertner wrote:
On Thu, 17 Jul 2008 10:45:22 +0200
"Vinzent Höfler" <[EMAIL PROTECTED]> wrote:
leledumbo <[EMAIL PROTECTED]>
Jonas Maebe-2 wrote:
Because there are easy ways around it (as you mention) and the
work to implement and maintain this would probably o
> Datum: Wed, 30 Jul 2008 10:10:09 -0700 (PDT)
> Von: Gene Buckle <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Translate C to Pascal
> > How to translate this:
> >
> > struct a;
> >
> >
> er...
>
> Closest would be:
>
> type
> record = foo
> ba
Original-Nachricht
> Zitat von Roland Turcan <[EMAIL PROTECTED]>:
>
> > Hello Mattias,
> >
> > I have also uncommented some DebugLns which are inside of code:
> >
> > Compiling ./unit/ResConf.pas
> > Assembling resconf
> > An unhandled exception occurred at $00148A20 :
> > TOutpu
leledumbo wrote:
Joost van der Sluis wrote:
And there's no way the compiler can detect this.
I don't think so. The compiler understand that a procedure doesn't return a
value while a function does (i.e. trying to return a value from a procedure
causes compile error). I haven't checked how com
Mattias Gaertner wrote:
On Tue, 12 Aug 2008 09:39:36 +0200
Jilani Khaldi <[EMAIL PROTECTED]> wrote:
Marc Weustink wrote:
Micha Nelissen wrote:
Mattias Gärtner wrote:
How to translate this:
struct a;
Isn't this a forward declaration? So sometime later it needs to
declare 'struct a { ... };'
Felipe Monteiro de Carvalho wrote:
On Wed, Aug 13, 2008 at 7:38 AM, Vinzent Höfler
<[EMAIL PROTECTED]> wrote:
What for? The C statement is empty, it's not a variable and not even a type.
So before translating that into an empty Pascal-record, you should rather
look at what the ac
leledumbo wrote:
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Super
leledumbo wrote:
Vinzent Höfler wrote:
Yes. Turn Extended Syntax off {$X-}, then a function result must be
assigned to a variable. At least it used to be that way.
...
so "inherited Create" did not compile anymore (and I remember that any
attempt to assign this "result"
Mattias Gärtner wrote:
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>:
[...]
a: record end;
Thanks. I will use that.
What for? The C statement is empty, it's not a variable and not even a
type. So before translating that into an empty Pascal-record, you should
rather look at what the actual
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid programmmer, I am
making mistakes all the time, a
Vincent Snijders wrote:
Vinzent Höfler schreef:
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please
Original-Nachricht
> Datum: Wed, 13 Aug 2008 16:02:10 -0400
> Von: Jeff Wormsley <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Compiler option to check return value ignorance
>
> Vinzent Höfler wrote:
> > I ju
> |if not SomeFunction <> Constant_Of_Sometype then {null};
Of course, usually it's without the "not"... ;) And with Boolean functions it's
a bit easier.
And I should have added that I never put in comments what I can easily put in
code. At first, comments don't get compiled, and second, nobod
Original-Nachricht
> Datum: Wed, 13 Aug 2008 22:03:23 +0100
> Von: Jonas Maebe <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Converting C\'s bit field struct
>
> On 13 Aug 2008, at 11:59, Vinzent Höfler wrote:
&g
Datum: Thu, 14 Aug 2008 08:48:58 -0400
Von: Jeff Wormsley <[EMAIL PROTECTED]>
> be forced to check for conditions that aren't likely to ever occur. The
> extra expense in development time isn't worth the risk of not doing the
> checks. That cost vs risk analysis will be different for everyone.
Marco van de Voort wrote:
In our previous episode, Tom Verhoeff said:
This means that the if statement is passed 7 times without problem with
x = -1, and on the 8th pass, where x = -1 again, it bails out with an FPE.
Hmm, didn't the x87 copro stack had 7ish registers? And recursive you say?
:-
Hi,
suppose I need some threadvars inside dynamically allocated objects to keep
track of the number of calls to certain methods. Basic requirement is to keep
track of recursive calls per thread, so I tried implementing that with thread
vars. Only problem: How do I initialize them? I can't do it
Hi,
> I think that thread variables are automatically initialized to zero. So
> you just need to use them in such a way that zero is the desired start
> value.
Hmm, yes. I just checked the sourcecode and indeed, for Win32 and Unix at least
the threadvars are indeed initialized to zero. That woul
Bee wrote:
It might be the case, I'm not sure. In my case, sometimes my app (fcgi)
couldn't create a new requested thread, but at other times it created
successfully. It happened randomly which gave me enough headaches to
find what caused the problem. Such case didn't happen on windows.
http:/
Graeme Geldenhuys wrote:
Some developers prefer to pass in a GUI component to a thread
instance, so the thread knows what widget to update. Other users
prefer to post a "gui update" message to the application event queue.
I'm very new to threads and might know just enough to make in
dangerous. :
Tom Verhoeff wrote:
I am surprised that for ShortString, the range is not
also 1 <= i <= Length(s).
IIRC Turbo Pascal only allowed you to access s[0] when range checking
was off, and similarly for s[i] with i > Length(s).
No. See transcript:
-- 8< -- the program --
{$R+}
var
s1 : String;
Tom Verhoeff wrote:
On Wed, Oct 29, 2008 at 09:58:10PM +0100, Vinzent Höfler wrote:
Tom Verhoeff wrote:
I am surprised that for ShortString, the range is not
also 1 <= i <= Length(s).
IIRC Turbo Pascal only allowed you to access s[0] when range checking
was off, and similarly for s[i
> Von: "Mattias Gärtner" <[EMAIL PROTECTED]>
> I'm curious: who needs more than 13 different image interpolations?
13 different users, of course. ;)
That was a rhetorical question, wasn't it?
Vinzent.
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.
Graeme Geldenhuys wrote:
Under linux, how do you know the users
favorite text editor?
$ echo $EDITOR
/usr/bin/vi
SCNR,
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Michael Van Canneyt wrote:
On Wed, 31 Dec 2008, leledumbo wrote:
Since it's possible to use libc's MM via cmem unit, would the opposite be
possible?
>From the point of view of FPC, there should not be a big problem.
The C library, this is another matter. I am not sure that it
supports plug
Jürgen Hestermann wrote:
I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good idea).
Consider the
following example:
for d in [Monday,Wednesday,Friday] do ;
Jürgen Hestermann wrote:
Mantra: First make it work, then make it fast.
In general that's true from the programmer's viewpoint. But this does
not apply to adding language details because there is no 'first make it
work'. Why obscure important implementation details if the only benefit
is sa
Original-Nachricht
> Datum: Tue, 20 Jan 2009 09:07:54 +0100 (CET)
> Von: Michael Van Canneyt
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] CPU affinity of TThread descendants
>
>
> On Mon, 19 Jan 2009, David W Noon wrote:
>
> > Hi,
> >
> > I am running FPC
Original-Nachricht
> Datum: Mon, 26 Jan 2009 17:42:23 -0600
> Von: "vmars"
> An: fpc-pascal@lists.freepascal.org
> Betreff: [fpc-pascal] If ShellExecute(0, \'open\', PChar(ExecuteName), \'\',
> \'\',0) <= 32 Then
> Thanks in advance!
>
> [Any ideas why this works:
> Ex
Richard Ward writes:
> I was refering to not seeing a note that one can not
> have a unit name be the same as a function name.
Sure you can, the function just should not reside in the very same unit. This
is a short-coming of the Pascal language definition.
Vinzent.
--
Pt! Schon vom neue
> Is it possible to have a multi-threaded console application?
Yes. BTDT.
> The reason I ask, is because I can't see CheckSynchronize() being
> called anywhere in TCustomApplication descendants like what Lazarus
> (console app project) creates?
Well, if you want to do it that way, you're free to
Mattias Gaertner :
> But I second Jonas mail: Before you run an fpc program in a
> zero-tolerance environment, you have to test a lot of things, because a
> lot of code was not written with zero-tolerance in mind.
Testing simply isn't enough. As we all should know, testing only proofs the
exista
Von: "Hans Mårtensson" :
> But then, in case of zero-tolerance, if you trust the compiler, what
> about the OS? and, worst, what about your program?
And what about the CPU? ;)
> I wouldn't trust the reliability of anything before the full system has
> been tested under working conditions.
Wha
Graeme Geldenhuys :
> How do I convert the GetCurrentThreadID() result to a string?
>
> At the moment for Linux and Windows the following works:
>
> var
> lsThreadID: string
> begin
> lsThreadID := IntToStr(GetCurrentThreadID);
lsThreadID := SysUtils.IntToStr (QWord(GetCurrentThread
Florian Klaempfl :
> If you have a better for unix this will be fine. IIRC it is not easy (if
> possible after all?) to implement TMultiReadExclusiveWriteSynchronizer
> for unix systems.
It's possible, yes. If it's possible in an efficient way, is another question.
Vinzent.
--
GRATIS für alle
Graeme Geldenhuys :
> I have a corrected TMultiReadExclusiveWriteSynchronizer implementation
> (don't worry, not based on Delphi implementation) that I can donate to
> FPC.
I hope it isn't based on the Delphi one. Last time I heard the Delphi
implementation suffers from occasional dead locks.
S
"Jürgen Hestermann" :
> >> And I don't know any other Pascal Compiler who does any checks in
> >> this direction. Do some?
> > I don't know, but ADA reportedly does.
Yes, but the semantics of discriminants is slightly different than in PASCAL.
> I don't know the differences to Pascal. Does it ha
Henry Vermaak
> I can't understand what you are trying to say. An array is a pointer
> to where the elements of the array resides in memory.
No, not in Pascal. In Pascal an array is a variable just like any other: A name
for some memory area where values can be stored.
> How else do you think
Henry Vermaak :
> One thing I think you don't understand is that an array _is_ a
> pointer. Look at this table to visualise:
>
> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements
One thing I think you don't understand is that arrays and pointers are
orthogonal concepts in almost every o
mar...@stack.nl:
> In our previous episode, "Vinzent Höfler" said:
> >
> > One thing I think you don't understand is that arrays and pointers are
> > orthogonal concepts in almost every other programming language than C.
> >
> > So technicall
Henry Vermaak :
> Thanks for the explanation, I was under the impression that arrays in
> Pascal were similar to C. How do you explain the "automatic"
> dereferencing with a pointer to an array that Jürgen is talking about?
Those are dynamic arrays, IOW pointers disguised as arrays. This is part
Henry Vermaak :
> 2009/10/10 "Vinzent Höfler" :
> > Henry Vermaak :
> >
> >> One thing I think you don't understand is that an array _is_ a
> >> pointer. Look at this table to visualise:
> >>
> >> http://en.wikipedia.org/wi
Henry Vermaak :
> Please don't confuse your opinion with "right" and "wrong".
It's not just my opinion, that arrays and pointer are different things. One
might say it's a fact.
> Confusion and consistency were what this discussion was about.
Confusing code may have many properties. But I doubt
Marco van de Voort :
> And the criticism about introducing Cisms in FPC/Delphi is also old. In
> the past I would have joined you, but after a few non-trivial header
> conversions and library conversions that pretty much died out.
Yes. But that's not the fault of the C-language. That's the fault
Andrew Brunner :
> 1st benefit:
>
> declaring methods associated with classes before TIntArray needs to be
> defined or declared.
> eg. procedure DoSomething(Var Data:TIntArray); vs (DataP:PIntArray);
Huh? Is there any difference other than the second one can take a NIL value?
> Lastly, passi
mar...@stack.nl:
> > That simply means, the code is not documented. Again: Not entirely C's
> fault.
>
> Docs. Like anybody reads them.
Well, I do. If the coder cares to write any, that is. :)
Vinzent.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer,
Henry Vermaak :
> You said C did it "wrong", because you think that arrays and pointers
> should be different things.
No, I said so, because arrays and pointers *are* different things (even in C
there are subtle differences - which should sort of prove my point).
Apart from that, I expect my re
"Jürgen Hestermann" :
> And why should that be the case? What are the outstanding feature of C
> that make it so supperiour? It's illogical and hard to maintain syntax?
Its "Compile anything, crash everywhere." interface. :P
Vinzent.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und M
"Jürgen Hestermann" :
> Adding yet another variant is not good. I once thought that Pascal was
> superior to other languages because of it's clear and strict concept but
> now there is no longer *the* Pascal language anymore.
If you're searching for some stricter Pascal then maybe you should gi
Martin :
> The beauty of the current solution is that static and dynamic arrays can
> be substituted with each other, simple by changing the declaration, and
> adding/removing a setlength. All other code can be left as it is.
No, because of subtle differences in the handling of "out" parameters
Andrew Brunner :
> On Sun, Oct 11, 2009 at 5:25 PM, "Vinzent Höfler"
>
> Read up on forward declarations. The technique of declaring a typed
> pointer to any data structure in FPC and Delphi was that you can use
> it in fields and methods of objects and data structures
Graeme Geldenhuys :
> Now I know why vendors of newer languages (Dephi, Java etc) are trying
> to hide pointers from programmers. They are very tricky to work with -
> and give errors without warning!
Especially when compiler and programmer are both trying to outsmart each other.
:D
Vinzent.
-
mar...@stack.nl:
> The reason is probably more because Wirthian languages traditionally use
> recursive descent parsers.
Yeah, right.
The reason is most definitely that of all those people who know the language
well enough to write the grammar, there's no one actually doing it.
Of course, with
"Jürgen Hestermann" :
> > You can post an ad for a C
> > programmer and get 1,000 applicants, if you post an ad for a Pascal
> > programmer you might get 5, at least where I live.
Yes, and guess what: Odds are that there are more than 5 good ones out of the
1000 C-programmers than a single goo
Graeme Geldenhuys :
> Any programmer worth hiring should find it relatively easy to switch
> to another language. Or and least become proficient in it in a
> relative short period of time. The basic principles apply to all
> languages, it's just the tool-chain and syntax that differs.
Yes and no
Graeme Geldenhuys :
> I have been programming solely in Object Pascal for the last 9 years.
> I dab in Java every now and again (but not for any production
> software). I also read a lot of C/C++ code which I rewrite into Object
> Pascal for whatever reason. So just like me being able to read and
Holger Bruns :
> Accessing ports is limited to ports < 03ffh, more ports cannot be
> released with fpioperm. This means to me, successful serial port access
> on higher addresses cannot yet be implemented with fpc.
Or any other compiler, for that matter, because this is a system restriction.
P
Von: Holger Bruns :
> If I intend
> to use device drivers, I need to know how to access the ports of a
> device, which means in my case to a serial port based on the 16550D
> Universal Asynchronous Receiver/Transmiter with FIFOs.
No.
> I need to read
> and write every register of that UART a
Von: Holger Bruns :
> I am rather clueless while dealing with device drivers like /dev/ttyS0
> on linux. My question is, what do I grab while reading from a device
> driver file like /dev/ttyS0?
You don't read from a "device driver". You read from a "device". What you read
is usually called "d
Michael Van Canneyt :
> On Mon, 9 Nov 2009, Wimpie Nortje wrote:
>
> It should stop the daemons properly. This is the code that gets executed:
>
> Procedure DoShutDown(Sig : Longint; Info : PSigInfo; Context :
> PSigContext);
> cdecl;
>
> begin
>Application.StopDaemons(True);
>Applicati
Jonas Maebe :
> On 09 Nov 2009, at 21:03, Michael Van Canneyt wrote:
>
> > On Mon, 9 Nov 2009, "Vinzent Höfler" wrote:
> >
> >> As wrong as in "Don't call most system functions from within a
> >> signal handler.", maybe?
>
Graeme Geldenhuys :
> A very quick and dirty solution would be to reimplement the public
> Create() constructor and immediately raise an exception inside it,
> explaining the problem. That way if any developer tries to use that
> default constructor, they will get an error - instead of some silent
Graeme Geldenhuys :
[FillChar]
> As for the COM usage requirement (which I honestly believe is the
> minority use case in FPC).
AFAIK, the different semantic of "out" parameters applies to all reference
counted types. That's especially unfortunate with dynamic arrays, where you
lose transparenc
Florian Klaempfl :
> Out is not made to solve such problems but plainly to work with
> COM/Corba.
Really? Well, that's not what the FPC manual says:
-- 8< --
The purpose of an out parameter is to pass values back to the calling routine:
The variable is passed by reference. The initial value of
Holger Bruns :
> > Despite queues an baud rates, you must expect data loss. You will
> > loss data in the physical layer. You have to implement some handshake
> > to prevent it. (using google translator, excuse my english).
>
> Which can be done through a direct port access and some lines of cod
mar...@stack.nl:
[Synapse/Synaser]
> How do you use it? I'm used to TComport, and it seems that synaser, like
> unit serial, only supports blocking use.
call Connect, call Config, call the appropriate reading and writing subroutines
(like SendString and RecvPacket)...
> Do you put it in a threa
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >
> >> Out is not made to solve such problems but plainly to work with
> >> COM/Corba.
> >
> > Really? Well, that's not what the FPC manual says:
>
> And
Graeme Geldenhuys :
> 2009/11/19 "Vinzent Höfler" :
> >
> > Why don't you create your own initialization routine together with the
>
> Because not all the code I maintain is my own. Some code, as in the
> case of DCPCrypt gave stacks of hints which were al
Graeme Geldenhuys :
> On 19/11/2009, Jonas Maebe wrote:
> >
> > > Or is it just a side effect?
> >
> > Yes.
>
> Well it seems the "side effect" is more popular use-case in FPC and
> Delphi developers projects than the original intention of "out" then.
Of course. The side-effect is much more in
Rainer Stratmann :
> For me a variable is initialised when it passes a procedure/function
> which has a var declaration in the parameters.
-- 8< --
procedure Add_2 (var I : Integer);
begin
I := I + 2;
end;
-- 8< --
If the variable for the parameter I wasn't correctly initialized before, it
Martin :
> Ideally it would be, if there was a directive or similar, to suppress it
> for given lines (or statements).
> one that is easier than {$push} { $HINT OFF} ... {$POP}
{$HINTS OFF}
... code ...
{$HINTS DEFAULT}
maybe? Whereas DEFAULT restores the switch to the original state.
Vinze
Rainer Stratmann :
> Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
> >
> > {$HINTS OFF}
> >
> > ... code ...
> >
> > {$HINTS DEFAULT}
> >
> > maybe? Whereas DEFAULT restores the switch to the original state.
>
> But the
> I fear you've simply no clue about the usage,
> internals and purpose of dyn. arrays so I stop this discussion.
As you always do once someone does not share your point of view, even after you
tried so hard to convince him. :P Well, never mind.
Still, dynamic arrays are a bitch, because they on
Bihar Anwar
> Moreover, I've seen many Delphi code snippets out there (e.g.
> http://www.cs.wisc.edu/~rkennedy/array-delete) rely on reference counting
> behaviour.
Great. I once wrote code that relied on Turbo Pascal's heap list structure
internals.
Shall I post a bug report that this doesn't
> c> TList wraps TFPList, which is based internally on an array. So access
> c> is fast; insertion, deletion not.
>
> But it is faster than inserting elements in a dynamic array (unless
> reference counted ones) because it usually moves less amount of data
> (4/8 bytes per element).
Implementing
> 1)
> TheArray: array of ItemArray;
> AnyItem: ItemOfArray;
> [...]
> for j:=0 to 1000 do begin
>SetLength(TheArray,j+1);
>TheArray[j]:=AnyItem;
> end;
> [...]
About 1000 GetMem operations (and 1000 assignments which aren't there in the
code below, so I won't count them).
> Now h
> Saturday, May 8, 2010, 5:07:12 PM, you wrote:
>
> JM> And depending on the usage patterns and the size of the
> JM> elements stored in the array, it probably can be. That's all he
> JM> was saying, and only as a side remark in the context of the
> JM> discussion (which was meanly to steer away a
> Hello FPC-Pascal,
>
> Saturday, May 8, 2010, 4:42:46 PM, you wrote:
>
> VH> So, apart from a possibly more optimized implementation (like
> VH> not changing the allocated memory size on each single
> VH> insertion/deletion) how do you come up with the idea that adding
> VH> another layer would
Von: "Jürgen Hestermann"
> > it's just easier to follow the crowd
> > than fight them. :-)
>
> In the first place it is. But if it would be available, the crowd may
> change its mind.
No, she won't. She never did.
Vinzent.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt fre
Bihar Anwar
> I've tried googling and searching FPC mailing list for information about
> this one, but I found nothing.
> I just found in http://www.delorie.com/djgpp/v2faq/faq3_1.html that
> DJGPP requires MS-DOS version 3.1 or later.
>
> Would someone here tell me exactly about lowest MS-D
Bee Jay :
[TDateTime]
> What if an app need a precise and correct result, say a rocket launcher?
> :D Is there other alternative solution?
Yes. Use a time type based on a fixed point representation. This eliminates
drift and accuracy issues cause by a floating point representation.
http://stop-
"spir ☣" :
> Thank you. Using dos.getTime (including its last arg), the following
> returns integer time in 10^-2s units:
[...]
>
> This is the needed base for my uses. (A unit of 1s is too gross for
> timing, this leads to endless runs; more precision than 10^-2s is
> unneeded.)
Actually, the r
> On Tue, 01 Jun 2010 19:58:54 +0200
> "Vinzent Höfler" wrote:
>
> > "spir ☣" :
> >
> > > Thank you. Using dos.getTime (including its last arg), the following
> > > returns integer time in 10^-2s units:
> > [...]
> > >
> The standard clock for the system timer runs at 1,193,182 Hz, derived
> for the original IBM PC as the 4.77 MHz processor clock divided by 4.
Digging a bit deeper clarifies it:
http://sos.enix.org/lxr/source/hwcore/i8254.c?v=6.5
|* Ahhh PC systems are nice toys: this maximum "strange" freque
Reimar Grabowski :
> > If you want to get better than that, you need to get system specific,
> > I'm afraid.
>
> That's not true. As Graeme already mentioned there is EpikTimer which is
> a cross-plattform, high-resolution timer (which btw works very well for
> realtime tasks).
Well, that depends
spir :
> Theoretically speaking, I'm all for type checking; and for programming
> discipline in general. But in practice I never get type errors.
Then you are either a genius or you are using not enough types. ;)
> So, a few questions:
> * Do you get type errors?
Occasionally, yes.
> (playing
spir :
> Sure, but this is just a matter of convention and support by a given
> compiler:
> typeIntegers = array of Integer;
> var ints : Integers = [1,2,3];
> could work as expected by automatically sizing, allocating and
> initialising. How else could work languages that have
> On 26 July 2010 19:26, Thierry Coq wrote:
> >
> > I see units as namespaces already existing: we use the unit names to
> > prefix
> > ambiguous function or variable names for example.
>
> Unit Names give very limited namespace support - which only applies to
> types or procedures/functions or g
Marcos Douglas :
> > But then, IME (most) name conflicts are a sure sign of inproper names.
> Take the
> > example of "constants.pas": What sort of constants shall I expect there?
> Screen sizes,
> > color codes, electron mass or the gravitational constant?
>
> You right about "constants.pas".
>
On Fri, 15 Oct 2010 16:45:04 +0200, Andrew Brunner
wrote:
It was also suggested that PThread's Suspend and Resume may not do
anything. What I would do (if that is the case), is try to find where
PThread has access to the Semaphore or CriticalSection it has on that
thread...
Huh? Why should
On Fri, 15 Oct 2010 17:39:59 +0200, Andrew Brunner
wrote:
BTW: I did notice that the semaphore was being used to suspend the
thread. And I also know that that was it's only function... Suspend
and Resume.
The problem is not pthreads or anything, the problem is how the
semantics of the Classe
On Fri, 15 Oct 2010 18:19:14 +0200, Andrew Brunner
wrote:
On Fri, Oct 15, 2010 at 10:57 AM, Vinzent Höfler
wrote:
If you access it inside the execute method, you more or
less crash (or at least leak memory).
You obviously had a problem with access ThreadID before it was assigned
On Fri, 15 Oct 2010 20:15:51 +0200, Andrew Brunner
wrote:
On Fri, Oct 15, 2010 at 12:01 PM, Vinzent Höfler
wrote:
Exactly. It was poor implementation. You should have had a global
barrier onExecute. That would unlock the thread after everything you
needed was readable.
If it's g
1 - 100 of 149 matches
Mail list logo
