Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Wednesday 11 April 2012 08:54:18 wahono sri wrote: > At line 5432 : > > if int1 > 0 then begin > > it should be : > > if int1 >= 0 then begin > > Because it always ignore first row. > Changed in git master e8f1d49de2fc18b898d662cd19a4b2cf3ada3a1e, thanks. BTW, I don't like the one-based FPC recno, I think it should be zero-based. What do you think? Martin -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
> Changed in git master e8f1d49de2fc18b898d662cd19a4b2cf3ada3a1e, thanks. > BTW, I don't like the one-based FPC recno, I think it should be zero-based. > What do you think? > I think zero-based is OK such as array concept. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hi. Array concept zero-based? not in objectpascal. Why the first element must be 0? You usually think first=1, second=2 first=0? I know there are lots of arguments about starting in 0 or 1 or whatever and I don't want to start a 'war' because it.. My point of view is to follow fpc/fcl direction. Cheers 2012/4/11 wahono sri > > Changed in git master e8f1d49de2fc18b898d662cd19a4b2cf3ada3a1e, thanks. > > BTW, I don't like the one-based FPC recno, I think it should be > zero-based. > > What do you think? > > > I think zero-based is OK such as array concept. > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > mseide-msegui-talk mailing list > mseide-msegui-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Julio Jiménez Borreguero -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Wednesday 11 April 2012 10:23:37 Julio Jiménez wrote: > Hi. > > Array concept zero-based? not in objectpascal. > > Why the first element must be 0? You usually think first=1, second=2 > first=0? > All indexes in FPC dynamic arrays are null-based, TList indexes are null based, direct data access in tmsebufdataset is null-based. BTW, do you know tmsebufdataset.currentas* property?. I assume one-based recno is a relict from Borland-BDE-Dbase times. The MSEgui datasets have a null-based recno already (controller.recnonullbased). Martin -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Probably there is a mix of concepts. When I read recno I understand item so first item is 1, second is 2.. Another thing is offset, in this case first element has offset 0, second 1 That's the main reason I understand for recno first element=1 If you rename it as recoffset then it's ok starting in 0. I'm not sure the one-based recno is a relict from Borland-BDE. Objectpascal does not enforce you to start an array index in 0, 1 or whatever. C language does it. Of course this is only my point of view. Cheers. 2012/4/11 Martin Schreiber > On Wednesday 11 April 2012 10:23:37 Julio Jiménez wrote: > > Hi. > > > > Array concept zero-based? not in objectpascal. > > > > Why the first element must be 0? You usually think first=1, second=2 > > first=0? > > > All indexes in FPC dynamic arrays are null-based, TList indexes are null > based, direct data access in tmsebufdataset is null-based. BTW, do you know > tmsebufdataset.currentas* property?. > I assume one-based recno is a relict from Borland-BDE-Dbase times. The > MSEgui > datasets have a null-based recno already (controller.recnonullbased). > > Martin > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > mseide-msegui-talk mailing list > mseide-msegui-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Julio Jiménez Borreguero -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On 11 April 2012 10:40, Martin Schreiber wrote: > > All indexes in FPC dynamic arrays are null-based, TList indexes are null > based, direct data access in tmsebufdataset is null-based. BTW, do you know > tmsebufdataset.currentas* property?. > I assume one-based recno is a relict from Borland-BDE-Dbase times. The MSEgui > datasets have a null-based recno already (controller.recnonullbased). Maybe you should raise this question in the fpc-pascal mailing list too. Find out why it was 1-based before you make the change - or maybe the change could be done in FPC itself if all agree. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
I have found this link where there is a talk about it. http://www.mail-archive.com/lazarus@miraclec.com/msg06970.html 2012/4/11 Graeme Geldenhuys > On 11 April 2012 10:40, Martin Schreiber wrote: > > > > All indexes in FPC dynamic arrays are null-based, TList indexes are null > > based, direct data access in tmsebufdataset is null-based. BTW, do you > know > > tmsebufdataset.currentas* property?. > > I assume one-based recno is a relict from Borland-BDE-Dbase times. The > MSEgui > > datasets have a null-based recno already (controller.recnonullbased). > > > Maybe you should raise this question in the fpc-pascal mailing list > too. Find out why it was 1-based before you make the change - or maybe > the change could be done in FPC itself if all agree. > > > -- > Regards, > - Graeme - > > > ___ > fpGUI - a cross-platform Free Pascal GUI toolkit > http://fpgui.sourceforge.net > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > mseide-msegui-talk mailing list > mseide-msegui-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Julio Jiménez Borreguero -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Wed, 11 Apr 2012 10:40:40 +0200: > All indexes in FPC dynamic arrays are null-based, TList indexes are null > based, direct data access in tmsebufdataset is null-based. BTW, do you Which are direct take-overs from C. > I assume one-based recno is a relict from Borland-BDE-Dbase times. The Could well be - records are usually sequenced by counting, which traditionally begins at "one" (1). > MSEgui datasets have a null-based recno already > (controller.recnonullbased). Your tribute to C, I guess. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Julio, Du schriebst am Wed, 11 Apr 2012 10:23:37 +0200: > Array concept zero-based? not in objectpascal. Right. Array indeices are based on whatever value the implementor decides on. > I know there are lots of arguments about starting in 0 or 1 or whatever As is always the case when the property used is completely arbitrary. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin,
Du schriebst am Wed, 11 Apr 2012 09:09:42 +0200:
> BTW, I don't like the one-based FPC recno, I think it should be
> zero-based. What do you think?
That's the distinction between _counting_ and _numbering_.
Do you count "0, 1, 2..."? Probabely not.
How do you number things?
Doesn't matter at all, because here, the numbers are just labels. Odered
labels, usually, but just labels. You could use any other set of symbols
having an oder relation, like letters of the alphabet, or the number names
("One, two, three...").
There's even a mathematical concept for each of these:
counting numbers are called "cardinal", while numbering numbers (;) are
called "ordinal".
Calculating is only defined for cardinal numbers, you can add, subtract or
multiply them (division is a special case here, because division cannot be
defined wholly within the cardinal number's space).
With ordinal numbers, you only have distance between them.
Usually, this isn't recognized, as one doesn't commonly attempt to multiply,
e.g., record numbers or array indices, or even add them together.
Subtracting two ordinal numbers produces _not_ an ordinal, but a cardinal,
giving the distance between the two. Distance can be positive or negative,
because ordinals are ordered - you can always tell whether one comes
"before" the other, is "smaller" by means of the ordering relation.
An implementation of ordinal data are Pascal's enumerations, a "typical"
use are array indices - which, in Pascal, are implemented such that there
is a starting value and a sequence defined, where the starting value can be
anything allowable for the index value. You can also use enumerations as
indices.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Wednesday 11 April 2012 21:42:13 Sieghard wrote: > Hallo Martin, > > Du schriebst am Wed, 11 Apr 2012 10:40:40 +0200: > > All indexes in FPC dynamic arrays are null-based, TList indexes are null > > based, direct data access in tmsebufdataset is null-based. BTW, do you > > Which are direct take-overs from C. > > > I assume one-based recno is a relict from Borland-BDE-Dbase times. The > > Could well be - records are usually sequenced by counting, which > traditionally begins at "one" (1). > > > MSEgui datasets have a null-based recno already > > (controller.recnonullbased). > > Your tribute to C, I guess. I think indexing null or one based should be consistent in a programming environment. In tmsebufdataset the record data can be addressed as array with null based index so there should be a null based record number too. Delphi datasets don't provide direct data access without scrolling the dataset AFAIK. I don't like the one based Pascal string indexes either, null based addressing is faster. Often one needs the next character in a string after a starting sequence of given length, null based index is more convenient here too. I'll probably add a "recindex" property to the datasets. Martin -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
> How do you number things? Me guess the best solution is that won't enforce referencing docs & sources whether 0 or 1 :) That's once established system for every case. If 90% is zero based then the remaining 10% should also turn into zero based. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
> counting numbers are called "cardinal", while numbering numbers (;) are > called "ordinal". In FPC, the "cardinal" is >=0 (can really be counted on fingers) with twice as higher upper bound. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Thu, 12 Apr 2012 07:22:32 +0200: > > > MSEgui datasets have a null-based recno already > > > (controller.recnonullbased). > > > > Your tribute to C, I guess. > > I think indexing null or one based should be consistent in a programming Yes, for sure - it should be consistently left to the user, i.e. programmer. (BTW, waht does "null based" mean here? Did you want to write "zero based"?) > I don't like the one based Pascal string indexes either, null based > addressing is faster. That's nonsense. Implemented correctly, _any_ index base gives identical speed - you _don't_ implement it using offset calculation from the first _existing_ element, but instead, you calculate the offset from a "virtual" element corresponding to the (invalid) index "0". No additional operations neccessary. (And without index range checking, you can access _any_ address anyway.) > Often one needs the next character in a string after a starting sequence > of given length, null based index is more convenient here too. Just as often one needs the character position behind some arbitrary string at some arbitrary location - there's no advantage to any starting index then. > I'll probably add a "recindex" property to the datasets. Sure - you're free to do so, for whatever reason you might imagine. ;-) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Friday 13 April 2012 00:05:07 Sieghard wrote:
>
> That's nonsense. Implemented correctly, _any_ index base gives identical
> speed - you _don't_ implement it using offset calculation from the first
> _existing_ element, but instead, you calculate the offset from a "virtual"
> element corresponding to the (invalid) index "0". No additional operations
> neccessary. (And without index range checking, you can access _any_ address
> anyway.)
>
You probably should have a look into the disassembler listings of your
programs and the FPC RTL.
Why do you think Pascal string index is one based in the first place? Because
it is a zero based index to the old shortstring data where [0]
denotes the length byte, do you remember? An AnsiString is
(rtl/inc/astrings.inc):
"
{
AnsiString is defined as a 'silent' pchar :
a pchar that points to :
@-8 : SizeInt for reference count;
@-4 : SizeInt for size;
@: String + Terminating #0;
Pchar(Ansistring) is a valid typecast.
So AS[i] is converted to the address @AS+i-1.
}
Type
TAnsiRec = Packed Record
Ref,
Len : SizeInt;
First : Char;
end;
"
> > Often one needs the next character in a string after a starting sequence
> > of given length, null based index is more convenient here too.
>
> Just as often one needs the character position behind some arbitrary string
> at some arbitrary location - there's no advantage to any starting index
> then.
>
How many lines of string manipulating code did you write? I wrote countless.
And often I switch to the C-notation (pchar(pointer())
[index]) because of performance and convenience reasons.
> > I'll probably add a "recindex" property to the datasets.
>
> Sure - you're free to do so, for whatever reason you might imagine. ;-)
Thank you.
Martin
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Fri, 13 Apr 2012 08:10:15 +0200: > > That's nonsense. Implemented correctly, _any_ index base gives identical > > speed - you _don't_ implement it using offset calculation from the first ... > You probably should have a look into the disassembler listings of your > programs and the FPC RTL. That was not a description of the actual implementation by FPC, but one giving the "state of the art" (a very old art, indeed, as it was common knowledge half a century ago - not longer though, it seems?). > Why do you think Pascal string index is one based in the first place? > Because it is a zero based index to the old shortstring data where > [0] denotes the length byte, do you remember? I _know_ this, as I used this over and over for getting and setting the length of strings in Tubo Pascal, until around version 6 it was "deprecated" (as it's called today) and replaced by "SetLength" for setting - getting was always possible by the "Length" function. But the original justification for the indexing scheme was said to be that the actually used character data should be counted "naturally", starting at 1, and the "0th" element was simply used because then it could be implemented as a simple array. With the "shortstring" type, accessing the count by index thus always required/s a type conversion between byte and char (functions "ord" and "chr"). > [0] denotes the length byte, do you remember? An AnsiString Anistrings were presented as "opake" types, where it was _not_ meant to be possible to access the fields directly, specifically not the length value. The _order_ and arrangement of the fields was not even officially specified in the beginning. > How many lines of string manipulating code did you write? I wrote Don't know. > countless. And often I switch to the C-notation (pchar(pointer > ()) [index]) because of performance and convenience > reasons. Yes, that's exactly the opposite of my style. I prefer the "Pascal" way, as introduced by UCSD Pascal and generalized and made public by former Borland. I prefer _safe_ string handling, and it's been fast enough for my purposes everytime in the past. I also prefer _static_ strings (and other data types), because most of my programming pertains to small systems with limited resources, which often cannot handle the large overhead dynamic memory incurs. (In addition, at least the "Pascal" string handling is inherently safe in contrast to the C-style way. This means that programs using it are _not_ prone to buffer overflows or out-of-bounds accesses which are so well regarded among the writers of malware programs. Similar safeguards have only recently been added to newer C versions and variants, such as C#.) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Friday 13 April 2012 23:51:12 Sieghard wrote: > > countless. And often I switch to the C-notation (pchar(pointer > > ()) [index]) because of performance and convenience > > reasons. > > Yes, that's exactly the opposite of my style. I prefer the "Pascal" way, as > introduced by UCSD Pascal and generalized and made public by former > Borland. I prefer _safe_ string handling, and it's been fast enough for my > purposes everytime in the past. Agreed. And if Pascal string index would be zero based such C-style tricks would not be necessary. Anyway, I don't think it will happen other than Embarcadero changes it. :-) Martin -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Sat, 14 Apr 2012 10:26:08 +0200: > > former Borland. I prefer _safe_ string handling, and it's been fast > > enough for my purposes everytime in the past. > > Agreed. And if Pascal string index would be zero based such C-style > tricks would not be necessary. Anyway, I don't think it will happen other > than Embarcadero changes it. :-) _What_ exactly is it that you think requires you to use "tricks" for string handling and hinders you from using the available functionality straight away? I don't see any need for such. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
