Re: [fpc-devel] New feature discussion: for-in loop

2009-10-31 Thread Vinzent Hoefler
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 the object being iterated, e.g. TList.Objects[I]. Those
 referenced objects can be volatile, the const-ness only applies to
 the TList.

Yes, that's what I thought.

 Ideally the iterator state and the state of the items 
 iterated over are separated. (Maybe this is not so with e.g.
 TStringList).

Suppose, the list items have a property Owner and the iterator calls 
some method that says Owner.Delete (self); somewhere. How's the 
compiler supposed to detect that?

In some languages, this problem is circumvented by creating a copy of 
the list before iterating the set, but I don't think that this is a 
viable solution for Pascal (or any compiled language, for that matter).


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Want to remove AVL_Tree from DOM

2009-10-31 Thread Vinzent Hoefler
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.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] class abstract, class sealed implementation. please review.

2009-10-17 Thread Vinzent Hoefler
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 advantage except that it is a
  hint to the compiler how the code can be optimized.
 
  I really doubt that sealed is just meant as hint to the compiler
  that the VMT remains static or something.

 It might be more but at least from compiler developer's point of view
 it can be used for this.

Well, yes. And from the programmer's PoV inline can be used as a 
restriction to prevent pointers to such functions. ;)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
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?
 The difference occurs at memory allocation or at memory access?

At memory access.

On x86 processors it's usually only a speed penalty (or has anyone ever 
seen the AC flag turned on?), on other processors you may even have to 
workaround exceptions (i.e. bus errors), because the processor simply 
refuses to read or write unaligned data. And then the only way to 
circumvent the processor's refusal is to read/write the data byte by 
byte or mask it out, which is slower than just reading or writing it.

Consider writing a 16-bit value spanning across 32-bit-values where the 
processor can only access a single 32 bits value at an aligned address:

*_ _ _ _*_ _ _ _
|0|1|2|3|4|5|6|7|
|___|

Now the data you need is spanning across bytes [2:5], but the processor 
can only read full 32 bits either at position 0 (reading bytes [0:3]), 
or position 4 (reading byte [4:7]). You'd need to read both processor 
words, mask the data in the lower and upper half of each and write back 
both words with the new data patched inbetween them.

So by now, no matter if the processor handles it for you or if the 
compiler would insert the necessary code to do it, even a simple 
increment is insanely expensive in terms of processor cycles.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
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}

?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
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 be useful for bitpacked records only, so it could 
appear anywhere where a {PACKRECORDS} directive or similar can appear 
currently.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
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 that the packed version causes more 
cache misses here. That was the part where I didn't understand why.

  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 the cache, it wouldn't matter anymore?

 Yes, but if you have an array of them (as we have in this case),
 considerably more of these records will fit in the cache.

Yes, that's what I figured, so I'm on the same path as you here, it 
seems, but tracing back the discussion it read:

-- 8 --
 I'd like to understand more this issue.
 Why are non packed records faster?

Cache trashing. One of the most underestimated performance killers in 
modern software.

 The difference occurs at memory allocation or at memory access?

Memory access. What happens is that the non-packed version causes more 
cache misses.

-- 8 --

The first part tells me non-packed records are faster, but the second 
line tells me that the non-packed version also causes more cache 
misses, thus is slower. That got me confused, I think.

Of course, the net result only depends on the benchmark you're using. ;)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
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 other data representation is supposed to be optimized
 for speed according to the processor architecture.

Hmm, not necessarily. I frequently use enumeration types to express the 
meaning of a set of hardware bits. So thinking about it, what if I'd 
use enumerations in a bitpacked record? Maybe like this:

-- 8 --
type
   // 2 bits.
   Enable_Set = (Dont_Care := 0,  // 00
 Disable   := 1,  // 01
 Enable:= 3); // 11

type
   Control =
   bitpacked record
  Continuous_Mode   : Boolean;// bit 0/rightmost bit
  Alternate_Compare : Boolean;// bit 1
  ...
  Enable_Mode   : Enable_Set; // bit 14 .. 15/leftmost bits
   end;
-- 8 --


I don't know if FPC can pack enumerations into a bitpacked record at 
all, but if it does, it might consider the bit order here, too.

Consider something like:

-- 8 --
var
   My_Set: Enable_Set;
   My_Record : Control;
   

My_Set := My_Record.Enable_Mode;
-- 8 --

How should the assignment be handled if the bit order for that bitpacked 
record is changed?


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
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,

Yes, bad example, because we already crossed the byte boundary. The real 
question about leftmost and rightmost was on which data line each bit 
would appear.

(Usually it's called most significant bit, but as we're talking about 
hardware bits, not numbers, I wouldn't use that term. In this context, 
no bit is necessarily more significant than the other.)

 So the two can't communicate this record via files or via network.

 If you want to have them understand each other, you need to define
 the edianess of the record independently of that of the processor.

Yes. That's what {$BIT_ORDER} would stand for (still, it would not 
change *byte* order).

 Enumerated types don't help here.

They weren't meant to solve the issue, they were meant to help to 
understand the issue I was trying to point out.

The question was, how to interpret the enumeration values, if their bit 
order could/would differ from that of the record they're in.

Should they be put in as is or swapped accordingly?


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
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 record is the leftmost or 
the rightmost bit.

It's a matter of interpretation. But as Jonas pointed out, the order of 
the bits may change depending on the endianess (assuming I didn't 
misunderstand him).

 I would call the issue byte-order and (thus I'd prefer something
 like {$BIT_PACKED_BYTE_ORDER} or {$BIT_PACKED_ENDIAN}.

It's not byte order.

If I declare:

|bitpacked record
|   X : Byte;
|   Y : Byte;
|end record;

X will still be at the lowest address and Y will be at @X + 1. The issue 
arises when I say:

|bitpacked record
|   X : Boolean;
|   Y : Boolean;
|   Z : Two_Bit_Enum;
|end;

Assuming, bit 0 is the LSB, does the compiler access bit 0 and 1 (low 
order first) for X and Y or does it choose bit 7 and 6 (high order 
first) then? And how would it interprete a specific value for Z? At 
least two interpretations are possible:

X:7, Y:6, Z[5:4]   or   X:0, Y:1, Z[3:2]

ASCII graphic:

  |X|Y|Z|Z|-|-|-|-|
  |-|-|-|-|Z|Z|Y|X|

Ok, I guess, the issue with the enum is none, because the LSB is still 
at the right place on the data bus, no matter how you look at it. So 
forget that. ;)


Of course, there are more nasty things like

|bitpacked record
|   X : Boolean;
|   Y : Byte;
|end;

where a single value would cross the byte boundary... *headscratch* I 
guess, there's a reason, why endianess issues are not automatically 
handled by the compiler. :D


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
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 layout (maybe they even used the structure in some 
assembly module?), and also aligned them manually to avoid unaligned 
access issues.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 like this (from the top
 of my head):


 #define _port = 0x87

 #define ByteIO(p) *(((volatile unsigned char)*)(p))

 #define port=ByteIO(_port)

-- 8 -- snip --

with Interfaces;
with System.Storage_Elements;

procedure Foo is
   --
   -- Declare a reusable volatile 8 bit IO port type.
   --
   type IO_Port is new Integer range 0 .. 255;
   for IO_Port'Size use 8;-- 8 bits, of course.
   pragma Atomic (IO_Port);   -- Sort of superfluous here.
   pragma Volatile (IO_Port);

   -- Make address conversions directly visible,
   -- but only inside Foo here.
   use System.Storage_Elements;

   -- Now declare a (volatile) IO port variable,
   -- and tell its address.
   My_Port : IO_Port;
   for My_Port'Address use To_Address (16#87#);
begin
   -- Assign the 0x55 value to the 0x87 address.
   My_Port := 2#01010101#;
end Foo;

-- 8 -- snip --

Although it's a whole lot of declarations for this simple:

-- 8 --

_ada_foo:
.LFB3:
movb$85, 135
ret
.LFE3:

-- 8 --

So, given the right choices, neither C, nor a preprocessor is needed.

And hell, preprocessors sometimes are even forbidden for a particular 
project. If you want to verify code you need the code which turns up 
after being preprocessed anyway.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 agree :P

No, I meant languages which are not able to give me bit level control 
over a type and have to circumvent this restriction with either 
awkward macro magic or even can't do nothing at all.

