Dynamic Arrays

[Portos]

After many small programs I made in VP, Ive tryed to reduce memory usage when working with huge arrays of ansistring/records.
I see resizable arrays like x:array of sometype; are not accepted.
Is it a workaround or sadly I must migrate all to Free Pascal ?

I see here people updating VP sources. Can my problem be solved by some update/patch ?

I think it will be usefull to keep a list with updates/mods in a separate discussion as soon as they are tested/approved by Allen.
If not enough space, I offer myself to host the files on my site if the owners send them to me by mail and instruct me what to write as their comments/howTo if necessary on the page.
I can host also entire remaked builds/betas of VP with your contribution.
I like too much VP to see it dead, so if I can't help with knowledge(I dont have much) I can help with hosting.

Please tell me how to help the comunity.
Please tell me how to improve my VP.

[Erik Nielsen]

Hej,
I do not know about dynamic arrays and the compiler. If it could be added without too much fuss it would have been added already I guess.
Fortunately pascal is so flexible so you can make your own dynamic arrays. Google is your friend and can show you what can be done. I myself have build a little framework for easy transition from Java to ObjectPascal (VP, WDSibyl and Delphi < 6). A little unusal A little unusual I admit but I had to have some Java code working on a maschine not able of running Java. And it works flawlessly.

mvh
Erik

[Marco van de Voort]

If I understood correctly, the current activity is only about repacking the last version with minor fixes, not about new development (which would be non-trivial). Development of new functionality of VP is still halted.

If you codebases are not to big, you could do dynamic memory allocation using getmem/freemem, like the way it was done in Pascal before dynamic arrays were added (D4 iirc). Dynamic array are pretty much just shorthand (and more faulttolerant) for that older way.

If you really have a large Delphi codebase with dyn arrays in them, I think you are out of luck, and FPC is your only option besides delphi.

[Portos]

Perhaps I was confuse explaining me.
Repacking last version can go to :
- basekit + documented/explained patches
- repacked kit for fresh install with increased build/beta/alpha number
I was offering me to host on same page one or both solutions, on a site I own, with high bandwidth&uptime for free, if "repackers" find it usefull.

I have a large codebase made with BP7 wich take long time to migrate to VP.
I was never used dyn. mem. alloc, pointers or dynamic arrays until now. Just static arrays.
I've seen the dynarrays in FPC&delphi. This is very close to static arrays and strings and if present or in the future included in VP I can avoid to remigrate my code to FPC.
Sincerely, I hate FPC's ide behaviour and Delphi is too advanced for me. So I prefer to work in my loved VP with my actual code + minor additions.
If someone has the knowledge, has the time and want to put dynarrays with huge number of elements in VP I think this will be more than useful.

[Allan Mertner]

I sympathise with your sentiment, but Marco is right: this is about adding small improvements and fixes that already exist. Bigger things like new compiler features are not part of this project and are unlikely to be.

I am being held back by the nice weather - when it starts raining again, I'll progress things :)

Allan

[Portos]

I get the point.
But the fixes are approved by you?
If approved, can you repack the 2.1_279 kit ?
Can you manage the fixes in a historical/updatable way to be used/downloaded ?

Or, can you let me know what's the last ones and inform me of updates ?
I promise to upload them on a high availability server so people can get them and use.
__
I am not asking for new compiler.
I want just a way to use safely huge dynamic lists of variables/records in VP, to not be forced to migrate all my sources to the ugly FPC.
Can the dynamic arrays be added to system(or other unit) in VP ? I don't know how to do it.

[Marco van de Voort]

Dynamic arrays are a language feature, and can't be implemented by libraries alone. It requires some compiler support (though maybe not as much as the next major feature due to similarities to ansistrings).

Note that it will do nothing for memory use, which is nearly the same. Are you sure you are not simply running into heap fragmentation? I don't know the function for heap manager stats under VP (getheapstatus?) but it might be worthwhile to research that, and print the stats in multiple places in your program. If the amount of memory allocated from the OS, but not in use for allocations rises, you know that this is the problem.


Btw, one of the reasons that FPC is ugly, is because a lot of people complain, but few take the time to nail down the exact problem and report it (and even less actually actively work on fixing bugs).

[Portos]

