On Saturday 24 October 2009, Sergei Gorelkin wrote:
> I want to remove the avl_tree-related stuff from DOM unit. The
> reasons are:
If that's a CfV, I vote "yes".
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasc
On Monday 26 October 2009, Micha Nelissen wrote:
> Vinzent Höfler wrote:
> > At first, "const function" would tell us that the function does not
> > change the object in any way, right?
>
> What is "the object"?
In that case, the list, of course.
> Usually there are 2 objects: the list (TList
>
On Saturday 17 October 2009, Florian Klaempfl wrote:
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >> From a compiler developers point of view, it makes optimization
> >> easier under certain cases (e.g. virtual method calls). It's the
> >> same as with inline: inline has no advantage except t
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it
looks quite different (and I'm not sure about all the types used here,
some seem to be sets, some enumerations). But at the first glance it
seems, they used both packed records to either ensure minimum size or
known record l
On Thursday 28 February 2008 13:09, Michael Schnell wrote:
> > Yes. That's what {$BIT_ORDER} would stand for (still, it would not
> > change *byte* order).
>
> I don't understand this. I don't think the bit order within a byte is
> to be considered changing.
Well, the question is, if the first bit
On Thursday 28 February 2008 12:17, Michael Schnell wrote:
> > Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits
>
> With an x86 the "leftmost bits" will be in the "rightmost" (second)
> of the two bytes,
>
> with an 68K the "leftmost bits" will be in the "leftmost" (first) of
> t
On Thursday 28 February 2008 11:28, Michael Schnell wrote:
> > AFAICS, it would be useful for bitpacked records only, so it could
> > appear anywhere where a {PACKRECORDS} directive or similar can
> > appear currently.
>
> IMHO it would only be useful (allowed with, regarded by) bitpacked
> record,
On Thursday 28 February 2008 11:25, Daniël Mantione wrote:
> Op Thu, 28 Feb 2008, schreef Vinzent Hoefler:
> > On Thursday 28 February 2008 09:16, Daniël Mantione wrote:
> >> Memory access. What happens is that the non-packed version causes
> >> more cache misses.
&
On Thursday 28 February 2008 10:01, Michael Schnell wrote:
> > {$BITORDER LOW_ORDER_FIRST}
> > {$BITORDER HIGH_ORDER_FIRST}
>
> Where can this be used ? What exactly does it mean ?
Well, call it proposal (of course, the names are strongly influenced by
personal language preferences).
AFAICS, it
On Thursday 28 February 2008 09:51, Micha Nelissen wrote:
> Well we have procedures to do byte swapping, but none to do bit
> swapping. It's also very inefficient AFAIK; while changing the
> compiler's definition of which bit to use is "free".
{$BITORDER LOW_ORDER_FIRST}
{$BITORDER HIGH_ORDER_FIR
On Thursday 28 February 2008 09:16, Daniël Mantione wrote:
> Memory access. What happens is that the non-packed version causes
> more cache misses.
Please elaborate. If the (unaligned) data is crossing a cache-line, thus
causing two full cache-line reads, I'd understand that, but once it's
in t
On Tuesday 26 February 2008 17:27, Luiz Americo Pereira Camara wrote:
> Yury Sidorov wrote:
> > The patch removes packed record for some platforms.
> > IMO packed can be removed for all platforms. It will gain some
> > speed.
>
> I'd like to understand more this issue.
> Why are non packed records
On Wednesday 27 February 2008 15:56, Michael Schnell wrote:
> In the Linux source code preprocessor macros are used if data
> structures are accessed that require a certain endianess (usually
> "net"- data that are defined high byte first by TCP/IP).
>
> Here clever tweaking provides that no additi
On Wednesday 27 February 2008 14:15, Florian Klaempfl wrote:
> Vinzent Hoefler schrieb:
> > And that's why I'd rather go with Ada's representation clauses. If
> > the hardware platform is unsuitable for the thing I want it to do,
> > it simply doesn't compi
On Wednesday 27 February 2008 13:55, Jonas Maebe wrote:
> And no, I'm not saying it's your fault if something you use breaks in
> a newer release, I'm merely saying it's nobody else's fault in
> particular either (at least not most of the time).
Hey, I wasn't trying to blame anybody here.
I was
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
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 tes
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 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
>
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 al
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 l
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 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, h
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]));
>
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 u
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 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 (X>3) or (X<10) then
>
> The "or" operator is stronger than the "<" operator b
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 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
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
decisions
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
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
> > t
On Wednesday 11 July 2007 06:39, Florian Klaempfl wrote:
> That's a point though I thought we could safe this extra check
> because I didn't expect that a lot of people are still using PII :)
Well, if the OS supports SSE and thus no SIGILL is generated, what would
be the point in using CPUID to
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
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 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 com
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 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 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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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: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: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 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 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: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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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
1 - 100 of 137 matches
Mail list logo
