Virtual Pascal

Classic Object Pascal for free

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.

Views: 486

Reply to This

Replies to This Discussion

If I has the knowledge to alter the VP or FPC code, my problem was solved without the need to post asking help.
I am a simple user, small programmerm many years satisfied by BP7, fully satisfied by VP. My knowledges cover <1/4 of the basic functions VP is able. Basically I don't use much functions. Never created classes or objects.
Text data handle, mostly arrays and records.
Do you think I can port FPC sources to VP ? If so, the dynamic arrays was solved first.
I come to the latest active guru's of the VP, thinking they maybe already solved it. Hoping they can solve it, because I don't know how.

I don't say I don't want. I DON'T KNOW HOW !
If the project is started from your part, I can find a way to contribute, increasing my knowledges, being guided by someone with knowledge, knowing what to ask and do.
If you start moving a piece of sand, others, including me will follow.
If the already verified fixes are grouped or included to a new setup, with a web site newly created, people seeing the revival can come back. Just a though and a hope.
But if you suggest me to use FPC, on the last still active VP page, don't expect more incomes.
This make me ask myself what I am doing here, and what are you doing here.
Well, I ask for help. You ???

Sorry, just happened to see Marco to the FPC developers list.
Now I understand why.
Hope you received my mail and read it.
It started when you asked for enhancements to VP and heard they are not scheduled for VP, and not likely to happen. You yourself had already indicated that FPC does have these features, and life in it, but there the FPC IDE is imperfect.

I correct some factual incorrect opinions about the IDE, and point out that the problem of the IDE is the slow pace (*) of development, not that it is beyond salvation and that quality contributions and bugreports can change that. You mail to FPC core (a message that I also got btw), and get all that confirmed.

And starting with development is always difficult. It is a slow proces, which is why I said that it was not wise to wait till time had run out. Getting source, learning your way around in the source takes time. Learning how to debug, exploring the depths of TV etc etc. And you'll have to find your own way, with only some pointers on maillist or IRC.

On the other hand, the textmode IDE is nothing more than a normal FPC/TP/VP program. The same practices apply more or less as would to normal programs.

I do care a bit about the IDE, but can't spend vast amounts of time on it. So I coordinate a bit, commit patches etc, in the hope it doesn't really die, and to help people that are interested find their way. I've never used VP much, but I have assisted in porting FPC code to VP and vice versa a few times, which is why I'm still here.

(*) it is not entirely halted btw. Patches are still submitted, and I added CHM support last fall.
You give me hope.
Are my general IDE "requests" weird to your opinion, as you worked also with VP ?
Do you know other IDE able to do this ? I've found few, some with sources but less featured even than the built-in IDE.
The differences between VP and FPC are more deep than I've mentioned but I am too small to say something.
Perhaps you can complement my list of features with more pertinent suggestions ? You know better than me the differences. I think VP IDE is far better. It is a total waste to not use it's optimised features in FP.
Don't you think ?
At least the built-in help for configurations and browse for files can be fixed soon.

I must admit, the IDE is keeping(ed) me far away from FP. The compile speed and result size is the other one, but less important.

If you think there is a way I can help, gladly I put myself to work.
Hi all !

I think it's strange to speak about FP here in the VP forum but why not ? Did you try Lazarus, the Delphi-like multiplatform IDE ? You can create classic FP programs, run and debug them.

;)
Well, lets first state that there is nothing wrong with using VP. The whole point of this thread is that while it might not be bad, it might be worthwhile to invest in whatever you plan to use after VP. And FPC is the most logical candidate.
I absolutely agree with you, Marco, and your presence here is appreciated.

We're all just trying to do what is best, with the realization that the number of people who can and want to contribute is small.

One of the good things about the fact that VP won't evolve any further is that the effort that goes into supporting the Delphi/Pascal programming community is not diluted: if you want to contribute, do so to FPC since that is where any evolution will happen...
Can be a solution for all the VP lovers to start contribute to FPC IDE.

Else, VP will go one day to the museum, no succesors alive.