If I mean to set the write buffer water mark of the SDRAM controller 
register, I'd rather write:

|SDRAM_Buffer_Control.WB_Watermark := Sixteen;

instead of

|SDRAMBufferControl := (SDRAMBufferControl and not WB_WATERMARK_MASK) or
|  WB_WATER_MARK_16;

Not even to think of the much more cryptic C version.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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;
   WriteLn (X.A);
   WriteLn (X.B);
   WriteLn (SizeOf (X));
end.

-- 8 --

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 not found bitpacked

 type  TSDRAM_Buffer_Control=bitpacked record
  {...}
end;

 var SDRAM_Buffer_Control:TSDRAM_Buffer_Control absolute [$xx];

 begin
{...}
SDRAM_Buffer_Control.WB_Watermark := Sixteen;
{...}

 Just like Micha I'm not impressed about the Ada code,

It wasn't meant to impress anybody. It was meant to show that there's no 
preprocessor needed.

 and it is off-topic, this is and remains a Pascal newsgroup.

Oh, I thought of it as a mailing list. ;)

 Comparisons 
 between Pascal and other languages are on-topic, comparisons between
 C and Ada are off-topic.

So we're on-topic again. You are comparing Pascal and Ada. I look at Ada 
as a more strict version of Pascal, is all. Too many Ada-features have 
crept into Pascal over the years. ;)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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:
  |SDRAM_Buffer_Control.WB_Watermark := Sixteen;
 
  instead of
 
  |SDRAMBufferControl := (SDRAMBufferControl and not
  | WB_WATERMARK_MASK) or WB_WATER_MARK_16;

 I don't see the point: pascal and also fpc know bitpacked records?

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). If it's 
similar to C-records then it's unusable anyway, as there are no 
guarantees. Not about endianess, not about padding. And what about 
volatile and/or atomic semantics?

Well, too many question at once. I boil it down to this one: How else do 
you write it? The original layout declaration:

|  for SDRAM_Buffer_Control use
|   record
|  WB   at 0 range 0 .. 0;
|  WB_Flush at 0 range 1 .. 1;
|  WB_Watermark at 0 range 2 .. 3;
|  Read_Ahead   at 0 range 4 .. 4;
|  --  bits [5:7] are reserved
|   end record;

It get's especially tricky, because in many cases the bit patterns don't 
fit the numbers:

|  type RAS_CAS_Delay is range 2 .. 4;
|  for  RAS_CAS_Delay'Size use 2;

or

|  type CAS_Latency is range 2 .. 3;
|  for  CAS_Latency'Size use 1;

I don't really want to write

|SDRAM_Timing_Control.CAS_Latency := 1; // Where 0 is 2 and 1 is 3.

Well, not that big a problem, because once the patterns get 
nonconsecutive, you'd need enums either way. ;)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 (mostly) from Pascal. And other languages had their influences 
(and others later were influenced), too. Even computer languages have 
their Babel tower.

 Some come from C, some from Modula-2, some from Visual 
 Basic. Bitpacking can be considered a real Pascal extension, early
 compilers in the eighties could already do it.

Well, Ada's representation clauses also were known in 1983 already. And 
that was after the standardization procedure was through, so they 
surely appeared in the earlier 1979 drafts already. (And no objection 
please, but representation clauses are quite a bit more than just 
bitpacking.)
But as most features of Ada those probably appeared somewhere else 
before, I guess.

But for sure, such types (do they really call it record there or is 
that just my imagination?) appeared in C not before 1999. Together with 
other brain dead design decision, this makes (or at least made) C 
about the worst choice for embedded, low level programming - and yet, 
it is the most successful.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 not found bitpacked

 bitpacked was introduced in version 2.2.0 (which is the latest
 official release).

See, and that's a problem im production code. The project started at the 
time where 1.0.10 was current (and a couple of months later I used the 
1.9.6 release candidate), but due to several show-stoppers (thread 
leaks, random XML parser crashes) I'm currently stuck to version 2.0.0.

Of course, I tried version 2.2.0 shortly after its release, but then the 
project didn't even compile anymore. Ok, my fixed up version of the 
tread manager implementation was expected to break, but that suddenly 
subroutines were moved to other units wasn't something I expected. 
(Yes, the Interlocked stuff is now in System where before it was in 
SysUtils - which generally is a good thing; when using such code, 
chances are high, you don't even want to pull in SysUtils - , but still 
it breaks my code). And there may have been other issues, I don't 
remember.

Of course, some day soon I'll probably do a branch to migrate to 2.2.0, 
but until then, sorry, bitpacked or not, documented or not, I can't 
use it, because it doesn't exist in the current setup.

 That said, bitpacking is unsuited for hardware interfacing because it
 is opaque:

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% of the times 
such RCs are hardware specific.

 The bit layout is also different on little and big endian systems.

And let me guess: There's no way to specify how the Endianess of the 
bitpacked type should be interpreted regardless of the target system?


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 appeared in 1992. Many
 Pascal compilers have supported bitpacking, since 2.2 we do too.

Well, the first version of the software I am maintaining appeared around 
1992, too. There still were IFDEFs for TP4 in it.

  If it's
  similar to C-records then it's unusable anyway, as there are no
  guarantees. Not about endianess, not about padding.

 This is simply a matter of documenting and standardizing.

For me it's a matter of the hardware.

 I.e. we can 
 exchange packed records with TP/Delphi, what would be the problem
 with bitpacking? If I recall well, Jonas made our bitpacking
 compatible with GCC and GNU-Pascal.

Great. And surely the PCI-board registers are compatible with GCC (oh, 
and if so, which compiler version then?).

  And what about volatile and/or atomic semantics?

 Pascal does not have volatile. It is not strictly needed either since
 the use of mem or absolute should provide sufficient information to
 the compiler it cannot optimize away reads/writes.

No. Global variables in threading context are just as volatile as any 
memory-mapped hardware might be. And how should the compiler know that 
a given pointer actually points to a memory-mapped hardware register if 
you can't tell it? Sure, so far I did not have problems with such (I 
don't use too many global variables, the embedded hardware is 
programmed in another language anyway, and I only (mis)use types as 
atomic, if I can sufficiently guarantee that in most circumstances the 
access will be atomic indeed).


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 merely reasoning why I can't use the latest bleeding edge 
compiler. ;)

  And let me guess: There's no way to specify how the Endianess of
  the bitpacked type should be interpreted regardless of the target
  system?

 As I said it's an opaque construct (so no control or guarantees
 whatsoever about the layout) and it was not written with hardware
 interfacing in mind (regardless of what other people like to promote
 it for).

So, basically it is not useful in the context I was mentioning (JFTR: 
neither do the similar C99 constructs). Things like memory controller 
register fall into the hardware category, I suppose. ;)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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% of
  the times such RCs are hardware specific.

 I still don't see how ada could handle things like little endian cpus
 accessing big endian peripherial with bit patterns overlapping byte
 borders (no, this is not an academic case, just look at the brain
 dead arm fpa).

Well, I'm not sure what you want here, let me try:

|type Data is ...
|
|for Data'Bit_Order use High_Order_First;
|for Data use
|  record
| Byte_3 at 0 range 0 .. 7;
| Byte_2 at 1 range 0 .. 7;
| Byte_1 at 2 range 0 .. 7;
| Byte_0 at 3 range 0 .. 7;
|  end record;

Don't get it wrong. An Ada compiler does *not* automatically flip bytes 
for you, so if you really have some type spanning byte boundaries in 
the wrong endianess, you still have to flip it accordingly. IOW:

|type Data is:
|
|for Data'Bit_Order use High_Order_First;
|for Data use
|  record
| Word_1 at 0 range 0 .. 15;
| Word_0 at 2 range 0 .. 15;
...

does not work as one might expect. The bytes would still be flipped on a 
little endian machine.

But at least it is possible to define a record representation totally 
endianess independent. It's a bit more complex than necessary, so it's 
probably better to read the whole stuff (although it might require some 
Ada experience to really see it through)

http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf

instead of letting me give you an example.

After all, for embedded programming the guarantees I get from Ada record 
representation clauses is usually enough to know it'll work.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
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 code is created if
 the byte order already is correct with the processor the code is
 compiled for.

As pointed out, this is possible without a preprocessor. Not in C, 
though.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] New download location for the ebook--sorry for the messup!

2008-02-20 Thread Vinzent Hoefler
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 it. :)


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
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},
   @FuncArg[i]));

