On 10-3-2013 21:56, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
I've written a demo application that:
uses regular TIBConnection and SQL commands to
1. create a new db on a server
2. create a user with GRANT ADMIN ROLE and full control over the new db
snip
Subject to a maximum user
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
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.
snip
True, but I thought that a detail relating to something that people were
likely to do
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
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
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
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk 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
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
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
On Mon, Mar 11, 2013 at 10:43 AM, Jonas Maebe jonas.ma...@elis.ugent.be 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
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
Daniel Gaspary wrote:
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk 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
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,
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...
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
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:
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 dgasp...@gmail.com
To: FPC-Pascal users discussions
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 g...@g--s.de
To: FPC-Pascal users discussions
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 at
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
On 3/11/13, Darius Blaszyk dhkblas...@zeelandnet.nl 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
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
I'm
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) - ((char
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) - ((char
24 matches
Mail list logo
