Re: [fpc-pascal] make[4]: i386-win32-as: (command not found)

[Sven Barth]

Am 06.12.2010 21:36, schrieb Osvaldo Filho:

make clean all CPU_TARGET=i386 OS_TARGET=win32
make install CPU_TARGET=i386 OS_TARGET=win32
PREFIX=/home/kxu/DevPascal/fpc_inst/fpc_win32 FPC_VERSION=2.4.3

make -C hermes smart
make[3]: Entrando no diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make all LINKSMART=1 CREATESMART=1
make[4]: Entrando no diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
i386-win32-as --32 -o units/i386-win32/mmx_clr.o src/i386/mmx_clr.as

*make[4]: i386-win32-as: Comando não encontrado* (command not found)
make[4]: ** [mmx_clr.o] Erro 127
make[4]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make[3]: ** [fpc_smart] Erro 2
make[3]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make[2]: ** [hermes_smart] Erro 2
make[2]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages'
make[1]: ** [packages_smart] Erro 2
make[1]: Saindo do diretório `/home/deskxu/DevPascal/fpc_inst_scripts/fpc'
make: ** [build-stamp.i386-win32] Erro 2


Sadly, since some time you must install some cross binutils for Win32 if 
you want to compile from Linux. I don't know where to find them though, 
I used the binutils that were compiled by the ReactOS build system some 
time ago.


Maybe you can look for something like "mingw32" in your package repository.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] make[4]: i386-win32-as: (command not found)

[Henry Vermaak]

On 06/12/10 20:36, Osvaldo Filho wrote:

make clean all CPU_TARGET=i386 OS_TARGET=win32
make install CPU_TARGET=i386 OS_TARGET=win32
PREFIX=/home/kxu/DevPascal/fpc_inst/fpc_win32 FPC_VERSION=2.4.3

make -C hermes smart
make[3]: Entrando no diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make all LINKSMART=1 CREATESMART=1
make[4]: Entrando no diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
i386-win32-as --32 -o units/i386-win32/mmx_clr.o src/i386/mmx_clr.as

*make[4]: i386-win32-as: Comando não encontrado* (command not found)
make[4]: ** [mmx_clr.o] Erro 127
make[4]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make[3]: ** [fpc_smart] Erro 2
make[3]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages/hermes'
make[2]: ** [hermes_smart] Erro 2
make[2]: Saindo do diretório
`/home/deskxu/DevPascal/fpc_inst_scripts/fpc/packages'
make[1]: ** [packages_smart] Erro 2
make[1]: Saindo do diretório `/home/deskxu/DevPascal/fpc_inst_scripts/fpc'
make: ** [build-stamp.i386-win32] Erro 2


If you're a debian user, you can install mingw32-binutils package.  You 
will have to pass BINUTILSPREFIX=i586-mingw32msvc- or something like 
that to your make command.


Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Felipe Monteiro de Carvalho]

In Android 2.3 you can write apps without any Java code, but you still
need to build it as a library:

http://developer.android.com/reference/android/app/NativeActivity.html

It seams to support OpenGL and user input without Java.

Still not ideal, however.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Matt Emson]

On 07/12/2010 10:46, Felipe Monteiro de Carvalho wrote:

Still not ideal, however.


Well, no. As Android targets any processor - not just ARM. Indeed, there 
are Intel based versions. Native is bad, and only come in to existence 
to compete with other platforms with purely native compilation - and 
then purely to counteract criticisms on the performance of games and 
multimedia apps. Davlik was created for a reason - compile once, run on 
multiple targets. Would it not be a better solution to create a Dalvik 
back-end? As I understand it, Dalvik is very, far from a traditional 
stack based Java VM and closer to a traditional register based processor 
in design. I know little about it, but the benefits of Android, as a 
platform, are completely lost when one focuses on native compilation.


M
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Felipe Monteiro de Carvalho]

On Tue, Dec 7, 2010 at 12:12 PM, Matt Emson  wrote:
> Well, no. As Android targets any processor - not just ARM. Indeed, there are
> Intel based versions.

I've never seen one and I've already worked with maybe 50 different
Android smartphones / tablets.

x86-Android is negletible. I bet that it has less then 0.1% of the
Android devices market share.

> Native is bad

your opinion. I disagree.

> Would it not be a better solution to create a Dalvik back-end?

1> This would be a huge, very hard task. Who will do it? I don't have
the resources (time / money) to do it. If you have, I'm all for it
that you do it! Good luck!

2> There are no guarantees that Dalvik's bytecode will remain
compatible in the future. Google is being sued over Dalvik and might
even decide to drop it completely as far as we know. If that happens,
you just lost all your work.

3> Existing FPC applications would need to be modified to work in this
FPC port. Think about pointers for example.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Sven Barth]

Am 07.12.2010 12:12, schrieb Matt Emson:

On 07/12/2010 10:46, Felipe Monteiro de Carvalho wrote:

Still not ideal, however.


Well, no. As Android targets any processor - not just ARM. Indeed, there
are Intel based versions. Native is bad, and only come in to existence
to compete with other platforms with purely native compilation - and
then purely to counteract criticisms on the performance of games and
multimedia apps. Davlik was created for a reason - compile once, run on
multiple targets. Would it not be a better solution to create a Dalvik
back-end? As I understand it, Dalvik is very, far from a traditional
stack based Java VM and closer to a traditional register based processor
in design. I know little about it, but the benefits of Android, as a
platform, are completely lost when one focuses on native compilation.


I don't see it that problematic to create a Dalvik code generator (or a 
normal Java or CIL one). The biggest problem is to create a suitable RTL 
and to be able to use the classes that are provided by the VM.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Michael Van Canneyt]

On Tue, 7 Dec 2010, Sven Barth wrote:


Am 07.12.2010 12:12, schrieb Matt Emson:

On 07/12/2010 10:46, Felipe Monteiro de Carvalho wrote:

Still not ideal, however.


Well, no. As Android targets any processor - not just ARM. Indeed, there
are Intel based versions. Native is bad, and only come in to existence
to compete with other platforms with purely native compilation - and
then purely to counteract criticisms on the performance of games and
multimedia apps. Davlik was created for a reason - compile once, run on
multiple targets. Would it not be a better solution to create a Dalvik
back-end? As I understand it, Dalvik is very, far from a traditional
stack based Java VM and closer to a traditional register based processor
in design. I know little about it, but the benefits of Android, as a
platform, are completely lost when one focuses on native compilation.


I don't see it that problematic to create a Dalvik code generator (or a 
normal Java or CIL one). The biggest problem is to create a suitable RTL and 
to be able to use the classes that are provided by the VM.


In fact I think this is one of the more easy things.
The main problem seems to me that you need to support things like pointers,
which is something deeply embedded in Pascal.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

fpc-pascal@lists.freepascal.org

[Amat Coder]

I think the problem is that SVN does not update 'Makefile' and 'Makefile.fpc'.
You need to delete them and you can regenerate them with 'svn update'.
Try it and tell us.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

fpc-pascal@lists.freepascal.org

[José Mejuto]

Hello FPC-Pascal,

Tuesday, December 7, 2010, 3:55:40 PM, you wrote:

AC> I think the problem is that SVN does not update 'Makefile' and 
'Makefile.fpc'.
AC> You need to delete them and you can regenerate them with 'svn update'.
AC> Try it and tell us.

Yes, it works, thank you. I never happends to me in Windows and this
is the first time in Ubuntu :-?

The problem should be that some Makefiles get changed when compiled or
in another case, but the difference does not raise a "unable to merge"
from SVN.

Again, thank you.

-- 
Best regards,
 José

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> > normal Java or CIL one). The biggest problem is to create a suitable RTL 
> > and 
> > to be able to use the classes that are provided by the VM.
> 
> In fact I think this is one of the more easy things.
> The main problem seems to me that you need to support things like pointers,
> which is something deeply embedded in Pascal.

I think the "suitable RTL" is a reference to an earlier discussion about
this subject, where this (pointers) was also said, and that maintaining an
native RTL without pointers was not desirable.  (and just after that is in
the air the guaranteed destructors will start to that, and the systems will
divergate more and more )

IOW, only the compiler frontend is shared, nothing else.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working Free Pascal android JNI example

[Michael Van Canneyt]

On Tue, 7 Dec 2010, Marco van de Voort wrote:


In our previous episode, Michael Van Canneyt said:

normal Java or CIL one). The biggest problem is to create a suitable RTL and
to be able to use the classes that are provided by the VM.


In fact I think this is one of the more easy things.
The main problem seems to me that you need to support things like pointers,
which is something deeply embedded in Pascal.


I think the "suitable RTL" is a reference to an earlier discussion about
this subject, where this (pointers) was also said, and that maintaining an
native RTL without pointers was not desirable.


I think 'RTl' is way too limited in scope. Pointers are used in 
many many pascal sources.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 2D Dynamic arrays and BlockRead

[andrew.bennett]

Marc Weustink  wrote
>On 3-12-2010 17:26, Jürgen Hestermann wrote: 
>> ...
>> STat = Array[0..W-1] Of Single ; { Static array } 
>> DST = Array Of STat ; { One dimension dynamic, the other static } 
>> D2T = Array Of Array Of Single ; { Two dynamic dimensions } 
>> 
>> STat always means the address starting with STat[0] (context independend). 
>> Also DST always means the address where DST[0]. 
> 
>Nope, there is a difference between DST and DST[0]. DST won't give you 
>the first element. You can try this youself with an untyped parameter: 
> 
>procedure Foo(const AParam); 
>begin 
>   WriteLN(Single(APAram)); 
>end; 
> 
> 
>You will see a difference between passing DST or DST[0] 
 
>To be safe, for any N-dimension dynamic array always use [0,..,0]  to 
>pass the first element. To avoid confusion, you can do this for static 
>arrays too. 
 
Thanks. I've now got things working. More or less.

But where do I find any of this in the documentation?
Ref 3.3.1 gives an example of a 2-D dynamic array that
looks just like a static array apart from the difference in
copying: no mention of the dramatic low-level differencess.
But then, these differences are part of the implementation
so perhaps they should be in the Programmers' Manual. They
aren't. The Ref example uses the 2-D form of Setlength which
is not to be found in RTL 37.9.309. Complexities are hinted
at in RTL 37.9.52, DynArraySetLength but I am very happy to
heed the warning not to mess with that!

Ref 3.3.1 states that memory for a dynamic array will be
disposed of at the exit of the procedure or function. Um!

In various places, "dynamic array" becomes "dynamical array"
which messes up searching. Somebody should decide which it is!

Andrew Bennett
 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 2D Dynamic arrays and BlockRead

[Richard Saunders]

On 12/7/2010 12:37 PM, andrew.benn...@ns.sympatico.ca wrote:

In various places, "dynamic array" becomes "dynamical array"
which messes up searching. Somebody should decide which it is!

Dynamical is inappropriate usage in this context. Dynamic is correct.

--
Rich S.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Looking for SDL_opengl header

[Darius Blaszyk]

Has anyone ever converted the SDL_opengl header to FPC? Couldn't find it
in the repository, but perhaps someone knows if it is part of another
project.

Regards, Darius

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Looking for SDL_opengl header

[Andrew Haines]

On 12/07/10 18:23, Darius Blaszyk wrote:
> Has anyone ever converted the SDL_opengl header to FPC? Couldn't find it
> in the repository, but perhaps someone knows if it is part of another
> project.
> 

Is there one included with jedi sdl??

Regards,

Andrew Haines
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal