Re: [fpc-pascal] Memoryleak in SQLite3db.TSqlite?
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
Re: [fpc-pascal] Porting C macro
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 *) & (((LList *)0)^.next > > I'm assuming that the "^." should be "->", in which case the last bit is > doing the same as the offsetof() macro. So the macro is subtracting the > offset in bytes of the "next" member of the LList struct from x, then > casting it to (LList *). > > I'd wager that the GETNEXT() isn't actually doing what it says, but > something more like container_of() (because it's _subtracting_ the > offset). I may be wrong, though, do you have an example of its usage? > > Henry > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal [1] BTW, you were right. The ^ was indeed a ->, but got replaced in the porting process. Regards, Darius Links: -- [1] http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting C macro
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 *) & (((LList *)0)^.next > > I'm assuming that the "^." should be "->", in which case the last bit is > doing the same as the offsetof() macro. So the macro is subtracting the > offset in bytes of the "next" member of the LList struct from x, then > casting it to (LList *). > > I'd wager that the GETNEXT() isn't actually doing what it says, but > something more like container_of() (because it's _subtracting_ the > offset). I may be wrong, though, do you have an example of its usage? > > Henry > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal [1] I will let your email sink in later, but here is a usage example as requested if (list->next) GETNEXT(list->prev)->nextname = GETNEXT(list->next)->name; else GETNEXT(list->prev)->nextname = 0; Both name and nextname are pchar's. Regards, Darius Links: -- [1] http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting C macro
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 assuming that the "^." should be "->", in which case the last bit is doing the same as the offsetof() macro. So the macro is subtracting the offset in bytes of the "next" member of the LList struct from x, then casting it to (LList *). I'd wager that the GETNEXT() isn't actually doing what it says, but something more like container_of() (because it's _subtracting_ the offset). I may be wrong, though, do you have an example of its usage? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting C macro
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 meant with the define? > Obviously LList is a linked list struct that has a prev and next > variable. But what does the & and 0 mean? > > Appreciate any > help. > > Regards, Darius AFAICS they mean "address" and "nil", respectively, so that part will return the offset of "next" inside and item of LList. -Flávio -Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Porting C macro
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 list struct that has a prev and next variable. But what does the & and 0 mean? Appreciate any help. Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 the other, a set to > contain up to (say) 257 elements would require more space and that's > not supported. > Probably a typo, but 8 bit * 8 bytes = 64 elements. So I suppose you mean `[...] occupies 32 bytes in memory [...]`? Just so nobody gets confused :-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 7:42 PM Subject: Re: [fpc-pascal] Set size limit 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, March 09, 2013 9:52 PM Subject: [fpc-pascal] Set size limit Hi, I am trying to create a Set Type... TMyEnum = (me1, me2, me3); // more than 500 elements TMySet = set of TMyEnum; ...but I get the following error: "Error: illegal type declaration of set elements" [1] The problem seems to be that TMyEnum has more than 256 elements. Can I specify such Set with some compiler option ? My fpc is pre 2.6, any change on new versions concerning Sets limits? Thanks. [1] A more specific message would help too. :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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, March 09, 2013 9:52 PM Subject: [fpc-pascal] Set size limit Hi, I am trying to create a Set Type... TMyEnum = (me1, me2, me3); // more than 500 elements TMySet = set of TMyEnum; ...but I get the following error: "Error: illegal type declaration of set elements" [1] The problem seems to be that TMyEnum has more than 256 elements. Can I specify such Set with some compiler option ? My fpc is pre 2.6, any change on new versions concerning Sets limits? Thanks. [1] A more specific message would help too. :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ubigset.7z Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memoryleak in SQLite3db.TSqlite?
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.freepascal.org/view.php?id=23247 Hello, I found no possibility to contact a person via Mantis. Can anybody apply this patch to the trunk? Done. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memoryleak in SQLite3db.TSqlite?
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 possibility to contact a person via Mantis. Can anybody apply this patch to the trunk? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 then it will be easier to implement compiler support using bitpacked arrays instead of creating so complex workarounds? Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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'd have to reimplement this for every single pseudo-set type you want to use (except maybe if you use generics, if generics for simple types already work). Generics do work for array, but maybe not for indices. 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... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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-element sets would be far better. 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 try to add more than 256 elements to the set ? 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 the other, a set to contain up to (say) 257 elements would require more space and that's not supported. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 single pseudo-set type you want to use (except maybe if you use generics, if generics for simple types already work). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 how many elements are inside it. > > The above also shows an alternative to sets in that case: you can use a > bitpacked array[TMyEnum] of boolean instead. Of course, then you can't use > the regular set operators. > > Jonas Your explanation made the implementation problem clear to me. And the alternative is interesting. Thank you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 compile the code and raise an exception if I try to add more than 256 elements to the set ? 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 how many elements are inside it. The above also shows an alternative to sets in that case: you can use a bitpacked array[TMyEnum] of boolean instead. Of course, then you can't use the regular set operators. If the array is a named one (e.g. "TMyArraySet = bitpacked array[TMyEnum] of Boolean") then operator overloading could be used... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 try to add more than 256 elements to the set ? 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 how many elements are inside it. The above also shows an alternative to sets in that case: you can use a bitpacked array[TMyEnum] of boolean instead. Of course, then you can't use the regular set operators. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 be far better. 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 try to add more than 256 elements to the set ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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 didn't have any vector instructions at all. Again: this limitation is unrelated to instruction sets, it's about deciding on a point at which you're going to waste a lot of memory by using a plain bitmap. For larger sets... OK, how /does/ one declare a set of UTF-8 characters? An UTF-8 character is not an ordinal data type and hence support for "set of " is orthogonal to support for larger sets. If you store them in strings or arrays, then you need a hashtable of strings or arrays (and/or support for sets of strings or arrays, which would probably be implemented using... a hashtable). 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 be far better. A modest expansion to be able to handle something like a bitboard for Go might be attractive though. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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-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 didn't have any vector instructions at all. Again: this limitation is unrelated to instruction sets, it's about deciding on a point at which you're going to waste a lot of memory by using a plain bitmap. There is a already a test for larger set support: http://svn.freepascal.org/svn/fpc/trunk/tests/test/tset6.pp Nobody has worked yet on implementing it, but if anyone thinks it's easy to do, please go ahead. For larger sets, especially if they are sparse, a simple hashtable-based class would probably be much faster and memory efficient than simply extending the default implementation though. With operator overloading and generics you might even be able to use more or less the same syntax as with built-in sets. For larger sets... OK, how /does/ one declare a set of UTF-8 characters? An UTF-8 character is not an ordinal data type and hence support for "set of " is orthogonal to support for larger sets. If you store them in strings or arrays, then you need a hashtable of strings or arrays (and/or support for sets of strings or arrays, which would probably be implemented using... a hashtable). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
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.g. vector operations that suggest a realistic
maximum size?
I am annoyed by some LCL bugs which are there only for Delphi compatibility.
This issue is similar.
It is not.
This kind of artificial limitation could easily be fixed.
I think it should apply for {$mode objfpc} only.
There is a already a test for larger set support:
http://svn.freepascal.org/svn/fpc/trunk/tests/test/tset6.pp
Nobody has worked yet on implementing it, but if anyone thinks it's easy to do,
please go ahead. For larger sets, especially if they are sparse, a simple
hashtable-based class would probably be much faster and memory efficient than
simply extending the default implementation though. With operator overloading
and generics you might even be able to use more or less the same syntax as with
built-in sets.
For larger sets... OK, how /does/ one declare a set of UTF-8 characters?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
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 comparatively infrequently (i.e. user management by a > custom app rather than by something like Flamerobin) was worth getting > into the record. FlameRobin etc have the exact same limitations though... Anyway, hope your project goes well... and it's always good to have somebody tell about his experiences with a new technology so missing/incomplete docs etc can be fixed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
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 table/trigger/sp/view/general object name max length in FB is about 32 bytes IIRC. True, but I thought that a detail relating to something that people were likely to do comparatively infrequently (i.e. user management by a custom app rather than by something like Flamerobin) was worth getting into the record. I suppose you found out FB has an 8 char effective password? You can use more letters but MASTERKE is the same as MASTERKEY. Of course this goes away if you use trusted authentication/OS authentication. I hadn't yet, but I was going to hash (etc.) the user's submission anyway so that it could be stored and moved around without grave risk. Which obviously introduces issues when communities with different salt are merged... and so on :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
