Cross platform far?

[Stuart Carnie]

Has there been any thoughts or previous discussions on taking far
cross platform?

There are obviously many approaches :

Option 1.
Refactor C++ codebase to be cross-platform

Option 2.
Refactor to another cross-platform runtime.
e.g. .NET (MS / Mono)

I prefer Option 2, as there are a number of advantages.
1. Single, cross-platform executable will run on Linux, Windows, OS
X and Free BSD
2. Potential for less platform-specific code, given Mono / .NET
class libraries hide the underlying platform implementations.
3. Leverage existing .NET platform features, such as RegEx,
configuration, scripting (ironpython, boo, ...)

I've successfully converted the Frodo C64 emulator from C++ to C#, so
I was thinking of starting this as a side project / experiment.

What is the level of interest in this?

Cheers,

Stu

[techtonik]

On Dec 21, 2007 9:10 PM, Stuart Carnie <stuart...@gmail.com> wrote:
>
> Has there been any thoughts or previous discussions on taking far
> cross platform?

There were discussions in russian forums and in linux groups. The
problem is different approaches to handling terminal input/output,
encodings, different mount schemes, shortcuts, systems calls and file
attributes. The amount of work to provide a common denominator could
be so huge that it will be easier to rewrite the program from scratch.

> There are obviously many approaches :
>
> Option 1.
> Refactor C++ codebase to be cross-platform

The biggest problem is not in cross-platform C++ code, but in
cross-platform WinAPI, which makes about 80% of functionality.

> Option 2.
> Refactor to another cross-platform runtime.
> e.g. .NET (MS / Mono)

.NET / Mono sounds good. I've heard that in combination with gtk+ it
could even deliver information both to GUI and console. Still the
problem is the same - there is no code to patch or refactor, only to
write from scratch.

> 3. Leverage existing .NET platform features, such as RegEx,
> configuration, scripting (ironpython, boo, ...)

How far .NET RegEx from Perl ones. The latter are more common and not
too hard to link to existing C++ code. Scripting in .NET is already
available, at least at plugin level - see
http://code.google.com/p/farnet/ Some people work on native binding
for a Python, but this doesn't move too fast lately.

> I've successfully converted the Frodo C64 emulator from C++ to C#, so
> I was thinking of starting this as a side project / experiment.
>
> What is the level of interest in this?

I think everyone is aimed on releasing the unicode version of Far
first and there are no plans to convert codebase to C#. Far is
designed as system utility that should work even on clean Windows 2000
installation with no .NET installed

In case you still want to bring it to .NET I'd first reviewed the code
to estimate amount of work needed. If the goal can be divided into
visible tasks, it makes it easier to calculate and also increases
chances to find support among other developers. It is Open Source BSD
project, so anything is possible.

Happy Holidays!

--
--anatoly t.

[Stuart Carnie]

Thanks for the reply. I have started a x-platform binding for
ncurses / pdcurses, which should provide good, generic cross-platform
terminal output for far. I am looking to use a driver / provider
model, so the output device could be configured. I notice the dialogs
are created in such a way we could render to text, or the target OS's
native GUI, using a row / column model for GUI widget alignment.



On Dec 22, 12:48 pm, techtonik <techto...@gmail.com> wrote:

> On Dec 21, 2007 9:10 PM, Stuart Carnie <stuart.car...@gmail.com> wrote:
>
>
>
> > Has there been any thoughts or previous discussions on taking far
> > cross platform?
>
> There were discussions in russian forums and in linux groups. The
> problem is different approaches to handling terminal input/output,
> encodings, different mount schemes, shortcuts, systems calls and file
> attributes. The amount of work to provide a common denominator could
> be so huge that it will be easier to rewrite the program from scratch.
>

Fair enough. I think porting to C# is essentially a 'rewrite', but
the great thing is we have a good platform (far) to base the code on.
I'm most interested in modelling the functionality as close to far as
possible, so that the learning curve is minimal.
.NET provides a good enough API that encodings, system calls (such as
TCP/IP, File I/O, etc) are covered by .NET. File attributes (rwsh,
directory) are available cross-platform; however, I would abstract the
file-system (FileInfo, DirectoryInfo, DriveInfo) to interfaces and
allow extended implementations for each platform.

> > There are obviously many approaches :
>
> > Option 1.
> >   Refactor C++ codebase to be cross-platform
>
> The biggest problem is not in cross-platform C++ code, but in
> cross-platform WinAPI, which makes about 80% of functionality.
>
> > Option 2.
> >   Refactor to another cross-platform runtime.
> >   e.g. .NET (MS / Mono)
>
> .NET / Mono sounds good. I've heard that in combination with gtk+ it
> could even deliver information both to GUI and console. Still the
> problem is the same - there is no code to patch or refactor, only to
> write from scratch.
>

Agreed. I think that is the approach I'll take, and as previously
mentioned,

> >   3. Leverage existing .NET platform features, such as RegEx,
> > configuration, scripting (ironpython, boo, ...)
>
> How far .NET RegEx from Perl ones. The latter are more common and not
> too hard to link to existing C++ code. Scripting in .NET is already

> available, at least at plugin level - seehttp://code.google.com/p/farnet/ Some people work on native binding

> for a Python, but this doesn't move too fast lately.
>

.NET RegEx is flexible enough (and quite performant too).

> > I've successfully converted the Frodo C64 emulator from C++ to C#, so
> > I was thinking of starting this as a side project / experiment.
>
> > What is the level of interest in this?
>
> I think everyone is aimed on releasing the unicode version of Far
> first and there are no plans to convert codebase to C#. Far is
> designed as system utility that should work even on clean Windows 2000
> installation with no .NET installed
>
> In case you still want to bring it to .NET I'd first reviewed the code
> to estimate amount of work needed. If the goal can be divided into
> visible tasks, it makes it easier to calculate and also increases
> chances to find support among other developers. It is Open Source BSD
> project, so anything is possible.

True - I have been looking at the code, and find it has plenty of
things we can reuse (or at least model from). I would like it to be a
close to Far as possible, so the learning curve is minimal. I spend a
lot of time across Windows and OS X now, and I really miss having a
single x/platform dual pane file manager :)

>
> Happy Holidays!
>

Likewise!

> --
> --anatoly t.

[doknir]

Hello!


Just one comment regarding .NET and FAR:
Currently there is no .NET in Windows Server 2008 Core, so C# version
of Far won't work in core edition - the same is true for PowerSheell,
for example:

http://geekswithblogs.net/lorint/archive/2007/10/30/116462.aspx

But maybe there will .NET Core Framework someday ...

Cheers, Roman