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
e.g.) and
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
On Saturday 17 October 2009, Florian Klaempfl wrote:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
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
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 faster?
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_FIRST}
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 would
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.
OMG. I'm s confused. ;) I read
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, as any
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
the two bytes,
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 in a
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
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
I did not yet use the preprocessor in Pascal but a standard way to
access memory mapped ports in C is something
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
You mean like ADA? Indeed, I
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote:
Then use bitpacked records:
If you'd document them properly?
-- 8 --
type
TX = 1 .. 4;
TY = 0 .. 3;
type
Foo = bitpacked record
A : TX;
B : TY;
end {record};
var
X : Foo;
begin
X.A := 1;
X.B := 2;
On Wednesday 27 February 2008 11:45, Florian Klaempfl wrote:
Vinzent Hoefler schrieb:
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
Vinzent Hoefler wrote:
If I mean to set the write buffer water mark of the SDRAM
controller
register, I'd rather write
On Wednesday 27 February 2008 12:33, Daniël Mantione wrote:
Too many Ada-features have crept into Pascal over the years. ;)
You can look at it that way, but Ada wasn't the blueprint for Pascal
extensions.
Well, in the early days, it was quite the other way around, yes. Ada is
derived
On Wednesday 27 February 2008 12:56, Jonas Maebe wrote:
On 27 Feb 2008, at 12:17, Vinzent Hoefler wrote:
Free Pascal Compiler version 2.0.0 [2005/09/09] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
test.pas(6,10) Error: Identifier
On Wednesday 27 February 2008 12:21, Daniël Mantione wrote:
Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
Well, TP didn't, and until now I found no real documentation on it
(it sure wasn't mentioned in *my* copy of the programmer's manual).
That is correct, but the last version of TP
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 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 compile. Which is justified, because in 99
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 additional
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 Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
Something like: Create a group of 4 threads named 0,1,2,3 and execute
a procedure/method?
for i := 0 to 3 do
Handle[i] := tThreadId(BeginThread (Func {tThreadFunc},
On Friday 14 December 2007 09:37, Felipe Monteiro de Carvalho wrote:
On Dec 13, 2007 7:55 PM, Mattias Gaertner [EMAIL PROTECTED]
wrote:
Has someone already created a unit for light weight threads?
I don't know much on the subject, but Is TThread heavy? What are the
disadvantages of using
On Friday 14 December 2007 10:20, Florian Klaempfl wrote:
I think some thread pool class is more important, it would be
basically the same as above
for i := 0 to 3 do
Handle[i] := TTask(ThreadPool.QueueTask(Func {tThreadFunc},
@FuncArg[i]));
for i
On Friday 14 December 2007 11:46, Mattias Gaertner wrote:
For many parallel algorithms you don't
need events, priority or synchronize. But you need to easily and fast
start a set of threads with IDs 0..N.
Ok, so you're mostly caring about the thread creation overhead, it
seems.
So yes,
On Tuesday 11 December 2007 10:04, Michael Schnell wrote:
Andrew Haines wrote:
Hi,
Is it possible to make this work:
if X 3 or 10 then ...
of course it would be shorthand for: if (X3) or (X10) then
The or operator is stronger than the operator by definition.
This can't
On 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 a
Hi all,
after we had that quite heated discussion in core, I decided to take
matters into my own hand and come up with some useful proposal. But now
I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate.
The thing is that I don't know if those are actual bugs, design
On 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
the issue.
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
Maybe other way to detect SSE support exists...
CPUID?
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
Maybe other way to detect SSE support exists...
CPUID?
To be more precise, the way recommended by Intel:
To make this check, execute the CPUID instruction with an argument of 1
On Thursday 14 June 2007 06:42, Florian Klaempfl wrote:
Why do you need a plug in mechanism? You've the sources? When you
have the sources, 90 per cent of the use of a plugin are gone.
Well, we'd call that non-intrusive change. ;)
You'd just need to compile the plug-in, and not a changed
On Wednesday 04 April 2007 15:29, Sergei Gorelkin wrote:
That is exactly what I'm speaking about. Removing 'Windows' from
uses clause is essentially stopping using it :) And if the code
continues to compile and work after that, it is just fine.
Sorry, I always forget that most people are not
On Thursday 05 April 2007 09:16, Sergei Gorelkin wrote:
It appears that my way of thinking has been severely affected by
using IDEs. When putting mouse over identifier shows where it comes
from, prefixing seems redundant :)
Prefixing *is* redundant, that's the whole point of it, but it also
On Wednesday 04 April 2007 10:33, Sergei Gorelkin wrote:
I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on
InitializeCriticalSection and DeleteCriticalSection symbols.
If I had to guess, I'd say this is probably because those
On Wednesday 04 April 2007 12:59, Sergei Gorelkin wrote:
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing names.
Therefore, to make my code cross-platform, I have only to remove
Windows from uses clause - then
On Wednesday 04 April 2007 13:13, Micha Nelissen wrote:
Sergei Gorelkin wrote:
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing
names. Therefore, to
They shouldn't be exposed publicly in the system unit.
On 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 13:06, Daniël Mantione wrote:
Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
program
Case_Test;
type
My_Range = 2000 .. 3000;
var
X : Integer;
begin
X := 2500;
case X of
Low (My_Range) .. High (My_Range) : WriteLn
On Thursday 15 February 2007 13:36, Daniël Mantione wrote:
Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
Well, fair enough, but why is that I can declare a
type
Foo = array[byte] of Something;
where the type name byte also indicates the range? Considering
that
type
On Friday 19 January 2007 13:12, Marco van de Voort wrote:
There is one dangerous caution against overzealous inifile use: with
lessened privileges (a situation that is going to become more
frequent under Vista, iow, user has no admin rights), apps can't
write to program files/ with the
On Friday 19 January 2007 13:23, Michael Van Canneyt wrote:
HKEY_USER keys is not desirable or feasible (roaming profiles etc). A
config directory can be made read/write for all users.
A registry key can be made that, too.
Vinzent.
___
fpc-devel
On Thursday 09 November 2006 08:22, Michael Schnell wrote:
Yes, of course, this still *is* nothing more than an event loop,
...
A decent event loop should use an OS API to free the processor until
the next event is scheduled:
That's why I wrote the example in Esterel.
Give me that API and
On Wednesday 08 November 2006 09:27, Ales Katona wrote:
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Michael Schnell wrote:
As for general use, you can't do a Timer this way.
Right
On Wednesday 08 November 2006 10:01, Michael Schnell wrote:
But doing a function call (or hence using a callback) does not change
the thread context you are running in and thus you are still the same
thread. IOW: code lines are not _dedicated_ to a thread context.
Oh that, of course. Seems
On Wednesday 08 November 2006 10:14, Michael Schnell wrote:
If you take a look the start of this thread, I mentioned that after
implementing Delphi/Lazarus like behavior for the main thread without
the need for a GUI, I'd like to enhance the concept by optionally
having an TApplication object
On Wednesday 08 November 2006 10:26, Ales Katona wrote:
This is an old problem, and not fixable by wishing it. If you want a
good async. timer, sure make one, but don't expect it to work safely
by magic.
I'm sure I won't, I'm paranoid. :)
That's what I ment, it won't simply just work
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote:
Sorry for all the confusion, I'm trying to clarify what I actually mean
(or what I would *expect* from such a timer object):
I don't see how async timers can be useful for software (maybe to
control hardware perhaps, but only the
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
Vinzent Hoefler wrote:
So, the semantics would be about the same as in a signal (apart
from the softer timing), but you would have much less
restrictions in the handler's implementation compared to a real OS
signal, which acts
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote:
Vinzent Hoefler wrote:
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
is totally impossible to work? To implement something less crude
you
It works,
Oh wonder. A couple
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote:
Vinzent Hoefler wrote:
but it's not realtime by any definition.
First, I never said real-time in that context and second: it sure
can
I concluded that from your quote:
meta-quote
Timing events allow for a handler
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote:
Vinzent Hoefler wrote:
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very
common misconception. which I still refuse as being a correct
answer
On Tuesday 07 November 2006 09:17, Micha Nelissen wrote:
Chris Cheney wrote:
Of course, the efficient way to build a sorted list is to set
Sorted to False and to sort the list after all the items have been
added.
It doesn't matter in O-time: both are O(n log n). Nevertheless, you
On Tuesday 07 November 2006 12:42, Ales Katona wrote:
If you want a Timer a polling mechanism has to take place which
looks if something happened on some timer for example,
Is that so?
OnTimer is ready to be fired (you can't call callbacks in threads,
I can't call callbacks in threads?
On Tuesday 07 November 2006 14:47, Michael Schnell wrote:
Well, for me it would have saved me some time which I wasted in
creating threads that implement timing events by simply sleeping
for a particular time.
IMHO this should be done following the Delphi paradigms to be nice to
Delphi
On Tuesday 07 November 2006 15:17, Ales Katona wrote:
So eg: if you want to do something every 1000ms, you could put a
TThread based timer in, and make it Sleep(1000) and then call the
code, but you must be sure that your main thread cannot have
conflicts if this code is called at any time
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which works in it's own thread and then calls some
callback in it's own thread,
I even call the callback of another thread. :P
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in multi-threaded or even interrupt.
That is not true ! (See my other post.)
Well, a timer is, even though the Delphi implementation of a so-called
TTimer object
On Thursday 19 October 2006 08:31, Marc Weustink wrote:
The case shows that users can do this. There is no language construct
that forbids it. So optimizing this with a smart linker may break
such code.
Yes, it may. So what?
There's hell a lot of code that is generally possible within the
On Thursday 19 October 2006 09:39, Marc Weustink wrote:
The only thing guaranteed by the language is that if you follow its
definitions, it will compile.
No. That's syntax. I'm talking about semantics.
Vinzent.
___
fpc-devel maillist -
On Tuesday 17 October 2006 09:03, Jonas Maebe wrote:
On 17 okt 2006, at 10:44, Daniël Mantione wrote:
procedure intRTLEventSetEvent(AEvent: PRTLEvent);
var p:pintrtlevent;
begin
p:=pintrtlevent(aevent);
pthread_mutex_lock(@p^.mutex);
pthread_cond_signal(@p^.condvar);
On Tuesday 17 October 2006 09:46, Jonas Maebe wrote:
On 17 okt 2006, at 11:22, Vinzent Hoefler wrote:
The pthread_cond_wait() function atomically unlocks the
mutex argument
and waits on the cond argument.
So the mutex should already be unlocked afterwards.
If you would
On Tuesday 17 October 2006 10:03, Micha Nelissen wrote:
Windows events do not have this problem since they are stateful.
To be more precise: Windows signals are persistent, not transient like
Unix signals are.
Vinzent.
___
fpc-devel maillist -
On Thursday 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 10 October 2006 08:29, Florian Klaempfl wrote:
Daniël Mantione wrote:
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas
resulting in
On Thursday 05 October 2006 08:13, Michael Van Canneyt wrote:
On Thu, 5 Oct 2006, Joost van der Sluis wrote:
Now I'm thinking about using an interface, to avoid double code.
But I don't know what effect that has on run-time performance. I
mean, the idea was to make if faster ...
An
On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote:
At my workplace we've standardized on using three scope prefixes:
p_ for function parameter, m_ for members/fields, and g_ for global.
I know that discussion, I lost it at work already, but apart from C
where every identifier is sort of
On 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.
Hi,
some questions:
1) Is there some good reason why the support for the inline keyword can
be turned on and off explicitely by the {$INLINE} directive?
2) Can I check somehow if inlining is enabled during compilation?
{$IFOPT INLINE} didn't work. ;)
2a) If the answer to 2) is no, can we
On Monday 17 July 2006 15:33, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Of course they don't. Unlike some other languages where such things
are standardized quite clearly, (most) consistency, dependency and
linking issues are beyond the scope of the official C-standard.
I'm not talking
On Monday 17 July 2006 15:03, Micha Nelissen wrote:
No these are separate things. The C compiler vendors do not provide a
common platform resulting in a differing mess that has to be held
together with scripts.
Of course they don't. Unlike some other languages where such things are
On Thursday 13 July 2006 12:31, Jose Manuel wrote:
The error code is: 193 0x00C1 N/A %1 is not a
valid Win32 application.
But that doesn't make sense.
[...]
I guess FPC is creating the DLL with no relocation section in it.
Another issue is that meaningless error. It should be
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
How can I zero-pad using Format ?
RTFM. :-)
SysUtils.Format ('%.4D', Some_Int);
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Tuesday 20 June 2006 11:39, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
How can I zero-pad using Format ?
RTFM. :-)
SysUtils.Format ('%.4D', Some_Int);
Sounds like I found a case where 'C' is more intuitive than pascal
On Wednesday 17 May 2006 20:50, Marco van de Voort wrote:
Having to check and guard each and every string operation is also not
really productive. KR tried that :-)
And I thought they did it the other way around. Leaving the check as an
exercise to the coder. ;-)
Vinzent.
On Tuesday 21 March 2006 04:37, Michalis Kamburelis wrote:
I'm concerned with using DivMod in cases when Dividend is 0. DivMod
declaration is
procedure DivMod(Dividend: Integer; Divisor: Word; var Result,
Remainder: Word);
which means that it doesn't allow for Result and Remainder to
On Wednesday 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 09:25, Micha Nelissen wrote:
Marc Weustink wrote:
If the generic is precompiled (which is maybe necesary if you
need access to privates) then I fear some runtime logic has to be
added to call the correct procedure. IE. something like
case TypeInfo(Data) of
On Friday 04 November 2005 13:00, Micha Nelissen wrote:
Combining some of the wiki ideas, and has no evil characters
:-).
I don't understand the fuzz about using . It's not even close to
being C(++)-ish, because it was used for describing discrete range
types _at least_ in Ada's generics
On Friday 04 November 2005 13:27, Marco van de Voort wrote:
[]
The evil is in
- using characters instead of modifiers.
- worse, recycling already used characters.
Alright, I completely understand at least the first part, so perhaps
they should simply not be overused. :-)
Just for the fun
On Thursday 07 July 2005 21:27, Marcel Martin wrote:
Vinzent Hoefler a écrit :
Personal note: Maybe there was a reason why Borland Pascal didn't
do range checks on Inc/Dec.
Yes, there is always a good reason for a bug :-)
Any sufficiently advanced bug cannot be distinguished from
On Friday 08 July 2005 10:49, Gerhard Scholz wrote:
Beside, v is word or byte, depending on a compiler-$if elsewhere, so
I would have to write:
inc ( {$ifdef big} smallint {$else} shortint {$endif }v, delta ) ;
Not very clear readable.
Agreed. It's not readable at all. So don't do that,
On Friday 08 July 2005 12:24, Gerhard Scholz wrote:
- Original Message -
From: Vinzent Hoefler [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Friday, July 08, 2005 1:24 PM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
OTOH, ...
new abbreviation
On Friday 08 July 2005 12:39, Tom Verhoeff wrote:
On Thu, Jul 07, 2005 at 07:47:03AM +, Vinzent Hoefler wrote:
operators. So especially with the added overflow check I think,
Inc and Dec are pretty useless functions, because the don't do
anything you can't accomplish by using
On Friday 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 Friday 03 June 2005 10:47, Jamie McCracken wrote:
It makes it more clear IMO not less. having all that interface code
and having to jump between it and the implementation does not aid
legibility.
It encourages reading code instead of interface specifications. Often
there is a big
On Thursday 02 June 2005 16:12, Marco van de Voort wrote:
Begin..End is redundant - you have to indent them to make em
readable anyways.
No. This makes the code more readable like normal english text. It
states much more clearly what it intents, at least much more than
just indenting
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms of _working_ lines of code? :-
Vinzent.
--
public key:
On Thursday 02 June 2005 13:22, Jamie McCracken wrote:
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer then :)
No, that's a common
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice as fast,
the maximum
On Thursday 02 June 2005 14:24, Jamie McCracken wrote:
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing my application.
I typically spend 80% of my development time
On Thursday 02 June 2005 14:44, Jamie McCracken wrote:
My point is to to reduce or remove *redundant* syntax that serves no
useful or productive purpose (to the programmer).
Well applied redundancy is a good thing.
Forward declarations are redundant - they exist purely for the
benefit of
On Thursday 02 June 2005 15:16, Uberto Barbini wrote:
If the goal is this, I'd prefear a way to declare objects
autocreated:
varauto:
strlist: TStringList;
begin
//some stuff
end;
[...]
It could be a problem to pass parameters to the constructor.
Yes, exactly. So why bother the
On 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
1 - 100 of 114 matches
Mail list logo
