Jonas Maebe wrote:
>
> On 6 jan 2005, at 22:21, DrDiettrich wrote:
>
> >> The FPC baseunix/unix units mimic more or less the POSIX standard
> >
> > As already mentioned, I couldn't find these units :-(
>
> They only exist for unix-like OS'es. They are not generic units which
> you can use to por
Jonas Maebe wrote:
> Why? There are cvs clients for pretty much any OS out there. Or does
> your working OS not have a network connection?
I have a network connection, that I use rarely when I need to access
some device built into my old computer. Everything else goes over the
phone line.
But pe
On Thu, 06 Jan 2005 22:29:45 +0100, DrDiettrich wrote
> Tomas Hajny wrote:
>
> > > I only don't know how to implement or check the other branches - is the
> > > Windows version of FPC equipped for crosscompilation?
> >
> > The compiler itself can compile for all platforms listed in help pages
>
On 6 jan 2005, at 21:21, DrDiettrich wrote:
I don't remember the exact procedures, isn't it required to connect to
the server for such updates? For me that would mean to boot a different
OS, connect to the server, synchronize with cvs, shut down and reboot
my
working OS again.
Why? There are cvs c
On 6 jan 2005, at 22:21, DrDiettrich wrote:
The FPC baseunix/unix units mimic more or less the POSIX standard
As already mentioned, I couldn't find these units :-(
They only exist for unix-like OS'es. They are not generic units which
you can use to port software from *nix to Dos/Windows (although
> Marco van de Voort wrote:
>
> > You might also want to have a look at
> >
> > http://www.stack.nl/~marcov/porting.pdf
>
> A very fine document, I'll have to study it in detail :-)
>
> At the first glance I found some more or less important errors in this
> document. Do you want an according l
Marco van de Voort wrote:
> You might also want to have a look at
>
> http://www.stack.nl/~marcov/porting.pdf
A very fine document, I'll have to study it in detail :-)
At the first glance I found some more or less important errors in this
document. Do you want an according list? How to refer to
Florian Klaempfl wrote:
> >>- easier navigation in editors
> >
> > Definitely NO, with regards to include files! (May miss your point?)
>
> Probably yes, you can easily open two editor windows viewing e.g.
> declaration and definition at once. Using splitted view is always a mess
> and requires m
Tomas Hajny wrote:
> > I only don't know how to implement or check the other branches - is the
> > Windows version of FPC equipped for crosscompilation?
>
> The compiler itself can compile for all platforms listed in help pages
The problem is that the installed FPC doesn't show any help - no fil
Michael Van Canneyt wrote:
> POSIX says nothing about pascal, it's basically a C interface.
To me POSIX means primarily the very different file handling, with
regards to devices, path separators, owner/group/world access rights
etc. This is what bites not only me when porting GNU software to
Wind
> Marco van de Voort wrote:
> >
> > crosscompilation from windows to unix using libraries is also not that easy.
>
> I did it already for arm/linux: simply copy the *.a files to win32 and
> pass the path with -Fl to the compiler.
I did it for small programs in sept-okt 2003 (mkxmlrpc specially)
Marco van de Voort wrote:
On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich wrote
.
I only don't know how to implement or check the other branches - is the
Windows version of FPC equipped for crosscompilation?
The compiler itself can compile for all platforms listed in help pages
(those running on th
> On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich wrote
> .
> > I only don't know how to implement or check the other branches - is the
> > Windows version of FPC equipped for crosscompilation?
>
> The compiler itself can compile for all platforms listed in help pages
> (those running on the same
On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich wrote
.
.
> I only don't know how to implement or check the other branches - is the
> Windows version of FPC equipped for crosscompilation?
The compiler itself can compile for all platforms listed in help pages (those
running on the same CPU). How
> grep/sed is more powerfull than any search/replae of an editor :) Even
> more if grep is integrated into the editor :)
Two advantages of using an editor search tool is:
* Interactive replace, because often not all of the possible
replacements should actually be replaced.
* Batch search where
On Tue, 4 Jan 2005, DrDiettrich wrote:
> Michael Van Canneyt wrote:
>
> > The FPC units are not POSIX, hence, UNIX.
> > (long threads have already been spent on that, and it is a done deal)
>
> I don't want to resurrect a discussion, but can somebody give me an idea
> how UNIX and POSIX are diff
DrDiettrich wrote:
Florian Klaempfl wrote:
Not everything is a matter of OS. It could be also a matter of toolkit,
database, word size of the cpu or whatever. Further smaller files are
usually easier to handle:
- cvs works much better with small files
Hmm...
- easier navigation in editors
Definit
Michael Van Canneyt wrote:
> The FPC units are not POSIX, hence, UNIX.
> (long threads have already been spent on that, and it is a done deal)
I don't want to resurrect a discussion, but can somebody give me an idea
how UNIX and POSIX are different, with regards to FPC?
> > Question: What's pref
Marco van de Voort wrote:
> You might also want to have a look at
>
> http://www.stack.nl/~marcov/porting.pdf
>
> and
>
> http://www.stack.nl/~marcov/unixrtl.pdf
Ah, thanks :-)
> There are 4 cases for Unix:
>
> 1 Kylix
> 2 FPC/Linux/x86 reusing Kylix libc code.
> 3 FPC/Linux/x86 using genera
Tomas Hajny wrote:
> > {$ifndef unix}
> > {$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc.
> > {$else}
> > {$i abiulin.inc}
> > {$endif}
>
> There's at least one (IMHO not worse at least) alternative to that (already
> used in FPC itself among others) - keep the include file na
Florian Klaempfl wrote:
> Not everything is a matter of OS. It could be also a matter of toolkit,
> database, word size of the cpu or whatever. Further smaller files are
> usually easier to handle:
> - cvs works much better with small files
Hmm...
> - easier navigation in editors
Definitely NO, w
peter green wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Marco van de
erstanding of include files. Codetools don't work at
all if you use
include files. That said: $ifdefs confuse it as well...
That is one, the another is that they simply have suppo
On Mon, 3 Jan 2005 14:56:07 -, peter green wrote
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Marco van de
> erstanding of include files. Codetools don't work at
> > all if you use
> > > include files. That said: $ifdefs confuse it as well..
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marco van de
erstanding of include files. Codetools don't work at
> all if you use
> > include files. That said: $ifdefs confuse it as well...
>
> That is one, the another is that they simply have support
On Mon, 3 Jan 2005 10:40:10 +0100 (Romance Standard Time)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 3 Jan 2005, Marco van de Voort wrote:
>
> >
> > > 2) File Restructuring
> > > I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
> > > and UNIX sections,
> On Mon, 3 Jan 2005, Marco van de Voort wrote:
>
> > > 2) File Restructuring
> > > I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
> > > and UNIX sections, each containing complete procedures. These sections
> > > could be moved into dedicated OS specific include files -
On Mon, 3 Jan 2005, Marco van de Voort wrote:
>
> > 2) File Restructuring
> > I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
> > and UNIX sections, each containing complete procedures. These sections
> > could be moved into dedicated OS specific include files - what's t
On Mon, 3 Jan 2005, Tomas Hajny wrote:
> On Sun, 2 Jan 2005 23:35:10 +0100 (Romance Standard Time), Michael Van Canneyt
> wrote
> > On Sun, 2 Jan 2005, DrDiettrich wrote:
> >
> > > Michael Van Canneyt wrote:
> .
> .
> > > 2) File Restructuring
> > > I've separated the spaghetti code in AbUtils
> Michael Van Canneyt wrote:
>
> > > I'm willing to demonstrate my ideas in a redesign and extension of
> > > Abbrevia, so that we have a concreter base for further discussions. But
> > > before starting with that work I would like to hear some encouraging
> > > opinions or suggestions.
> >
> >
On Sun, 2 Jan 2005 23:35:10 +0100 (Romance Standard Time), Michael Van Canneyt
wrote
> On Sun, 2 Jan 2005, DrDiettrich wrote:
>
> > Michael Van Canneyt wrote:
.
.
> > 2) File Restructuring
> > I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
> > and UNIX sections, each co
> > > I'm willing to demonstrate my ideas in a redesign and extension of
> > > Abbrevia, so that we have a concreter base for further discussions. But
> > > before starting with that work I would like to hear some encouraging
> > > opinions or suggestions.
> >
> > I think you can do this. I wil
On Sun, 2 Jan 2005, DrDiettrich wrote:
> Michael Van Canneyt wrote:
>
> > > I'm willing to demonstrate my ideas in a redesign and extension of
> > > Abbrevia, so that we have a concreter base for further discussions. But
> > > before starting with that work I would like to hear some encouraging
Michael Van Canneyt wrote:
> > I'm willing to demonstrate my ideas in a redesign and extension of
> > Abbrevia, so that we have a concreter base for further discussions. But
> > before starting with that work I would like to hear some encouraging
> > opinions or suggestions.
>
> I think you can
Michael Van Canneyt wrote:
> > 1) Target Dependencies
> Agreed 100%.
> In general, a component suite should have all os-dependent code in a single
> unit, presenting the rest of the suite with a uniform API.
Fine :-)
But how should that code be implemented? For various target platforms?
> > 2)
On Sat, 1 Jan 2005, DrDiettrich wrote:
> In the meantime I downloaded the Abbrevia package from SourceForge, and
> came across several unpleasent constructs. Please let me introduce my
> preferred programming model for portable code.
>
> 1) Target Dependencies
> I don't accept any OS or machine
35 matches
Mail list logo
