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 ev
On Thursday 17 February 2005 07:37, Marco van de Voort wrote:
> type myset = set of ( a1,a2,a3,a4,a5,a6);
>
> // workaround types
> const
> beginmyset=ord(low(myset));
> endmyset=ord(high(myset));
> type
> uglyenum = beginmyset..endmyset;
> uglyset= set of uglyenum;
>
> var b :
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. Su
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
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
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 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 e
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
&g
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 Monday 25 April 2005 12:10, Florian Klaempfl wrote:
I hate to possibly annoy someone here, but I didn't get an answer yet,
if this will be fixed or not...
> It's simply a thing to make life easier especially for beginners. I
> don't know a real reason why the arrays shouldn't be considered eq
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 ther
On Monday 23 May 2005 09:25, Marco van de Voort wrote:
> > On Sunday 22 May 2005 10:17, Tomas Hajny wrote:
> >
> > Alright. How much time would someone need for that task? Or, to be
> > more specific: what is known to need high priority work to get the
> > most basic stuff of a DOS-Compiler working
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 checke
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 m
On Wednesday 25 May 2005 13:12, Lee, John wrote:
> Just put a v2.1.1 basedos.zip (compiler & rtl only) snapshot which I
> just made on win me, using supplied makes into ftp.freepascal.org
> .../snapshot/v21/. Used .../snapshot/v21/source/ . Not tested much,
> but it works for hello world program a
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 ar
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
http://lists.freepascal.org/mailman/listinfo/
On Thursday 26 May 2005 20:27, Gerhard Scholz wrote:
[**] operator precedence left-right, right-left
> yes, exactly like this.
>
> and other compilers also follow this scheme,
Or doesn't compile it at all because of the possible ambiguity when
there are no explicit parentheses.
Vinzent.
Hi,
attached a patch which reenables (at least according to my tests) the
SIGINT and SIGTERM key handling which is a strong indication that
exception handling might work again. Further tests regarding exception
handling should be done yet. I'm onto it.
So, if nobody complains, I hereby apply f
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: http://www.t-domaingrabbing.ch/
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#.
> >
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 m
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 hi
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 tim
On Thursday 02 June 2005 13:54, Sebastian Kaliszewski 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#.
>
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 both
On Thursday 02 June 2005 15:13, Sebastian Kaliszewski wrote:
> So here is some little idea which seems to me Pascalish enough to be
> considered:
>
> how about new keyword: local
> Class variable declared local will be automatically freed upon every
> exit from the scope (i.e. something along the
On Thursday 02 June 2005 15:23, Jamie McCracken wrote:
> Vinzent Hoefler wrote:
> >>manual memory management of tobjects is redundant as you can get
> >> good performance with ref counting tobjects.
> >
> > That can be a point, yes. But it is somehow not related to
On Thursday 02 June 2005 15:53, Sebastian Kaliszewski wrote:
> Vinzent Hoefler wrote:
> > On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote:
> >
> > No, they aren't (or let me put it this way: It depends on what you
> > measure). For instance, studies i
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 discre
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
> > j
On Friday 03 June 2005 14:52, Sebastian Kaliszewski wrote:
> Vinzent Hoefler wrote:
> >>If you didn't notice I wrote "C nothwithstanding". C is far away
> >> from modern high level languages (and also many older than it but
> >> hight level langua
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 05:39, Peter Vreman wrote:
> > shouldn't it implement inv(v,-1) in exactly the same way it
> > implements v:=v-1?
>
> The problem is what type do you give to -1. In the old situation the
> -1 was converted to the same type as v -> longword.
Which should trigger a range ch
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
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 tha
On Friday 08 July 2005 12:24, Gerhard Scholz wrote:
> - Original Message -
> From: "Vinzent Hoefler" <[EMAIL PROTECTED]>
> To: "FPC developers' list"
> Sent: Friday, July 08, 2005 1:24 PM
> Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
>
On Friday 08 July 2005 12:39, Tom Verhoeff wrote:
> On Thu, Jul 07, 2005 at 07:47:03AM +0000, 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
> > an
On Friday 04 November 2005 09:25, Micha Nelissen wrote:
> Marc Weustink wrote:
>
> > If the generic is "pre"compiled (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 TypeI
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 ge
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 th
On Friday 04 November 2005 13:48, Vinzent Hoefler wrote:
Stupid KMail. Deleted the text after file's eof.
After the file there was supposed to be a remark about that the example
does not compile as is, because generics in Ada are different from C++
templates, which are merely more like m
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 Remain
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. K&R 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
http://lists.freepascal.org/mailman/listinfo/fp
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);
>
&
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
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
standar
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 of
On Tuesday 25 July 2006 14:42, Graeme Geldenhuys wrote:
> Sorry, I added the two Size() functions as a last minute and only
> after sending the patch I noticed that it breaks the FPC build!
> Sorry!
>
> I attached another patch, without the Size() functions... Anybody
> know how we can get around
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 ma
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.
Alth
On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> Chris Cheney wrote:
> >> I'm pretty sure he means that no can no longer, for example, copy
> >> a function from one class to another, without risking having to
> >> rewrite all the parameter names.
> >
> > You have understood me correctly - I
On Tuesday 03 October 2006 11:15, Micha Nelissen wrote:
> On Tue, Oct 03, 2006 at 07:36:11AM +0000, Vinzent Hoefler wrote:
> > On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> > > Ok, so enforcing different names is good then, that makes code
> > > more
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
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 ...
>
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
> >> http://www.hu.
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^.condv
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
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 - fpc-deve
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, yo
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 threa
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
On Tuesday 07 November 2006 15:02, Michael Schnell wrote:
> > I always thought a timer is more comparable to an interrupt or
> > signal than a polling loop.
>
> That is a very common misconception.
Indeed. Even a paper in "Embedded Computing Design" about Ada 2005
follows that "very common" misc
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
TTim
On Wednesday 08 November 2006 09:15, Michael Schnell wrote:
> Right ! The beauty of TTimer (and GUI events as well) is that it does
> not work in a thread.
Well, I don't consider it beautiful, I consider it a hack. :)
Vinzent.
___
fpc-devel maillist
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 ! The beauty of TTimer (and GUI events as well) is that it
> > does not work in a thread. Otherwise it e.g. would not b
On Wednesday 08 November 2006 09:27, Ales Katona wrote:
> On st , 2006-11-08 at 07:35 +0000, 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. :)
&
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 u
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. Seem
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 obj
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 wi
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 tri
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 implementat
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 somethi
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 qu
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."
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 A
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
Hi all,
consider the following program:
-- 8< --
program
Case_Test;
type
My_Range = 2000 .. 3000;
var
X : Integer;
begin
X := 2500;
case X of
Low (My_Range) .. High (My_Range) : WriteLn ('In range. (1)');
My_Range : WriteLn ('In range. (2)'
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
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 "
On Thursday 15 February 2007 14:46, Daniël Mantione wrote:
> Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
> Because, in a case statement you are already "inside" the brackets:
Yeah, I sort of figured that. ;)
> > Another oddity would be a for loop:
> >
>
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
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 no
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
1 - 100 of 137 matches
Mail list logo
