Author
Topic: Patched FV to compile in ObjFPC (Read 6260 times)

Hi if anyone is interested, I made a patched version of FV to be able to compile it in objfpc-mode, partly with ansistrings.With IDE.patch you could patch the ide to get it to compile with the patched FV in objfpc-modeBoth projects now have a .lpi/.lpk so they are easily compilable in lazarus.

Can you guys not put the FV and Text IDE changes somewhere on Github or such for easier collaboration and testing? I have been hosting a Github mirror of FPC’s SubVersion repo for years, so simply fork that repository, create a FV mods branch and work in that.

Thanks for sharing the code on Github. If you use a clone of my repository (which in turn mirrors the official FPC trunk repo), integration back into Free Pascal's official repository should be easier (with full commit history). You will also be able to keep up to date with the latest FPC trunk changes, and the build system will also already be in place.

I missed that weditor bit, but fixed it with a call to wutils.rtrim. (unfortunately a function variant instead of a procedural one)

I think it is the best for common operations to single it out to procedures instead of putting handcrafted code everywhere.

I also had a look at fv/editors, but there a variable "tab_settings" is fillchared to initialize. Which is dangerous with ansistrings for two reasons:

1. the ansistring pointer is nilled leading to a memory loss, since the string identifier's adress points to the pointer location not the zeroth char (followed by the rest of chardata) like in shortstrings.

2. Even if you fix that, the reason that this is done might be that this unit access chardata beyond length(s) which is also not safe with ansistring.

Do we really need objfpc mode btw? Afaik ansistrings work in plain (fpc) mode too. Otherwise you also need to check all occurences of "Integer", and get a different system unit.

At the very least it should be a per unit decision so that you don't have to convert (and revalidate) existing units with only minor string usage.

P.s. I don't use git, and have no plans to change that, and I prefer if this discussion was kept on topic. I don't mind if people use git to craft patches against trunk though.

@marcovThe call to RTrim is a much better solution. If inlined the compiler can do the optimization ...

Ok, ansistrings work in FPC, but how about Unicode?

The on unit decision might be a solution for now, but in the long-run the dependency on a specific (in my opinion old) compilemode should be minimized.

On the other hand delphi and objFPC mode go quite well together ...

BTW. We/I Intend to do just that, (use github to prepare patches and diffs)And since I am still a one-man-army, and due to the fact that i am used to SVN for quite a while, and my experiments with git and TortoiseGIT resulted in a loss of data, SVN is and will be my weapon-of-choice.But then possibilities to merge code in and from tags and branches seem to be quite better in git, so i've been told ...Because of that i put my public repository on github.@GreameI'd very much like that, but i would need help to do it since I have very less experience in git.

@marcovMy intention with this thread was to give people who need objFPC in their project the ability to work with FV I didn't expected someone to change the original FV that's why I called my version FV+/IDE+. So I appreciate your work on FV/IDE very much, and I am thankful that the codebases don't drift apart so much.

@marcovThe call to RTrim is a much better solution. If inlined the compiler can do the optimization ...

Ok, ansistrings work in FPC, but how about Unicode?

Any way of handling unicode (be it the delphi way with unicodestring and mode delphiunicode or lazarus-ut8fhack) will be terribly involved.

with Unicodestring sizeof(char) changes which would need code modifications, and with lazarus-ut8fhack is lazarus only (while FV and IDE are in FPC where that is not enabled), and any operation on single s[] needs to be checked.

Also all utility units (like Video) will have to be checked and patched for this. Or rewritten.

One step at a time...

Quote

The on unit decision might be a solution for now, but in the long-run the dependency on a specific (in my opinion old) compilemode should be minimized.

The reason to not start over but do it in the existing codebase is to keep a working codebase. Too radical changes undermine this course.

I can still remember the FVnew (the old copyrighted TV code) to FV transition in 1.0.x times. That was not pretty, and may be less involved than what is planned here.

On the other hand delphi and objFPC mode go quite well together ...

I prefer delphi mode over objfpc anyway. The only reason that I used objfpc in the past went away since poiinter math is allowed in Delphi (and delphi mode) too.

Quote

BTW. We/I Intend to do just that, (use github to prepare patches and diffs)And since I am still a one-man-army, and due to the fact that i am used to SVN for quite a while, and my experiments with git and TortoiseGIT resulted in a loss of data, SVN is and will be my weapon-of-choice.But then possibilities to merge code in and from tags and branches seem to be quite better in git, so i've been told @marcovMy intention with this thread was to give people who need objFPC in their project the ability to work with FV I didn't expected someone to change the original FV that's why I called my version FV+/IDE+. So I appreciate your work on FV/IDE very much, and I am thankful that the codebases don't drift apart so much.

You are in good company, both Florian and I did a similar attempt in the past, and got mired in details. I gave up because ansistrings in objects weren't properly managed. Afaik that is remedied now, which is why I'm interested in how far you'd come, and am a bit knowledgable on the subject.

@marcov About unicode...Sorry, i think you got me wrong, i wasn't talking about converting all strings to unicode,( Though it would be a nice thing, but i know it's a long and stony way there, because of the problems you mentioned. Widestring can be an alternative since s[] works there, so you only have to mind that char is byte and widechar is word at least.) no i was talking about are unicode-strings or widestrings generally supported in FPC-mode ?

One step at a time...+1 from me (I am happy for every step)

...I prefer delphi-mode too ...

BTW the platform.inc only supports delphi to version 5 (DELPHI5/VER130). Should newer Delphi-versions be supported ?