Hi,

This my test to see if free pascal can be used to compile Delphi Projects.

I have thousands of delphi projects/project files etc... but for this test I simply create a new application and save it to c:\freepascal testen\hello world\version 0.01

I notice how free pascal does not support delphi projects ?

I still open and after running it, free pascal ide says:

project1.dpr(4,8) Fatal: Can't find unit FORMS

This is the source:

program Project1;

uses
Forms,

  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

So much for that.

Now I try to compile a delphi console project.

I again create a new project in delphi and save it as hello console ;)

This time it went as follows:

Euhm maybe this is because I used my free pascal cross compiler which compiles from
windows to linux.... I made that once lol... but still I started the win32 fp ?

Oh well

Here is how it went (still not good ;)):

■ Free Pascal IDE Version 0.9.2
Using "C:\pp2\bin\win32\cygwin1.dll" version 1003.22.0.0 program started
press enter to continue

program finished
CallSignal called
Exception_Continue_Execution set

Here is the source:

program Project1;
{$APPTYPE CONSOLE}
uses
  SysUtils;
begin
  { TODO -oUser -cConsole Main : Insert code here }
  writeln('program started');
  writeln('press enter to continue');
  readln;
  writeln('program finished');
end.

Free Pascal does not seem like an alternative to delphi at first sight.

Free Pascal claims compatiblity with delphi... but I am not seeing it from these very simple quick tests.

I have very little time to spent on free pascal etc... so if I do give free pascal a chance I would like it to have a couple of euhm things:

1. Delphi Project File support.

2. Open Delphi Project File, Press Compile, Press Run and voila ;)

Free Pascal should simply make it happen just like that ;)

I have all delphi source code... like classess.pas and the vcl source... so maybe an installer
can be made for free pascal so that it can find the delphi source code.

Bye,
Skybuck.

Lazarus provides the GUI parts. See http://www.lazarus.freepascal.org

Try the latest 1.9.6 release

A crash of an IDE does not say something about the compatibility of the compiler itself.

Why do you need FPC for that? Delphi can do it

Try Lazarus it provides the VCL replacement units you are looking for.

If you want as much as possible delphi compatibility and a delphi styled environment, use lazarus: www.lazarus.freepascal.org .

Which version did you use? It doesn't seem to be 1.9.6 :)

True, forms is part of lazarus. And it is not 100% compat either, since the .res format is different. (win32 dependancies had to be removed)

This will not even work with Kylix.

What version FPC, what version Windows? Make sure you use 1.9.6, the latest version.

The example program should work, but only if compiled with -Sd or delphi mode enabled in the IDE or lazarus.

Free Pascal does not seem like an alternative to delphi at first sight.

Take a second sight.

Free Pascal claims compatiblity with delphi... but I am not seeing it from these very simple quick tests.

100% compability doesn't exist. It is not even doable in theory, since Delphi is very windows centric.

I have very little time to spent on free pascal etc... so if I do give free pascal a chance I would like it to have a couple of euhm things: 1. Delphi Project File support.

Not possible. .res is a windows only platform. Nothing can be done with it. (conversions are possible though from .dfm files, see lazarus)

2. Open Delphi Project File, Press Compile, Press Run and voila ;) Free Pascal should simply make it happen just like that ;)

Impossible, even in theory.

I have all delphi source code... like classess.pas and the vcl source... so maybe an installer can be made for free pascal so that it can find the delphi source code.

Using Delphi code won't work, its useless anyway, since it is stuffed with assembler and windos routines.

Make sure you have the newest versions, read the manuals, follow the examples. It takes some time to get used to any new environment, even a delphi version.

Open Source requires some effort.

Marco van de Voort wrote

Open Source requires some effort.

Not necessarily more than closed source, although in practice it often does, unfortunately. The issues you mentioned (impossible to make Windows-centric things work seamlessly on all other platforms) have nothing to do with open source, however.

Jonas

Indeed.

The issues you mentioned (impossible to make Windows-centric things work seamlessly on all other platforms) have nothing to do with open source, however.

No, this was more a hint in the direction of the manuals.

I just wondered if there was a package that allowed one to create and manipulate MIDI files easily.

Hi,

Peter H.M. Brooks wrote

I just wondered if there was a package that allowed one to create and manipulate MIDI files easily.