for i := 0 to 3 do
   Result[i] := WaitForThreadTerminate (Handle[i], 0);
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
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 it?

No, TThread is either heavy or middle-weight, according to the 
definitions at

http://whatis.techtarget.com/definition/0,,sid9_gci814910,00.html

depending on the actual implementation. On Linux 2.4 it would be 
heavyweight, on Win32 systems and Linux kernel 2.6+ it would be 
middle-weight. (Well, the context switching times mentioned there are 
not really up to date, usually not even context switching between 
processes takes several milliseconds, or thousands of microseconds as 
they liked to say.)

But actually, I don't know how much more light a thread can take:

When all context and thread operations are exposed at the user level, 
each application needs only the minimal amount of context saved with 
it, so that context switching can be reduced to tens of microseconds. 
Therefore, user-level threads are considered lightweight threads.

Which is something that you simply never want to do outside of 
bare-metal embedded systems. And even there you'd normally wrap your 
threading implementation in something more middle-weight before you 
expose that API to the user.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
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 := 0 to 3 do
   Result[i] := WaitForTask(Handle[i], 0);

Yes, that would be something nice and useful, indeed.



Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
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, here I'd go with Florians thread pools advice. And no, it's not 
implemented yet, AFAIK.

You still can implement such thread pools on top of OpenMP(I) (or 
similar APIs), if you need to get much lighter. ;)



Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] weird syntax

2007-12-11 Thread Vinzent Hoefler
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 be changed.

Neither needs to be. There is no operand, but two operators (or ) in 
the second expression, so you wouldn't even be able to apply precedence 
rules.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Parallel Computing

2007-12-10 Thread Vinzent Hoefler
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).

BTW, I didn't have time to look at your proposal, but once I 
got procedure of thread you're quoting here, I'd expect the language 
to take care of (most) synchronization issues, much like the protected 
object in the Ada language does.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Parallel Computing

2007-12-03 Thread Vinzent Hoefler
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  TThread class.

Yeah, right. And back in 1983, Ada already tried to encapsulate that in 
a task object.

If any of the FPC developers had time to implement something more nifty, 
there would have been plenty of time to come up with something. Quite a 
while ago there were even some ideas shared for the OMP API etc. pp.

I can't imagine that Microsoft's ideas of adding multi processing to 
dot-net will change the overall picture. Especially not when I think of 
all the parallel language( construct)s invented in the past 30 years to 
accomplish just that.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] SysUtils exception translation issues

2007-10-22 Thread Vinzent Hoefler
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, or Delphi compatibility issues:

1) Strangely, runtime error 1 (invalid function number) is translated to 
EOutOfMemory.

2) Translation to I/O errors: there's a string set for RTE15, although 
it's not even handled by the case statement, as well as RTE 16 to 18, 
and 104, which are not handled neither.

3) Most DOS-specific errors are not handled at all (see RTE150 - 162).

4) RTE 202 (Stack check error), and RTE210 (object not initialized) are 
not handled.

5) RTE206 is translated to EOverflow, although there is an EUnderflow 
exception type.

6) RTE212 (stream registration error) is translated to an EExternal 
exception, although EExternal should probably not be raised on its own, 
but rather provide as base class for real external error situations.

7) RTE213 again is not handled, while RTE214 (collection overflow error) 
suddenly becomes an EBusError.

8) Why is RTE217 (unhandled exception) translated to EControlC?

9) RTE220 - 225 are not documented as Variant errors.


For me it looks as if the runtime error to exception translation is more 
or less screwed anyway.


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] property syntax extension

2007-10-18 Thread Vinzent Hoefler
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 installed.

 Valid considerations, but regarding this, PDF is a much better
 option. (BTW.: Open Office does write PDF without any plugins or
 external programs.)

Oh, come on. An OpenOffice created PDF would have had about 30K+ size 
after base64 encode. :P

And that for data which could most easily have been provided as plain 
text inside the mail:

-- 8 --
PropertyDeclaration ::= PROPERTY Identifier [PropertyInterface]
[PropertySpecifiers]
[Directives]

PropertySpecifiers ::= [ ... ]
   [ ... ]
   [ATTRIBUTES AttributesArray]
AttributesArray ::= '[' (AttributeDeclaration
[, AttributeDeclaration]) ']'
AttributeDeclaration ::= string':'string

Declaration examples:

TmenuItem = class(...)
...
property Detachable: Boolean read  FDetachable
 write SetDetachable
   attributes ['widgetsets:qt,gtk,win32',
   'implementor:Vasya Pupkin',
   'creation-date:01.01.2007'];
...
end;

TxxxDatabase = class(...)
...
property TransactionModel: TTransactionModel read FtransactionModel
 write SetTransactionModel
   attributes ['engines:firebird,oracle,sybase-asa'];
...
end;
-- 8 --

Of course, the syntax highlighting is now missing but as the intended 
target audience are the developers and not managers, the missing blue 
won't lose you information, I'd say.


VinHow big is that whole mail now?zent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] sdlgraph, pre-alpha

2007-08-22 Thread Vinzent Hoefler
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.

 Before me going too far in unknown territory, but isn't that the
 basis for any software implemented graphics routine: drawing pixels ?

According to Michael Abrash: No, it's not. Linedrawing is more like it.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] win32 debugging broken in fixes_2_2?

2007-07-10 Thread Vinzent Hoefler
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


Re: [fpc-devel] win32 debugging broken in fixes_2_2?

2007-07-10 Thread Vinzent Hoefler
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 
in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) 
are set to 1.

  -- IA32 Software Developer's Manual,
 Volume 3: System Programming Guide

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] language extensions

2007-06-14 Thread Vinzent Hoefler
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 compiler 
(which then may even apply recursively). This rules out a whole class 
of possible error sources.

So it's probably the last 10% that counts. ;) Which, BTW, fits nicely 
into another 90/10 rule: 90% of all errors are coming from only 10% of 
the code. ;)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Issue with Critical sections

2007-04-05 Thread Vinzent Hoefler
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 like me and just use 
subroutine names without caring where they come from, while I'm used to 
always prefix the unit names to the subroutines and thus simply 
removing Windows from the use clause would not work, because the 
routines suddenly come from a different place.

Well, my opinion and my experience say you should know which routines 
you are actually using. I know that since the days I used DisposeStr 
and the FPC compiled code horribly crashed, because it was the wrong 
one.

 The code I was compiling was already cross-platform (Delphi/Kylix),
 and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix,
 InitializeCriticalSection and DeleteCriticalSection are implemented
 in SysUtils unit, so any code using these functions continue to work
 under Linux. It was surprise for me that this code could not compile
 with FPC.

I won't judge if FPC is correct here (it's supposed to be Delphi-, not 
Kylix-compatible), but if Borland decided to move those routines, they 
didn't do it right neither. ;)

Well, I'd still suggest to either stick to System.InitCriticalSection 
etc. regardless if the Windows unit is included or not (yes, this 
actually *requires* you to prefix it), or just use the SyncObjs unit 
like everyone else out there.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Issue with Critical sections

2007-04-05 Thread Vinzent Hoefler
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 
takes you to the safe side. I never liked Pascal's solution of calling 
subroutines with the same name depending on the order of the use 
clauses, when those use clauses are so far away from the actual code. 
Change the clause, you (may) change the code.
Not mentioning this awful reuse clause here, that's the worst. But I'm 
getting carried away... stop.

Well, so doing the mouseover to look at where it's from already has a 
bad taste of suspecting some surprise.

And well, an IDE can't help you on the printout. Clicking on the 
headlines in a newspaper doesn't take you to the article, neither. ;)

 VH I won't judge if FPC is correct here (it's supposed to be
 Delphi-, not VH Kylix-compatible), but if Borland decided to move
 those routines, they VH didn't do it right neither. ;)

 They did not move routines - they just had to implement Linux
 versions somehow. And they did it in a way that was not breaking
 existing code.

So they should have implemented the Windows unit, simple as that. Or 
add a Linux unit as replacement.

 In this particular case I wanted to avoid FCL dependence via using
 SyncObjs.

Fair enough. It's a reason after all.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
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 identifiers 
come from the Windows unit.

 After
 searching through RTL code, I discovered that abovementioned
 functions are named InitCriticalSection and DoneCriticalSection. At
 the same time, the EnterCriticalSection and LeaveCriticalSection are
 not renamed, so code using them compiles without errors. Why this
 inconsistency?