I use more memory than really needed because I use actually static arrays.
I declare 100.000 elements but at runtime the items can be 1000.
Many of my programs are array based.
Long time it worked.
Recently, the data amount to process start increasing. To avoid overflow and frequent recompilations, I increase periodically the size of the arrays, but some lists fit 90% of the arrays and other under 1%.
I like the array style, but to keep working I must go to dynamic sized, with minimal changes in my algorithms.
That' my pain. I've tried to use FPC but I must change hundreds of items to make one program work. And I have many in use.

Agree with you. I should complain to them !
FPC's IDE is far away to be like VP.
Including in the IDE the compiler, linker and debugger make it similar to BP7(from wich I migrate).
But I think they will shoot me if I tell them to integrate them in the FPC's ide. Compiler, debugger and linker are designed as separate. I think nobody want to integrate them to the ide.

[Marco van de Voort]

As long as you don't seek help on e.g. a FPC list, you'll simply never now. It might be that one of the dialect fixes solve a lot of the problems. There are not that many language differences between VP and FPC.

Well, old school pointer based dynamic arrays do indeed require to insert a lot of ^ on every array access.

Modern versions of FPC integrate compiler, debugger and (on Windows) linker into the IDE, and have so for a decade so I don't get your last bit. Did you try to start "fp.exe" ?

[Portos]

I was tring to use FPC from time to time, since v0.9 to 2.2.4(latest), of course by starting the fp.exe (the dos like IDE).
Firstly, when working with BP7, to escape from the 16bit limitations.
After few days tring to acomodate with FP, run back to BP7, dissapointed until new version of FP to give a try to this one too.
I have about 6 FP versions on CD's, before I get VP, big pause and the latest 2.2.x FP versions.

All this come&go until I get to VP.
Beautiful and fits perfectly to my BP7 habits and all other stuff (sources and IDE style of work).

Used VP many years, no need to upgrade it, because it really FIT ME PERFECTLY.
I am too obfuscated by the built-in FP IDE. Much too verbose in messages, unable to track my errors deep in sources, to run by step in multi level includes...
One modification in sub-sub-include need manual save+incremental recompile or compile all.
Compiled result is bigger, the IDE put lot of files in the working folder and lot more stuff not polished after so many years.

VP has all the modules inside the IDE. FP use a chain for compiler, linker and debugger to return results in message window.
Third party IDE's for FP(notepad's with muscles) are even more lite than the built-in IDE.
Tried to use Lazarus. Too big, verbose and slow to build my console small programs. Has same lacks as FP's IDE for debug and use. Like sending an entire army to buy 1 bread.

No. I don't need other environment/IDE. Except if it REALLY look and smell to BP7 or VP.
As I said, my only "problem" with VP is the need to use the dynamic arrays ti minimise the amount of memory wasted by supra dimensioned static arrays to load all my lists without overflow.
And this problem is about few mounths old. That's why I try to get help from the ashes of the VP comunity I was long time ignored.
I like too much VP to need other updates or FP.
If there is a way to merge VP and FP sources&libs to work with VP IDE, you have all my support and time to help.
Perhaps the father's of VP can make a very small "last" effort ?

[Marco van de Voort]

FPC - VP hybrids are extremely unlikely. The amount of work required to make something like that work is most likely magnitudes more work then fixing the relatively minor issues of the FPC IDE.

Your comments reflect the real problem of the FPC textmode IDE: Lack of users and people willing to work on it. Mostly because those people cling to either BP (in the past) or VP, and refuse to invest anything in FPC till the very last moment. Not even testing from time to time, list bugs, try minor patches etc. And at the very last moment (when BP or VP is no longer doable because of new required features or targets), it is usually too late.

Because of this, the non compiler parts of the FPC textmode IDE are virtually at the same level as in the 2000-2003 timeframe, while Lazarus in the same time grew from practically being a rough proof of concept to something that is slowly being supported by commercial Delphi component vendors.

Most TP users don't seem to realized that they have lived on borrowed time since Borland canned the line in 1996 or so. The fact that VP became freeware bought them some time, but that is also running out. Slowly, but surely.

[Portos]

In fact, you are right. Didn't noticed fp.exe was increased in size. I deleted the ppc386.exe and other exe's and still fp.exe is able to compile. I was tricked by the version of the IDE via help/about.
I subscribed to the first maillist. Browsed the archive. Ugly enough, but I hope to accomodate.
I will try to get contact with one of the IDE developpers to see if things can be moved.
But, I think I will stay on VP loong time.

[Marco van de Voort]

> I will try to get contact with one of the IDE developpers to see if things can be moved.

Well, that will not be as hard as you think :-)