The IDE is working again with the 1.1 development compilers. For linux a 1.1 IDE is already available in the snapshots directory. For go32v2 and win32 it'll be monday or tuesday before it will be available.

Peter

04 ��� 01 17:35, Peter Vreman wrote:
PV> The IDE is working again with the 1.1 development compilers. For linux PV> a 1.1 IDE is already available in the snapshots directory. For go32v2 PV> and win32 it'll be monday or tuesday before it will be available.

Is there a fvision source avaible to make IDE from source? A CVS sources from date 2001/07/22 (22 jul) have problems.

A one of problems: now (even in -So mode) FPC do not understand assigment of procedure to procedural variable without @. It is mistale in -So handling, or it is a new point of view?

Regards,
Sergey Korshunoff

PS: as I understand from FPC 1.1 sources, FPC can now produce *.o file without AS? This is nice. But 1.1 eats much more RAM then 1.0.5 when compiling itself. FPC 1.0.5 can work on PC with 16 MBytes of RAM. And FPC 1.1 start swapping to disk.

When you rename fvision to fv it is possible to build the IDE. But there are still some problems and the asciitable and symbol browser are excluded.

A one of problems: now (even in -So mode) FPC do not understand assigment of procedure to procedural variable without @. It is mistale in -So handling, or it is a new point of view?

Please provide an example that doesn't work

PS: as I understand from FPC 1.1 sources, FPC can now produce *.o file without AS? This is nice. But 1.1 eats much more RAM

Yes, there is now an internal ELF objectfile writer for linux

then 1.0.5 when compiling itself. FPC 1.0.5 can work on PC with 16 MBytes of RAM. And FPC 1.1 start swapping to disk.

The memory requirements are a little higher. But the source of the compiler is also bigger so that is another reason why more memory is required.

At 08:36 07/08/01 , vous avez écrit:

FVISION is far from being stable :(

I am currently tring to get it to give at least correct display, but there are still several big issues
related to using fvision.

We got the fvsion code from Leon de Boer and we made several change since that, but
there are several incompatibilities with Turbo Vision.

The most important one is probably that in FVISION the Origin field of a TView gets set relative to the outermost owner (in general the Application itself) when it is inserted to the owner.
In Turbo Vision, Origin is always relative to the first level owner only.

This can lead to several complication and errors if :
- you access the Origin field directly (especially if you change its value)
- you insert the same view into several owner (which is bad programming, but not
forbidden, even if it can lead to disposal problems later).

The only solution to reallly achieve better compatibility is probably to change all the internal FVISION code to give a Origin field that is compatible with Turbo Vision.

So if you are going to try the FVISION library out, don't forget about these
points.

Of course if anyone is willing to help us to get a more compatible FVISION, or willing to implement some missing or incorrect units, please raise your hands, you will be most welcome.