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
abort
Thanks again Jonas, that worked ok!.
Leonardo M. Ramé
http://leonardorame.blogspot.com
--- On Wed, 1/6/10, Jonas Maebe wrote:
> From: Jonas Maebe
> Subject: Re: [SPAM] Re: [fpc-devel] Creating ppc386 from ppcx64
> To: "FPC developers' list"
> Date: Wednesday, January 6, 2010, 6:26 PM
>
> On
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 /usr/l
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 sampl
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 -Fu
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:
http://wiki.lazarus
Michael Schnell wrote:
Juha Manninen wrote:
I hope Lazarus can soon edit parts of one file in many editor tabs.
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 compress
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 he
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
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 MemoryMa
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 W
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 do
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 up-to-date
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 wrote:
> In our previous episode, London Disney said:
>
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
___
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 creat
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 o
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
>
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 w
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 clas
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 can
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
__
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 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 mul
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
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 infor
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 sin
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 p
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
> becaus
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) t
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 don'
> 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 - fpc-devel@lists.free
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 o
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 us
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
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 th
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 Hit
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
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 m
Juha Manninen wrote:
> I hope Lazarus can soon edit parts of one file in many editor tabs.
>
>
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 could e
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 l
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
crea
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 mone
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, differe
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 oth
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++ e
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 a
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 con
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'
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
>
> $ ./mloc
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
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
mlockall:
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?
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
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, 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 realtim
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
>> pr
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 *C
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
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 predefi
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
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, 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
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
abstr
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 every
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
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. Surpr
On 5 Jan 2010, at 22:40, Graeme Geldenhuys
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 Interfaces or raise sha
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 righ
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 cou
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 se
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
http://lists.freepascal.org/mailma
Graeme Geldenhuys schrieb:
> 2010/1/6 Vincent Snijders :
>> 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 tiOP
2010/1/6 Vincent Snijders :
>
> 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 compilers (Delphi and
74 matches
Mail list logo