I can be the "maid/doorman/beautifier helper" as I can't have high level contributions.
Tried it.
Much too verbose.
Filled with huge workspace for GUI applications I will never use for my console compilations.
I manipulate data, doesn't matter if the screen is black.
If you can reccomend me a way to remove all GUY related additions from Lazarus.
I try to find the more simple way to work with resizable big arrays.
- An fix/update to VP. Obviously only here can be solved by someone who worked to VP and feel/agree it must be added.
- Another environment, VP like, with confortable IDE to work with. Logic choice go to FP

- VP has 15Mib/466files, including sources, help and libs
- FP has 289Mib/22.144files (140Mib/2.164files + 29Mib/10.500helpfiles + 120Mib/9.480sourcefiles)
- Lazarus has 506Mib/12.702files

I think you understand why I want VP on my flash drive to make <100Kb exe's.
Apart the topic mentioned lack, ALL the VP satisfies me.
For a small fix should I use FPC, 20 times bigger and less friendly or try to get help from you ?
Of course, in time, as the FP IDE get more friendly (maybe I will be able to contribute or they can use my suggestions) or get another IDE for it, I will write my code with it.

But I am somehow pressed by the need to quikly face the input data / memory needed to load it, making the minimum modifications in the big code I use.
With time I will find better solutions.
The use of FP push me to change >40% of my code working with the IDE wich make all harder.
Changing the array type and adding some lines can be <5% code change.
I can have the time to do this before my deadline.

The time acomodating to FP and the amount of extra modifications is too long to be a solution in this moment.
It's a long term move, I will have to make.
First, my smallest stick is 1GB. Second, the size of a default (or even maximal) install is a bit unfair.

So you need to try to judge by what you really need. And for FPC that is at least the bin (12MB) and units/i386-win32/rtl (10MB). This can be weeded out further (kill the cmdline compiler, delete unused units). For the rest you can simply pick the precompiled packages you need from units/i386-win32 and copy the relevant packages.

The basic CHM helpfiles (a separate download) are about 3 MB for the RTL and 1 MB for the FCL. They work with 2.2.4.

However FPC will be larger, no doubt about that. .... Just not by that margin.

The development effort went more towards modern requirements, and less towards keeping it small and downloadable over phone line. The distributed development makes this also more necessary.

Moreover you don't really specify what the size problem really is for you. See also http://wiki.freepascal.org/Size_Matters
Compilled result size is not so important. I see sysutils add the 100Kb extras. Usually I have about 50 small apps roundly 30Kb each in VP. Somehow found it weird (misconfig of FPC for sure) to get results over 100Kb (done long time ago, numbers can differ). Not crucial but the VP compilled 50apps fit on 1.44 floppy(USB has troubles in w95). This is really secondary problem. Forget about it, please.

Of course, I try to reduce the size of the FPC but I also need the sources to step debug in them too. It is my method to learn something new.
As usb drive, I use 2pcs of 16Gb. Not the space occupied is the big problem. The drives are fat32, 8Kb cluster, so the real occupied space is increased.
No.
The time needed to load and compile is very long. Even huge for Lazarus.
I can fix this by moving to archives unused and delete unneeded.
The above can be fixed quickly if I stick to a single version and I believe I can make an exe to repeat the job on new installs.
They are not my real problem. Just mentioned. Shouldn't.

But, it seem the choice is myne.
Leave my nice VP because I really need this arrays wich nobody want to help & put them in.
Migrate all I can before my deadline and accomodate to FP IDE.

I am forced.... to go to FP this way.
Hi Portos and everyone else.

Since this thread is going on since almost one month I thought I should check out the problems
discussed myself and add my thoughts and findings.

First of all, I also appreciate the presence of Marco around here or the NDN forum, and I don't mind any discussion or information related to FP.

I cannot say anything concerning the IDEs of VP or FP, since I've never used them.
I always prefer to have my programs to be built by makefiles or a vpc.cfg only on the command line.

Portos, I want to help you with your dynamic array problem by giving you some alternatives on how to
implement a similar behaviour in standard pascal code. Just don't expect to get a FULL solution or description
for this. I will try to give you all you need (some source code examples) to implement something similar yourself.
From my point of view, there's no reason to use anything else than VP (at the moment).

For this I first had to check out what dynamic arrays are and do anyway.
We are talking about "x: array of y;", which can be resized like "SetLength(x, 10);" and accessed like standard arrays " z := x[0]", right?