I've wrote a translation of ALSA's library headers to Pascal. It has support for Linux only, and it can be used with Kylix and FPC compilers. It covers all the ALSA API: raw (low level) MIDI devices, high level MIDI sequencer, Control interface (mixer) and PCM digital Audio devices. It's name is ALSAPAS and it is available here:
http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html It is a bit outdated now, specially the PCM part, but MIDI is working well with latest ALSA releases (1.0.x)

If you want to work with MIDI files only, but not to play or record sequences, you can download this file:
http://perso.wanadoo.es/plcl/ametro/ametro-0.4.tar.bz2

Inside the tarball you will find a directory named musicobjects/ and inside it there is a file "smf.pas", a Standard Midi File unit, that allows you to read and write MIDI files. The metronome program itself does not uses this unit, though. This directory is a set of components for Kylix and Lazarus that I would like to distribute some day as a standalone project, if I could find some time to test, to write the documentation and to create the packages.

Regards,
Pedro

Thank you very much for that - it sounds as if it will be very useful!

I'm wanting to do two things actually. One is to write a program that composes think that the above will do that nicely. The other is to work at the rather less tractible problem of converting autio files to MIDI - not truly a soluble problem, but I'm actually interested in taking audio of whistling and converting that to MIDI, not polyphonic stuff.

I'll be working on a Mac.

I've been enjoying looking through these. Your smf.pas unit looks perfect for my requirements - it's nicely put together.

I'm using fpc, not kylix, and I it chokes over the variable length array "fred : array of byte" is illegal in fpc, but presumably fine in Kylix.

Have you got a version that has compiled in fpc? I've tried setting the Delphi compatability switches but it doesn't help. I could set it up as a fixed length array and modify the code where necessary, but, if you do have a version that works with fpc then I'd rather use that!

While I'm asking, I don't suppose that you have a sample program that uses the unit, do you? It isn't, of course, necessary, but it would be nice to see, if you have one.

Peter H.M. Brooks wrote

I'm using fpc, not kylix, and I it chokes over the variable length array "fred : array of byte" is illegal in fpc, but presumably fine in Kylix.

This construct is supported in FPC 1.9.6

Jonas

Hi,

I've uploaded the latests sources (one year old) here: http://perso.wanadoo.es/plcl/alsapas/midiobjects-0.1.tar.bz2 http://perso.wanadoo.es/plcl/alsapas/midiobjects-0.1.tar.gz

You need to use FPC 1.9.4 or later; 1.9.6 should work, as Jonas pointed, because I'm using some features not available in older releases.

There is an example program "spysmf.pas", that shows how to read and dump a MIDI file contents to stdout. To create a MIDI file from scratch is very similar: First create an instance of the component, assign some properties as Division, Number of Tracks, and FileFormat (0 or 1). You should also assign event handlers for the OnWriteTrack (and optionally OnWriteTempoTrack) events. Inside these handlers you should issue calls to the methods WriteMidiEvent, WriteMetaEvent etc.; to start the output, invoke WriteToFile or WriteToStream and the engine shall perform the calls to your supplied handlers. That's all (more or less) ;-)

Regards,
Pedro

Brilliant! Thank you very much....!

Here's a really curious thing!

I've been working to compile smf.pas. I've loaded fpc 1.9.6 on Windows XP and, indeed, it compiles perfectly - later I get errors finding Libc, but that's understandable as it isn't Unix, besides I really want it wo work on the Mac.

So, I've loaded fpc 1.9.6 on my Mac (powerpc, Mac/OS 10.x.x - the latest). When I try to compile it, I get the same error about the byte array, using Xcode. So I tried it with a command line compile:

ppcppc -Sd smf.pas

I get the same problem! This was very peculiar, so I tried:

ppcppc -iV
1.9.6

So I haven't loaded the wrong compiler by mistake.

It looks very much as if the code for the 1.9.6 compiler on Windows/XP and Mac/OS is different - in fact it looks as if the Mac version is an earlier release.

How could this have happened? Should I download the compiler and compile it from scratch, or is it likely that somebody will fix the problem?

Could I have something else wrong?

Have you actually managed to compile this on a Macintosh running the Panther OS?

While on the subject, of compiling the compiler. I have a dual 64-bit CPU on my Mac. Would it be possible to compile the compiler to run in 64bit mode and be multi-threaded - and produce code that is 64bit and multi-threaded? I know that Tiger will provide full 64bit operation (at least that is promised), but, in theory, the compiler should be able to produce 64bit code now. If not, how long before this will be possible? Is it difficult to do?

