2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl:
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Ah, but that would explain why I don't use it. I never develop in
delphi mode, only objfpc mode - unless I work with projects like tiOPF
where both
Graeme Geldenhuys schrieb:
2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl:
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Ah, but that would explain why I don't use it. I never develop in
delphi mode, only objfpc mode - unless I work with
In our previous episode, Mehmet Erol Sanliturk said:
it seems that 2.2.4 needs to be 2.4.0 , and 2.3.x needs to be 2.5.x .
Fixed, will be updated soon (I hope)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Nikolai ZHUBR schrieb:
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve this problem at least partly. They seem to
On keskiviikko, 6. tammikuuta 2010 03:08:35 Nikolai ZHUBR wrote:
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve
On keskiviikko, 6. tammikuuta 2010 10:59:36 Florian Klaempfl wrote:
Indeed, there are multiple ways to prevent the hell of circular class
references between units:
- abstract base classes
- interfases
- include files
- big units
- type casting (in the worst case)
- ...
The right choice
On 5 Jan 2010, at 22:40, Graeme Geldenhuys graemeg.li...@gmail.com
wrote:
I must say, I agree with the original poster - it would be very
useful. I have had many battles to try and overcome circular reference
issues, and I do take care in my class designs.
I would also agree. I used to use
In our previous episode, Juha Manninen said:
- big units
- type casting (in the worst case)
- ...
The right choice depends on the application.
Abstract base classes and interfaces are recommended by many but actual
projects end up copying everything into one file. Surprising... :-)
On 06 Jan 2010, at 11:14, Juha Manninen wrote:
I must try include files for this problem sometimes. Does FPC really
treat
them differently than Delphi.
No. {$i xxx} is exactly the same as copy/pasting the contents of xxx
into the current file at that point.
Jonas
On Wed, 6 Jan 2010, Marco van de Voort wrote:
In our previous episode, Juha Manninen said:
- big units
- type casting (in the worst case)
- ...
The right choice depends on the application.
Abstract base classes and interfaces are recommended by many but actual
projects end up copying
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really needed (and nothing like
In our previous episode, Michael Van Canneyt said:
projects end up copying everything into one file. Surprising... :-)
I never do this, there is no need. Probably similar to the fact that 90% of
the Delphi programs have all important code in event handlers of the GUI
components. That
Stefan Kisdaroczi wrote:
to create hard realtime linux programs with freepascal and xenomai [1] in
userspace
Ooops
Userspace means Linux and Linux means no hard realtime possible (with
the official definition of hard realtime: reaching a predefined timing
deadline with 100% certainty).
In our previous episode, Florian Klaempfl said:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's
Michael Schnell schrieb:
Stefan Kisdaroczi wrote:
to create hard realtime linux programs with freepascal and xenomai [1] in
userspace
Ooops
Userspace means Linux and Linux means no hard realtime possible (with
the official definition of hard realtime: reaching a predefined timing
Florian Klaempfl schrieb:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really
On 05 Jan 2010, at 16:39, Stefan Kisdaroczi wrote:
Looking at rtl/inc/heap.inc from 2.4.0 it seems that the locking is
now done using CriticalSections,
is that true ?
Yes.
To adapt my ThreadManager for 2.4.0 I think I have to:
- remove the SetMemoryMutexManager() call
- implement the
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a
In our previous episode, Stefan Kisdaroczi said:
i need the mlockall() call (unit libc) in my realtime apps on linux i386
to lock the address space of the process. Works, but unit libc has no
future and it's the only function i need from this unit.
mlockall is part of the posix 2001 realtime
Juha Manninen wrote:
IMO, the compiler should not force a programmer to make a 34 000 lines source
file (like VirtualTreeView has). Programmer should have a choice to split it
if he wants.
What about include files (used a lot in Lazarus LCL) ? You can e.g.
separate the interface part from
In our previous episode, Florian Klaempfl said:
cannot test a unit with external circular class references without the
other involved units. So why should the stuff be separated?
I don't like extremely large ( few thousand lines) units from an overview
perspective.
One can also say a
In our previous episode, Michael Schnell said:
I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do
a kind of linking manually by using a main file that includes
everything else.
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
On 06 Jan 2010, at 11:54, Marco van de Voort wrote:
I saw some hints on the web that OS X doesn't support it (but it
should be
checked against 10.3/10.4+ since afaik those implement a lot more
calls due
to synchronization with FreeBSD5)
$ gcc -o mlockall mlockall.c
$ ./mlockall
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for small/large
units and if a design
In our previous episode, Jonas Maebe said:
I saw some hints on the web that OS X doesn't support it (but it
should be
checked against 10.3/10.4+ since afaik those implement a lot more
calls due
to synchronization with FreeBSD5)
$ gcc -o mlockall mlockall.c
$ ./mlockall
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still, I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
Florian Klaempfl schrieb:
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for
Marco van de Voort wrote:
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
CCS
Same had been the cheapest option for a C compiler to try out the PICs.
I never switched to something else, as I am abandoning the 8 bit PICs
for the 16 Bit ones that are
In our previous episode, Juha Manninen said:
Other programming languages have different cultures. See the comment from my
original post in this thread. It was from a professional programmer and I
understand it. Some development teams want to put every class into its own
file. C and C++ even
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still, I don't like that compiler forces such a thing.
The compiler forces you many
Juha Manninen schrieb:
Other programming languages have different cultures. See the comment from my
original post in this thread. It was from a professional programmer and I
understand it. Some development teams want to put every class into its own
file.
Different languages, different
In our previous episode, Michael Schnell said:
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
CCS
Same had been the cheapest option for a C compiler to try out the PICs.
Well, the microchip one academic option is free. So CCS gives money with
Florian Klaempfl wrote:
Did you look at the xenomai website?
Seemingly you need to do your own device drivers and not use any Linux
system calls in your realtime process, that seems to run Linux in a kind
of virtualization.
So FPC programming for realtime would require to prevent FPC from
Michael Schnell schrieb:
Florian Klaempfl wrote:
Did you look at the xenomai website?
Seemingly you need to do your own device drivers and not use any Linux
system calls in your realtime process, that seems to run Linux in a kind
of virtualization.
Hard real time causes a lot of
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
Maybe you
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why they are not commonly used in Delphi programs as source
files. It
Juha Manninen wrote:
Ok, include files seem to solve this problem.
I don't know why they are not commonly used in Delphi programs as source
files.
Maybe because (some old version of the) Delphi IDE's debugger could not
step into include files. AFAIK, the actual Lazarus can do this with no
Did you have a look at AVR?
They use GCC, although commercial compilers are also available should
you need it. I have used GCC-AVR for years without problems.
Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
Which is that then? Afaik the microchip own, and the
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote:
Different languages, different habits. I even consider putting every
class in its own header and implementation file as a bad habit.
There is
no reason to do anymore because modern C/C++ compiler can smartlink
on a
sub-object level which
Marco van de Voort wrote:
I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very
happy with them.
Same here (with PIC 24xx). A friend of mine uses the 33s very happily, too.
But I still use the PIC18F60j60 part since there is no
16-bit integrated ethernet part, and as
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why they are not commonly
Jonas Maebe schrieb:
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote:
Different languages, different habits. I even consider putting every
class in its own header and implementation file as a bad habit. There is
no reason to do anymore because modern C/C++ compiler can smartlink on a
Include files - just like conditional defines - totally mess up all
code tools.
Is this true for the newest versions of Delphi, too ? I seem to remember
rumors about lots of IDE improvements.
-Michael
___
fpc-devel maillist -
On Wed, 6 Jan 2010, Michael Schnell wrote:
Include files - just like conditional defines - totally mess up all
code tools.
Is this true for the newest versions of Delphi, too ? I seem to remember
rumors about lots of IDE improvements.
Well, not yet in D2009 as far as I remember, but I
In our previous episode, Michael Schnell said:
But I still use the PIC18F60j60 part since there is no
16-bit integrated ethernet part, and as spare replacement for legacy parts.
This fried uses the (quite new) Microchip Ethernet MAC/PHY chip
(including frame buffers, doing 100MBit) that
In our previous episode, Florian Klaempfl said:
memory, depending on the used compiler (and debug information or
optimization settings)
For single class c++ files, imo most of the time is spent into reading
the huge headers which are often even not needed and a complete mess
because
Am 06.01.2010 12:35, schrieb Michael Schnell:
Florian Klaempfl wrote:
Did you look at the xenomai website?
Seemingly you need to do your own device drivers and not use any Linux
system calls in your realtime process, that seems to run Linux in a kind
of virtualization.
So FPC
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Another reason is probably to speed up the compilation:
* (re)compiling huge source files can be slow and/or require lots of
memory, depending on the used compiler (and debug information or
optimization settings)
For
Jonas Maebe schrieb:
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Another reason is probably to speed up the compilation:
* (re)compiling huge source files can be slow and/or require lots of
memory, depending on the used compiler (and debug information or
In our previous episode, Wimpie Nortje said:
Did you have a look at AVR?
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
toolchains
Marco van de Voort schrieb:
In our previous episode, Wimpie Nortje said:
Did you have a look at AVR?
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple
Stefan Kisdaroczi wrote:
You can call normal linux system calls without problems, that is one of the
big features of xenomai, but of course you have to take care, it can have an
impact on the realtime performance.
Meaning that when doing a Linux system call, at this point a potentially
huge
Marco van de Voort wrote:
I rather use FPC to substitute some of my 10-20 line programs on the
delphi side.
This is what I intend to get running before I retire :) : Have an
existing Delphi project of the size you mention run on NIOS/Linux.
-Michael
Marco van de Voort wrote:
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
toolchains (if a free one exists at all)
What was
Matt Emson wrote:
I would also agree. I used to use Interfaces or raise shared
classes/declarations to a new unit both could use to overcome this
issue myself. But I remember the Be GUI porters having loads of issues
mimicing the Be API header structure because there were so many
forward
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why
In our previous episode, Wimpie Nortje said:
Marco van de Voort wrote:
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
Is there a way to find out what stuff have been generated after a make under
osx ?
The fpcbuild.zip includs a lot of files; I do a make all under
...ide/compiler/ and
it seems that it compiles fine; I mean compunit.ppu and compunit.o are
created however
I was expecting a proper ppc* compiler as
In our previous episode, London Disney said:
Is there a way to find out what stuff have been generated after a make
under osx ? The fpcbuild.zip includs a lot of files; I do a make all
under ...ide/compiler/ and it seems that it compiles fine; I mean
compunit.ppu and compunit.o are created
Wimpie Nortje wrote:
I don't want to start a AVR/PIC fight because it always ends up in a
religous war
We could just as well add Renesas and whatever other such archs :) . I
suppose each has it's pros and cons, otherwise it would already have
died out out taken the world.
-Michael
ok thanks.
really hard to get into new stuff under *nix systems.
would be nice to have xcode projects for all this as well as
command-line make files.
are there any plans to do that ?
On Wed, Jan 6, 2010 at 2:06 PM, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, London
On 06 Jan 2010, at 15:09, London Disney wrote:
would be nice to have xcode projects for all this as well as
command-line make files.
are there any plans to do that ?
I don't think so, since I know of nobody that uses Xcode to work on
FPC (and such a project would have to be kept
Am 06.01.2010 14:02, schrieb Michael Schnell:
Stefan Kisdaroczi wrote:
You can call normal linux system calls without problems, that is one of the
big features of xenomai, but of course you have to take care, it can have an
impact on the realtime performance.
Meaning that when doing a
all done and built ! :)
@Jonas
yeah it was just a thought for people like me making a transition from
some commercial tools under each platform (MSVS, XCode, etc...).
good incentive to be able to visualize the structure w/o having to read
lots, don't you think so ?
anyway, just a thought.
On
On 06 Jan 2010, at 15:25, Stefan Kisdaroczi wrote:
AFAIK the RTL allocs the heap on app startup, or on thread-creation
with 2.4.0.
In my code im using getmem() to alloc mem from the heap, this will
not generate
syscalls because the heap is already allocated and the RTL has its
own
Jeff Wormsley wrote:
I would think any time you have two objects that need bidirectional
access of any sort that you would need to define an connector object
to make this link, so the data or functions that needs to be shared
between the two don't reside in either object, but in the connector
Am 06.01.2010 15:38, schrieb Jonas Maebe:
On 06 Jan 2010, at 15:25, Stefan Kisdaroczi wrote:
AFAIK the RTL allocs the heap on app startup, or on thread-creation
with 2.4.0.
In my code im using getmem() to alloc mem from the heap, this will not
generate
syscalls because the heap is
Michael Schnell wrote:
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
http://www.lazarus.freepascal.org/index.php/topic,8304.msg39889.html#msg39889
http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/046906.html
It can
Hi, I'm trying to create a cross compiler from Linux-x86_64 to Linux-i386, to
do this, I have installed the compiled version 2.4.0 from Ubuntu repositories,
which is ppcx64, then got the compiler trunk version from svn.
To create the cross compiler, I'm following this guide:
On 06 Jan 2010, at 20:15, Leonardo M. Ramé wrote:
To create the cross compiler, I'm following this guide:
http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux
When I do sudo make all CPU_TARGET=i386 I receive this message:
/usr/bin/fpc -Pi386 -XPi386-linux- -Xr -Fui386 -Fusystems
Thanks Jonas, I went a step further.
Now, when I just do fpc, to I got this:
Error: ppc386 can't be executed, error message: Failed to execute ppc386,
error code: 127
What can be causing this?
...but I found the new ppc386 in /usr/local/lib/fpc/2.5.1/ppc386, so I tried to
compile a sample
On 06 Jan 2010, at 21:15, Leonardo M. Ramé wrote:
Thanks Jonas, I went a step further.
Now, when I just do fpc, to I got this:
Error: ppc386 can't be executed, error message: Failed to execute ppc386,
error code: 127
What can be causing this?
Create a symlink from
Thanks again Jonas, that worked ok!.
Leonardo M. Ramé
http://leonardorame.blogspot.com
--- On Wed, 1/6/10, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
From: Jonas Maebe jonas.ma...@elis.ugent.be
Subject: Re: [SPAM] Re: [fpc-devel] Creating ppc386 from ppcx64
To: FPC developers' list
Hello,
I'm doing my first steps in fp - and for a long time in Pascal again -
and use the 2.4.0 version. I more or less often come into a situation,
where the compiler simply tries to compile my program and just says
(after a long list of infos - but not errors or warning): Compilation
74 matches
Mail list logo
