[fpc-pascal] Locate method in TBuFDataset
Hi all, Does anyone know if TBuFDataset.Locate honours the TLocateOptions parameter passed to it ? It certainly doesn't *seem* to work. I am actually using a TSQLQuery against an SQLite3 database, Laz 0.9.28.2, fpc 2.2.4, Win32. I should say that I am probably well out of my depth looking at this stuff, but as far as I can see, TSQLQuery does not override locate, and looking at the code in TBufDataset I can't see anywhere that the options are passed to anything. TDBCompareRec has a field for the options, but I can't see that it is set. If they were set in that structure, DBCompareText seems to honour loCaseInsensitive, but takes no notice of loPartialKey. cheers, John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can variables be declared within a block?
On 19 October 2010 15:06, Rob Kennedy > wrote: > On Tue, Oct 19, 2010 at 12:23 AM, Jürgen Hestermann < > juergen.hesterm...@gmx.de> wrote: > >> Reimar Grabowski schrieb: >> >> for (int i = 0;...) >>> Can't see anything wrong. I use declaration of variables inside blocks >>> quite often in Java and C++ but have never missed it in pascal. Please >>> enlighten me. What is so bad about creating temporary variables inside >>> blocks instead of the beginning of a function in a language that supports >>> it? >>> >> your example is at the start of a "for loop" block, which is much the same as having it at the start of a procedure block pascal prevents people from putting declarations strewn throughout the block, which i found reduces mistakes & bugs from 20-30 people coding, and their code is more readable. Coding standards are do similar thing. which of the three languages do you find fastest to code in, including any debugging time? > >> I never thought about doing such declarations in Pascal. >> Although I would not be against it in general (provided >> that all identifiers have to be different) > > > That seems like an arbitrary restriction, given that Object Pascal > *already* allows multiple variables to have the same name *and* be declared > somewhere other than the top of the function. Think of exception handlers. I > don't know about everyone else, but my exception variables are all always > named e. > are you sure? i've tried making var's in WITh and Try Except blocks using Delphi7 with no luck. Or is this a difference between object pascal & delphi? > > I could understand disallowing variables from *shadowing* other local > variables of the same name (it's legal in C, but better compilers warn about > it), but I see no reason for the language to require variables from > different local scopes to have unique names. Write that into your local > coding guidelines and enforce it in code reviews, not the language spec. > > i'd agree with that, local vars are local after all. perhaps make it a compiler option. - V ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What are the issues involved in threads sharing variables?
> Polling where the list size is highly dynamic you will need protect > it. I think FPC has thread safe list objects too. Yes it does, Classes.TThreadList I think. I thought it was a conatiner for threads, but it is a safe list. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Can variables be declared within a block?
On Tue, 19 Oct 2010 02:07:25 +0200, Dimitri Smits wrote: on the other hand, what stops the OP from using 'with'? (multiple levels/variables?) "with" contaminates the name space. Locally scoped variables don't. and you won't die from using another stack variable scoped at the beginning of the method. True. If the subroutine is long enough that an additional declaration block seems necessary, it's probably too long already. just to say that I'm not too fond of that c-ism in a pascal language (although I've used it plenty in c++, java, C#, php, ... over the years). Just because C has it doesn't mean it is a C-ism. Local declaration blocks are definitely not an invention of C. IIRC, C89/90 didn't even had it yet. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntList
Take a look at http://code.google.com/p/fprb/. I have just perused it, but it looks pretty good. Brian. > > Currently, the FPC team is looking at an implementation of Vlado Boza > for a standard template library for inclusion in FPC. > > The code is on > > http://code.google.com/p/stlpascal > > Please have a look and comment on it. > > I'm not a generics expert and am not in the position to judge whether this > library is good or not. > > Michael. > ___ > fpc-pascal maillist - fpc-pas...@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] IntList
On Tue, 19 Oct 2010, Sven Barth wrote: Am 19.10.2010 19:54, schrieb Juha Manninen (gmail): On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote: Yes it's ready in fpc 240: uses Fgl; type TIntegerList = specialize TFPGList; Well, yes. It is almost as good as a dedicated class. It has a Sort method but you must feed the compare function for it. It does not have a Find method for a binary search in a sorted list. Indexof does a linear search. Anyway, it could be used as a base class in Lazarus. I don't know what is the Lazarus team's policy for using generics in Lazarus code-base. In FPC 2.4.0 I had problems with memory consumption of generics containers. A map hogged gigabytes of memory while my data took only kilobytes (less than 1 MB for sure), on a 64 bit Linux. Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added 10 integers to both a List and to a Map and didn't even notice the memory increase in resource monitor. TIntegerList = specialize TFPGList; TIntegerMap = specialize TFPGMap; TFPGMap's problem still is that it is not a hash map and is butt-slow with lots of data. A hash map is a superior container type, it really should be changed. Besides, people expect to get a hash map when they see "map" in the class name. Now they get a list which is deceivingly named as "map". As you seem to have experience with efficient data structures, what about creating such a generic hash map? :) (but don't use 2.4.2rc1 and current/unpatched 2.4.3 as a test base as those don't have the fixes from trunk to make "specialize" working again) Currently, the FPC team is looking at an implementation of Vlado Boza for a standard template library for inclusion in FPC. The code is on http://code.google.com/p/stlpascal Please have a look and comment on it. I'm not a generics expert and am not in the position to judge whether this library is good or not. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntList
Am 19.10.2010 19:54, schrieb Juha Manninen (gmail): On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote: Yes it's ready in fpc 240: uses Fgl; type TIntegerList = specialize TFPGList; Well, yes. It is almost as good as a dedicated class. It has a Sort method but you must feed the compare function for it. It does not have a Find method for a binary search in a sorted list. Indexof does a linear search. Anyway, it could be used as a base class in Lazarus. I don't know what is the Lazarus team's policy for using generics in Lazarus code-base. In FPC 2.4.0 I had problems with memory consumption of generics containers. A map hogged gigabytes of memory while my data took only kilobytes (less than 1 MB for sure), on a 64 bit Linux. Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added 10 integers to both a List and to a Map and didn't even notice the memory increase in resource monitor. TIntegerList = specialize TFPGList; TIntegerMap = specialize TFPGMap; TFPGMap's problem still is that it is not a hash map and is butt-slow with lots of data. A hash map is a superior container type, it really should be changed. Besides, people expect to get a hash map when they see "map" in the class name. Now they get a list which is deceivingly named as "map". As you seem to have experience with efficient data structures, what about creating such a generic hash map? :) (but don't use 2.4.2rc1 and current/unpatched 2.4.3 as a test base as those don't have the fixes from trunk to make "specialize" working again) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntList
On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote: > Yes it's ready in fpc 240: > > uses > Fgl; > > type > TIntegerList = specialize TFPGList ; Well, yes. It is almost as good as a dedicated class. It has a Sort method but you must feed the compare function for it. It does not have a Find method for a binary search in a sorted list. Indexof does a linear search. Anyway, it could be used as a base class in Lazarus. I don't know what is the Lazarus team's policy for using generics in Lazarus code-base. In FPC 2.4.0 I had problems with memory consumption of generics containers. A map hogged gigabytes of memory while my data took only kilobytes (less than 1 MB for sure), on a 64 bit Linux. Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added 10 integers to both a List and to a Map and didn't even notice the memory increase in resource monitor. TIntegerList = specialize TFPGList ; TIntegerMap = specialize TFPGMap ; TFPGMap's problem still is that it is not a hash map and is butt-slow with lots of data. A hash map is a superior container type, it really should be changed. Besides, people expect to get a hash map when they see "map" in the class name. Now they get a list which is deceivingly named as "map". Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IntList
Juha Manninen (gmail) escreveu: Hi In Lazarus project jcf2 component has an IntList class which is poorly implemented. It depends on integer and pointer being the same size. I will later suggest to replace it. I have a better IntList. See: http://github.com/JuhaManninen/Pascal/blob/master/IntList/intlist.pas It is similar to TStringList except that it works with integers. It is well tested. Question: can this class be added to FCL? Clearly such class is needed sometimes and people must make their own versions of it. Generics can solve it in the future but it is not ready yet. Yes it's ready in fpc 240: uses Fgl; type TIntegerList = specialize TFPGList ; Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can variables be declared within a block?
On Tue, Oct 19, 2010 at 12:23 AM, Jürgen Hestermann < juergen.hesterm...@gmx.de> wrote: > Reimar Grabowski schrieb: > > for (int i = 0;...) >> Can't see anything wrong. I use declaration of variables inside blocks >> quite often in Java and C++ but have never missed it in pascal. Please >> enlighten me. What is so bad about creating temporary variables inside >> blocks instead of the beginning of a function in a language that supports >> it? >> > > I never thought about doing such declarations in Pascal. > Although I would not be against it in general (provided > that all identifiers have to be different) That seems like an arbitrary restriction, given that Object Pascal *already* allows multiple variables to have the same name *and* be declared somewhere other than the top of the function. Think of exception handlers. I don't know about everyone else, but my exception variables are all always named e. I could understand disallowing variables from *shadowing* other local variables of the same name (it's legal in C, but better compilers warn about it), but I see no reason for the language to require variables from different local scopes to have unique names. Write that into your local coding guidelines and enforce it in code reviews, not the language spec. > I see one (small) disadvantage: > > If you want to know the number of bytes pushed to the stack > (i.e. in a recursive function) then you don't have the declarations > at one place anymore but they are spread over the code which would make it > hard to get an overview. Definitely small. It's already hard to do since you don't know how much stack the compiler will allocate for temporary variables. (If the function's small enough that you *can* predict the compiler's temporary usage, then it's probably also small enough that you can count all the variable declarations no matter where they appear.) -- Rob ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] non visual timer win32
Op 2010-10-19 10:17, Felipe Monteiro de Carvalho het geskryf: > MyTimer := TTimer.Create(Application); > MyTimer.OnTimer := myHandler; > or even MyTimer := TTimer.Create(nil); MyTimer.OnTimer := myHandler; ...later when application terminates... MyTimer.Free; Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReadStr/WriteStr vs Val/Str
On 19 Oct 2010, at 01:56, Richard Ward wrote: > As a user of the old Macintosh Pascal (later THINK Pascal), both ReadStr and > WriteStr functions were included and I used them quite a bit. The names > were different but the FPC implementation is basically the same as far as I > can tell. > > Besides backward compatibility, portability issues and personal preference, > is there any functionality Val and Str may have that ReadStr and WriteStr > don't? I can't see any, but wanted to make sure there there were no subtle > technical issue(s) I might need to consider. readstr gives a run time error when you try to read an invalid number, while val() returns an error in the last parameter. Other than that, they all use the same helper routines to perform the actual conversions. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] non visual timer win32
MyTimer := TTimer.Create(Application); MyTimer.OnTimer := myHandler; -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for High Performance Computing (HPC) Components with Application API
Andrew Brunner wrote: Ok. You mentioned NPTL. What can you tell me about that? Is that the project that makes pthreads? I'm looking to get the latest and greatest source of posix threads so I draw upon that code and perhaps even come up with a native version for FPC. Any help would be greatly appreciated. I wonder if I could possibly make a suggestion here. NPTL is fairly well established in the Linux kernel- it's been a bit of a long haul, with some architectures getting it much later than others. However a lot of unix programmers are still very unfamiliar with the concept of threads, and "diluting the brand" with a competing implementation isn't going to help matters. If you want to do something which is implemented inside FPC then don't mess with threads. Instead get an efficient coroutine implementation working, and then build whatever else you want on top of that- but call it something like Preemptive Coroutines :-) -- 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] Can variables be declared within a block?
Am 18.10.2010 20:21, schrieb Vannus: On 18 October 2010 15:33, Sven Barth mailto:pascaldra...@googlemail.com>> wrote: Am 18.10.2010 16:20, schrieb Michael Van Canneyt: Object Pascal is a simple, beautiful and easy to read language. The FPC team tries to keep it that way. And that is why I like the FPC team so much. :D agreed. When I went from C++ to Pascal back in 98/99, I found it quite hard initially. Not being able to put variables anywhere & everywhere was really awkward, but it dawned on me that I shouold be coding better. Since then, i would say "If you need vars throughout your code, then something is wrong with your code" Makes you wonder why the ReactOS devs always declare their variables at the beginning of the functions (they're using C). :P Take a look at the source files of ntoskrnl for example. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal