Am 11.03.2013 16:27, schrieb Michael Van Canneyt:
Can anybody apply this patch to the trunk?
Done.
Thank you.
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Henry Vermaak schreef op 12 mrt '13:
> On Mon, Mar 11, 2013 at
11:26:57PM +0100, Darius Blaszyk wrote:
>
>> I'm stuck porting a macro
from C. Below is the original define. The part I'm struggeling with is
the right most part after the - sign. #define GETNEXT(x) ((LList
*)(((char *) x) - ((cha
Henry Vermaak schreef op 12 mrt '13:
> On Mon, Mar 11, 2013 at
11:26:57PM +0100, Darius Blaszyk wrote:
>
>> I'm stuck porting a macro
from C. Below is the original define. The part I'm struggeling with is
the right most part after the - sign. #define GETNEXT(x) ((LList
*)(((char *) x) - ((cha
On Mon, Mar 11, 2013 at 11:26:57PM +0100, Darius Blaszyk wrote:
>
>
> I'm stuck porting a macro from C. Below is the original define. The
> part I'm struggeling with is the right most part after the - sign.
>
>
> #define GETNEXT(x) ((LList *)(((char *) x) - ((char *) & (((LList
> *)0)^.next)))
On 3/11/13, Darius Blaszyk wrote:
>
>
> I'm stuck porting a macro from C. Below is the original define. The
> part I'm struggeling with is the right most part after the - sign.
>
>
> #define GETNEXT(x) ((LList *)(((char *) x) - ((char *) & (((LList
> *)0)^.next
>
> Does anyone know what is mea
I'm stuck porting a macro from C. Below is the original define. The
part I'm struggeling with is the right most part after the - sign.
#define GETNEXT(x) ((LList *)(((char *) x) - ((char *) & (((LList
*)0)^.next
Does anyone know what is meant with the define?
Obviously LList is a linked l
Once upon a time, Mark Morgan Lloyd said:
> No, because the elements in a set are dictated by their position. A
> set that can contain anything between 0 and 256 elements occupies 8
> bytes in memory with the (bit representing the) 0 element at one end
> and the (bit representing the) 256 element a
Sorry, there are some changes neccessary:
drop the reference to unit
uAsms
delete the line
FillOnes ( ...
it was there for debugging purposes
- Original Message -
From: "Gerhard Scholz"
To: "FPC-Pascal users discussions"
Cc:
Sent: Monday, March 11, 2013
Here is a unit that could be useful.
Works with pentium and Win32; not tested with other CPUs or operating
system.
I hope you have 7zip, or I will create a zip file.
Greetings
Gerhard
- Original Message -
From: "Daniel Gaspary"
To: "FPC-Pascal users discussions"
Sent: Saturday,
On Mon, 11 Mar 2013, Michael Fuchs wrote:
Am 31.10.2012 10:54, schrieb Michael Fuchs:
It works, but the heap trace shows a bunch of memory leaks.
...
Is this a bug or am I doing something wrong?
For information: I created an entry in the bug tracker for this problem:
http://bugs.freepasca
Am 31.10.2012 10:54, schrieb Michael Fuchs:
It works, but the heap trace shows a bunch of memory leaks.
...
Is this a bug or am I doing something wrong?
For information: I created an entry in the bug tracker for this problem:
http://bugs.freepascal.org/view.php?id=23247
Hello,
I found no p
11.03.13, 22:10, Sven Barth wrote:
Generics do work for array, but maybe not for indices.
Only for type of element as I remember.
Also you'd need
to declare the operators anyway. Best solution in this case might be to
encapsulate the array in a record and define the operators there...
Maybe
Am 11.03.2013 14:59, schrieb Jonas Maebe:
On 11 Mar 2013, at 14:52, Sven Barth wrote:
If the array is a named one (e.g. "TMyArraySet = bitpacked
array[TMyEnum] of Boolean") then operator overloading could be used...
Yes, but since neither open nor dynamic bitpacked arrays are
supported, you
Daniel Gaspary wrote:
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
wrote:
That was pretty much my gist. Since these days Unicode is larger than 65536
codepoints I don't think there's any advantage to expanding sets from 256 to
65536 elements, efficient operations on sparse arrays of 256-e
On 11 Mar 2013, at 14:52, Sven Barth wrote:
If the array is a named one (e.g. "TMyArraySet = bitpacked
array[TMyEnum] of Boolean") then operator overloading could be used...
Yes, but since neither open nor dynamic bitpacked arrays are
supported, you'd have to reimplement this for every sin
On Mon, Mar 11, 2013 at 10:43 AM, Jonas Maebe wrote:
> A set is basically a bitpacked array of boolean. Element X is set to true if
> you add X to the set, and to false if you remove it again. That means that
> if you have a set with 600 possible values, you need at least 600 bits,
> regardless of
Am 11.03.2013 14:43, schrieb Jonas Maebe:
On 11 Mar 2013, at 14:32, Daniel Gaspary wrote:
In my case the enum has near 600 elements.
TMyEnum = (me1, me2...);
The set though would never be used to contain more than 256.
TMySet = set of TMyEnum;
Is it not viable to modify the compiler to com
On 11 Mar 2013, at 14:32, Daniel Gaspary wrote:
In my case the enum has near 600 elements.
TMyEnum = (me1, me2...);
The set though would never be used to contain more than 256.
TMySet = set of TMyEnum;
Is it not viable to modify the compiler to compile the code and raise
an exception if I t
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
wrote:
> That was pretty much my gist. Since these days Unicode is larger than 65536
> codepoints I don't think there's any advantage to expanding sets from 256 to
> 65536 elements, efficient operations on sparse arrays of 256-element sets
> would
Jonas Maebe wrote:
Provided that one calls a Z80 16-bit :-) More to the point: do any
current CPUs have e.g. vector operations that suggest a realistic
maximum size?
The current x86's bit test/set instructions support addressing the
complete 32/64 bit address space. But the original 8086 did
On 11 Mar 2013, at 10:39, Mark Morgan Lloyd wrote:
Jonas Maebe wrote:
On 10 Mar 2013, at 15:00, Juha Manninen wrote:
There are no 8-bit CPUs
supported by FPC that would justify it.
It is unrelated to 8 bit cpus. Even Turbo Pascal 1.0 ran on a 16
bit cpu.
Provided that one calls a Z80 16-b
Jonas Maebe wrote:
On 10 Mar 2013, at 15:00, Juha Manninen wrote:
There are no 8-bit CPUs
supported by FPC that would justify it.
It is unrelated to 8 bit cpus. Even Turbo Pascal 1.0 ran on a 16 bit cpu.
Provided that one calls a Z80 16-bit :-) More to the point: do any
current CPUs have e
On 11-3-2013 9:24, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
>>> Subject to a maximum user name length of 31 characters on Firebird. The
>>> manual suggests that PostgreSQL has a limit of 64.
> True, but I thought that a detail relating to something that people were
> likely to do compa
Reinier Olislagers wrote:
Subject to a maximum user name length of 31 characters on Firebird. The
manual suggests that PostgreSQL has a limit of 64.
If you're going to list all differences between PG and FB as you hit
them, you might put them on a wiki page for easy retrieval by others.
The t
24 matches
Mail list logo