Because one is the RTL abstraction on the different OSes, the other one 
is the direct Windows-API-Call.

 Should I supply a patch that adds
 Initialize/DeleteCriticalSection as aliases for
 Init/DoneCriticalSection?

No, I'd suggest to fix your code.


Regards,

Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
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 cross-platform versions from System
 unit will be used. This is fine.

No. If you want to be cross-platform just do not use the Windows unit 
at all. Rather only use the functionality provided by the system unit, 
regardless of the compilation target.

The Windows unit should generally only included if you write platform 
specific code and such code should be separated in its own include file 
or even unit anyway.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
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.

Why's that? At least it's documented that way. And I don't see any harm 
in doing so.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: Inter Process Communication

2007-02-28 Thread Vinzent Hoefler
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;
|
|{$mode objfpc}{$H+}
|
|interface

There's the {$H+} in it, so String actually is an AnsiString already, no 
ShortString anymore.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] case with range stupidities

2007-02-15 Thread Vinzent Hoefler
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 ('In range.
  (1)'); My_Range  : WriteLn ('In range.
  (2)'); else
WriteLn ('Out of range.');
 end {case};
  end {Case_Test}.
 
  -- 8 --
 
  Is there any reasoning why the first switch in the case statement
  (Low (My_Range) ...) is allowed, whilst the second one (just
  My_Range) is not (says: constant expression expected)?

 Well, a case label is basically a set of values. A type definition is
 something different, i.e. you cannot use byte or longint as case
 labels either.

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
  Foo = array[Low (byte) .. High (byte) of Something;

is totally equivalent, the allowed usage of range types seems a little 
bit inconsistent...


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] case with range stupidities

2007-02-15 Thread Vinzent Hoefler
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
Foo = array[Low (byte) .. High (byte) of Something;
 
  is totally equivalent, the allowed usage of range types seems a
  little bit inconsistent...

 Yes, but as I said, case labels are a set, not just a range:

 const x=[0,1,5];

 type foo=array[x] of something

 ...would again be rather weird.

It would be, yes. It even seems constants can't be used in an array type 
declaration at all (well, not in a way different from defining the 
lower and upper bound, I mean) and

   const
  X = 0 .. 5;

does not work either while type X = (Zero, One, Five) would do both 
cases. ;)

So in short: it seems a range type like byte can be used where a 
pure range is expected, but it cannot be used where a set is expected 
(like for a case label, even though there a set constant would not be 
accepted either):

-- 8 --
type
   X = (Zero, One, Five);

var
   Bla : X;

const
   Foobar = [Zero, One];

begin
   Bla := Five;

   case Bla of
  Low (Foobar) .. High (Foobar) : WriteLn ('Less than Five.');
  // The following two lines don't work, of course.
  //Foobar: WriteLn ('NO.');
  //[Foobar]  : WriteLn ('NO.');
   else
  WriteLn ('More than One, I guess.');
   end {case};

   // A real set operation.
   if Bla in Foobar then
  WriteLn ('Really less than Five.')
   else
  WriteLn ('Wrong. It is NOT less than five!');
end.
-- 8 --

So if the case label is considered a set why can't I use a set constant 
(see the commented lines above) and if I do the range thing, which 
compiles, it does not consider the value of the constant but rather the 
range of its /type/...?

Seems to me that case labels are very special things, at least.

Another oddity would be a for loop:

   for Bla := One to Five do ...

would be a range only, yes? (Apart from the fact that - due to the to 
keyword - really isn't).

So wouldn't it be easier to write

|  for Bla := X do ...

here, when X is some range type, I'd like to iterate over? Again I have 
to Write Low (X) to High (X) quite similar to the case case.

I suppose changing that behaviour regarding range types is not an option 
at all, so I'd ask for some other improvement:

*deep breath*

What about a compiler built-in like Low() and High() called Range() 
where its return type indicates something that would be compatible to a 
case and for label and just denote the range of the whole type?

Basically a short cut to the Low (Type) ..|to High (Type) expression, 
but without the possible pitfall of writing

   Low (Type) .. High (A_Similar_And_Unfortunately_Compatible_Type)

and thus being less error-prone...?

I mean, doing:

|for Bla := Range (X) do

or

|case Bla in
|Range (X): ...

doesn't actually look unreadable to me...


Regards,

Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Error: Unable to create reg.xml file

2007-01-19 Thread Vinzent Hoefler
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 default permissions, and must use
 special directories for this.

Yes, and the hell they should, multi user OS's are out there for how 
long? Thirty years? Almost fourty?

So - writing application specific data to the same, single location for 
each and every user is inappropriate for most applications anyway.
This leaves us with the AppData (or whatever it's called) directory in 
the user's home directory - or the local registry keys.

Without proper rights you can't write to the global registry keys 
either.

So I don't see the difference apart from the usual Is it better to back 
up thousands of ini files in different locations, or a single blob aka. 
registry which is several megabytes of a mixture of important data and 
junk? question.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Error: Unable to create reg.xml file

2007-01-19 Thread Vinzent Hoefler
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 maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-09 Thread Vinzent Hoefler
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 I sure will use it. Modula had signals at least 
(although I don't remember it too good), Ada has task entries (and you 
still write your tasking code in a loop, then). Alas, Object Pascal 
lacks a decent portable OS tasking interface.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 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

 No you can't.

You still refuse to tell me why, so please stop telling me what I can't 
do, especially when I *am* doing it. Of course the procedures in 
question are protected against concurrent execution from different 
threads at the same time. This was needed anyway, because the object 
was designed to be called from different threads anyway. So adding a 
timed call from another thread wasn't too hard, as you probably can 
imagine.

Of course I am not using this GUI based TTimer object, I was talking 
about the concept timer in a more general way. Call it signal, if you 
like that better.

  If you'd do that, the timer event callbacks would be queued and
  then executed in the context of the main thread.
  The user is only required to call CheckSynchronized from time to
  time, but because the accuracy of the time of execution of any
  associated handler is in the hands of the user anyway as long as
  you stick to a synchronous solution to avoid putting the burden of
  locking data to the programmer.
  As long as you don't want to implement real-time behaviour, I don't
  even see a problem in that. If the user decides to not call/execute
  any provided message event loop, the execution of the timer
  handler code will be deferred until the end of the universe anyway.

 This is exactly the oh-so-complex solution I use in lNet,

Let me quote yourself: Apart from asynchronous stuff like watching 
handles etc. I don't see much use for this relativly complicated 
program model.

So you yourself seem to look at it as complex somehow.

 and is basicly the only solution.

Well, using a (priority) message queue is a common solution, yes. Yet 
it's not necessarily the only one. :P

It all depends on what you're trying to accomplish. I still like to have 
a asynchronous timer event model. It would still simplify some code.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 ! The beauty of TTimer (and GUI events as well) is that
it does not work in a thread. Otherwise it e.g. would not be
possible to do GUI stuff in a timer event, as VCL and LCL are
not thread save (and probably can't be made thread save).
  
   It can't because X-Windows or MS-Windows are not thread-safe.
 
  Yeah, right. And threading in DOS is not possible either, because
  DOS is non-reentrant, is it?

 I don't know. I didn't make any statements about DOS, AFAIK.

No you didn't. But I heard the same before and yet there *is* a 
thread-safe implementation on top of GTK (which isn't thread-safe, 
either) and there *are* threading implementations under DOS.

So I'd be careful with such it can'ts. ;)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 I got confused by all the talking that my code 
can't work at all, and started to think in TThread objects instead of 
execution context. Well, right. I wasn't going to write a task 
scheduler. ;)

But now ... rereading the post, the original text was 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, and I still wonder why I shouldn't be 
able to do that (well, if TTimer would actually do what its name 
suggests and no-one else would change the subject to one particular 
Delphi-way-implementation called TTimer, when I am still talking about 
a timer object in general).


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 for any thread (e.g.
 TThread.Application) and thus having an event scheduler for same.

Sorry, if it caused confusion, but I don't know about TApplication or 
its particular implementation. I don't do GUI. ;) I was just reading 
about timer objects ... sorry.

 By this it would be possible to implement TTimer in a way that it's
 callbacks can be fired in the context of a thread and thus
 asynchronous timer event are possible in a completely compatible
 way, allowing the user to define, regarding what context the event is
 asynchronous. IMHO this would be a great plus for any embedded
 real-time use of FPC.

Now we're talking. :)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 without implications
 like TThread SEEMS to.

Alright, yes. But as soon as you start overriding Thread.Execute the 
user (as in programmer) should start thinking about those issues 
anyway, so I didn't consider that a show-stopper. Maintaining 
thread-safety ain't so complex once you start following some simple 
rules.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 trivial kind as well, no
 complex state allowed), as you cannot take any locks,

First: Of course you can take locks. Such a timed execution is - just 
like any other thread - still scheduled by the OS and thus follows the 
same rules. A higher priority to make sure an expired timer actually 
preempts other running threads doesn't change this fact.

 and must be re-entrant. This implies you can almost call no function
 at all.

Second: You could call any function you can call safely from within any 
other plain thread.

That's the difference to a real signal (where you can merely set some 
variable to be polled later and bail out), and makes it so much nicer 
to use than OS' signals.

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 more 
like an interrupt.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 more like an interrupt.

 Impossible.

