Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Ok, I'll bite.. ;-) I spoke to Dean the other day and he mentioned a new update for FPCUnit will be sumbitted shortly. I didn't want to start on the new XSLT stylesheet before I know what format the XML is in. Dean, if you can confirm that the new xml format with nested test suits are still as is, then I'll go ahead and modify the XSLT file. Regards, - Graeme - On 2/3/07, Vincent Snijders <[EMAIL PROTECTED]> wrote: Hi, Dean Zobec created a new xmlreportwriter for fpcunit. Among others it supports nested test suites. Does anybody have a stylesheet for showing such a report. Maybe somebody is willing to create one. Examples of the old xml format+ style sheet (slightly modified): http://www.hu.freepascal.org/lazarus/testresults/monitor.xml Example of the new xml format: http://www.hu.freepascal.org/lazarus/testresults/results.xml Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Graeme, I spoke to Dean the other day and he mentioned a new update for FPCUnit will be sumbitted shortly. I didn't want to start on the new XSLT stylesheet before I know what format the XML is in. Dean, if you can confirm that the new xml format with nested test suits are still as is, then I'll go ahead and modify the XSLT file. Vincent produced the new results.xml example with the new report writer: http://www.hu.freepascal.org/lazarus/testresults/results.xml (he already added the missing xsl tag ) The new writer is this: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/fcl/fpcunit/xmltestreport.pp?rev=6311&view=markup There's a new structure for the fpcunit reports, descending from TCustomResultsWriter. There are two other report writers for text and latex output (you can find an example of the two other output formats in fpcunit/example_output directory, the pdf is produced using pdflatex from the latex output). Note that we moved the essential fpcunit units to fcl/inc, the reports and other utils remain in the fpcunit directory. Ciao, Dean Regards, - Graeme - On 2/3/07, Vincent Snijders <[EMAIL PROTECTED]> wrote: > Hi, > > Dean Zobec created a new xmlreportwriter for fpcunit. Among others it > supports nested test suites. Does anybody have a stylesheet for showing > such a report. Maybe somebody is willing to create one. > > Examples of the old xml format+ style sheet (slightly modified): > http://www.hu.freepascal.org/lazarus/testresults/monitor.xml > > Example of the new xml format: > http://www.hu.freepascal.org/lazarus/testresults/results.xml > > Vincent > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ 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] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
On Fri, 2 Feb 2007, Marco van de Voort wrote: > > Can anyone recommend a method to search a whole drive, of arbitrary > > size, without running out of memory. > > I don't know seen SysTools, but I worked analysing logfiles for a year. All > containertypes (TList TObjectList and TstringList included) that have a > single array as internal datastructure become prone to fragmentation or > slowdowns when the number of elements get bigger. If you approximately know the number of elements in advance, you can reduce the fragmentation to nearly zero if you set the capacity of the list before filling it. It will also speed up the loading of the list. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
> On Fri, 2 Feb 2007, Marco van de Voort wrote: > > > > Can anyone recommend a method to search a whole drive, of arbitrary > > > size, without running out of memory. > > > > I don't know seen SysTools, but I worked analysing logfiles for a year. All > > containertypes (TList TObjectList and TstringList included) that have a > > single array as internal datastructure become prone to fragmentation or > > slowdowns when the number of elements get bigger. > > If you approximately know the number of elements in advance, you can > reduce the fragmentation to nearly zero if you set the capacity of the > list before filling it. The reallocations at the end hurt the most. So if you guess slightly too low it still fails. > It will also speed up the loading of the list. (not if it is sorted). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
On Sat, 3 Feb 2007, Marco van de Voort wrote: > > On Fri, 2 Feb 2007, Marco van de Voort wrote: > > > > > > Can anyone recommend a method to search a whole drive, of arbitrary > > > > size, without running out of memory. > > > > > > I don't know seen SysTools, but I worked analysing logfiles for a year. > > > All > > > containertypes (TList TObjectList and TstringList included) that have a > > > single array as internal datastructure become prone to fragmentation or > > > slowdowns when the number of elements get bigger. > > > > If you approximately know the number of elements in advance, you can > > reduce the fragmentation to nearly zero if you set the capacity of the > > list before filling it. > > The reallocations at the end hurt the most. So if you guess slightly too low > it > still fails. Obviously, but it'll hurt less, since it grows with 25%; At most you'll get maybe 1 reallocation, which is acceptable. > > > It will also speed up the loading of the list. > > (not if it is sorted). Yes it will, because the reallocations don't happen as often. The sorting introduces an overhead anyway, whether you set capacity or not. The correct procedure IMHO is - Set capacity - Load - Sort I tested such things with an N^3 algorithm for my daytime job, and the difference is very noticeable. All this doesn't exclude that a specialized class may be more suitable for the job. I just want to illustrate that, if programmed correctly, TList, TStringList and friends can still get you a long way... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
Am Freitag, den 02.02.2007, 08:52 -0800 schrieb Cox, Stuart TRAN:EX: > I am trying to EnumerateFiles (create a list of all files that match a > given filespec) across and down a whole drive. I've directly used the > EnumerateFiles code from TurboPower's SysTools as available on > SourceForge. > > The code works just as TurboPower designed and it and my wrapper code > runs find on some drives but fails miserably on the very one that I > would like to use the code on. As the EnumerateFiles code attempts to > append one more filename to the Tstrings, it throws an exception and > dies from lack of memory. The trouble is not in the memory used by the > Tstrings to hold the list of found files but, rather, in the way that > memory fragmentation occurs during the FindFirst(), FindNext() and > FindClose() calls. This can be verified by eliminating the storage of > anything in the Tstrings list at all. The routine will still die and in > the same place and at the same filename. > > The error is not from a lack of stack space, either. The error is > EOutOfMemory that indicates a less easily solved problem. > > Can anyone recommend a method to search a whole drive, of arbitrary > size, without running out of memory. >From reading this thread I think you must have another problem, likely in TurboPowers or your own implementation. I've been doing the same (listing deep file systems) and never had any problems with memory. My classes are made mainly for indexing storage and backup media (CD, DVD, ...) and I've tested it five minutes ago on an amount of: $ wc -l storage.txt 152811 storage.txt lines naming a file or directory each. The list class in use is a derivation of "TFPList" (think it's from "classes") with an new sorting routine (qsort) attached. I had some problems with the "FindXxxx"-implementation on *nix-like OS, but that dealt with symlinks. Happy bug hunting and memory profiling, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
> Yes it will, because the reallocations don't happen as often. > The sorting introduces an overhead anyway, whether you set capacity or not. Yes, but I was talking about slowness in general, not just from the heap. And TStringList with those huge internal list has to move on avg half of the array. If TStringList had an extra indirection (array of ptr to blk of ptrs) it would be less so. > The correct procedure IMHO is > - Set capacity > - Load > - Sort > I tested such things with an N^3 algorithm for my daytime job, and the > difference is very noticeable. With a single array or a multilevel one? > All this doesn't exclude that a specialized class may be more suitable for > the job. To be honest, the only good point of TStringList seems to be that it is default available on all Object Pascal. The specialised stuff (splitting strings) is also plagued with oddities. (most notably the fact that characters under space are always used as separator) > I just want to illustrate that, if programmed correctly, TList, > TStringList and friends can still get you a long way... I think that the lengths to which people will go to stick to them paints what is needed to make a serious effort to make them legacy. There should be a set of container classes in a separate unit (a unit not existing in Delphi most notably) that is Open Source and works on Delphi too. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
Am Samstag, den 03.02.2007, 16:36 +0100 schrieb Marc Santhoff: > Am Freitag, den 02.02.2007, 08:52 -0800 schrieb Cox, Stuart TRAN:EX: ... > > Can anyone recommend a method to search a whole drive, of arbitrary > > size, without running out of memory. > > >From reading this thread I think you must have another problem, likely > in TurboPowers or your own implementation. > > I've been doing the same (listing deep file systems) and never had any > problems with memory. My classes are made mainly for indexing storage > and backup media (CD, DVD, ...) and I've tested it five minutes ago on > an amount of: > > $ wc -l storage.txt > 152811 storage.txt > > lines naming a file or directory each. The list class in use is a > derivation of "TFPList" (think it's from "classes") with an new sorting > routine (qsort) attached. > > I had some problems with the "FindXxxx"-implementation on *nix-like OS, > but that dealt with symlinks. Since you asked for a method, not the class type to use, I had a deeper look at it: My implementation does not stick anything into one list but uses a tree of nested lists, one TFPList derivate for each directory at each level. For every single file handled there is an item-class object holding file info (name, size, ...) put into the directory (container-)list. Works nice and fast ... only the recursion scheme seems to be somewhat more complex. HTH, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
On Sat, 3 Feb 2007, Marco van de Voort wrote: > > Yes it will, because the reallocations don't happen as often. > > The sorting introduces an overhead anyway, whether you set capacity or not. > > Yes, but I was talking about slowness in general, not just from the heap. > > And TStringList with those huge internal list has to move on avg half of the > array. If TStringList had an extra indirection (array of ptr to blk of ptrs) > it would be less so. Eh ? What happens if you do a Insert(0,'SomeString') ? Don't you need to move across all blocks ? Or will you just grow the first block ? Anyway, it could be a nice idea to implement as TLargeStringList. > > > The correct procedure IMHO is > > - Set capacity > > - Load > > - Sort > > > I tested such things with an N^3 algorithm for my daytime job, and the > > difference is very noticeable. > > With a single array or a multilevel one? Multilevel. > > > All this doesn't exclude that a specialized class may be more suitable for > > the job. > > To be honest, the only good point of TStringList seems to be that it is > default available on all Object Pascal. The specialised stuff (splitting > strings) is also plagued with oddities. (most notably the fact that > characters under space are always used as separator) Why do you call this oddities ? For GUI programming (and that's what it was implemented for) it makes perfect sense. > > > I just want to illustrate that, if programmed correctly, TList, > > TStringList and friends can still get you a long way... > > I think that the lengths to which people will go to stick to them paints > what is needed to make a serious effort to make them legacy. I fail to see why, but no doubt you have your reasons. I'd like to see a complete list of 'issues' with TStrings (not TStringList, that's just a specific implementation). Maybe we can then create a TFPStrings which would be interface compatible, (in the sense that it can replace TStrings without source changes. It can have internal differences, like the space handling) but with a more sensible behaviour ? I mean, I know since some time you don't particularly like tstrings and tlist and whatnot (although I don't fully know why), but, by all means: let's then do an effort and design something better. Starting with a list of issues seems like a good beginning. > > There should be a set of container classes in a separate unit (a unit not > existing in Delphi most notably) that is Open Source and works on Delphi > too. Like Decal was set up to be ? I'm all for starting such a thing. I would be the first one to use such a beast if it was better. It was the prime reason for implementing TFPlist. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Graeme, Ok, I'll bite.. ;-) I spoke to Dean the other day and he mentioned a new update for FPCUnit will be sumbitted shortly. I didn't want to start on the new XSLT stylesheet before I know what format the XML is in. Dean, if you can confirm that the new xml format with nested test suits are still as is, then I'll go ahead and modify the XSLT file. I think a treeview layout is a way to go. Googling around I've found a link to a nice article, hope it's of any help: http://rollerjm.free.fr/pro/Treeview/Treeview.html Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
> On Sat, 3 Feb 2007, Marco van de Voort wrote: > > > > Yes it will, because the reallocations don't happen as often. > > > The sorting introduces an overhead anyway, whether you set capacity or > > > not. > > > > Yes, but I was talking about slowness in general, not just from the heap. > > > > And TStringList with those huge internal list has to move on avg half of the > > array. If TStringList had an extra indirection (array of ptr to blk of ptrs) > > it would be less so. > > Eh ? What happens if you do a Insert(0,'SomeString') ? Don't you need to move > across all blocks ? Or will you just grow the first block ? Assume 1M elements. Then the tstringlist case is 1M*sizeof(pointer) bytes. Inserting a new node on avg moves (1M*sizeof(pointer))/2 bytes. Overhead of index is only heapmgr overhead for the big block. Assume and (max) 1k elements per block. Means we have an array of 1000 pointers, each to a block of 1000 ptrs. Inserting means a binsearch in the first array to locate the block, and then there are two cases: 1 there is slack in the block: insert into the block, on avg (1000*sizeof(pointer)/2) bytes are moved. 2 the block is full, you have to insert a new block in the toplevel index, ( avg 1000*sizeof(pointer)/2) and then redivide the block between the two (again about 1000*sizeof(pointer)/2 roughly. If you do the splitting smart, 1 is way more common than 2. So that is 1k*sizeof(pointer)/2 vs 1M*sizeof(pointer)/2. > Anyway, it could be a nice idea to implement as TLargeStringList. Yes, but I'd get rid of the string splitting stuff etc. IMHO they don't belong in the same class. > > > The correct procedure IMHO is > > > - Set capacity > > > - Load > > > - Sort > > > > > I tested such things with an N^3 algorithm for my daytime job, and the > > > difference is very noticeable. > > > > With a single array or a multilevel one? > > Multilevel. Then it is not really tstringlist. Or do you mean tstringlists as major index with tstringlists under each node? That is IMHO already a custom class. > > > All this doesn't exclude that a specialized class may be more suitable for > > > the job. > > > > To be honest, the only good point of TStringList seems to be that it is > > default available on all Object Pascal. The specialised stuff (splitting > > strings) is also plagued with oddities. (most notably the fact that > > characters under space are always used as separator) > > Why do you call this oddities ? For GUI programming (and that's what it was > implemented for) it makes perfect sense. The problem is that it is used for way more. It is container type, splitter, GUI data backstore etc. One can argue about how it is was meant originally, but this is the practice now. And a lot of code scales bad because of it. > > > I just want to illustrate that, if programmed correctly, TList, > > > TStringList and friends can still get you a long way... > > > > I think that the lengths to which people will go to stick to them paints > > what is needed to make a serious effort to make them legacy. > > I fail to see why, but no doubt you have your reasons. I'd like to see a > complete > list of 'issues' with TStrings (not TStringList, that's just a specific > implementation). I think we would have to agree first on the target of TStrings and -list. But the main reason is simply bad scaling. I want to be able to use a container type, and not first wrap it, or risk scaling issues later. A language/RTL should provide such type, and not position a type originally meant for GUI bindings with internal limits as basetype for datastructures. Not lots of new machines have memories that easily allow such large datastructures. The end conclusion can also be we need to promote e.g. contnrs types more. My remark here was more the backwards delphi compat (e.g. FPC extensions should not be in contnrs, but in a different unit that also compiles on Delphi) > Maybe we can then create a TFPStrings which would be interface compatible, > (in the sense that it can replace TStrings without source changes. It can > have internal differences, like the space handling) but with a more sensible > behaviour ? IMHO - linesplitting and container function should be separated. - GUI and non GUI interfacing (data structures) should be separated. - There should be default containers that are not vectors (there are some in contnrs). IOW more java style iterators. > > There should be a set of container classes in a separate unit (a unit not > > existing in Delphi most notably) that is Open Source and works on Delphi > > too. > > Like Decal was set up to be ? More or less yes, with one big problem here. Decal abused interfaces and variants as a way around missing generics, causing larger performance problems than it solved. However generics support in FPC won't solve it either, since then TStringList and TList will still be the lowest common denomitor. And a lot of programmers need to keep Delphi
Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Graeme Geldenhuys schreef: Ok, I'll bite.. ;-) Thanks. It is nice to find a volunteer. :-) Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
Michael Van Canneyt wrote: All this doesn't exclude that a specialized class may be more suitable for the job. To be honest, the only good point of TStringList seems to be that it is default available on all Object Pascal. The specialised stuff (splitting strings) is also plagued with oddities. (most notably the fact that characters under space are always used as separator) Why do you call this oddities ? For GUI programming (and that's what it was implemented for) it makes perfect sense. Early i think that the space issue in DelimitedText was only something with very few usages. Later i found that is useless. Take the following scenario: you want to load a csv into a TStrings. In TStrings to add a string with space is necessary to enclose it with quotes For example: if you want that the csv string ';bb bb;' becomes a TStrings with 3 items (, bb bb and ), is necessary to transform ';bb bb;' into ';"bb bb";' But to do this in a generic way, without knowing if determined value has space than you have to parse each item of the csv, check if has space and then quote. But in this case is better to add the string directly through add method. I just want to illustrate that, if programmed correctly, TList, TStringList and friends can still get you a long way... I think that the lengths to which people will go to stick to them paints what is needed to make a serious effort to make them legacy. I fail to see why, but no doubt you have your reasons. I'd like to see a complete list of 'issues' with TStrings (not TStringList, that's just a specific implementation). Maybe we can then create a TFPStrings which would be interface compatible, (in the sense that it can replace TStrings without source changes. It can have internal differences, like the space handling) but with a more sensible behaviour ? Good idea, i think the same. My issue suggestion is fix the DelimitedText handling space. See above. I have a small function that parses csv strings and add to a TStrings but uses strutils.posex. In terms of flexibility, and to comtemple those that want to quote a string with space (or whatever) an event can be added to be called at each added string though delimitedtext. but since we are talking about efficiency i dont think a good idea. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
On Sat, 3 Feb 2007, Marco van de Voort wrote: > > On Sat, 3 Feb 2007, Marco van de Voort wrote: > > > > > > Yes it will, because the reallocations don't happen as often. > > > > The sorting introduces an overhead anyway, whether you set capacity or > > > > not. > > > > > > Yes, but I was talking about slowness in general, not just from the heap. > > > > > > And TStringList with those huge internal list has to move on avg half of > > > the > > > array. If TStringList had an extra indirection (array of ptr to blk of > > > ptrs) > > > it would be less so. > > > > Eh ? What happens if you do a Insert(0,'SomeString') ? Don't you need to > > move > > across all blocks ? Or will you just grow the first block ? > > Assume 1M elements. > > > Then the tstringlist case is 1M*sizeof(pointer) bytes. Inserting a new node > on avg moves > (1M*sizeof(pointer))/2 bytes. Overhead of index is only heapmgr overhead for > the big > block. > > Assume and (max) 1k elements per block. Means we have an array of 1000 > pointers, each to a block of 1000 ptrs. Inserting means a binsearch in the > first array to locate the block, and then there are two cases: > > 1 there is slack in the block: insert into the block, on avg > (1000*sizeof(pointer)/2) bytes are moved. > 2 the block is full, you have to insert a new block in the toplevel index, >( avg 1000*sizeof(pointer)/2) and then redivide the block between the two > (again about 1000*sizeof(pointer)/2 roughly. > > If you do the splitting smart, 1 is way more common than 2. > > So that is 1k*sizeof(pointer)/2 vs 1M*sizeof(pointer)/2. It's what I thought, yes. > > > Anyway, it could be a nice idea to implement as TLargeStringList. > > Yes, but I'd get rid of the string splitting stuff etc. IMHO they don't > belong in the same class. Why, they make coding much easier ? I found myself having 10-20 custom functions, all accepting a TStrings + some args. The coding is easier if it's just a method of TStrings. But there is a way around that; Encapsulation. > > > > The correct procedure IMHO is > > > > - Set capacity > > > > - Load > > > > - Sort > > > > > > > I tested such things with an N^3 algorithm for my daytime job, and the > > > > difference is very noticeable. > > > > > > With a single array or a multilevel one? > > > > Multilevel. > > Then it is not really tstringlist. Or do you mean tstringlists as major > index with tstringlists under each node? That is IMHO already a custom > class. I don't consider that a custom class, I didn't have to declare extra classes for it :-) > > > > > All this doesn't exclude that a specialized class may be more suitable > > > > for > > > > the job. > > > > > > To be honest, the only good point of TStringList seems to be that it is > > > default available on all Object Pascal. The specialised stuff (splitting > > > strings) is also plagued with oddities. (most notably the fact that > > > characters under space are always used as separator) > > > > Why do you call this oddities ? For GUI programming (and that's what it was > > implemented for) it makes perfect sense. > > The problem is that it is used for way more. It is container type, splitter, > GUI data backstore etc. One can argue about how it is was meant originally, > but this is the practice now. And a lot of code scales bad because of it. Ok, that means we just have to separate out the container type. > > > > > I just want to illustrate that, if programmed correctly, TList, > > > > TStringList and friends can still get you a long way... > > > > > > I think that the lengths to which people will go to stick to them paints > > > what is needed to make a serious effort to make them legacy. > > > > I fail to see why, but no doubt you have your reasons. I'd like to see a > > complete > > list of 'issues' with TStrings (not TStringList, that's just a specific > > implementation). > > I think we would have to agree first on the target of TStrings and -list. > But the main reason is simply bad scaling. I want to be able to use a > container type, and not first wrap it, or risk scaling issues later. > > A language/RTL should provide such type, and not position a type originally > meant for GUI bindings with internal limits as basetype for datastructures. > > Not lots of new machines have memories that easily allow such large > datastructures. > > The end conclusion can also be we need to promote e.g. contnrs types more. My > remark here was more the backwards delphi compat (e.g. FPC extensions should > not be in contnrs, but in a different unit that also compiles on Delphi) I understand. > > > Maybe we can then create a TFPStrings which would be interface compatible, > > (in the sense that it can replace TStrings without source changes. It can > > have internal differences, like the space handling) but with a more > > sensible > > behaviour ? > > IMHO > - linesplitting and container function should be separated. You can do that
[fpc-pascal] Question on how to avoid memory trouble
>The error is not from a lack of stack space, either. The error is >EOutOfMemory that indicates a less easily solved problem. >Can anyone recommend a method to search a whole drive, of arbitrary >size, without running out of memory. >Stu Cox This is exactly the kind of thing my string class works great with. It's a dynamic double linked list - and the way its set up - there are three versions - the simple tracks just pointers, the next has name, value and Description ansistrings and I make pretty huge lists with it, and it has Append, insert, findfirst, findnext, etc. I have an unofficial release on www.jegas.org and you need to use the compile switch that allows += construct. Fpc -Sc yourprogram.pas Worth a shot. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
