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
[fpc-pascal] IntList
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. If it can't be included then I try to get it to Lazarus libraries. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TInterfacedObject memory management
On Sunday 17 October 2010 15:01:37 Paul Ishenin wrote: > Try the same but replace io type to IUnknown. Thanks Marco and Paul. I should have known this one. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TInterfacedObject memory management
Hi
I have a program that creates a TInterfacedObject and nothing else.
program project1;
{$mode objfpc}{$H+}
uses
Classes;
var
io: TInterfacedObject;
begin
io := TInterfacedObject.Create;
end.
I compile it with -gh (heap trace) and get the following output:
[DBGTGT] Heap dump by heaptrc unit
[DBGTGT] 19 memory blocks allocated : 1191/1208
[DBGTGT] 18 memory blocks freed : 1167/1184
[DBGTGT] 1 unfreed memory blocks : 24
[DBGTGT] True heap size : 393216
[DBGTGT] True free heap : 393024
[DBGTGT] Should be : 393064
[DBGTGT] Call trace for block $77FAE6C0 size 24
[DBGTGT] $004001F2 line 11 of project1.lpr
[DBGTGT] $004001B0
If I add "io.free" then there are no unfreed memory blocks.
Now, I have understood interfaced objects are reference counted and freed
automatically. Is this a bug or did I understand it wrong?
Regards,
Juha
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Sunday 03 October 2010 23:20:05 Juha Manninen (gmail) wrote: > Anyway this is a good example of a valid Lazarus patch that is ignored, > again. :-( Ok, sorry Lazarus guys, I must take this one back. The valid patch was uploaded only today so it was not really ignored. Now there are 2 valid patches to choose from. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Sunday 03 October 2010 19:48:22 C Western wrote: > >> Please report the bug. Yes the result is integer and in 64 bits, this > >> looks like a problem. > > > > I think this is an issue I reported back in March, though I can now see > > I uploaded the wrong patch for it > > Sorry - meant to add: http://bugs.freepascal.org/view.php?id=16132 I reported it already earlier as issue #17537: Debugger: added a typecast to prevent a range check error I added your issue as a duplicate. Our patches are different but both work (although mine is shorter :-) Anyway this is a good example of a valid Lazarus patch that is ignored, again. :-( Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Saturday 02 October 2010 17:47:27 José Mejuto wrote: > The assembly window in Lazarus is shown when no backtrace line is > available to point the cursor in, so open callstack "View -> Debug -> > Callstack" and you will see that there is no available backtrace, > maybe except the fpc sources without debug information (you will see > some, usually 3, function names). The backtrace is often damaged when > memory corruption happends and usually calling a non initialized > object and not nil of course (as freed objects with heaptrc are > signaled with a magic number). Right. I finally found some errors. One was a real error in my code, freeing an object twice, which happened seldom. For some reason Lazarus could not take me to its source line either. FPC output showed the place one level up in the call stack. Lazarus Debugger code causes one range error which can be fixed with a typecast. FPC showed the point clearly. Issue #0017537. TApplication.HandleException Range check error Stack trace: $0115AA93 line 1541 of ../debugger/gdbmidebugger.pp $00786075 $011678C7 line 3884 of ../debugger/gdbmidebugger.pp $00E53D13 line 1819 of ../debugger/debugger.pp ... I think this is a Lazarus specific problem but I always get RunError(216) window when there is a range error. Sometimes I get a SIGSEGV window, too, while there is only a range error. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Saturday 02 October 2010 16:45:51 Jonas Maebe wrote: > > Forgot to tell, I compiled with "-gw -gh". > > "-gw" should be as good as "-gl". > > It has nothing to do with being "as good as", they do different things > (just like "-gw" and "-gh" do different things). I have used only -gw and debugging works fine. Maybe I should use both -gl -gw. Anyway, I made a clean build wirh -gl and still had the problem. I will do some more experiments... > As long as it says "0 unfreed memory blocks : 0", there is no problem. Ok. The last 3 lines practically say Lazarus has a memory corruption or leak or something, while it does not have. It is OK not that I know it. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Saturday 02 October 2010 16:22:02 Honza wrote: > I just tried and can confirm that a LCL app running inside Lazarus > (r27491), having turned on range checks is able to perfectly catch and > show the place of an range check error (Ubuntu 10.04/AMD64). What I've > not tried, but suggest to try, is to open the Lazarus project in > Lazarus and run it as the tes app I'm talking above. Maybe then it > will show nicely also the range check error sources in Lazarus itself. I tested with your code and yes, Lazarus places the cursor to the correct line. In addition it shows the RunError and the Assembly window just like when debugging Lazarus. My Lazarus is now built using the Configure Build Lazarus Window. I will build it throught the lazarus.lpi project later and tell what happens. Hmmm... maybe Lazarus is too big for FPC and it chokes... Or maybe Lazarus is too big for itself :-) Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get to Range Check Error location
On Saturday 02 October 2010 12:21:20 Jonas Maebe wrote: > Compile with -gl, or set a breakpoint on FPC_RANGEERROR Forgot to tell, I compiled with "-gw -gh". "-gw" should be as good as "-gl". Now I tried with -gl but no luck. I get an Assembly window: http://koti.phnet.fi/juhamann/Lazarus/AssemblyRangeCheck.jpg but no source lines. For FPC_RANGEERROR, I found this in FTL system.inc: procedure fpc_rangeerror;[public,alias:'FPC_RANGEERROR']; compilerproc; begin HandleErrorFrame(201,get_frame); end; I didn't even know there is such syntax in this language. Should I build the compiler with debug info? I think I will leave it for now and debug Lazarus without -Cr. The program (Lazarus) works when built without range checks. Maybe the errors are not "real" errors and could be solved by strict types. Or, maybe the memory corruption happens so seldom that nobody notices. When testing the Delphi converter I get many such errors, maybe because the input data is unpredictable. In any case FPC should give better feedback to the user about range check errors. A RunError and an Assembly window are quite useless. Regards, Juha P.S. Because of "-gh" I am getting the following output always when closing Lazarus. Only the numbers change with Lazarus versions and compile options. Likely it is not a "real" error. Vincent Snijders suspected it is a bug in the way heaptrc does its counting in a 64-bit system. In a 32-bit system it works. Heap dump by heaptrc unit 4323916 memory blocks allocated : 939864995/951779128 4323916 memory blocks freed : 939864995/951779128 0 unfreed memory blocks : 0 True heap size : 1048576 True free heap : 1924768 Should be : 1048576 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How to get to Range Check Error location
Hi I asked this on Lazarus list but it belongs better here. So, how to get to the source line that gives a range check error? I built the whole Lazarus with -Cr and debug it. When the range error happens, it only shows a RunError or similar and doesn't show me the faulty source line. When closing Lazarus I get many notes like this: Call trace for block $7F8404FF23E0 size 55 $... hex numbers ... I tried running under gdb but it didn't give any meaningful output either. Maybe I have missed some setting? How do other people check for range error in a big project? In a smaller project it is not a problem because you can debug into the point where the error happens. I have a 64-bit Linux. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Fwd: Delphi incompatible conditionals?
On Friday 01 October 2010 19:33:48 Mark Daems wrote:
> ...
> And it's a weird behaviour, because it's all within an {$IFDEF FPC}
> construct. Why does delphi even try to interprete it?
>
> Somebody knows how to avoid the problem?
Try this instead:
{$IFNDEF FPC}
// Can be empty
{$ELSE}
...
{$ENDIF}
I got feedback for the Delphi converter in Lazarus about this same problem.
Now the converter always adds IFNDEF instead of IFDEF to the code.
Juha
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] heap size & free heap
Hi Maybe someone here knows... I built Lazarus with "-gh", started it and closed without doing anything else. --- Heap dump by heaptrc unit 717866 memory blocks allocated : 81646458/83984784 717866 memory blocks freed : 81646458/83984784 0 unfreed memory blocks : 0 True heap size : 851968 True free heap : 942784 Should be : 851968 --- What are the 3 last lines about? I am running on 64-bit Linux. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Nesting
A new Lazarus review : http://delphimax.wordpress.com/2010/09/13/freepascal-and-lazarus-success-or- failure/ has this comment about Lazarus source: --- Abundant use of the Exit() command instead of nesting code in If/then/else. It has been proven (last time in Delphi Informant Magazine) that allowing a method to nest itself out makes faster code. It is also easier to read and study. Exit should of course be used (it must be used in many situations) but prudently. --- Does nesting really create faster code? For readability I like the nesting style, except when there are very many such tests in one function. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TreeView and Nonrecursion
On Thursday 02 September 2010 00:47:23 José Mejuto wrote: > You must know at which node a new node must be inserted... If your input data contains a string which always identifies the parent node then you can map the string -> "parent node" and find it later for adding a child node. Pseudo code again: var ParentNode, Node: TNode; Map: TStringHashMap; ParentId, Id: string; ... // get data from somewhere ParentId := ... Id := ... ParentNode := Map[ParentId]; // This should make Node a root node if ParentNode = nil. Node := Tree.AddNode(ParentNode, Id); // Pseudo syntax. Map[Id] := Node; // Use as parent for following nodes. If you don't have such ID then you must use recursion. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hashmap for integers
On Sunday 22 August 2010 17:34:55 Andreas Schneider wrote: > uses fgl; > > type > TIntMap = specialize TFPGMap; //Maps Int --> Int I compared the performance of this generics map to a simple integer list. The map was much slower and it also ate huge amouts of memory, > 1.5 GB. Strange. My data is only some kilobytes, not gigabytes. The code runs in parallel threads. Could that be a problem? Anyway, I will look for some other lookup methods now... Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hashmap for integers
On Sunday 22 August 2010 18:51:21 Andreas Schneider wrote: > Afaik, inserting items into a sorted List is done via InsertSort, which is > the fastest way (O(n))to go (IMHO), so you do /not/ have to resort the > list. True. I could optimize the current implementation a little. Now I insert and then sort. However, inserting means moving lots of data which is slow, and on the other hand quicksort is very fast when data is "almost sorted" already. I would not expect any big speed-up there. > I am not really sure, how else you would implement a hash map ... > internally you always have to have some list like structure, be it an array > or a linked list. A tree wouldn't be really fast for lots of inserts, since > rebalancing a tree isn't that cheap either. > Ok, sure, you could have a huge array of buckets that are either assigned > or not, but IMHO that would waste too much memory or would have too much > overlapping items/hashes. "waste too much memory" ... No, hash arrays are always implemented as an array of buckets. The only drawback is that you must know about the size of your data in advance. Otherwise the array is too big and wastes memory or it is too small and thus slow because of overlapping items/hashes. I can tell about my experience of a string hashmap with Delphi. I had a reporting feature in my application. The huge amount of data was read from an in-memory tree-DB which is very fast and didn't slow things down. (I plan to publish the related component soon...) Due to a complex data structure there were duplicate lines in the report. It was not enough to check for duplicates in 1 record, I had to check the whole generated report line. I used TStringList for that. The report took > 20 minutes to generate... I optimized, pre-calculated things... the time dropped to 8 minutes. Not bad. I realized most time was spent checking for duplicate report lines. I figured by using a hash map I could cut that time maybe to half, to 4 minutes (!). I used the class StringHashMap which I later extracted and ported to FPC and published: http://wiki.freepascal.org/StringHashMap It seems to be a very fast implementation of a string hash map. After that the report was generated in 6 seconds (not minutes, seconds!). I was looking at the memory consumption. According to Windows resource diagram 850 MB mem was used with the old version. With the new version it was maybe 860 MB. Who cares really... Total mem was 1 GB. > Also I think "map" is the right term for what the TFPGMap does, even if it > inherits from a list. A mapping is simply a relation from some key to some > data, and thats exactly what TFPGMap does. True, the name "map" does not define the implementation. But still, most often a "map" is implemented as a hashmap. I was surprised that it is not so in this case. I felt almost like cheated in fact ... sorry :-) Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hashmap for integers
On Sunday 22 August 2010 18:45:04 Jeppe Johansen wrote: > I don't think the name map is misleading. It does exactly what a map > does. It maps a type Key to another type Value. A list maps an > integer(index) to a type Value The search is of course based on a list. > Hash tables, as far as I know, are usually only profitable when you have > a large number of insertions on keys that take a long time to compare ... take a long time to compare and to insert. Yes, I have that. Your comment about map definition is valid. "Map" doesn't define the implementation, "hashmap" would define it. > I don't think there's a generic hash table for FPC. So I'm sure many > could benefit from it if you implemented it :) > > There's a string based hash table in contnrs.pp Let's see :-) Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hashmap for integers
On Sunday 22 August 2010 17:34:55 Andreas Schneider wrote: > uses fgl; > > type > TIntMap = specialize TFPGMap; //Maps Int --> Int Thanks. I tried that. However the class name, TFPGMap, turned out to be misleading. It inherits from TFPSMap which inherits from TFPSList, which is a list, not a map, as the name says. Lists should be named as "List", not as "Map". I already have a self-made TIntList. It has Quicksort and Find functions and it is as fast as can be. I made it years ago because I didn't find any proper alternative. (Java people don't need to do such things...) Is it really so there is no generics HashMap container in fgl, or in other FPC libraries? Someone should make it! And, the name "Map" should really be reserved for hash maps and not used for lists (= kind of poor man's map). My prog has a big amount of integers, thats why an integer list is not enough. A binary search from a sorted list is pretty fast but the problem is that I am adding items to the list and it must be sorted after every addition. My experience from string hashmaps says that the speed difference can be huge, compared to any list implementation. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Hashmap for integers
Hi Is there an implementation of a hash map where the keys are integers. It is needed when the integers are too big for a lookup array. I only need check the existence of keys so the data type is not important. About like this: var Len: integer; SeenLen: TIntMap; // or whatever the type is called ... if not SeenLen.Has(Len) then begin ... work with Len ... SeenLen[Len] := nil; // If the data type is pointer end; A related question: What is the state of the generic containers now? I want to use FPC 2.4.x features for this program and I will not experiment with new development code now, but some time later I will. Do the generic containers work equally well with primitive types like integer, pointer and string, and then with TObject derivatives? I would guess the primitive types are a challenge. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OFF TOPIC - how I can migrate of Delphi to FPC
On Saturday 14 August 2010 20:04:33 Marcos Douglas wrote: > 3- Do exists something I can do with Delphi but not do with FPC? > Especialy on Windows. ... > 7- Is there any other factors we should consider before making this > migration, which was not written above? 1. Are you targeting for Windows-only or multi-platform? If it is Windows-only then you can use Windows specific features, otherwise not. 2. Are you using VCL with Delphi? If yes, then you must use Lazarus + LCL, not only FPC. And then the discussion should actually go to Lazarus list instead of FPC list. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