Here are the possibilities that came to my mind:
A) TCollection and inheriting objects
This is probably the best tradeoff between speed and memory usage for dynamic list and object handling.
You basically have a list of pointers, which point to a type or your choice. The code itself doesn't care and know
what it points at. There are many examples for enhanced objects based on TCollection.
You shoud have no problem understanding these after some source code studies.
But I think that this is not very efficient if you want to handle types of size <= 4.
(Except if you abuse the pointer list not to hold pointers but the type itself...)
Also, it is quite some code change from static arrays to dynamic lists.

B) Implementing the dynamic arrays yourself: Memory handling
Here I want to give you source code that might help you.
First of all, create a type for your array (see objects.pas):
type
PByteArray = ^TByteArray;
TByteArray = array[0..512*1024*1024 div sizeof(Byte)] of Byte;

Now, get some memory:
var
P: PByteArray;
Size: Integer;
begin
Size := WantedByteCount * sizeof(Byte);
GetMem( P, Size );
...
writeln( P^[Index) );
...
Size := NewByteCount * sizeof(Byte);
ReAllocMem(( P, Size );
...
FreeMem( P, Size);
end;

Except for the visible memory handling you now have a dynamic array.
Of course, the P^[Index] is also a little different.
You could probably wrap all the 3 memory functions into a custom SetLength...() function.
And: replace Byte with your type!

C) Implementing the dynamic arrays yourself: AnsiStrings
Look at following test program. It uses an AnsiString and it's SetLength() functionality.
We still use the PByteArray from above:
Program test;

uses
objects, sysutils;

Var
P: PByteArray;
S: AnsiString;
begin
SetLength( S, 0 );
P := @S[1];
Writeln( IntToHex( Longint(@S), 8 ) + ' ' + IntToHex( Longint(@S[1]), 8 ) + ' ' + IntToHex( Longint(@P^[0]), 8 ) );
SetLength( S, 512 );
P := @S[1];
Writeln( IntToHex( Longint(@S), 8 ) + ' ' + IntToHex( Longint(@S[1]), 8 ) + ' ' + IntToHex( Longint(@P^[0]), 8 ) );
SetLength( S, 1024 );
P := @S[1];
Writeln( IntToHex( Longint(@S), 8 ) + ' ' + IntToHex( Longint(@S[1]), 8 ) + ' ' + IntToHex( Longint(@P^[0]), 8 ) );
SetLength( S, 256 );
P := @S[1];
Writeln( IntToHex( Longint(@S), 8 ) + ' ' + IntToHex( Longint(@S[1]), 8 ) + ' ' + IntToHex( Longint(@P^[0]), 8 ) );
SetLength( S, 0 );
P := @S[1];
Writeln( IntToHex( Longint(@S), 8 ) + ' ' + IntToHex( Longint(@S[1]), 8 ) + ' ' + IntToHex( Longint(@P^[0]), 8 ) );
end.

Here's the output:
02E81E60 00000000 00000000
02E81E60 02EB0904 02EB0904
02E81E60 02EB0B14 02EB0B14
02E81E60 02EB099C 02EB099C
02E81E60 00000000 00000000

Ok, as you can see the actual memory location of the data after each SetLength() is different.
It's the same effect you would get if you would check the memory pointers returned by
GetMem() ReAllocMem() FreeMem()
Also note that the memory location of @S[1] and @P^[0] is always equal!
So the only drawback using this is
- P := @S[1]; after each SetLength(), but you could wrap this in a function.
- P^[Index] is a little different than P[Index]

Again, you always have to do SetLength() size calculations like "Count * sizeof(Type)".
Instead of Byte you can use any other type.

I hope this helps you or anyone else.

All the best,
Stefan / AH
Just when the time ran out for editing I realized that answers B and C do not implement
dynamic arrays as in Delphi, but only work for fixed size types.
Then again, ShortStrings are of fixed size (max 256 bytes), and, AnsiStrings are of fixed size too,
as only their references are copied.

Maybe the answers B+C may work fine.

RSS

© 2018   Created by Allan Mertner.   Powered by

Report an Issue  |  Terms of Service