Yeah, right. So this:

--- 8 ---
{/= tFlusher.Execute =\}
{  }
{\/}
procedure tFlusher.Execute;
begin
   self.Started.SetEvent;

   repeat
  SysUtils.Sleep (self.Interval);
  self.Logger.Flush;
   until self.Terminated;

   // Last Action Hero.
   self.Logger.Flush;
end {tFlusher.Execute};
--- 8 ---

is totally impossible to work? To implement something less crude you 
could either implement a delay until by checking the point in time, 
the threads gets woken up or on UNIX you could even sigwait() for 
SIGALARM and (re)set it accordingly.

 You'll end with TThread.Synchronize, but without its
 advantage of knowing in which thread it runs, because the entire
 *point* of a GUI thread is that it's not doing anything for 99% of
 the time (waiting for user input only).

I don't a GUI thread. Currently I have up to 24 threads processing image 
data and writing log information (which I don't want to be written line 
by line, that's why I collect them in a queue for a couple of seconds 
before actually writing it to a file) and some other threads processing 
RPC requests. And only one of them provides an RPC interface to 
something you'd call GUI.

But of course, automatically calling methods by a timer with such 
semantics is totally impossible. Guess I have to rethink, why it 
actually works.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 of lines ago these semantics were still 
impossible.

 but it's not realtime by any definition.

First, I never said real-time in that context and second: it sure can 
be, if the thread's priority demands an immediate wake-up after the 
sleep.

Then and if implemented a litte bit less crude - as I suggested - it 
would be no less real-time than

|declare
|   Next_Cycle : Ada.Real_Time.Time := Ada.Real_Time.Clock;
|   CYCLE_TIME : constant Ada.Real_Time.Time_Span :=
|  Ada.Real_Time.To_Time_Span (1.0);
|   use type Ada.Real_Time.Time;
|begin
|   loop
|  Next_Cycle := Next_Cycle + CYCLE_TIME;
|  Do_Some_Work;
|  delay until Next_Cycle;
|   end loop;
|end;

in Ada would be. And the jitter in the above Ada code was about 30 
microseconds running on an RTOS, of course.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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 to be executed at a future point in
 time in an efficient way, as it is a standalone timer that is
 executed directly in the context of the interrupt handler (it does
 not need a server task).
 /meta-quote

I mainly quoted that to clarify my intention of the term timer, 
because there seemed to be some confusion about that.
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.

[It seems that a lot of people seem to put all their efforts in looking 
at a single particular implementation before trying to see the big 
picture. ;)]

I didn't say that it *is* necessarily an interrupt or signal, I just 
said it is comparable to one, by which I meant its preemption of 
ongoing operations.

To implement the semantics of timing events allow for a handler to be 
executed at a future point a polling-loop could prove to be a very 
problematic solution.
Especially outside of the usual GUI-application, we seemed to be talking 
about, because the user/programmer somehow has to make sure that the 
polling is actually done some time in the future.
Considering that a simply ReadLn can block indefinitely already, this 
is quite hard to accomplish then, isn't it?

 I read server task as thread, and a timer as interrupting any thread
 at the time it was fired and calling some callback then.

Yes. And if a timer implemented as thread has the highest priority it 
would even do exactly that, and I also said that in one of my last 
mails. Still no word of real-time, although now we're catching up. ;)

 Maybe Ada creates a hidden thread itself in which it calls these
 callbacks (so cheating on its own definition IMHO),

Maybe. :) I didn't read the new standard yet, but I guess, the actual 
implementation is left to the implementor as long as the required 
semantics are kept. Although it seems rather unliky it actually might 
be an additional thread on top of the OS' scheduling system, or it 
might be a real hardware interrupt, or it might be the scheduler of the 
runtime without any OS running at all ...

 but otherwise the
 only value for such interrupts would be realtime requirements.

Well, Ada is - of course - a language designed with real-time systems in 
mind. Yet, this doesn't mean, that the general concept is useless 
outside of a hard real-time scope.

Considering that in the GUI-application such things seem to be used very 
commonly (due to the polling-loop implementation without the 
implications of being executed concurrently), the value seems to be a 
little bit greater than to useful in real time environments only.

As far as I understood, the only problem here we discussed were 
applications without such dedicated event loop.

  microseconds running on an RTOS, of course.

 That's not the common OS case.

Precisely, and that's why I even tried to avoid the term real time 
thus far. Yet, such feature can be useful.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
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.

 The irony is of course that you clamp to your interrupt definition,
 but still implement your log timed event with a loop :-).

Well, yes and no, just like I would do in Esterel, for example:

|loop
|   await NEXT_TIME;
|   emit EXPIRED;
|end loop;

Because I do not know of any other construct to express indefinite 
repeatition, I used a loop. Any other ideas? ;)

Yes, of course, this still *is* nothing more than an event loop, and its 
asynchronous character would only come from the fact that it is done in 
parallel with some main thread, so it neither does interfere with the 
execution of the main program nor does it depend on it.

  Especially outside of the usual GUI-application, we seemed to be
  talking about, because the user/programmer somehow has to make sure
  that the polling is actually done some time in the future.
  Considering that a simply ReadLn can block indefinitely already,
  this is quite hard to accomplish then, isn't it?

 Well, readln is used in the trivial (T)UIs; TUIs/GUIs are usually
 event-driven,

Whatchamacallit, it was an example where calling this event loop might 
be close to impossible. Yet, admitted, the expiring timer still 
wouldn't stop the ReadLn from reading its file, so you're screwed 
either way, but you could for example emit a beep to the user from 
time to time. ;)

 like networked apps also can be. A Timer fits in a event-driven app
 just fine,

I didn't say, it doesn't, did I? If so, I'm sorry. But I even remember 
mentioning priority queues in that context (which could somehow ensure 
a timer event would be handled in time, so even real time is possible 
if enough care is taken by the programmer).

 and then a timer doesn't interrupt
 anything anymore; but your intuition may say that it should, that's
 why it's a common misconception.

Ok, I now understand where my misconception comes from. :P

We're back to the usual GUI application where everything depends on that 
event loop. :) Of course, that's fine for most event-driven 
applications, especially when being GUI. IOW, it can be considered the 
difference between being preemptive and being cooperative. ;)

Problem here is that I would call my event loop only every couple of 
hours, because responding to on the event now process image data 
takes so long. :) And as far as I understood, the problem was exactly 
that: To implement something like TTimer in an application which is 
*not* based on a regularly called event loop.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] TStringList.CustomSort

2006-11-07 Thread Vinzent Hoefler
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
 probably will save some function call overhead.

That highly depends on the sorting algorithm used. A plain Quicksort has 
a very bad worst case of O(n**2) that develops especially when the list 
to be sorted already is. Even Bubblesort would be faster in such a 
case.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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? Why's that? Or am I understanding 
something wrong?

 and if you go single-threaded you have to provide the main loop
 hooks).

Do I? I always thought a timer is more comparable to an interrupt or 
signal than a polling loop.

 So basicly, let's say TTimer is in RTL and there's some event
 mechanism already too, you'd have to do something like this:

 procedure init;
 begin
   Timer.Timeout:=somenumber;
   Timer.OnTimer:[EMAIL PROTECTED];
   EventHandler.RegisterTimer(Timer); // could be the other way around
 end;

 procedure MainLoop;
 begin
   EventHandler.HandleEvents; // if eventhandler after polling all
 timers in it's watchlist find out some has it's interval done, it
 fires it's callback end;

 begin
   Init;
   MainLoop;
 end.

Timer.OnTimer  := @Some_Callback;
Timer.Timeout  := Some_Number;
Timer.Periodic := True;

And somewhere a Timer.Start;, that should be it. There's no need to 
register the timer in a global event loop or even explicitely calling 
it. If that's needed on a particalur target, the timer's implementation 
should take care of this.

 Apart from asynchronous stuff like watching handles etc. I don't see
 much use for this relativly complicated program model.

Don't know what's complicated here. It's asynchronous by definition, of 
course, but apart from that?

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. And there's really nothing complicated in queuing log 
messages and saving the queued messages every five seconds.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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 users coming over to FCP (only enhancement allowed). Of course
 Lazarus does this, but IMHO it would be great to have this in a
 system without a GUI, too.

At first: It doesn't matter how it's done to me as long as it works. :)

My system is a system without a GUI, or to be more precise: with a 
remote (G)UI. That's why I don't know about LCL or whatever and I don't 
even care, because I simply don't understand what time as in timer 
has to do with graphics as in graphical. For me that's two 
completely different subjects unless we're talking about animations 
where those two subjects meet.

All I needed was a simple timer, so that some user supplied routine was 
being called after some specified time has been elapsed. There's 
nothing complicated in that view of the programming model, because it's 
the user's view. I implemented that by using an additional thread in a 
relatively simple way, although its execute method was merely a

|while not self.Terminated do
|begin
|   SysUtils.Sleep (self.Interval);
|   self.Logger.Flush;
|end {while};

to take care of my requirement that the Flush-routine of the logger 
object would be called once in a while.

If following the Delphi paradigm leads to such complicated solutions 
as layed out here by Ales (and I'm still talking about the user's view 
here, not any particular implementation) I surely can live without such 
a solution.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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 misconception:

-- quote -- 8 --
Timing events allow for a handler to be executed at a future point in 
time in an efficient way, as it is a standalone timer that is executed 
directly in the context of the interrupt handler (it does not need a
server task).
The use of timing events may reduce the number of tasks in a program and 
the overhead of context switching. It provides an effective solution 
for programming short time-triggered procedures and implementing some 
specific scheduling algorithms, such as those used for imprecise 
computation. Imprecise computation increases the utilization and 
effectiveness of real-time applications by means of structuring tasks 
into two phases (one mandatory and one optional). Scheduling algorithms 
that try to maximize the likelihood that optional parts are completed 
typically require changing asynchronously the priority of a task, which 
can be implemented elegantly and efficiently with timing events.
-- /quote -- 8 --

But of course, the Delphi concept is right.

 A TTimer event is not an
 interrupt in that it does not interrupt any code in the Application.
 such an automatic event is always done in the main thread and only
 started when (1) the application is idle, (2) the application comes
 back from some other event, or (3) Application.ProcessMessages is
 called. Only another thread can be interrupted (preempted) by such
 an event.

Those are details of _one_ particular implementation.

 The big advantage is that you do not need to protect any resources
 from multi-threaded access if you do not explicitly create a thread
 by means of TThread.

And the big disadvantage seems to be a overly complicated programming 
model. Guess, what I'd prefer.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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 (eg: variable writes
 etc.).

Of course, because the common concept of a timer is as asynchronous as 
in multi-threaded or even interrupt.

You're not seriously trying to work around that simple fact, do you?


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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

 unless the users are informed, and-or
 the thing is locked and protected but you can't do that from within a
 TThread (because you don't know what the callback code is).

Well, in Turbo Pascal I could write interrupt handlers the wrong way, 
without locking code/data in question and nobody cared about that 
simple fact.

But if that's so complex: Why don't you use the usual synchronization 
stuff then to put the asynchronous timer event in a message queue using 
Synchronized?

 In case of gui TTimer this cannot happen because it's not threaded,
 so the userloop would first finish, then the user function returns
 and the main gui loop does it's stuff (this is my oh-so-complicated
 part, done by the gui).

The problem in a portable general solution is that the may be no main 
gui loop and you can't just write one and force anyone to use it, 
right?

So why don't you use Synchronized/CheckSynchronize (or whatever it's 
called) then?

If you'd do that, the timer event callbacks would be queued and then 
executed in the context of the main thread.
The user is only required to call CheckSynchronized from time to time, 
but because the accuracy of the time of execution of any associated 
handler is in the hands of the user anyway as long as you stick to a 
synchronous solution to avoid putting the burden of locking data to the 
programmer.
As long as you don't want to implement real-time behaviour, I don't even 
see a problem in that. If the user decides to not call/execute any 
provided message event loop, the execution of the timer handler code 
will be deferred until the end of the universe anyway.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
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 might not.

Basically a timer starts, later then it expires an that expiration 
creates an event (in the old days we called that interrupt). This event 
is no way synchronous to the code currently running.

 Timer events are queued in a line (message-queue) with all
 hardware/GUI events.

Ok. So this would do nothing more than synchronize the asynchronous 
event of an expired timer to the main thread. Of course, the time of 
execution of the code associated with the expiration is now determined 
by the time the message queue is handled the next time.

So why don't use CheckSynchronized for this?


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] CmdLine

2006-10-19 Thread Vinzent Hoefler
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 
language. Still it can be unportable, plain wrong, only work in certain 
situations etc. pp. Read: It still may break.

So no language construct that forbids it is no excuse, especially when 
you're digging around in internal compiler constructs.

Otherwise I'd expect some of my old code to work with FreePascal - where 
I outsmarted TPs heap manager to be able to free parts of dynamically 
allocated arrays.

IMO, ppl will always be smarter and find a valid case where things get 
broken.

This highly depends on your definition of valid. My opinion: If it 
ain't guaranteed by the language, it ain't valid.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] CmdLine

2006-10-19 Thread Vinzent Hoefler
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-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
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);
pthread_mutex_unlock(@p^.mutex);
  end;
 
  procedure intRTLEventStartWait(AEvent: PRTLEvent);
  var p:pintrtlevent;
 
  begin
p:=pintrtlevent(aevent);
pthread_mutex_lock(@p^.mutex);
  end;
 
  procedure intRTLEventWaitFor(AEvent: PRTLEvent);
  var p:pintrtlevent;
 
  begin
p:=pintrtlevent(aevent);
pthread_cond_wait(@p^.condvar, @p^.mutex);
pthread_mutex_unlock(@p^.mutex);
  end;

 This last pthread_mutex_unlock does not make sense to me. From the
 pthread_cond_wait man page:

   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 have read a couple of lines further you also would have 
found:

|Before returning to the calling thread, pthread_cond_wait re-acquires
|mutex (as per pthread_lock_mutex).

 Further, what is
 the lock/unlock for in the intRTLEventSetEvent? pthread_cond_signal
 can perfectly deal with multiple threads simultaneously signalling
 the same condition variable (pthreads is a multithreading api, not a
 random non-reentrant piece of code).

Oh, is it? Read the f*cking man page:

|A condition variable must always be associated with a mutex, to avoid
|the race condition where a thread prepares to wait on a condition
|variable and another thread signals the condition just before the first
|thread actually waits on it.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
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 have read a couple of lines further you also would
  have
 
  found:
  |Before returning to the calling thread, pthread_cond_wait
  | re-acquires mutex (as per pthread_lock_mutex).

 That is not on the Mac OS X man page for pthread_cond_wait. See
http://www.hmug.org/man/3/pthread_cond_wait.php

I see.

 Not sure if this means it's not necessary in the Mac OS X (and
 possibly FreeBSD) versions, or that the Mac OS X man pages are
 incomplete.

They are most definitely incomplete.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
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  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] format function

2006-10-12 Thread Vinzent Hoefler
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', [-0.0001])
 the resulting string is
 -0.000
 and not
 0.000
 Why?

Hmm, I'd guess that's because the (original) number is negative and the 
sign is not changed by rounding or chopping off digits.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] format function

2006-10-12 Thread Vinzent Hoefler
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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Tail recursion optimization

2006-10-10 Thread Vinzent Hoefler
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.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11
  is the new compiler, fpc11 the old, both are 2.1.1).
 
  Wow!

 Well, it's use for real world applications is limited

Limited to what? Binary tree data structures only? ;)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Adding a unidirectional dataset to sqldb