[Sorry, didn't notice reply-to is set to sender and not the list here]

Skybuck,

thanks for the detailed guide. However, it was simpler than that... with the help from the guys at #fpc, I got
ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/mingwcross.zip

Unzipped that to <install>\cross, then got myself some linux libs needed for the dynamic linker (libc.so.6 and friends) and finally I'm able to cross-compile hello world
C:\pp\demo\text>fpc -Tlinux -FDc:\pp\cross\i686-linux -XPi686-linux- -Xd -Xc -Fl c:\crosskylix\lib hello.pp

This is with dynamic linking of libc as pthreads is going to be used. The resulting binary is a valid dynamic ELF file:

/home/scamp# ldd hello
libc.so.6 => /lib/libc.so.6 (0x2aade000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)

So far so good. Sadly it segfaults:

/home/scamp# strace ./hello
execve("./hello", ["./hello"], [/* 26 vars */]) = 0 --- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Static linked binarys work fine, though. Now I only have to find out why everything dynamically linked crashes.

Simon

The addresses where the shared libs should be loaded, look very strange usually it's 0x40000000+ ?

Yes, I've a feeling mingw crosstools ignore -dynamic-linker=

Hello!

After downloading and unzipping doc-html.zip (11.4M), I found that units/units.html, referenced by fpctoc.html, is missing. Where can I find units documentation?

Thank you,

Anton.

Peter H.M. Brooks wrote

It looks very much as if the code for the 1.9.6 compiler on Windows/XP and Mac/OS is different - in fact it looks as if the Mac version is an earlier release.

They are compiled from the same sources.

How could this have happened? Should I download the compiler and compile it from scratch, or is it likely that somebody will fix the problem?

I will have a look at it.

While on the subject, of compiling the compiler. I have a dual 64-bit CPU on my Mac. Would it be possible to compile the compiler to run in 64bit mode and be multi-threaded - and produce code that is 64bit and multi-threaded?

There is no 64 bit powerpc code generator in the compiler yet. A compiler also does not "produce multi threaded code". There is some research on the topic of automatically turning single threaded code into multi threaded code, but generally I do not know of any production compiler which can automatically turn a generic single threaded program into a multi threaded program.

In the foreseeable future, it's still the programmer which has to explicitly write multi threaded code. This is far from trivial, and as a result writing both highly efficient and 100% multi threaded code is very difficult for all but the most simple examples.

I know that Tiger will provide full 64bit operation (at least that is promised),

No, it's not promised and it won't. No 64 bit versions of the standard GUI libraries will be provided, only of most (command line) generic unix libraries. See http://developer.apple.com/macosx/tiger/64bit.html

but, in theory, the compiler should be able to produce 64bit code now. If not, how long before this will be possible? Is it difficult to do?

I don't know when I will start with it, I'm currently still fixing things for the 32 bit code generator. Also, there are two different 64 bit things you can do: 64 bit mathematics, and 64 bit memory spaces. The former can already be done under Mac OS X 10.3 (but is not supported by our compiler yet either), the latter will only be possible from 10.4 onwards (and initially not for GUI programs, as mentioned above).

Jonas

Without output we can't say anything.

80% of the compiler is platform independent. Only the codegenerator and assembler parser and writers are CPU dependent.

A 64-bit PowerPC codegenerator needs to be written first. The compiler itself is already 64-bit ready.

Multithreaded compiler is not usefull. It'll the compiler very complex and less maintainable. Also the benefit is very small because of all the dependencies.

----- Original Message -----

it's in rtl/index.html. The fptoc.html is outdated. This is meanwhile fixed, but not on the FTP site.

Michael.

There is also the issue of optimizing 32-bit code for the G5 (powerpc
970) processor. Interesting to read is
<http://developer.apple.com/hardware/ve/g5.html>.

Regards,

Adriaan van Os

I've no idea about how to compile it under Mac, but it seems strange to me the Libc dependency, because this unit and the example program doesn't need Libc under Linux. ldd says "not a dynamic executable".

BTW, you can find here a new version:
http://perso.wanadoo.es/plcl/alsapas/midiobjects-0.2.tar.gz http://perso.wanadoo.es/plcl/alsapas/midiobjects-0.2.tar.bz2

I've added one more example program, "buildsmf.pas", that creates a MIDI file from scratch, and also fixed several bugs. The ALSA examples still don't run with FPC, because some thread troubles.

Regards,
Pedro

smf compiles fine under freeBSD.

Alsapas has a unit libc dependancy. Most symbols used seem to be simple types that are named slightly differently, but the piping functions use libc stdio, which is not defined platform independant for FPC. (since FPC's stdio doesn't go through libc).

If you don't really use

inputh.inc:function snd_input_stdio_attach(var inputp:Psnd_input_t; fp:PIOFILE; _close:longint):longint;cdecl;external asoundlib_name;
outputh.inc:function snd_output_stdio_attach(var outputp:Psnd_output_t; fp:PIOFILE; _close:longint):longint;cdecl;external asoundlib_name;

then it could be made to compile with FPC without using unit libc I thik.

I've added one more example program, "buildsmf.pas", that creates a MIDI file from scratch, and also fixed several bugs. The ALSA examples still don't run with FPC, because some thread troubles.

buildsmf compiles and generates a 90 byte midifile (under FreeBSD). spysmf also compiles. Rest uses ALSA, and doesn't.

Thank you! I've sorted out the problems that I had. I now have a clean install on the Mac and it compiles well. I'm not working to get my interface up to speed...

Marco van de Voort wrote

smf compiles fine under freeBSD.

Thanks for testing.

Those functions are seldom used, but are part of the ALSA library API. And the main goal for ALSAPAS is to give full support of the ALSA library API.

Besides inputh.inc and outputh.inc, there are more places where Libc is used. See the pollfd references in rawmidih.inc, or timeval/timespec in globalh.inc

But even if you could take away all of them, I don't understand why to do so. I mean that ALSA is very Linux specific and it is not possible to use ALSA in xBSD, MacOS, Solaris or Win32, so there is not a need to use ALSAPAS outside a Linux box. And the ALSA userspace library, libasound.so, depends on Libc anyway (and libm, libdl, libpthread...).

OK. Thanks again. I have successfully tested the unit "smf" and the two programs buildsmf and spysmf in Win32 today. They should work in any environment supported by FPC. The resulting file "test.mid" is 90 bytes length, and has a single track with 8 notes, playing a simple C-Major scale. The other program should give this output on that file:

$ ./spysmf test.mid
0 -- SMF Header Format=0, Tracks=1, Division=120 0 -- Track Start
0 0 Note On 60 120
60 0 Note Off 60 120
60 0 Note On 62 120
120 0 Note Off 62 120
120 0 Note On 64 120
180 0 Note Off 64 120
180 0 Note On 65 120
240 0 Note Off 65 120
240 0 Note On 67 120
300 0 Note Off 67 120
300 0 Note On 69 120
360 0 Note Off 69 120
360 0 Note On 71 120
420 0 Note Off 71 120
420 0 Note On 72 120
480 0 Note Off 72 120
480 -- Meta Event End Of Track
480 -- Track End

As I have said, the programs involving ALSA are Linux only, but if there is some interest on that, I can prepare and distribute a separated package with the SMF related files only.

Regards,
Pedro

Use Lazarus. FPC itself doesn't even distribute the Visual Components so 90% of the Delphi projects can't even be used without Lazarus.

Hi,

I have downloaded FPC 2.0.0 for ARM and installed. I have compiling a project in pascal with socket.
To compile the program I need to use Xc switch ("pass --shared to the linker (Unix only)").
but when I run the executable program I receive a segmentation fault!

If I don't use Xc switch I have problem in link stage: ------------------------------------------------------------------------ ------------------
/usr/local/lib/fpc/2.0.0/units/arm-linux/rtl/cprt0.o(.text+0x64): In function `_haltproc':
: undefined reference to `_fini'
/usr/local/lib/fpc/2.0.0/units/arm-linux/rtl/cprt0.o(.text+0x6c): In function `_haltproc':
: undefined reference to `_init'
------------------------------------------------------------------------ ------------------

I'm crosscompiling the program host x86 target arm.

What is the problem with _fini and _init? (I suppose is due that libc is dynamic library?)
But If I use Xc ("pass --shared") I receive a segmentation fault. Using gdb I receive

------------------------------------------------------------------------ ------------------
Program received signal SIGSEGV, Segmentation fault. 0x2a042c2c in _start ()
------------------------------------------------------------------------ ------------------

It seems like linker has link my program with libc in a wrong way?

tia!

best regards