2006-10-05 Thread Vinzent Hoefler
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 interface does not contain any code, so how would adding an
 interface help ?

No code - no execution time. Try being faster than that. SCNR.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Suggestion for change: Overly strict check

2006-10-04 Thread Vinzent Hoefler
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 global, there's absolutely no need 
for this:

Writing this/self. removes the need for m_ and even adds some sort of 
safety, because that's one rule the compiler can actually check. - 
That's one.

The difference between locals and paranetrized locals does not need to 
be mentioned at all, because inside the function they behave the same 
and have the same scope. - That' two.

Globals should be forbidden. That's three.
Hmm, ok, if really needed, you should prefix the unit name to ensure 
sudden name clashes (like my Break identifier) anyway, so globals are 
easily identified simply by being used already. - So, now that's three.

 I have used scope prefixes long before this/them and I as a
 somewhat-die-hard-Pascal-programmer had a hard time getting used to
 the underscores, which seems to divide the identifier and makes you
 code look like C, but I barely notice it now ;-) And it's very
 practical for code completion :-)

Well, since my variable names tend to be longer than four chars, I 
always use underscores and my code sure does NOT look like C. ;)

ItMakesIdentifiersMoreReadableBecauseTheUnderscoreIsAsCloseAsYouCanGetToNormalTextWithoutUsingWhitespace.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Suggestion for change: Overly strict check

2006-09-28 Thread Vinzent Hoefler
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. 
Although I usually like tremendous amounts of compiler checks, because 
they save my time, I have to agree with Christian here. 
This sort of syntax check is far too strict. If at all, it should be a 
warning and *only* if the types could actually be confused.

Forcing people to use Hungarian Notation, like it was already suggested, 
to avoid this check doesn't help neither, there are enough examples for 
that.

(Granted, maybe this is due to the fact, that I always write self. ... 
for an object method/variable, so local names can't get confused in 
such a way at all.)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Inlining functions...

2006-07-25 Thread Vinzent Hoefler
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 make the compiler to ignore it 
like the far keyword? It's because, I'm quite used to the fact that 
inline is merely a suggestion to the compiler, not taken as a command 
to be obeyed all times.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

2006-07-18 Thread Vinzent Hoefler
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 about the C language, but the vendors, the C library
 implementors, etc.

And I was talking about the deficiency of its language definition that 
leads to exactly what your complaining about.

Don't make the mistake to reduce language to syntax only.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

2006-07-17 Thread Vinzent Hoefler
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 
standardized quite clearly, (most) consistency, dependency and linking 
issues are beyond the scope of the official C-standard.

What a luck that at least the code is portable from one platform to 
another. If you have a spare floppy to transport it. :-


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problem loading 2 dlls created on Free Pascal

2006-07-13 Thread Vinzent Hoefler
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 Abnormal
 process termination or the like.. :-?

Uhuh. How come that this would make more sense? ;-)


SCNR,

Vinzent.

-- 
An unexpected error occured. - Oh, all the other ones are *expected*?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Format with zero padding

2006-06-20 Thread Vinzent Hoefler
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/fpc-devel


Re: [fpc-devel] Format with zero padding

2006-06-20 Thread Vinzent Hoefler
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
 ;-).

As if format strings were intuitive at all. :-)

I'd call Zero_Pad (Some_Int, 4) definitely more intuitive.

 Seriously, isn't Format an imitation of C's printf ?

Apart from the fact, that you can get run time type checking? Yeah, I 
suppose so.

 At least they
 are very similar, but on this detail (and maybe some others as well)
 they are different.

Well, let's assume it's due to Delphi-compatibility. Probably Borland 
decided to do it differently just for the fun of it. ;-)


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] dominant short strings in compiler source

2006-05-18 Thread Vinzent Hoefler
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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Math.DivMod results should be signed

2006-03-21 Thread Vinzent Hoefler
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 be  0.

Which would seem correct, if this were really a modulo-operation.

Unfortunately, DivMod should really be called DivRem, because it does 
not calculate the modulus, but rather the remainder of the division 
operation. But at least the name of the result variable suggests so.

 But when Dividend is  0, Result and/or Remainder sometimes have to
 be  0. For example,

 var
UnsignedDivResult, UnsignedModResult: Word;
DivResult: SmallInt absolute UnsignedDivResult;
ModResult: SmallInt absolute UnsignedModResult;
 begin
DivMod(-39, 20, UnsignedDivResult, UnsignedModResult);
 end;

 gets me UnsignedDivResult = 65535 and UnsignedModResult = 65517. Of
 course when treating memory as signed values (DivResult and
 ModResult), I can decipher correct values (-1 and -19) but that's
 obviously unclean.

Agreed. This result proves, that on an x86 the IDIV instruction is used, 
which is a signed integer operation with _signed_ results. So if Delphi 
does it the same way, they really screwed up the interface, because 
then it only works correctly for non-negative Dividends and Divisors 
less than 32768.

 Sure I can also just use div and mod
 operators, they always get me correct values, but I understand that
 doing div and mod separately may be slower than DivMod on some
 processors.

Yes, just because you would do exactly the same operation twice.

 I know that DivMod arguments have to stay as Word for Delphi compat.

I suppose so, although it is wrong (or let's say: very restricted) 
anyway.

 But in the light of the above, it seems like a good idea to add
 overloaded DivMod version that returns Result and Remainder as signed
 values ?

It would be, definitely. Especially because it does seem to calculate it 
that way.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] about realtime tasks

2006-01-18 Thread Vinzent Hoefler
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 routines: ...

As far as I understand that it means you should not do that at the 
_application side_. There is a ThreadManager to abstract away these 
system specifics.

 As far as I understood, I need to include the unit cthreads, which i
 have done.

Which AFAIK in turn uses the pthreads library. Which is probably not 
what you want.

 When I include cthreads and (manually?) initialize the ThreadManager,
 would it be ok ?

I think you should simply write and install your own thread manager 
based on the (native or the RT-POSIX-threads) xenomai API and link to 
the xenomai library _instead_ of the libpthread.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Templates / Generics

2005-11-04 Thread Vinzent Hoefler
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
  StringType: Show(Data);
  IntegerType: Show(Data);
end;

 The whole idea of Generics is to avoid this :-)

At user level, yes. But as a compiler-writer you'd gotta make it work 
somehow.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


pgp8YjRx3wBer.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Templates / Generics Syntax

2005-11-04 Thread Vinzent Hoefler
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 back in 1983[*] already.
Perhaps someone should take a look at those, because these are also 
quite different from C++-templates.


Vinzent.

[*] That would be the same year the term C++ just appeared first in 
history of programming languages then, and this particular C++ didn't 
even have templates yet.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


pgp3kje8Y8SWV.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Templates / Generics Syntax

2005-11-04 Thread Vinzent Hoefler
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 and for those who don't know it yet, the previously 
given example in Ada95-syntax:

-- 8 -- snip --
procedure Gen_Test is

   -
   package Show is
  procedure Do_It (i : Integer);
  procedure Do_It (s : String);
   end Show;

   package body Show is
  procedure Do_It (i : Integer) is
  begin
 null;
  end Do_It;

  procedure Do_It (s : String) is
  begin
 null;
  end Do_It;
   end Show;
   -

   -
   generic
  type T () is private;

  procedure Dump (Value : T);

  procedure Dump (Value : T) is
 use Show;
  begin
 Do_It (Value);
  end Dump;
   -

   -
   procedure My_Dump is new Dump (Integer);
   procedure My_Dump is new Dump (String);
   -

begin -- Gen_Test
   My_Dump (42);
   My_Dump (foobar);
end Gen_Test;


pgp0x2VjCjF7F.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
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 a 
feature. :-)

 If ever you changed that, i.e., if you suppressed the overflows
 with Inc and Dec, thanks to let us know explicitely (here, for
 instance).

Full ACK. They have to document it either way (and in the past they 
did).

 Personally, I would have to rewrite a few lines of
 code, like, for instance, in

 procedure XDiv2(X: PBigFloat);
 begin
with X^ do if not IEqu0(Mantissa) then {$Q+} Dec(Exponent); {$Q-}
 end;

Yeah. Sure. Same reason I had to rewrite:

|   for i := 0 to Buf_Len - 1 do
|   begin
|  b := tByteArray (Buf)[i];
|  Inc (C_Sum, b); { work around range check error RRG/VH 161100 }
|  ComOut (P_Nr, b);

because after we decided to port the whole stuff to Linux, FPC broke the 
code again. :-)

  The only time I ever used it was a checksum
  calculation which was modulo anyway. Any other time I use the usual
  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 + or - unless you have
  very_long_and_complex_variable_names and want to save some typing
  work.

 That's a matter of habit. Not sure but I believe that with TP3,
 the compiled code was better with Inc than with +.

Yes, it used a direct memory increment which was better on the 
processors we used back then. Interestingly with the introduction of 
the Pentium 10 years ago which (in most cases) could execute the 
mem-store/reg-inc/mem-store faster than the direct in-memory-addition 
this optimization fired back. Of course then it didn't matter that much 
anymore, 'coz the processor was too fast already. ;-)


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
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, instead

{$IFDEF BIG}
type My_Type = SmallInt;
{$ELSE}
type My_Type = ShortInt;
{$ENDIF}

and then

|Inc (My_Type(v), Delta);

should do the trick.

OTOH, to be honest: I don't see the point in using Inc/Dec here at all, 
especially if v := v + Delta; would work perfect already. I even 
think the standard way of doing the addition would be much more 
readable in that context.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


pgplFJ6tp8cLb.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
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? what's that?

http://www.acronymfinder.com/af-query.asp?String=exactAcronym=otoh

;-)

 With some accustomization, inc(... and v := v + ... is both good
 readable, and normally (at least with checks off) it was assumed to
 produce compacter and faster code. Especially when v is not a simple
 variable, but a more complex one, e.g.:
 Inc ( v[j]^[k].a[l], delta ) ;
 And in such a case it's also better readable.

Yes, if you really need to do such complex expressions. I tend to write 
smaller subroutines which take arguments.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


pgpaGLZ96AKdh.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Advantages of/alternatives for Inc (was: bug: Inc(v, i)/Dec(v, i))

2005-07-08 Thread Vinzent Hoefler
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 + or - unless you have
  very_long_and_complex_variable_names and want to save some typing
  work.

 You suggest that it saves only typing,

No, I just tried to ignore that point and hoped nobody would notice. :)

 but it also simplifies
 optimization in cases where the variable is compositite, because the
 address needs to be calculated only once.

Yes, but in the same way it endorses using functions with side-effects. 
Consider

|Int_Ptr^ := Int_Ptr^ + 1;

vs.

|Inc (Int_Ptr^);

where Int_Ptr is a function returning a pointer to a different Integer 
each time it is called.

  E.g. in one piece of code,
 I have a 13-dimensional array of integers, and I do

   Inc ( A[e1, e2, ..., e13] )

 I don't know if modern compilers will properly optimize

   A[e1, e2, ..., e13] := Succ ( A[e1, e2, ..., e13] )

They should, unless the index expressions are functions - which may have 
side-effects. See above.

 In fact, it would be nice to have a Self for arrays as well (as for
 objects), where you could write

   with A[e1, e2, ..., e13] do
 Self := Succ ( Self )

It could be more generic, if you'd allow renaming declaration like Ada 
does:

declare
   X : Integer renames A(e1, e2, ..., e13);
begin
   X := X + 1;
end;

Well, the problem with possible side-effects would remain then. Perhaps 
we should introduce the notion of a pure function (like in VHDL) to 
give the compiler a hint that it doesn't need to recalculate all that 
stuff.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


pgpMSJLwHG0Le.pgp
Description: signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] {$DEFINE x := something}

2005-07-01 Thread Vinzent Hoefler
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 that window need refactoring. :- Are we done with the 
dicksize war now?


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-03 Thread Vinzent Hoefler
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 discrepancy between what the code is supposed to do and 
what it really does. If a fellow programmer relies on the latter this 
is known to break sooner or later.

Of course, this implies that there *is* a specification.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-03 Thread Vinzent Hoefler
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 or putting curly braces around it.

 Not every syntax is about minimizing code or readability.

The latter it should.

 Some are
 also to simply simplify parsing (and that is about compiler
 developer, but to make the language more internally consistent) and
 avoid long lookaheads. These things combined also improve quality of
 error messages a lot.

Well, it is still named begin, end, not x0x0x0 0x0x0x, is 
it? ;-)

And for the compiler: it wouldn't make a difference if you'd parse 
begin end or curly braces tokens, would it?

   Maintenance is easier as their is less redundancy.
 
  It simply depends on the kind of redundancy.
 
  For instance, type and var keywords are just redundant, the
  compiler could figure it out by itself, still they serve a useful
  purpose.

 See above.

Yes, it might make the compiler writer's job easier. But typically you 
don't design a language around a compiler. And I strongly doubt that 
Wirth did.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
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/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
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 of _working_ lines of code? :-

 Dont kid yourself - a lot of my fellow Delphi programmers have dumped
 it for C# already so it is really worrying for me espcially with
 borland being virtually bankrupt. Delphi as it is faces a bleak
 future so its looking increasingly like its time to modernise or die.

Yeah. Flies. Shit.

They keep telling me the same about Ada. Still, I am much more 
productive than any of my fellow programmers who are doing things in C, 
Java, or Python. While they are still debugging and chasing 
NullPointerExceptions and such stuff, I already implemented the next 
needed feature.

I can't even remember when was the last time I actually needed a 
debugger.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
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 misunderstanding (especially amongst C-programmers).

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 
(s)he would gain would be five percent in overall performance.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
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 (s)he would gain would be five percent in overall
  performance.

 you are missing the point!

No, I don't. I'm damn sure what I am talking about.

 Whather you can implement something faster in another language is not
 the issue.

Right. The issue is if you can make it work, i.e. how long you have to 
test and debug it and how long someone needs to understand it when he 
comes to that code later (that's called maintenance, I think).

 I am arguing for less verbose syntax without decreasing
 the clarity of the code in delphi/pascal

Which is an almost impossible task. Sure you can tweak it here and 
there, but it would _at best_ simplify the task of writing the code in 
the first place. You are just missing the remaining 98% of the 
development cycle of a typical medium to large software project.

You won't gain anything there, even if and /only if/ you could manage to 
simplify some syntax without having *any* impact on understanding the 
code later.

(BTW, Ada is even more verbose than Pascal and for the things I'm doing 
it is still /more/ productive. I'm talking about error rates and such 
stuff, not how much time spending in front of the monitor typing 
something that *may* work, if you just debug it long enough).

 and that is logically gonna
 improve productivity without taking anything away.

It would, if you could actually manage to accomplish that task. But as I 
tried to point out, those 5% don't matter. You can lose *much* more and 
much easily on a bad design. 90% of software development costs is 
testing. And then it is much better to actually be able to _read_ and 
_understand_ the code instead of writing it.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
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 in *thinking* about what I 
should do, 10% in writing the code, 5% in showing that it works and 5% 
in drinking coffee to enhance the productivity of the first 80%.

Well, of course, this is a slight exaggeration.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
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 the compiler.

IBTD.

 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 or putting curly braces around it.

 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 any syntax.

 All in all the changes would mean you spend more of your time
 implementing your application rather than typing loads of redundant
 code.

Typing is only a very small part of the development cycle. Performance 
measures indicate that rhe average programmer delivers about 2 to 20 
lines per code per day (measured over the whole development cycles, 
this of course includes testing, too).

Compare these with the lines of code you *could* write in eight hours if 
you would just write them and you see how much you could optimize away 
there if you'd actually manage to double the performance.

 Maintenance is easier as their is less redundancy.

It simply depends on the kind of redundancy.

For instance, type and var keywords are just redundant, the compiler 
could figure it out by itself, still they serve a useful purpose.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
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 extra complexity? You still need the 
real thing, so for consistency it's better to stay with it only.

Something like this you can see in Java: In the constructor of a derived 
class you always need to call the constructor of the base class in the 
first place. So, to simplify the task, the compiler does the magic 
for you, if there is a default constructor that has no parameters. 
Great. But the virtually same code just does not compile when there is 
no such thing as a parameterless constructor and you keep asking you 
why it does not f***ing compile. Until you read the 500 pages of the 
JLS and then *know* that the compiler does stupidly magic tricks for 
you. It can even become much more confusing if you have more than a 
single constructor.

I don't think, this makes anything easier, less error-prone, whatever. 
It just confuses people.


Vinzent.

-- 
public key: http://www.t-domaingrabbing.ch/publickey.asc


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


  1   2   >