Re: [fpc-pascal] fpc isn't optimised for tail recursion, is it?

[Michalis Kamburelis via fpc-pascal]

Steve,

If you're looking for equivalent to "return X", use "Exit" with a
parameter in Pascal: "Exit(X)".

It's just a shortcut for "Result := X; Exit;"

Regards,
Michalis

pon., 12 cze 2023 o 19:57 Steve Litt via fpc-pascal
 napisał(a):
>
> Nikolay Nikolov via fpc-pascal said on Mon, 12 Jun 2023 09:15:17 +0300
>
> >On 6/12/23 04:44, Steve Litt via fpc-pascal wrote:
>
> [snip]
>
> >> So, subject to your guidance, I'm assuming FPC isn't optimized for
> >> tail recursion. Is my assumption an accurate one?
> >
> >FPC supports tail recursion optimization, it is enabled at -O2
> >optimization level for most CPUs, however your code isn't eligible for
> >that optimization, because there's extra code, after the recursive
> >invoke. If you change it like that:
> >
> >program recursion_hello;
> >
> >function nextt(num: int64): int64;
> >begin
> >writeln('Going deeper=>   ', num);
> >nextt := num;
> >if (num > 0) then
> >   begin
> >   nextt(num - 1);
> >   end;
> >end;
> >
> >begin
> >   nextt(10);
> >end.
> >
> >And if you compile with -O2 it works, without segfaulting (tested with
> >FPC 3.2.2 on x86_64-linux).
>
> Thanks Nickolay,
>
> You're right about not assigning nextt below the call to nextt, and
> about the -O2 argument. After learning from you about -O2 and
> investigating further, I used {$OPTIMIZE tailrec}, which isn't quite the
> same thing, but it worked beautifully. {$OPTIMIZE on} also enables tail
> recursion and speeds things up about 10% of tailrec.
>
> Thanks for your help.
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What is -CO ?

[Michalis Kamburelis via fpc-pascal]

I'm also curious :)

I just tested, and the -Co (lowercase "o") enables overflow checking
by default (like "{$Q+}" in code),
https://github.com/michaliskambi/modern-pascal-introduction/wiki/What-are-range-and-overflow-checks-(and-errors)-in-Pascal
.

But -CO (uppercase "O") seems unrelated to it.

This example:

"""
{$mode objfpc}
uses SysUtils;
var
  A: Int64;
begin
  A := High(Int64) - 100;
  A := A + 200;
  Writeln('Result is ', A);
end.
"""

... behaves the same, regardless if it's compiled with "-CO" or not.
(Only "-Co" is relevant, controls do we make overflow check, as
expected.)

Regards,
Michalis

pt., 9 cze 2023 o 12:03 Mattias Gaertner via fpc-pascal
 napisał(a):
>
> Hi,
>
> What is -CO?
>
> In the docs I can only find this sentence:
> "Check for possible overflow of integer operations"
>
>
> Mattias
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Programming Pascal using an AI Chatbot

[Michalis Kamburelis via fpc-pascal]

The chatbot is quite amazing :) I wrote about my nicest moments on
https://castle-engine.io/wp/2022/12/17/my-mind-is-blown-i-can-use-ai-to-generate-castle-game-engine-code-to-integrate-it-with-physx-i-can-use-ai-to-generate-html-documentation-from-comments-in-pascal-code/
-- generate Pascal code to integrate Castle Game Engine + PhysX, or
perform the job of PasDoc. It can do that :)

Regards,
Michalis

niedz., 1 sty 2023 o 00:44 Anthony Walter via fpc-pascal
 napisał(a):
>
> The following page hosts a series of Pascal programming questions I asked an 
> AI chatbot system while testing its abilities.
>
> https://www.getlazarus.org/aichatbot
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Strange "division by zero" error using variants

[Michalis Kamburelis via fpc-pascal]

That's a funny interaction between Variants and Pascal's ambiguous
(logical or bitwise) "and" :) Both the operators and the types are
ambiguous -> making the boolean short-circuit evaluation not possible.

Indeed one workaround is to cast the variants to Booleans explicitly,
which makes it use logical "and" with expected result. I.e. this
doesn't raise "division by zero":

if Boolean(v1) and Boolean(v2 > 0) and Boolean((0+1) mod v2 = 0) then
Writeln ('ok');

Regards,
Michalis

wt., 24 maj 2022 o 22:52 Florian Klämpfl via fpc-pascal
 napisał(a):
>
> Am 24.05.22 um 19:28 schrieb Thomas Kurz via fpc-pascal:
> > Dear all,
> >
> > please consider the following code:
> >
> >
> > program Project1;
> >
> > {$booleval off}
> >
> > var
> >v1, v2: variant;
> >a: boolean;
> >b: integer;
> >
> > begin
> >a := true;
> >b := 0;
> >// this works as expected:
> >if a and (b > 0) and ((0+1) mod b = 0) then Writeln ('ok');
> >
> >v1 := true;
> >v2 := 0;
> >// this gives a "division by zero":
> >if v1 and (v2 > 0) and ((0+1) mod v2 = 0) then Writeln ('ok');
> > end.
> >
> >
> > The "variant" variant results in a "division by zero". Obviously, it tries 
> > to evaluate the modulo-expression even though this shouldn't happen because 
> > complete boolean evaluation is disabled and the "if"-result is already 
> > known to be false after checking "v2>0".
> >
> > Can anyone explain this strange behavior?
>
> When compiling the and expressions, the compiler does not know (in this
> example it could, but in general it cannot) what the variants contain so
> just the variant and-operator is executed which does not/cannot
> distinguish between the logical and bitwise and variant.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 3.2.0 released!

[Michalis Kamburelis via fpc-pascal]

Great news! Thank you to the FPC team for all magnificent work.

I maintain Docker images with FPC (with various versions and
cross-compilers, with Castle Game Engine and some related tools), see
https://hub.docker.com/r/kambi/castle-engine-cloud-builds-tools/ and
https://github.com/castle-engine/castle-engine/wiki/Docker . I just updated
them to contain FPC 3.2.0 (and use it by default, as "latest stable
release").

Regards,
Michalis

sob., 20 cze 2020 o 23:59 Tomas Hajny  napisał(a):

> On 2020-06-20 19:47, code dz via fpc-pascal wrote:
> > great .
> > but why fpc-3.2.0.i386-win32.exe in the ftp site is different in size
> > and date than sourceforge one
>
> They have the same size, it's just the SF webpage shows the size
> differently from the FTP listing:
>
> [SF.net]$ ls -l /home/frs/project/freepascal/Win32/3.2.0
> total 379964
> [permissions and ownership hidden]  99388066 Jun 16 00:15
> fpc-3.2.0.i386-win32.cross.android.exe
> [permissions and ownership hidden]  27577540 Jun 16 00:15
> fpc-3.2.0.i386-win32.cross.arm-wince.exe
> [permissions and ownership hidden] 168171805 Jun 16 20:03
> fpc-3.2.0.i386-win32.cross.i8086-msdos.exe
> [permissions and ownership hidden]  40791180 Jun 16 00:16
> fpc-3.2.0.i386-win32.cross.x86_64-win64.exe
> [permissions and ownership hidden]  53136366 Jun 16 00:16
> fpc-3.2.0.i386-win32.exe
> [permissions and ownership hidden] 16097 Jun 16 21:00 readme.txt
>
>
> [FTP site]$ ls -l ftp/dist/3.2.0/i386-win32
> total 379956
> [permissions and ownership hidden]  99388066 Jun  5 12:43
> fpc-3.2.0.i386-win32.cross.android.exe
> [permissions and ownership hidden]  27577540 Jun  4 11:08
> fpc-3.2.0.i386-win32.cross.arm-wince.exe
> [permissions and ownership hidden] 168171805 Jun  7 08:09
> fpc-3.2.0.i386-win32.cross.i8086-msdos.exe
> [permissions and ownership hidden]  40791180 Jun  4 10:51
> fpc-3.2.0.i386-win32.cross.x86_64-win64.exe
> [permissions and ownership hidden]  53136366 Jun  4 10:42
> fpc-3.2.0.i386-win32.exe
>
>
> The dates differ because I didn't pay attention to use the -p parameter
> while uploading the files ( :/ ), thus the date and time on SourceForge
> reflect the time when the files were transferred there. BTW, the date
> and time of files on the FTP site have no special meaning either (it
> could be the time of uploading the files to the main FTP server, or the
> time when the packages were prepared, or the time when they were updated
> the last time (sometimes there may have been last minute fixes of e.g. a
> certain source files or a readme file, etc.), or whatever.
>
> Tomas
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Using docker to build software

[Michalis Kamburelis]

Torsten Bonde Christiansen  wrote:

> Hi List.
>
> I am curious to know if there is someone out there that have tried to
> use Docker (https://www.docker.com) containers to build fpc applications?
>
> I have 3 applications in a suite that I am thinking of experimenting
> with, see if I can create an image containing eg. Ubuntu linux, FPC,
> Lazarus and dependencies.
>
> But if you have tried this before success or not, I would be glad to
> share thoughts and designs before I embark on my adventure.
>
>
We provide a Docker image as one option of compilation for Castle Game
Engine applications (it contains FPC with some cross-compilers, Lazarus,
CGE build tool, Android tools etc. ready). See
https://github.com/castle-engine/castle-engine/wiki/Docker and
https://hub.docker.com/r/kambi/castle-engine-cloud-builds-tools/ .

Best regards,
Michalis

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

Re: [fpc-pascal] TFPGObjectList error

[Michalis Kamburelis]

Ryan Joseph  wrote:

>
> > Or you could use Generics.Collections unit with generic TList for
> > records. It by default compares records by comparing memory contents.
>
> Is that part of the RTL and if so what’s the unit name? I had a hard time
> finding good resources on classes the RTL provides.
>

It is part of FPC 3.1.1, and the unit name is "Generics.Collections". For
FPC 3.0.x you can take them from Maciej Izak's original repo
https://github.com/maciej-izak/generics.collections .

Some examples of basic usage are in my
https://castle-engine.io/modern_pascal_introduction.html#generic-containers-section
. Also Delphi docs are quite useful since the API is deliberately
compatible:
http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Generics.Collections
.

Regards,
Michalis

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

Re: [fpc-pascal] TFPGObjectList error

[Michalis Kamburelis]

 2018-07-01 4:01 GMT+02:00 Vojtěch Čihák :
> this seems to be misleading error message. TFPGObjectList works well for
> objects (classes). When I tried to push record to it, I got the same error
> message. TVec3 is not class, right?

Indeed, it's a misleading message. The message

   ...identifier idents no member "Free"

doesn't talk about the line

list.Free;

(which is fine, "list" is an instance of a class). It talks most
likely about the "Free" call inside FGL implementation in

"""
procedure TFPGObjectList.Deref(Item: Pointer);
begin
  if FFreeObjects then
T(Item^).Free;
end;
"""

If you look inside the FGL unit sources of your FPC version, you will
likely find this to be at line 992 :)

Short explanation:Since your TVec3 is probably not a class, you cannot
do "Free" on it.

The solution is to use TFPGList instead of TFPGObjectList. You should
also define an equality operator if TVec3 is a record. See e.g. my
example in 
https://castle-engine.io/modern_pascal_introduction.html#_operator_overloading
(scroll to the example with TMyRecordList).

Or you could use Generics.Collections unit with generic TList for
records. It by default compares records by comparing memory contents.

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

Re: [fpc-pascal] FPC on gaming consoles: XBox One, PlayStation 4, Nintendo Switch

[Michalis Kamburelis]

2018-05-10 4:08 GMT+02:00 Marco van de Voort <mar...@stack.nl>:
> In our previous episode, Michalis Kamburelis said:
>>
>> 1. XBox One. It uses an operating system based on Windows 10. As such,
>> maybe compiling FPC programs for it is already possible (or is easy to
>> add)? Maybe I can even just run a normal Windows exe on XBox One?
>
> As far as I know Xbox One uses UWP/WinRT binaries, so the same format as
> Windows "apps".
>

Aha, so it would be a new target for FPC, right?

Do I understand correctly that at least UWP/WinRT is normally
documented by MS, and implementing it in FPC just waits for a
contributor who has time to do it? There are no legal hurdles around
it?

Thank you everyone for the answers. Keep them coming:)

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

Re: [fpc-pascal] FPC on gaming consoles: XBox One, PlayStation 4, Nintendo Switch

[Michalis Kamburelis]

2018-05-10 4:05 GMT+02:00 Dmitry Boyarintsev <skalogryz.li...@gmail.com>:
> On Wed, May 9, 2018 at 9:38 PM, Michalis Kamburelis
> <michalis.ka...@gmail.com> wrote:
>>
>> This would mean that it is impossible to openly distribute an open-source
>> code interfacing with e.g. PlayStation custom OS. Precluding open-source
>> support from both FPC and Castle Game Engine for the consoles. Any code that
>> uses some API covered by NDA must be closed-source, can be available only to
>> people who also signed the NDA.
>
>
> Not sure how much of impact it is for a game engine and/or FPC as is.
> Unity engine is capable of compiling for PS4. Yet it's distributed freely.
>
> Sure, it's a closed-source, but it doesn't mean that an open-source project
> couldn't support the closed-source system.

The issue is that some console libraries (like PS4 GNMX, their
rendering API) are not only closed-source. They are also covered by
NDAs that prevent you from openly discussing their API. That is my
understanding, from reading the
https://www.ogre3d.org/2006/01/08/official-support-for-game-consoles ,
confirmed explicitly by https://www.gamedev.net/forums/topic/666961-x/
, and the fact that you cannot find *any* documentation or examples
about GNMX on the Internet.

This means that you cannot write open-source code (and distribute it
publicly) that talks with GNMX. Such code must be kept secret, and
distributed only to other PlayStation devs who signed the Sony's NDA.

Which is not a show-stopper... but it's a real hindrance. I can still
write Castle Game Engine renderer targeting GNMX. But this renderer
can only be shown to other PlayStations devs who signed the NDA. I
cannot just place it in Castle Game Engine repository on GitHub.

Moreover: The developers using C or C++ get a working compiler from
Sony, once they sign the NDAs. So they don't worry about interacting
with Orbis OS (for stuff like reading files etc.) and generating code
for the appropriate CPU. However, we cannot hope that Sony provides a
working Pascal compiler tailored to work under PS4 operating system.
We can only speculate that hopefully it remains compatible with
FreeBSD (from which it was forked), and that FPC support for FreeBSD
will work (or will only require minimal modifications).

> It just requires some company with the business interest in it.
>
> The first step to be done is to have a big game product at the market,
> compiled with FPC.

I have such company. And we are working on such game :)
https://store.steampowered.com/app/746750/The_Unholy_Society/

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

Re: [fpc-pascal] FPC on gaming consoles: XBox One, PlayStation 4, Nintendo Switch

[Michalis Kamburelis]

The more I was reading about console development, the more I understood
that the main problem are NDAs that seem to still "guard" the information
about each consoles closed APIs.

This would mean that it is impossible to openly distribute an open-source
code interfacing with e.g. PlayStation custom OS. Precluding open-source
support from both FPC and Castle Game Engine for the consoles. Any code
that uses some API covered by NDA must be closed-source, can be available
only to people who also signed the NDA.

I do not know are the NDAs so drastic for all the modern consoles too (Xbox
One, PlayStation 4, Nintendo Switch). Xbox One seems to be more open, with
things like Universal Windows Platform openly documented.

Ogre3d was facing a similar problem, see
https://www.ogre3d.org/2006/01/08/official-support-for-game-consoles
. That said, that post is from 2006, I'm hoping that things are better in
2018:)

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

[fpc-pascal] FPC on gaming consoles: XBox One, PlayStation 4, Nintendo Switch

[Michalis Kamburelis]

Hi,

I am wondering about the possibility to port Castle Game Engine to
modern gaming consoles.

Summary (TL;DR):

- Is it possible to use FPC to compile programs/libraries for one of
the gaming consoles mentioned in the subject?

- If it is not possible *yet*, how easy it would be to add such
support to FPC? (Note: We *could* sponsor such work.)

Details: (And apologies for writing such long email.)

From what I read, the modern consoles feature more "normal" hardware
and APIs, contrary to the past consoles that had incredibly
specialized stuff (like PlayStation 3 with Cell).

Note that I'm thinking here about working with the standard OS
available on the console, and distributing the game through the
standard shop available on each console. So I'm not interested in
solutions like installing Linux on a PlayStation 4.

Bear in mind that I do not have any personal experience developing on
these consoles. I'm mostly a desktop gamer/developer :) So I'm just
gathering knowledge now. Any information is appreciated.

Finally, if the answer to one of these platforms is like "it is
possible, but it requires ~2 months of serious work", please tell me
so (in public or private). We are in the business of making games
using Castle Game Engine and FPC, and as such we may be able to pay
the developer willing to port FPC to one of the console platforms. We
are talking now with a 3rd party that could provide the funds --
things are not settled yet, but we keep our fingers crossed :)

The gaming console platforms I'm interested in:

1. XBox One. It uses an operating system based on Windows 10. As such,
maybe compiling FPC programs for it is already possible (or is easy to
add)? Maybe I can even just run a normal Windows exe on XBox One?

From what I read, all XBox versions use Direct X for rendering, so
porting CGE to XBox would require adding a Direct 3D renderer. But
that is very doable on my side, so I don't worry about it :) And in
the meantime, we could use ANGLE (a library that provides OpenGLES
API, using Direct X internally), thus we can render using OpenGLES on
XBox One even today.

See wikipedia: https://en.wikipedia.org/wiki/Xbox_One ,
https://en.wikipedia.org/wiki/Xbox_One_system_software

2. PlayStation 4 has it's special OS (Orbis OS, based on FreeBSD 9). I
don't know how close it is to normal FreeBSD supported by FPC.

It's main graphics API is GNMX, which is "mostly like Direct X
11". So, again, I don't worry.

See wikipedia: https://en.wikipedia.org/wiki/PlayStation_4 ,
https://en.wikipedia.org/wiki/PlayStation_4_system_software

As for CPU: From what I read, both XBox One and PlayStation 4 use
https://en.wikipedia.org/wiki/Jaguar_(microarchitecture) , which has
instruction set like AMD64 (x86-64). Am I right assuming that, as far
as FPC is concerned, this is just a normal x86_64 CPU?

3. Nintendo Switch.

CPU: Octa-core (4×ARM Cortex-A57 & 4×ARM Cortex-A53),
microarchitecture ARMv8-A. Does it mean it is the same instruction set
as existing 64-bit ARM CPU, uses e.g. by 64-bit iOS? It is called
"aarch64" by FPC.

OS is custom. I have not found much information about it. The
"syscalls look similar to Nintendo 3DS", it seems,

The graphics API: Nintendo Switch seems to include support for
OpenGL, OpenGL ES and even Vulkan (
https://wccftech.com/nintendo-switch-supports-vulkan/ ), which is very
cool. In addition to their custom API NVN. So Castle Game Engine could
just use modern OpenGL renderer on it.

See wikipedia: https://en.wikipedia.org/wiki/Nintendo_Switch ,
https://en.wikipedia.org/wiki/Nintendo_Switch_system_software .

Thanks for all the answers.
Regards,
Michalis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] pas2js Webgl unit committed

[Michalis Kamburelis]

Ryan Joseph  wrote:

>
>
> > On May 1, 2018, at 9:56 PM, Michael Van Canneyt 
> wrote:
> >
> > You must do
> >  gl := TJSWebGLRenderingContext(canvas.getContext('webgl'));
> >
> > because getContext can return various classes depending on the argument.
>
> Ok so getContext is method of TJSElement I guess.
>
> Btw I’ve been reading and I don’t see WebGL examples using interlaced
> vertex data like I suggested in my record question. Rather they all seem to
> be using different buffer objects for each type of vertex attribute
> (position, color, texture coord etc…).
>
> Can anyone confirm WebGL just doesn’t support this? OpenGL heavily relies
> on the idea of pointers with byte offsets but perhaps JavaScript just can’t
> support that so they opted for 0-offset single type arrays in all cases.
> That would be too bad though since it makes laying out data more difficult.
>

WebGL supports interleaved data, see e.g.
http://learnwebgl.brown37.net/rendering/interleaved_buffers.html .

In general, WebGL is capable of rendering e.g. glTF 2, which allows to use
interleaved data in various configurations, PBR etc. So it's quite
powerful:)

Many thanks for the WebGL unit! (I will play with it once I catch some
breath at other work :) ).

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

Re: [fpc-pascal] Next language feature for pas2js...

[Michalis Kamburelis]

2018-05-01 4:50 GMT+02:00 Ryan Joseph :
>
>
>> On Apr 25, 2018, at 9:43 PM, Michael Van Canneyt  
>> wrote:
>>
>> Ah, webgl...
>>
>> I had a look at this some time ago, and got depressed. Quickly closed the 
>> browser and didn't look back. Same for webaudio :(

The API of WebGL is actually mostly a subset of OpenGLES which is a
subset of OpenGL. WebGL is quite small, if you compare it to other
graphic APIs :) OpenGL(ES), Direct3D, Vulkan, Metal are way more
complicated and larger.

>
> I’m actually a little curious about this myself because I’ve been using 
> OpenGL often recently. I’ve seen the Ingemar’s demos but I only slightly 
> grasp how it’s working.
>
> The wiki says you’re actually parsing the Pascal (not compiling it) and 
> outputting JavaScript. If that’s the case then how does porting libraries 
> work in practice? For examples lets say I want to translate a single OpenGL 
> function, how does that look?
>

I suspect that we will have a unit like WebGL in pas2js that exposes
the necessary JS functions for Pascal applications. Engine like Castle
Game Engine will used this unit when compiled with pas2js (instead of
GL when compiled with FPC for desktop, or GLES20 when compiled with
FPC for mobile). And then CGE can expose an API that looks the same
(both in pas2js and FPC).

(Yes, I want to port Castle Game Engine one day to pas2js :) )

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

Re: [fpc-pascal] Read comments via fcl-passrc

[Michalis Kamburelis]

Michael Van Canneyt  wrote:

>
>
> On Mon, 23 Apr 2018, Michael Fuchs wrote:
>
> > Am 23.04.2018 um 12:43 schrieb Mattias Gaertner:
> >>> I found TPasTreeContainer.NeedComments but it does nothing.
> >>
> >> Set that to true. Then create the parser.
> >
> > Ok, so I can not use the function ParseSource from unit PParser anymore
> > and have to write my own one?
> >
> >> Read Parser.SavedComments on every CreateElement.
> >
> > Can I save the comments in the DocComment property of every element or
> > is this used somewhere else?
>
> It's normally not used; The idea is to use this in a pasdoc->fpdoc
> converter.
>

Or the PasDoc inplementation itself :) I want to one day migrate PasDoc
code to just use fcl-passrc parser. Currently PasDoc uses custom parser,
that reads only interface.

Thanks for making this available.

Regards,
Michalis

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

Re: [fpc-pascal] Managed properties idea

[Michalis Kamburelis]

2017-10-06 23:55 GMT+02:00 Maciej Izak :
> ... and here is library with exclusive usage of "management operators" for
> FPC:
>
> https://github.com/pda0/AutoScope
>
> ... and here is experimental smart pointers/objects/nullable types
> implementation:
>
> https://github.com/maciej-izak/PascalSmartPointers
>

Oooh this is perfect, thank you for this. And I do mean both projects.

I see that AutoScope (
https://github.com/pda0/AutoScope/blob/master/AutoScope.pas ) is using
management operators in new FPC, or internal COM interface (FGuardian)
in older FPC or Delphi. Although AutoScope only "frees when outside of
scope", it doesn't try to implement a full equivalent of a shared
pointer. So if you store the instance of your object (like
TSomeObject1 mentioned in https://github.com/pda0/AutoScope example)
in some global variable / field, then you can end up with having an
invalid reference (pointing to already-freed object). Unless you also
store the relevant TScope instance in the same scope.

Your TSmartObj is, well, exactly what I want:) As long as you pass
around only "TSmartObj" (and don't create cycles :) ),
you're perfectly safe and leak-free.

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

Re: [fpc-pascal] Managed properties idea

[Michalis Kamburelis]

2017-10-06 21:49 GMT+02:00 Michalis Kamburelis <michalis.ka...@gmail.com>:
> 2017-10-06 20:52 GMT+02:00 Marcos Douglas B. Santos <m...@delfire.net>:
> [...]
>>> In this case, in which you indeed want two of these features simultaneously,
>>> I advise COM interfaces myself :) That's why they are documented after all.
>>
>> I can use it only to use reference counting.
>
> You can, but it's a little uncomfortable.
>
> If you use interfaces only for reference counting (not to share the
> API between some unrelated classes), then you define a single
> interface for each single class, repeating the same API -- methods,
> properties. It's possible, but it's just a lot of work. I have a lot
> of classes in my engine, and FPC RTL, FCL, Lazarus LCL define many
> more classes --- wrapping them all in an equivalent interface, only to
> get reference-counting for them, would imply a lot of work and
> constant maintenance.
>
> In contrast, something like C++ "shared pointer" is a feature that can
> be applied to any existing class, without the need to repeat it's API.
> See e.g. https://en.wikipedia.org/wiki/Smart_pointer . And once we
> have management operators (see Sven's pointers), we can implement
> something like this in Pascal. So you could use something like
> "TSharedPointer" and you get a reference-counted instance
> of TStringList.
>

P.S. It's possible to implement "shared pointers" using
reference-counted COM interfaces, too, without memory management
operators. You'd have something like "ISharedPointer",
and then it's comfortable too (no need to duplicate TStringList API).
So I'm not trying to say that management operators are the only way to
get something like "shared pointer".

The point of my text (on
http://castle-engine.io/modern_pascal_introduction.html#_corba_and_com_types_of_interfaces
) was that if you look for a feature that gives you ability to share
API between classes (and nothing else), then you want CORBA
interfaces. They are equivalent to "interface concept" from Java and
C#.

I feel that separation (one optional feature gives you
reference-counting, some other optional feature gives you ability to
share API between classes and requires to repeat this API) would be
better :)

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

Re: [fpc-pascal] Managed properties idea

[Michalis Kamburelis]

2017-10-06 20:52 GMT+02:00 Marcos Douglas B. Santos :
[...]
>> In this case, in which you indeed want two of these features simultaneously,
>> I advise COM interfaces myself :) That's why they are documented after all.
>
> I can use it only to use reference counting.

You can, but it's a little uncomfortable.

If you use interfaces only for reference counting (not to share the
API between some unrelated classes), then you define a single
interface for each single class, repeating the same API -- methods,
properties. It's possible, but it's just a lot of work. I have a lot
of classes in my engine, and FPC RTL, FCL, Lazarus LCL define many
more classes --- wrapping them all in an equivalent interface, only to
get reference-counting for them, would imply a lot of work and
constant maintenance.

In contrast, something like C++ "shared pointer" is a feature that can
be applied to any existing class, without the need to repeat it's API.
See e.g. https://en.wikipedia.org/wiki/Smart_pointer . And once we
have management operators (see Sven's pointers), we can implement
something like this in Pascal. So you could use something like
"TSharedPointer" and you get a reference-counted instance
of TStringList.

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

Re: [fpc-pascal] Managed properties idea

[Michalis Kamburelis]

05.10.2017 2:07 PM "Marcos Douglas B. Santos"  napisał(a):

On Thu, Oct 5, 2017 at 5:55 AM, Ryan Joseph 
wrote:
>
>> On Oct 5, 2017, at 12:28 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>>
>> The way to go in Object Pascal are reference counted interfaces (aka
COM-style interfaces). After all one should program against an interface
anyway and that reference counted interfaces are automatically handled by
the compiler is an added bonus.
>>
>>
>
> example? I’ve been doing retain management manually and honestly I prefer
that for some cases where I want more control so I still like that syntax
option.
>

As Sven told you, just use COM Interfaces.
Look this explanation ->
http://castle-engine.io/modern_pascal_introduction.
html#_corba_and_com_types_of_interfaces
but don't pay attention when to author says "Ugly (COM) interfaces"
because it is not. :)

Really, it is not.


I hope I explained there why I consider the COM design "ugly": because it
puts three often-unrelated features (reference counting, and ability for
multiple classes to expose same API safely, and interaction with COM
technology) in one bag.

In this case, in which you indeed want two of these features
simultaneously, I advise COM interfaces myself :) That's why they are
documented after all.

In general, I would prefer these features to be available separately. Like
other languages do: interfaces in Java and C# are only to "expose same API
from multiple classes" (granted, comparison is unjust as Java and C# just
have garbage collection) -- in Pascal you get this by CORBA interfaces. And
reference counting like in e.g. C++ "shared  pointers", that can wrap any
class, without any additional feature (in Pascal we may get this with
"management operators").

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

[fpc-pascal] Castle Game Engine 6.0 released

[Michalis Kamburelis]

Hi,

We're proud to release Castle Game Engine 6.0, an open-source 3D and
2D game engine for Object Pascal.

This release is a culmination of more than a year of intensive engine
development. The main feature is that almost every part of the engine
got significant improvement, and we have more "new features" than you
probably care to read about:)

You can download the engine, and read the documentation, from

  https://castle-engine.sourceforge.io/

The release annoucement, with more complete list of changes, is on

  
https://castle-engine.sourceforge.io/wp/2017/02/18/castle-game-engine-6-0-release/

Some highlights of the new features:

- New user interface features: auto-scaling, parents, anchors, many
new components and properties,

- New build tool features: automatic generation and usage of
GPU-compressed and downscaled textures, --mode=valgrind,

- A large number of "Android package components", that provide an
integration with various 3rd party Android libraries on Android
(Google Play Games, In-app Purchases, sound libraries, ad networks,
analytics, vibrations...),

- New castle-anim-frames format, with a Blender exporter, to export
*any* animations from Blender to our engine (armature, shape keys,
baking physics simulations, ).

Also, the website, and the manual on
https://castle-engine.sourceforge.io/manual_intro.php, received a lot
of additions and changes.

Last but not least, I wanted to mention our new Patreon page. You can
support the engine development and get some real rewards --- I'm
devoting a weekend per month exclusively to the features requested by
Patrons, you can get access to the "cloud build server" (continous
integration) for your game projects, and I will have a 24h gamejam
every month making a demo game requested by Patrons. Please check out
our Patreon page on:

  https://www.patreon.com/castleengine

P.S. Everything compiles with the today's announced FPC version 3.0.2
(and other FPC versions too) of course. Congratulations to the FPC
team!

Best regards,
Michalis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Checking the validity of Format and friends at compile-time

[Michalis Kamburelis]

2016-10-05 9:00 GMT+02:00 Maciej Izak <hnb.c...@gmail.com>:
>
> 2016-10-05 4:32 GMT+02:00 Michalis Kamburelis <michalis.ka...@gmail.com>:
>>
>> For example, the call
>>
>>   Format('%s', [123])
>
>
> I have a small hint (instead of answer). We have in mORMot / NewPascal in
> SynCommons module nice function which works perfect in most of cases:
>
> FormatUTF8('%', [123], []); // same string '%' works for both: integer and
> string values
> FormatUTF8('%', ['123'], []);
>

That's a cool improvement. No need to write the type, so one less
thing that can go wrong:) I seldom use non-standard formats anyway
(like %g instead of %f for floats).

Still, you can use an invalid number of arguments for FormatUTF8. So
you still have this uncomfortable feeling that "it's only checked at
runtime, while it could be checked earlier at lint / compile phase" :)

I'm leaning toward implementing a simple pascal-lint tool myself,
using the fcl-passrc. But to make it really useful on my real code,
I'll need some fixes to fcl-passrc first:)

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

[fpc-pascal] Checking the validity of Format and friends at compile-time

[Michalis Kamburelis]

Hi,

I'm wondering if there is a tool that checks the correctness of calls
to Format and friends (like Exception.CreateFmt) in your code. Or does
someone plan to write one, as an external tool (like a "lint") or
inside the FPC compiler:)

For example, the call

  Format('%s', [123])

is guaranteed to result in an EConvertError at runtime. But nothing at
compile-time detects or warns about it.

Sure, it's not possible to check all cases of Format usage, as you can
construct the Format pattern (or list of arguments) at runtime. You
can also replace resourcestrings at runtime. Still, such tool would be
useful since (at least in my code) the majority or Format calls have
constant strings and could be checked at parse time.

The tool would have to know which routines have Format-like parameters
(and at which positions), to capture Format, and Exception.CreateFmt
(and I have a couple of more in my own units). They could be marked in
the source code, by some special directive or a special comment, or
the checking tool should just know their names.

Such tool seems useful for me. It would at least catch *some* blatant
errors, that otherwise sleep undetected until runtime. E.g. today I
have a bugreport that user observed an EConvertError in my program
(unfortunately, he cannot write more exactly what is the message, or
send a screenshot...). I suspect the bug is in one of my Format or
EXxx.CreateFmt calls, but I have a lot of them. Most of them have
constant pattern (and a list of arguments with size and types known at
compile-time), so it should be possible to run some kind of "lint" on
my code... except I don't have any:)

Does anyone know of such a tool?

If you don't have a good answer, I may implement it myself:) I'd like
to use fcl-passrc for it, but so far it fails to parse my real-life
code in Castle Game Engine:) I submitted a couple of bugreports about
it today.

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

Re: [fpc-pascal] corba interfaces - is/as not working properly

[Michalis Kamburelis]

2016-09-30 18:19 GMT+02:00 stdreamer <stdrea...@freemail.gr>:
> On 30/09/2016 17:24 μμ, Michalis Kamburelis wrote:
>>
>> 4. And how about going even more further, and just generate an
>> internal GUIDs (random, or based on a memory address) when no GUID is
>> explicitly specified? This way "is", "as", "Supports" always just
>> work. And it removes the need to do 1., 2., 3. above, of course.
>>
>>Is there a drawback to doing this, that I don't see?
>>
>
> You assume that the interfaces are
> 1) user controlled
> 2) is not used outside from your own environment.
>
> Both valid use cases but invalid assumptions. GUID needs to stay user
> selectable otherwise you loose the ability to implement interfaces for 3rd
> party applications (banking, stock exchange, ms office etc). Interfaces are
> compiler agnostic you might import them to use a 3rd party library (eg. ADO)
> which has its own GUIDs that you must not change.
>

I didn't say I want to remove user-selectable GUIDs from the language.
I understand that e.g. when using COM interfaces for inter-process
communication, you want to explicitly specify the GUIDs.

My point (4.) was to generate an internal GUID *when no GUID is
explicitly specified by the programmer*. This way the interfaces would
work more reliably ("is", "as", "Supports" working as expected) when
you're fine with using them only internally in your application.

Right now, not specifying the GUID of your interface is a trap. You
get something that compiles, without a warning, but "is" and "as"
don't work correctly. See the examples in my email, or in the 1st mail
in this thread. It would be nice to eliminate this trap:)

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

Re: [fpc-pascal] corba interfaces - is/as not working properly

[Michalis Kamburelis]

This thread, and my own tests, showed that you need to assign GUIDs to
interfaces to have reliable "is", even for CORBA interfaces.

I'm wondering, would it be possible to improve here things on the
compiler side (at least only in FPC-specific modes or under some
modeswitch), to make things safer?

Propositions:

1. The question "X is IMyInterface", when "IMyInterface" does not have
a GUID, could fail to compile.

  Just like right now "Supports(X, IMyInterface)" does not compile
when "IMyInterface" does not have a GUID. This is better -- the
presence of GUID is checked at compile-time.

  Right now, the "X is IMyInterface" seems like a trap, when the
interfaces can have no GUIDs. Two interfaces without GUIDs are treated
as equal, by the "is" operator. The example code that started this
thread shows how bad are the consequences. I made my own little
example, attaching.

2. I assume "as" operator has the same problem? So "X as IMyInterface"
would benefit from the same safeguard.

3. How about going further, and just making the GUID required at every
interface declaration? Since it's necessary to have reliable "is",
"as", "Supports"...

4. And how about going even more further, and just generate an
internal GUIDs (random, or based on a memory address) when no GUID is
explicitly specified? This way "is", "as", "Supports" always just
work. And it removes the need to do 1., 2., 3. above, of course.

  Is there a drawback to doing this, that I don't see?

Regards,
Michalis

P.S. I have added to
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html
a section documenting it.
{$mode objfpc}{$H+}{$J-}
{$interfaces corba}

{ Simple test that without GUIDs, the "is" operator on interfaces
  returns "true" when a class implements *any* interface.
  Most likely because "is" simply compares GUIDs, and "no GUID" equals
  something like "GUID all filled with zeros".
  This means that GUIDs are necessary, for both CORBA and COM interfaces,
  if you want reliable "is". }

uses SysUtils, Classes;

type
  IMyInterface = interface
procedure Shoot;
  end;

  IMyUnrelatedInterface = interface
procedure Eat;
  end;

  TMyClass1 = class(IMyInterface)
procedure Shoot;
  end;

  TMyClass2 = class(IMyUnrelatedInterface)
procedure Eat;
  end;

  TMyClass3 = class
procedure Shoot;
  end;

procedure TMyClass1.Shoot;
begin
  Writeln('TMyClass1.Shoot');
end;

procedure TMyClass2.Eat;
begin
  Writeln('TMyClass2.Eat');
end;

procedure TMyClass3.Shoot;
begin
  Writeln('TMyClass3.Shoot');
end;

procedure UseThroughInterface(I: IMyInterface);
begin
  Write('Shooting... ');
  I.Shoot;
end;

var
  C1: TMyClass1;
  C2: TMyClass2;
  C3: TMyClass3;
begin
  C1 := TMyClass1.Create;
  C2 := TMyClass2.Create;
  C3 := TMyClass3.Create;
  try
if C1 is IMyInterface then
  UseThroughInterface(C1 as IMyInterface);
{ VERY WRONG: "C2 is IMyInterface" is evaluated as "true",
  and the "I.Shoot" call inside "UseThroughInterface" calls
  the "TMyClass2.Eat" method. }
if C2 is IMyInterface then
  UseThroughInterface(C2 as IMyInterface);
if C3 is IMyInterface then
  UseThroughInterface(C3 as IMyInterface);
  finally
FreeAndNil(C1);
FreeAndNil(C2);
FreeAndNil(C3);
  end;
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cross platform mobile development

[Michalis Kamburelis]

2016-09-07 18:41 GMT+02:00 Ryan Joseph :
>
> I did enough research in Android for FPC to know I could do a simple OpenGL 
> game using the JNI but it didn’t look very complete and I never could get the 
> compiler built on my Mac. Is there enough of the Android NDK (I think it’s 
> called) ported to Pascal so that it’s useful?

Android SDK + NDK and OpenGL ES work flawlessly with Pascal:)That's
what we use in Castle Game Engine to have a cross-platform game engine
for desktops (Windows, Linux, MacOSX...), and mobile (Android, iOS).
See http://castle-engine.sourceforge.net/engine.php . We're actually
making large Android games with it, http://cat-astrophe-games.com/ :)

We have a special "built tool" that takes care of compiling and
creating Android APK for your project (it calls FPC, and Android SDK /
NDK tools underneath). See
https://github.com/castle-engine/castle-engine/wiki/Build-Tool and
https://github.com/castle-engine/castle-engine/wiki/Android . Things
are not so easy for iOS *yet* (that is, creation of iOS application
from Pascal is not 100% abstracted by the tool yet), but I'm confident
we'll get there in next release:)

The only downside for "normal" applications is that the GUI does not
look native. We draw everything  ourselves (or you can embed the
engine control within a Lazarus form, and then use Lazarus GUI for
it). This is not a problem for games, that traditionally have their
own GUI, themed to look like the game.

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

Re: [fpc-pascal] GZip - Stream decompress only in memory

[Michalis Kamburelis]

 2016-09-04 18:08 GMT+02:00 Marcos Douglas :
> I have streams compressed using GZip. I get these streams from WebServices.
> So, how can I decompress these streams only in memory?

It seems you already have a solution, but here's another one:)

In Castle Game Engine, I have a unit CastleZStream that provides
TGZFileStream that can compress/decompress in memory. It uses the
CastleGzioInternal unit, which is a modified version of Gzio unit from
FPC, modified to be able to work with TStream (not just a file). You
can take these two files to have it working:

https://github.com/castle-engine/castle-engine/blob/master/src/base/castlegziointernal.pas
https://github.com/castle-engine/castle-engine/blob/master/src/base/castlezstream.pas

For base64, the TBase64EncodingStream and TBase64DecodingStream from
standard FPC Base64 unit do the job nicely:)

They all (TBase64EncodingStream, TBase64DecodingStream, TGZFileStream)
descend from TOwnerStream which is a common useful class for a stream
that processes another stream.

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

Re: [fpc-pascal] Mouse, scroll wheel support?

[Michalis Kamburelis]

2016-06-28 15:05 GMT+02:00 John Youngquist :
> Is there a non Lazarus means of accessing the mouse, and scroll wheel?
> I have an app that uses some old driver which doesn't address the wheel.
> I'm trying to make the wheel work. I have tried SDL and the demo code works
> but it seems to work only in an externally created window. I can't find any
> documentation for it nor can I post on the forum.
>

Accessing events like mouse and keyboard always requires to use some
API. It may be high-level API like Lazarus LCL or SDL (or my
TCastleWindow), it may be lower-level like GTK, or WinAPI, or even
Xlib. For all these APIs, the exact answer "how to read mouse wheel
events" is different:)

In most of them, you can only read mouse events that reach windows
that you yourself created (windows for which you have a "handle" or
some equivalent). If you want to get mouse wheel events that occur
above *any* window --- you may be out of luck (or you may be able to
use some hack in the lowest-level APIs, like WinAPI or Xlib, but I
can't help you more here).

For SDL, the way to read mouse wheel is to

- either use https://wiki.libsdl.org/SDL_MouseWheelEvent (but it seems
SDL_MOUSEWHEEL is not translated in FPC SDL headers, neither in
original jedi-sdl headers),

- or you can watch for event types SDL_MOUSEBUTTONDOWN ,
SDL_MOUSEBUTTONUP with button set to SDL_BUTTON_WHEELUP or
SDL_BUTTON_WHEELDOWN (this works without problems for me, trying on
old jedi-sdl examples with FPC SDL units).

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Michalis Kamburelis]

> After upgrading fpc 2.6.4 -> 3.0.0, I'm seeing a bug where (as noted in
> subject) reference-counted function results are not being initialized to
> nil.

They were never guaranteed to be initialized to nil.

Reference-counted types (unlike other types) cannot contain memory
garbage. But it doesn't mean that they are always initialized empty
when the function starts. You need to explicitly do Result := '' if
your code reads the Result later.

See similar questions for Delphi:
http://stackoverflow.com/questions/5336863/what-is-the-default-value-of-result-in-delphi
http://stackoverflow.com/questions/5314918/do-i-need-to-setlength-a-dynamic-array-on-initialization/5315254#5315254

Luckily, FPC warns about it, at least in my simple test:

$ fpc -vw a.lpr && ./a
a.lpr(5,20) Warning: function result variable of a managed type does
not seem to be initialized
blabla
blablablabla
blablablablablabla

Regards,
Michalis


a.lpr
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] why (ClassType as TMyClass).Create fails

[Michalis Kamburelis]

 2016-06-21 15:57 GMT+02:00 Dennis :
> Following up to the cloning example code:
>
> Type
>  TMyClassRef = class of TMyClass;
>
> implementation
>
> function TMyClass.Clone(AOwner: TComponent): TMyClass;
> begin
>   Result := TMyClassRef(ClassType).Create(AOwner);
>
> //but the next line will fail to compile
> //  Result := (ClassType as TMyClassRef).Create(aOwner);
>   Result.Assign(Self);
> end
>
> Isn't (ClassType as TMyClassRef).Create(aOwner)  supposed to be safer
> because sometimes we copy and paste code around and in the end  (ClassType
> might not be a descendant of TMyClass and the compiler won't catch this type
> mismatch if we do
>
>   Result := TMyClassRef(ClassType).Create(AOwner);
>
> Am I missing something?
>

The "is" / "as" operators are just not defined on class references
(they only on classes and interfaces). Not really sure why.

To make the typecast *somewhat* safer (but see disclaimers below) you
can check the InheritsFrom (
http://www.freepascal.org/docs-html/rtl/system/tobject.inheritsfrom.html
) before casting. InheritsFrom is a class method, it can be used on
instances of class references easily.

So like

if ClassType.InheritsFrom(TMyClass) then
  Result := TMyClassRef(ClassType).Create(AOwner) else
  raise Exception.Create(...);

Note that you check for "InheritsFrom(TMyClass)" , not
"InheritsFrom(TMyClassRef)". So it will *not* secure from bugs when
someone changes the definition of TMyClassRef (to be "class of
TSomeOtherClass").

But it will secure from bugs if this code is copy-pasted into some
unrelated class, where ClassType is not compatible with TMyClass.

Actually, since this is inside an instance, you can write
"InheritsFrom(TMyClass)" instead of
"ClassType.InheritsFrom(TMyClass)". Actually you can write "Self is
TMyClass". Which is actually trivially true in this code (this is
inside a TMyClass method)... But maybe some variation of this check
will be useful, if this is used in a more complicated code, with
something less obvious than "ClassType" as an argument.

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

Re: [fpc-pascal] Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-21 15:03 GMT+02:00 Sven Barth <pascaldra...@googlemail.com>:
> Am 21.06.2016 12:31 schrieb "Michalis Kamburelis"
> <michalis.ka...@gmail.com>:
>> Current FPC defaults:
>>
>> - Help people who except the {$mode fpc} to be default (so they write
>> code without classes and a lot of other new features),
>> - Or people who expect that string is by default ShortString (limited
>> to 255 chars).
>
> One might argue about changing the default mode, but changing the default
> String type of mode ObjFPC will very likely result in compilation or runtime
> errors (probably even in the compiler itself) which is something we tend to
> avoid without good reasons. At the very least there will be performance
> differences which - depending on the code - might be noticeable as well.
>

These errors and differences will be only felt by projects that use
{$mode objfpc} but assume that string = ShortString (and they don't
use {$H-} explicitly). I don't think it would apply to too many
projects?

And if we do it in some major version, with proper release notes, like
Mr Bee proposes, these projects would have plenty of time to adjust
their compilation scripts / config files. They could just add "-Sh-"
or "{$H-}" and be OK, for both past and future FPC versions.

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

Re: [fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-21 12:14 GMT+02:00 Marco van de Voort <mar...@stack.nl>:
> In our previous episode, Michalis Kamburelis said:
>>
>> - A section about TPersistent.Assign. This is the "basic approach to
>> cloning" that should probably be shown first. See it here:
>> http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_cloning_tpersistent_assign
>
> See also
> http://stackoverflow.com/questions/4041760/correct-way-to-duplicate-delphi-object/4041906#4041906
>
> That is for an own root class and pre class helpers, but you could do it also 
> in or TPersistent
> helper:
>
> type tpersisthelp = class helper for TPersistent
> function Clone(t: TPersistentClass = nil): TPersistent;
> end;
>
> function tpersisthelp.Clone(t: TPersistentClass = nil): TPersistent;
>   begin
> if Assigned(t) then
>   Result := t.Create
> else
>   Result := TPersistentClass(Self.ClassType).Create;
> Result.Assign(Self);
>   end;
>
> Since TComponent declares a virtual destructor that might even be better.

I saw your post on stackoverflow before writing my article:)

But doing this on TPersistent means that you avoid calling the
constructor of the actual class. If you use this helper on a class
TMyClass, you will have an instance of TMyClass that "bypassed" the
constructor of TMyClass. Only "TPersistent.Create" was called. I
suspect that in real-world usage, a lot of classes will fail to work
correctly then, since code inside TMyClass often assumes that TMyClass
constructor was performed. I know that a lot of my own classes will
fail because of this...

That's why I would limit this usage only to the cases when you have a
virtual constructor on the base class. Only then the final class has a
chance to execute it's proper constructor.

Regards,
Michalis


test_clone.lpr
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

>> I even expect a bit further. These {$MODE OBJFPC}, {$H+}, and {$J-}
>> directives should be the *default* directives for every new FPC
>> programs/units. We're now using Free Pascal compiler on 2016. Why do we need
>> to explicitly declare Free Pascal mode in a Free Pascal program? In 21st
>> century, our string should not be limited to 255 chars anymore. And what the
>> hell is "writable constant"? It's contradictio in terminis. :)
>
> We have a strong focus on backwards compatibility, so the default mode stays
> "fpc" and changing a modes' default settings would also affect backwards
> compatibility.
>

Maintaining compatibility is usually a compromise. I feel that in this
case, maintaining such compatibility hurts more than it helps. It is
of course my opinion, biased by the kind of code I write, and by the
programmers I talk with (many of whom don't know Pascal, but know
Java, C# or other OOP languages).

Current FPC defaults:

- Help people who except the {$mode fpc} to be default (so they write
code without classes and a lot of other new features),
- Or people who expect that string is by default ShortString (limited
to 255 chars).

I think that the majority of people use now suitable command-line
options, or directives, to change FPC mode to something more modern
({$mode objfpc} or {$mode delphi}, and {$H+}). So changing the
defaults will not hurt them. Sure, I don't have any hard data to back
it up, I don't know how much is "majority". But this applies at least
to all Lazarus users that have these settings "by default".

Again, this is just my opinion, but I would say that breaking
compatibility in this case is warranted. Making objfpc the default
mode, and making $H+ the default in objfpc mode, before the fpc.cfg is
read (so it applies to everyone, and can be overridden by fpc.cfg or
command-line later) would be a nice thing.

(Making {$J-} would be a cool bonus, but I don't dream about it, as it
could admittedly break more recent code.)

In 
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html
I decided to just write

  {$mode objfpc}{$H+}{$J-} // Just use this line in all modern sources

at the beginning of a first "hello world" example. And I never explain
the reason for this line, I just repeat it in all examples (that are
full programs/units). That's an ugly solution, but I just couldn't see
a better one. It doesn't sound nice to explain that:

- otherwise, they don't have classes ("why are classes disabled?"),
- otherwise their stings are limited to 255 ("are you sure this is a
modern language?"),
- and otherwise their constants are not necessarily constant ("what?") ...

It's not a good learning experience, if you have to learn about so
many historical things when you learn to write a first Pascal program.
And these things are already fixed -- just the defaults are old.

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

Re: [fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

> |I remember someone once asked whether we should override the method Assign
> or AssignTo.|
> |I am worried, choosing the wrong method to override will produce unexpected
> result.|

The AssignTo is only used by TPersistent.Assign, so it's a "fallback"
--- if class A cannot copy *from* B, then AssignTo is called on B to
let B assign *to* A. This allows to implement the copying on any end,
which is useful e.g. when you cannot change the source code of A.

This is documented on
http://www.freepascal.org/docs-html/rtl/classes/tpersistent.assign.html
.

The short advice is that you usually want to override Assign, and
forget about AssignTo. Overriding Assign is always enough if you think
about a typical cloning scenario, when you usually copy instance of
class A to another instance of class A, and not mix classes.

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

Re: [fpc-pascal] Bls: Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-21 8:15 GMT+02:00 Marc Hanisch :
> Thanks Michalis for your excellent work! It's very important to left the
> early 90s associated with Pascal programming behind us and to encourage new
> developers to have a look onto the modern aspects of Object Pascal!
>
> Maybe a little bit offtopic, but I have a question regarding the compiler
> directives: is there a way to tell Lazarus to use these directives in every
> new unit?
>

In Lazarus, you can choose the mode ("Object Pascal - default
(ObjFpc)") and $H+ ("Use AnsiStrings") in the Project -> Options ->
Compilation Options. This is equivalent to starting all your code with
"{$mode objfpc}{$H+}".

In fact, these are already the default: ObjFpc and $H+. So, if you're
using Lazarus for your development, these are already set at nice
default values.

It seems not possible to set the "{$writeableconst off}" (equivalent
to "{$J-}") using Lazarus options. Probably because it seems not
possible to do it using FPC command-line, so Lazarus would not have
how to communicate it to FPC. Seems like a simple omission, and a
bugreport to FPC would fix it:)

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

Re: [fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-20 14:30 GMT+02:00 Marcos Douglas :
> Don't agree with "Ugly (COM) interfaces". Yeah, _AddRef, _Release,
> QueryInterface is ugly implementation but reference-counting mechanism
> is nice.
>

Reference-counting is a useful concept, but "entangling" it with
interfaces is somewhat ugly IMHO. Those two concepts, and needs,
should be unrelated language features in my opinion:

- you use interfaces when you want to cast a class to multiple
possible interfaces,
- you use reference-counting to get automatic memory management (to
some extent, e.g. beware of cycles).

Both of these are useful, but forcing them together seems ugly. And it
causes actual problems:

- Various classes, using standard TComponent, have to "hack around"
reference counting by proving _AddRef implementations that do nothing,
- Even with hack above, you need to be extra careful about interface
temporary variables (you cannot free the class instance, if some
temporary interface variable may refer to it).

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

Re: [fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-20 11:44 GMT+02:00 Mark Morgan Lloyd
:
[...]
> I'd suggest warning readers early about "dangling else", and using otherwise
> rather than  else  in the  case  examples.

As for dangling else - good idea, I added a text and example
mentioning it briefly at the of
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_testing_if
.

As for "otherwise" in "case" - I admit I prefer the "else" keyword
there. Although I don't have any other argument for it than being
accustomed to it, from reading existing sources. I just grepped FPC
and Lazarus source code, and I couldn't find any "case" with
"otherwise" section... while I easily found occurrences of "case" with
"else" sections.

For this reason, I am inclined to keep the example with "case ..
else", not "case .. otherwise". Indeed, one needs to be more careful
then (to not mix the "else" with an "if" from the last statement).

> It's unfortunate that there's a lot of C programmers who wouldn't dream of
> writing in K, but who still assume that Pascal is still as primitive as it
> was in the 1970s.

That's a great analogy. I may steal it some day:)

>
> There's a few places where a native English author would have done things a
> bit differently. For example, in most places "Castle Game Engine" would
> probably be prefixed by "the", and also "it allows [something, what] to deal
> with cases when simple class inheritance is not enough".
>

Thanks! I improved it a bit, adding "the" at some places and changed
to sentence to simpler "Useful when a simple class inheritance is not
enough.".

I'm not a native English speaker, so any corrections and suggestions
are very welcome when it comes to the language (and everything else:)

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

Re: [fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-20 6:16 GMT+02:00 Dennis Poon :
> May I suggest the addition of :
> 1) user defined operator?

Added. I had it on my TODO list already:) See it here:
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_operator_overloading
.

I documented also overriding operators for classes and records, and
mentioned the need for "class operator" on records to be able to work
with TFPGList and such.

> 2) use of ClassType function for cloning objects

I added two things:

- A section about TPersistent.Assign. This is the "basic approach to
cloning" that should probably be shown first. See it here:
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_cloning_tpersistent_assign
. I mentioned the special rules when calling the "inherited" from
Assign overrides, and AssignTo, and the fact that TPersistent makes
the default visibility "published".

- And the ClassType, with the example of Clone method using it, is
added at the desciption of "class references" on
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_class_references
.

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

Re: [fpc-pascal] Bls: Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

2016-06-20 5:31 GMT+02:00 Mr Bee :
[...]
> I have a little suggestion though. I prefer to use {$J-} directive in my
> Pascal program. I think it encourages good programming practice in Pascal.
> The {$J-} means constant is a constant no matter how you declare it. To bad
> FPC is still using {$J+} as the default even in the {$MODE OBJFPC}, which
> means a constant becomes a variable once you include the data type
> eventhough it's declared within a 'const' block. CMIIW.
>

Ouch. For some reason, I thought that {$J-} is the default in {$mode
objfpc} since years, and we have left that mistake behind us. Quick
test showed me that I was mistaken. This makes a *lot* of my code less
safe that I assumed, as in many recent projects I didn't bother to
explicitly use {$J-}.

This is an excellent suggestion then, thank you. I updated the
document to encourage everywhere doing

  {$mode objfpc}{$H+}{$J-}

at the beginning.

I definitely *do not want* to explain to any new programmer what a
"writeable constant" is... This concept should remain buried:)

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

[fpc-pascal] Quick Modern Object Pascal Introduction, for Programmers

[Michalis Kamburelis]

Hi,

So, I wrote a document describing (quickly!) many features of the
modern Object Pascal:)

Read on:

http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html

http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.pdf

This document started just Thursday morning. I thought that such
document would be a helpful resource for the developers interested in
my Castle Game Engine (http://castle-engine.sourceforge.net/ ). The
document is directed at programmers who already know the concepts
(like classes, virtual methods) but they don't know how they look like
in Object Pascal. Or maybe they know Object Pascal classes, but don't
know about some "advanced" (but really useful IMHO) language features
added in the recent years. For example, many people are not aware that
Pascal has generics -- a powerful and important language feature,
IMHO. Many people are not sure what happens when an exception occurs
during the constructor -- which is quite important to know, if you
want to write correct destructors, I think.

This document quickly grew over the last 3 days:) It starts from
really basic stuff, and quite quickly jumps into "advanced" stuff. The
PDF is now 52-pages long, and calling it a "Quick Introduction"
becomes harder and harder:)

Parts of it apply only to recent FPC versions, and only to {$mode
objfpc} mode. I deliberately didn't want to burden the reader with
historic details, or differences between Delphi and FPC, or FPC
$modes. This is for readers who just use the latest FPC version, as
their primary Pascal compiler, and want to use the language with all
it's current features.

Share and redistribute as you like. The source is in AsciiDoc,
available on GitHub
https://github.com/michaliskambi/modern-pascal-introduction , and
corrections and improvements and all comments are very much welcome!
You're also welcome to reuse parts of it for FPC/Lazarus wiki or any
other document (license is the same as wikipedia). I hope you will
find this useful:)

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

Re: [fpc-pascal] Smartphone apps in FPC

[Michalis Kamburelis]

2016-03-17 15:17 GMT+01:00 Paul Breneman :
> I would suggest checking this out:
> http://castle-engine.sourceforge.net/engine.php
> https://github.com/castle-engine/castle-engine/wiki/Build-Too
>

Small correction, the link should be:

  https://github.com/castle-engine/castle-engine/wiki/Build-Tool

(final "l" was missing from the URL). Our instructions how to setup
environment (FPC + Android SDK, NDK) may also be useful,
https://github.com/castle-engine/castle-engine/wiki/Android

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

Re: [fpc-pascal] Building Android cross compiler error

[Michalis Kamburelis]

  

> /Developer/Android/android-ndk-r10e/toolchains/arm-linux-
androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ld.bfd:
cannot find -lc  
pp.pas(219,36) Error: Error while linking  

>

>  

Have you defined the -Fl option correctly?

  

For example, I put something like this in my ~/.fpc.cfg:

  

#ifdef android

#ifdef cpuarm

-Fl/home/michalis/.../android/ndk/platforms/android-19/arch-arm/usr/lib/ 

#endif

#ifdef cpu386

-Fl/home/michalis/.../android/ndk/platforms/android-19/arch-x86/usr/lib/ 

#endif

#endif  

  

You can see Castle Game Engine instructions about setting up Android+FPC
environment on https://github.com/castle-engine/castle-engine/wiki/Android :)

  

Michalis

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

Re: [fpc-pascal] Android porting ideas

[Michalis Kamburelis]

>  

>

> This will probably make more sense when I learn about the asset manager
more. I think I read there is a format like asset:// for file URL’s.

  

Remember that the "asset:/..." URL is just implemented in Castle Game Engine
(see http://castle-engine.sourceforge.net/tutorial_network.php ). It's not
something recognized by other APIs (Android or not). Although Qt has analogous
concept (http://doc.qt.io/qt-5/platform-notes-android.html#assets-file-
system).

  

If you want to do it yourself: the AssetManager functions are part of
CastleAndroidInternalAssetManager , which are bindings for C API documented as
part of Android NDK here:
http://developer.android.com/ndk/reference/group___asset.html . These are the
gory details to access assets:)

  

The unit CastleAndroidInternalAssetStream wraps Android assets into a Pascal
TStream, and converts URL (more-or-less strips/adds the "asset:/..." prefix)
by URIToAssetPath / AssetPathToURI functions.

  

Regards,

Michalis

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

Re: [fpc-pascal] Android porting ideas

[Michalis Kamburelis]

> I see you made a builder tool I’ll have to check out. From the Android
tutorials I’ve seen building Android packages seems be pretty forward. You can
run/install apps from the terminal also I think based on your documents.
That’d be nice to not be in Android Studio if I don’t have to be.

  
Yes, you can do whole compile + install + run process using castle-engine
tool. It's a rather simple wrapper around some Google tools, ant etc. You
don't need to download Android Studio at all, you only need basic Android SDK
and NDK.

  

> It looks like the majority of the startup code is in castlewindow_android
but I was expected to see an OpenGL context (surface view I think in Android).
How do you render OpenGL then?

  

castlewindow_android.inc does  

  

  {$I castlewindow_egl.inc}

  

and the code that initializes OpenGLES context is inside castlewindow_egl.inc.
It's using EGL library, https://www.khronos.org/registry/egl/ , specification
blessed by Khronos, available on Android, able to initialize OpenGL ES
context.

  

It can also be used to initialize OpenGL ES context on the desktops (which is
useful to test OpenGL ES renderer on Linux, Windows etc.). That's why the code
is not inside castlewindow_android.inc --- it's more generally useful.

  

> So UNIX I/O “works” but you can’t read anything without the asset manager?
That doesn’t really make sense but either way using the Asset manager in a
stream like you did is just fine. I only need to read the contents of images
and XML files anyways.

  
UNIX I/O works for reading files. On disk (device internal memory, sdcard
etc.).

  

It doesn't work to read stuff from the apk. Because the files you put inside
apk ("assets" in Android terminology) are not available to you as normal files
inside the Android application. You don't know where (and if, at all) they are
unpackaged on the Android filesystem. You can only access them (read-only)
using AssetManager.

  

> I was using ReadXMLFile to read the XML file but I assume this is just a
helper function that wraps something lower level I could use in conjunction
with the asset manager. Is that correct? Can’t find your code for this.

  
See the URLReadXML implementation:

  

procedure URLReadXML(out Doc: TXMLDocument; const URL: String);  
var  
 Stream: TStream;  
begin  
 Doc := nil; // clean "out" param at start, just like ReadXMLFile  
 Stream := Download(URL, []);  
 try  
   ReadXMLFile(Doc, Stream);  
 finally FreeAndNil(Stream) end;  
end;  
  

So it simply reads URL to a TStream, then uses overloaded ReadXMLFile version
that reads XML from a stream:)

> So internally Android just uses the same C libraries we were using in
Pascal? I guess that makes sense but I was thinking EVERYTHING on the system
was now Java but that’s not the case I guess. The lesson here is that Android
is built on Linux so we’re sharing more than I think.

  

There are *some* C libraries on Android, indeed. There is a version of libc,
there is OpenGLES (and friends like EGL). But not much else, so don't get your
hopes up:) http://developer.android.com/ndk/guides/stable_apis.html has the
list of available native libraries.

  

You can make a working game with them --- you have access to display (through
EGL and OpenGL ES) and sound (through OpenMAX). And you have access to input
by communicating through JNI with NativeActivity.

  

But a lot of other stuff is only available in Java libraries, and you need to
write custom Java code to access it. For example, everything that is part of
https://en.wikipedia.org/wiki/Google_Play_Services --- integration with Google
Maps, Google Analytics, Google Games, etc. Also in-app purchases. Also
integration with other apps e.g. to get/make photos. Or take location from
GPS. Or even open a WWW browser.

  

Fortunately, using these Java APIs through a JNI layer is not really hard in
my experience. And Castle Game Engine gives you some helpers:) ---
CastleMessaging and component system, to make it even easier.

  

Regards,

Michalis

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

Re: [fpc-pascal] Android porting ideas

[Michalis Kamburelis]

2016-02-21 23:00 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>:
> Am 21.02.2016 19:36 schrieb "Michalis Kamburelis"
> <michalis.ka...@gmail.com>:
>> >
>> > 1) All the file I/O in the FPC RTL is not available so what possible
>> > work arounds are there for loading data from files?
>>
>> Actually, all the IO in FPC works perfectly. You can read / write
>> files just like on any other Unix (although you need to declare
>> appropriate permissions in the AndroidManifest.xml first ---
>> READ_EXTERNAL_STORAGE , WRITE_EXTERNAL_STORAGE, otherwise access to
>> "/sdcard/..." files will be restricted). For example, config files are
>> just normal files on Android. You only use a special function to get
>> the proper config file location, but this is done for you by CGE, you
>> just use CastleFilesUtils.ApplicationConfig:)
>
> I think he means on FPC's JVM target. There file I/O using Write/Read is
> indeed not implemented.
>

Oh, OK. My comments were indeed about the native target (Android+Arm
communicating through JNI), not JVM. Well, at least I can confirm that
I/O works cool there:)

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

Re: [fpc-pascal] Android porting ideas

[Michalis Kamburelis]

2016-02-21 4:36 GMT+01:00 Ryan Joseph :
> I’m going to attempt to port a game to Android but I have some questions 
> about potential problems. Now at least I think building a library and loading 
> using the JNI would be best but using the JVM could be helpful also (the 
> entire project couldn’t be compiled though). Not sure which way is best or if 
> they can be mixed perhaps.

In Castle Game Engine the whole Pascal code is compiled into an .so
library (for Android+Arm, though we could also target Android+x86). It
is then packaged into an apk, with the activity class set to the
"NativeActivity" Java class.

You can communicate with the Java code using JNI. In the base version,
the NativeActivity (part of Android since Android 2.3) already does a
lot for you, and you don't even need to touch the "Java side". For
more complicated stuff, you need to write some Java code, and
communicate with it using JNI. Of course if you use an engine like
Castle Game Engine, you get a lot of help with this:) --- most things
are already implemented for you, and for adding your own Java
extensions we have CastleMessaginig unit and a "component" system for
Android projects,
https://github.com/castle-engine/castle-engine/wiki/Android-Project-Components-Integrated-with-Castle-Game-Engine
.

See http://castle-engine.sourceforge.net/engine.php and download the
engine and try it:) You can use the stable release 5.2.0, or the (soon
to be released as 5.3.0) version from GitHub on
https://github.com/castle-engine/castle-engine .

We have a lot of documentation, some Android/mobile specific stuff:

- http://castle-engine.sourceforge.net/tutorial_mobile.php (tutorial
showing how to write cross-platform game code using CGE --- for
standalone, Android, iOS, web browser plugin...)

- https://github.com/castle-engine/castle-engine/wiki/Android - how to
install Android development environment

- 
https://github.com/castle-engine/castle-engine/wiki/Android-Project-Components-Integrated-with-Castle-Game-Engine
- extra Android components, e.g. for in-app purchases or analytics.

>
> 1) All the file I/O in the FPC RTL is not available so what possible work 
> arounds are there for loading data from files?

Actually, all the IO in FPC works perfectly. You can read / write
files just like on any other Unix (although you need to declare
appropriate permissions in the AndroidManifest.xml first ---
READ_EXTERNAL_STORAGE , WRITE_EXTERNAL_STORAGE, otherwise access to
"/sdcard/..." files will be restricted). For example, config files are
just normal files on Android. You only use a special function to get
the proper config file location, but this is done for you by CGE, you
just use CastleFilesUtils.ApplicationConfig:)

The important thing is that your program data (what you put in apk) is
*not* stored on disk as normal files. You need to use AssetManager to
read it. With some helpers, you can just open an "asset file" as a
Pascal TStream, and then read from there. In CGE, you just use URL
like "assets:/some_subdirectory/blahblah.png", pass it to any
file-reading function and it will read the file
"some_subdirectory/blahblah.png" from your data. More info on
http://castle-engine.sourceforge.net/tutorial_network.php .

>
> 2) OpenGL functions are not available so how can I call into the Android 
> library? Callback wrappers perhaps?

You use OpenGL ES for rendering (version 2 or 3, for modern devices).
Pascal bindings are available already in FPC, see unit GLES20. Of
course engines like CGE  give you more comfortable API for rendering,
on top of this.

>
> 3) I use ReadXMLFile from XMLRead but that uses file loading internally so is 
> there anyway to load XML on Android?

As said above --- you can still use these functions to read / write
regular files on Android.

To read XML in your apk data, you need to get a TStream from
AssetManager, and read / write XML using this stream. This works
perfectly:)

We use XML files in CGE a lot, and we have helpers like URLReadXML
that reads TXMLDocument from an URL, and URL can be "file:/..." or
"assets:/..." (or even http or others, see the mentioned tutorial
about networking:)

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

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[Michalis Kamburelis]

>>  Right now we only have "with notifications, and not type-safe"
>> containers (TObjectList/TList) and "without notifications, and
>> type-safe using generics" containers (TFPObjectList/TFPList).
>
>
> These latter 2 are not generics based. There was some experimental code
> which attempted to implement TFPObjectList/TFPList on top of generics,
> but they were slower than the native implementation. That experiment is
> unmaintained.
>
> TFPGList is the one you meant, probably.
>

Ups. Yeah, by "without notifications, and type-safe using generics"
containers I meant TFPGList and TFPGObjectList (and other TFPGXxx)
from the FGL unit.

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

Re: [fpc-pascal] Primitive Record Wrappers

[Michalis Kamburelis]

2016-02-18 15:43 GMT+01:00 Mazola Winstrol :
> Em 18/02/2016 10:12, "Marco van de Voort"  escreveu:
>>
>> In our previous episode, Mazola Winstrol said:
>> >end;
>> >
>> >
>> > Suppose that this class represent data of the Person table in a sql
>> > database. Suppose that there is records where the column "BirthDate" is
>> > null. How do i represent a null "BirthDate" in my object?
>>
>> Keep using variants instead of typed data.
>>
>
> I think this is not a good alternative. As the variant are untyped, should
> the consumers of the person class assume that BirthDate are filled as a
> formated date string '01/01/1980' or as a native tdatetime?
>
> I think it would be better using record wrappers to primitive types. See
> http://blogs.embarcadero.com/abauer/2008/09/18/38869.
>
> What do you think about that?

Personally, I like the Nullable idea from C#, which is basically a
generic record adding a "HasValue: boolean" to "Value: T". The
type-safety is nice, and it's sometimes very useful (when you cannot
"cheat" and say that "empty string" or "zero value" always means
"uninitialized"). Looking at your link
http://blogs.embarcadero.com/abauer/2008/09/18/38869 , this is exactly
trying to implement Nullable in Object Pascal.

The major problem there is that it's difficult to force it to be
always initialized with zeroes. Currently, a non-global variable of
unmanaged type can always be filled with memory garbage, as explained
in other thread. The trick in
http://blogs.embarcadero.com/abauer/2008/09/18/38869 to use interfaces
feels ugly, it's an over-use of the "interface" specifics in Object
Pascal.

I remember a thread on fpc-devel "Pascal Smart Pointers Idea + ARC
implementation" where the original author (Maciej Izak) was already
working to overcome this:
https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg33172.html
. His reasons was similar (force the contents to be initialized with
zero) and his solution felt cleaner -- introduce "class operator
Initialize" where you can initialize your record.

Any chance that this would be added/merged to FPC one day?:)

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

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[Michalis Kamburelis]

>> Can you send little bit sample showing this degradation? I can inform him
>> to not send the patch because this problem. (I think that him isn't
>> registered here in the list yet)
>
> There's no need for a sample. This degradation is the whole reason why the
> non-generic classes TFPObjectList and TFPList exist compared to TObjectList
> and TList which do have notifications.

Hm, two points.

1. I'm using FGL containers a lot (because I like type-safety given by
generics), and I agree that adding a notification mechanism there can
slow them down. Mostly at allocation (because a deallocation is
already burdened down by having to do Deref() on every item, so it
would probably not suffer *so much* with unassigned OnNotify).

2. But this should not stop us from making a "generic container with
notification" classes. Maybe as new classes, maybe as a boolean toggle
to existing classes (as Graeme nicely suggests).

  Right now we only have "with notifications, and not type-safe"
containers (TObjectList/TList) and "without notifications, and
type-safe using generics" containers (TFPObjectList/TFPList). But
these two features (1. notifications and 2. type-safety thanks to
generics) should be independent. It makes sense to create a "with
notifications, and type-safe using generics" option.

  So I would not reject the idea so quickly. But it indeed should be
implemented carefully, without slowing down the existing
TFPObjectList/TFPList.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Michalis Kamburelis]

Maciej Izak wrote:
> +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen"
> from math and strutils modules.
> 
> IfThen from System totally breaks the compatibility :\ . C'mon Sven. In
> one field you're rigorously but in something like this you're liberal
> (braking/dangerous change / for existing code base).
> 
> If i understand correctly "ThenExpr" is executed only when "Condition"
> is true and "ElseExpr" is executed only when "Condition" is false. For
> standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is
> executed before IfThen is called.
> 
> for me different syntax for System.IfThen is required (fpIfThen ? or
> http://docs.elementscompiler.com/Oxygene/Expressions/If/ ).

As far as I understand, compatibility is not broken: new IfThen was
deliberately introduced as part of the System unit, that is implicitly
always used as the 1st unit. If you use Math (or StrUtils or any other
modules that provide IfThen implementations), they will "cover" the
System.IfThen definition. So your code will continue to work as it was.

And the name like FpIfThen look rather ugly, actually. As far as I'm
concerned, IfThen sounds simple and Ok.

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

Re: [fpc-pascal] GLExt crashing

[Michalis Kamburelis]

Ryan Joseph wrote:
> Is it available in any version before 2.0 do you know? I don’t know
> much about OpenGL but there is a 1.5 version also which maybe has
> it.
> 

Before OpenGLES version 2.0 (shader pipeline), you only have OpenGLES
1.1 and OpenGLES 1.0. See https://en.wikipedia.org/wiki/OpenGL_ES and
https://www.khronos.org/opengles/1_X/ . Although OpenGLES 1.1 was based
on (desktop) OpenGL 1.5, which included glBlendEquation (you can see it
in https://www.opengl.org/documentation/specs/version1.5/glspec15.pdf ).
But I guess glBlendEquation was not included in OpenGLES for simplicity
--- OpenGLES was, by design, a very "trimmed down" version of (desktop)
OpenGL.

And "glBlendEquation" is not available in OpenGLES 1.1. You have
"glBlendFunc" in 1.1, but it only allows you to specify blending
parameters, while blending equation is "hardcoded". Effectively,
OpenGLES 1.1 always behaves like

  glBlendEquation(GL_FUNC_ADD)

was called. You can see it e.g. by comparing glBlendFunc specifications
for 1.1 and 2.0:
- https://www.khronos.org/opengles/sdk/1.1/docs/man/glBlendFunc.xml ,
- https://www.khronos.org/opengles/sdk/docs/man/xhtml/glBlendFunc.xml

In 1.1 version, the equation is simply hardcoded, while in 2.0 it can be
configured by glBlendEquation.

Hmm, but there's this extension:
https://www.khronos.org/registry/gles/extensions/OES/OES_blend_subtract.txt
. If this extension is supported, you could load glBlendEquationOES
function, which should be what you need.

I'm not sure why the thread on
http://stackoverflow.com/questions/17457327/blending-issue-porting-from-opengles-1-0-to-2-0-ios
suggests that glBlendEquation was used in OpenGLES 1.1. Maybe it's an
Apple extension that, once you have OES_blend_subtract, you can load
entry point "glBlendEquation", without "OES" suffix? Or maybe the poster
on stackoverflow just simplified his/her code, to simplify the question?

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

Re: [fpc-pascal] GLExt crashing

[Michalis Kamburelis]

Ryan Joseph wrote:
> Just tested on iOS and I get that error. I think on iOS it loads from the 
> OpenGLES.framework and therefor this is failing. Also that load function 
> wasn’t available but it failed upon including the GLExt unit.
> 
> An unhandled exception occurred at $0001000CDEF7:
> Exception: Could not load OpenGL from 
> /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib
>   $0001000CDEF7
>   $0001000D0F85
> 
> 

Um, GLExt is for OpenGL, it loads OpenGL extension, *not* for OpenGLES.
For Android and iOS, use GLES20 unit. My Castle Game Engine uses this
for Android and iOS and it works cool:)

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

Re: [fpc-pascal] GLExt crashing

[Michalis Kamburelis]

Ryan Joseph wrote:
> I’m using OpenGLES 1.1 because it was easier to learn but I don’t see
> glBlendEquation being included in the GLES11 unit. Maybe it didn’t
> exist until OpenGLES 2.0?
> 

Indeed, glBlendEquation is simply not available in OpenGLES 1.1.

See the specs: https://www.khronos.org/opengles/ , e.g. the list of
OpenGLES 1.1 functions on
https://www.khronos.org/opengles/sdk/1.1/docs/man/ .

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

Re: [fpc-pascal] FreeGLUT on Windows

[Michalis Kamburelis]

Ryan Joseph wrote:
> I’m trying to learn some basics of Windows and porting some OpenGL
> code. The first step is getting an OpenGL context prepared but I’m
> already stuck here.
> 

I would recommend our Castle Game Engine
http://castle-engine.sourceforge.net/ . It can be used together with
Lazarus form (as TCastleControl, descendant from Lazarus TOpenGLControl).

Or you can use CastleWindow unit, which gives you a window with OpenGL
context, without any Lazarus/LCL dependencies. It includes TCastleWindow
class, which is kind of "modern and object-oriented GLUT". It works on
Linux, Windows, Mac OS X, Android, iOS...

You can use there high-level Castle Game Engine features for 2D and 3D
rendering, but you can also write your own direct OpenGL calls in
TCastlewindow.OnRender, OnOpen, OnClose and such callbacks.

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

Re: [fpc-pascal] Castle Game Engine 5.0.0 release

[Michalis Kamburelis]

Reimar Grabowski wrote:

On Sat, 03 May 2014 21:35:17 +0200 Michalis Kamburelis
michalis.ka...@gmail.com wrote:

The main engine site, with detailed list of features, links to
downloads and documentation, is on

http://castle-engine.sourceforge.net/engine.php


First I have looked everywhere but not found how physics are handled.
It does not look like there is an integrated engine but I have not
found any documentation on how and which external engines can be used
either. Can you tell me where to find the information?


We do not integrate yet with any physics engine. I know it's important 
(and fun!), and it is planned for the near future (for 5.1.0 or 5.2.0) 
release. See also 
http://castle-engine.sourceforge.net/forum.php#section_developers . 
Right now, we have our own collision detection and gravity, but without 
any real physics fun.


Contributions are very, very welcome here of course :) You could also 
implement physics integration on top of the engine, in principle you 
don't need to modify the engine, just animate the transformation 
hierarchy. (Although in practice integrating physics more tightly with 
the engine will surely be nice.)



Second I am not sure that I understood correctly what kind of
animations are supported. If I export my animations from blender, can
I export the armature (bones) and get access to them in your engine
or is it only key frame animation. Key frame animations would not be
enough for me since at least some animations need to be physics based
and not predefined.


We support various animations in VRML/X3D using interpolators, we also 
support H-Anim skeletal and skinned animation ( 
http://castle-engine.sourceforge.net/x3d_implementation_hanim.php ).


However, current exporter from Blender-X3D does not export Blender 
animations in any way to X3D... As a solution, for now, you can export 
Blender animations to KAnim ( 
http://castle-engine.sourceforge.net/blender.php ), which is really just 
a sequence of 3D models that is intelligently merged by engine when 
loading. IOW, that is a short-coming of the current Blender X3D exporter 
(which I hope will be fixed one day, maybe even by me :)).


So, if you wonder about using the existing Blender-X3D exporter: it 
currently just does not export animations. If you think about writing 
your own Blender-X3D exporter (or improving the existing one), then you 
could export the animation from Blender however you like to standard X3D 
and the engine will take them :)


However, like said above: the integration with physics engine is not 
done yet, so you will not get physics-based animation (like rigid 
bodies) anyway. For now!


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

[fpc-pascal] Castle Game Engine 5.0.0 release

[Michalis Kamburelis]

Hi everyone,

We're proud to announce the release of Castle Game Engine 5.0.0 :) 
Castle Game Engine is an open-source (LGPL) 3D and 2D game engine, of 
course for modern Object Pascal (FreePascal / Lazarus). We support many 
3D formats and various graphic effects. The main engine site, with 
detailed list of features, links to downloads and documentation, is on


  http://castle-engine.sourceforge.net/engine.php

The main feature of 5.0.0 release is the support for Android and iOS 
(iPhone, iPad) platforms. We use OpenGLES 2.0 renderer underneath, and 
our engine can render on Android/iOS almost the same things as on normal 
desktop systems :) Thousand thanks go the FPC team for making it all 
possible.


Other new engine features include nice 2D API (although the engine 
started as a 3D engine, it's very comfortable now to make pure 2D games 
too) and new font reading and rendering (using FreeType).


Check out also Darkest Before the Dawn 
http://castle-engine.sourceforge.net/darkest_before_dawn.php , our first 
game done for Android :)


The details about new engine features are on 
http://castle-engine.sourceforge.net/news.php?id=2014-05-01 .


There is also a wiki page documenting Android specifics: 
https://sourceforge.net/p/castle-engine/wiki/Android%20development/ and 
iOS specifics: 
http://sourceforge.net/p/castle-engine/wiki/iOS%20Development/ .


Engine usage tutorial is on 
http://castle-engine.sourceforge.net/tutorial_intro.php and API 
reference is on 
http://castle-engine.sourceforge.net/apidoc/html/index.html .


Have fun!
Michalis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExtractFilePath and \ as pathdelim

[Michalis Kamburelis]

Mattias Gaertner wrote:

Hi all,

ExtractFilePath and ExtractFileDir stops at last '/','\', so it treats the
normal character \ as path delimiter under Unix.

Is there a RTL function that handles the \ as normal character?



You can change global AllowDirectorySeparators 
(http://www.freepascal.org/docs-html/rtl/system/allowdirectoryseparators.html 
) to exclude '\' on non-Windows. I do this in my engine:


  {$ifndef MSWINDOWS}
  AllowDirectorySeparators -= ['\'];
  {$endif}

This way ExtractFilePath and friends behave correctly on non-Windows.

And I really, really wish this would be changed in FPC too... That is, 
AllowDirectorySeparators should be ['/'] on Unix, not ['/','\']. 
Backslash is a completely normal character in Unix filenames. The 
default value of AllowDirectorySeparators variable *should* be 
OS-dependent, just like PathDelim and others.


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

Re: [fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes

[Michalis Kamburelis]

Michael Van Canneyt wrote:

The above implementation should not be changed, it is Delphi compatible:
TStream.ReadBuffer works on the assumption that Read will always return
the amount of bytes requested if they are available.

So, if you want to make changes, there is no reason why TStream.Read
should not benefit from 'trying harder', it could try harder to actually
get the requested number of bytes from the underlying low-level
implementation. Some TStream descendents already work that way
(compression, hash, encoding), others don't.

This in turn means that affected TStream descendents such as TFileStream
or THandleStream should try harder to read the requested number of
bytes, taking into account the
specifics of the underlying file/socket/whatever protocol.



In effect, you want to change all the streams Read method 
implementation, such that it returns less than requested Count *only* 
when the stream actually ended...


What about socket streams that potentially download the data? Or 
THandleStream streams that *may* read/write data from/to a pipe, like 
stdin/stdout, and may have to wait for another process? Should their 
TStream.Read really hang, waiting for Count data?


1. See Ewald objections. Like Ewald, I also think it is useful to have a 
TStream.Read that only returns the amount of data that is immediately 
available (and hangs only when no data is available yet).


2. This would be large work, IMHO... I propose to fix a single 
TStream.ReadBufffer implementation (well, and TStream.WriteBuffer). You 
propose to fix Read method in all stream descendants, inside and outside 
FPC sources.


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

Re: [fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes

[Michalis Kamburelis]

Michael Van Canneyt wrote:

If an implementation of Read does not return the requested data when in
fact it is available, then the implementation of Read is broken.


I guess it depends how do you interpret TStream.Read documentation... 
http://www.freepascal.org/docs-html/rtl/classes/tstream.read.html does 
not explicitly say that TStream.Read returns less than requested Count 
*only when the stream ends*. And I saw a lot of code working under the 
assumption that only when TStream.Read returned zero - then the stream 
ended.


If you want to put stricter requirements on TStream.Read, I suggest to 
update the docs to explicitly say this.




Your proposal is a quick and dirty hack that does not address the real
problem.


Whether it's a hack or not really depends on your definition of correct 
TStream.Read implementation.


My proposal is also a single solution that will make ReadBuffer correct 
for all the eternity.


Your proposal means that we have to fix THandleStream (Read and Write), 
which is definitely broken according to your requirements. Then we check 
TGZFileStream (I'm not sure whether it's already correct; it is 
definitely incorrect if gzRead in PasZLib is equivalent to gzRead inside 
C Zlib). And then every time I use another TStream implementation I'll 
have to check whether it's Read method is trying hard enough. 
TStream.Read that doesn't try hard enough is a very sneaky bug, since it 
will often work by accident (if reading small enough data).


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

[fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes

[Michalis Kamburelis]

Hi,

I'm often reading fixed-size structures using TStream.ReadBuffer, 
working under the assumption that it will fail only if it's not possible 
to read the requested amount of bytes (that is, if the stream ended 
prematurely). This is actually the documented usage, see 
http://www.freepascal.org/docs-html/rtl/classes/tstream.readbuffer.html 
and see many usage examples of ReadBuffer in FPC, Lazarus etc. sources. 
I'm using various stream classes in my code (TFileStream, TGZFileStream, 
TMemoryStream, TBase64DecodingStream...) and I always depend that 
ReadBuffer will work correctly for all streams.


But in some hardly-reproducible cases sometimes ReadBuffer fails even 
though I know I have more bytes. Looking at the sources, I was surprised 
to see this ReadBuffer implementation (in rtl/objpas/classes/streams.inc ):


procedure TStream.ReadBuffer(var Buffer; Count: Longint);
begin
   if Read(Buffer,Count)Count then
 Raise EReadError.Create(SReadError);
end;

This is quite incorrect, IMHO. The TStream.Read implementations of 
various streams can sometimes return less Count than requested, and 
that's Ok, and that doesn't mean that stream ended. Stream ended only 
when TStream.Read returns exactly zero.


Which means that ReadBuffer should retry calling Read, in a loop, trying 
to finish the reading. ReadBuffer should raise an exception only when 
Read returns zero (before we can gather all the Count bytes).


Right now, the way I see it, a lot of the code using ReadBuffer works 
purely by accident. At least if it's supposed to work with any TStream 
descendant.


For example: on Linux, TFileStream.Read calls fpRead which is a system 
call, and it definitely can return less than requested amount of bytes, 
and it doesn't mean that stream ended. (See e.g. Libc docs: 
http://www.gnu.org/software/libc/manual/html_mono/libc.html#I_002fO-Primitives 
: If read returns at least one character, there is no way you can tell 
whether end-of-file was reached. But if you did reach the end, the next 
read will return zero. ) So if you use TFileStream with ReadBuffer, 
your code is working purely by accident right now...


If you agree, I can provide a patch to ReadBuffer (and similar to 
WriteBuffer).


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

Re: [fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes

[Michalis Kamburelis]

Ewald wrote:

And what with non-blocking pipes pipes? Wait for a *some* period
until you get all data? It is up to the programmer to do this INHO.


If you want to get partial data (instead of waiting until all requested 
data is available) you should just use TStream.Read instead of 
TStream.ReadBuffer. Then it's indeed up to the programmer to handle this.


All existing usage of ReadBuffer right now works only if you get all the 
data in a single Read call (which translates to a single read syscall on 
Linux, as far as I see), otherwise it fails with exception. That's just 
wrong behavior for a ReadBuffer IMHO.



Also, if you would enforce this behaviour on all kinds of streams,
you might (`will`, actually) get unexpected performance drops...


I don't see why you would get any performance drop. If you're lucky and 
a single Read call is all you need, then the speed is the same as 
current implementation, since the 1st check if Read(Buffer,Count)Count 
then will return false and we will not call Read again.


Besides, we're talking about correctness here. And TStream.ReadBuffer is 
non-virtual and must be suitable for all TStream descedants, handling 
whatever virtual TStream.Read does.






For example: on Linux, TFileStream.Read calls fpRead which is a
system call, and it definitely can return less than requested
amount of bytes, and it doesn't mean that stream ended. (See e.g.
Libc docs:
http://www.gnu.org/software/libc/manual/html_mono/libc.html#I_002fO-Primitives
: If read returns at least one character, there is no way you can
tell whether end-of-file was reached. But if you did reach the end,
the next read will return zero. ) So if you use TFileStream with
ReadBuffer, your code is working purely by accident right now...



But if you work with a blocking fd (which, for example, a TFileStream
uses IIRC) you will always get your data. If there is more data to be
read(), but it would take time, it simply takes time. The only case
where zero is returned, is IIRC (like you quoted) when the end of the
`fd` (e.g. pipe, socket, file) is reached on *blocking
filedescriptors*.


Yes, zero is returned only if stream ends. But a result that is 
non-zero, but still less than requested Count, doesn't tell you if the 
stream ends. The whole point is whether ReadBuffer should take this into 
account.



FYI: I've never had the problem of a `partial read` (e.g.
SomeStream.Read(50) returning 36 or something) on linux, osx and
windows; so perhaps you have exposed some bug in an obscure TStream
descendant?



Reproducing this behavior proved to be difficult, but I definitely 
observed it with TFileStream on Linux.


And, even if it would accidentally work for some streams, that's not a 
solution. Like I mentioned, TStream.ReadBuffer is non-virtual and must 
be suitable for every TStream.


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

Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

[Michalis Kamburelis]

Flávio Etrusco wrote:

Members refer to each available section according to the flags.
Re-read this whole paragraph you posted and a few following you'll
realize only one file is allowed in a gzip file/blob.



I think this confusion comes from the fact that 
http://www.gnu.org/software/gzip/manual/gzip.html#Advanced-usage says 
clearly that Multiple compressed files can be concatenated. It doesn't 
mean that gzip is a good format to keep multiple-file archive (for this 
you should use tar), as multiple compressed files will be decompressed 
to a single stream on output.


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

[fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

[Michalis Kamburelis]

Hi,

Like the subject says, I'm looking for a TStream implementation that 
takes another TStream and compresses/decompresses data in gzip format. I 
would like to read/write gzip data to a stream, any TStream (maybe 
TFileStream, maybe TMemoryStream, maybe a stream from the network like 
TSocketStream, etc.).


One would think that the ZStream unit will contain something like that, 
but it does not. ZStream has:


- TCompressionStream and TDecompressionStream, but they use the deflate 
format, which is different than gzip format (gzip format at least 
adds some headers around). So you can't use them to directly read/write 
data from a xxx.gz file.


- TGZFileStream, which does use the desired gzip format... but it can 
only read local files (constructor takes just a FileName parameter). It 
cannot read from/to another stream.


Is there a stream class that satisfies both these conditions 
simultaneously (uses gzip format and can read/write to another TStream)?


Offtopic: I probably would avoid the ZStream unit anyway, as it uses 
PasZLib, which is a Pascal rewrite of the old zlib code. I would prefer 
to rather use ZLib unit (that links to a Zlib library, usually in 
so/dll/dylib) instead. Reasons are security (the C zlib library is 
probably more maintained than gory internals of paszlib) and because I 
have to distribute Zlib library anyway (libpng depends on it, and I use 
libpng).


Google found an old thread on lazarus mailing list about this (FPC, 
gzip and stream) but without any solution, everything mentioned there 
has either the limitations of TCompressionStream/TDecompressionStream 
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal 
streams).


Thanks in advance for answers,
Michalis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

[Michalis Kamburelis]

José Mejuto wrote:

El 27/03/2013 19:22, Michalis Kamburelis escribió:


Google found an old thread on lazarus mailing list about this (FPC,
gzip and stream) but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).



Hello,

.gz is a quite simple format, but it can not be implemented as a TStream
(only) descendant because in a single .gz file many files could be added
so something like the class to handle .zip files should be used.


The existing TGZFileStream in ZStream unit already shows that it can be 
implemented, i.e. TGZFileStream reads gzip data and is a TStream 
descendant. I assume that TGZFileStream simply returns the first file 
inside a multi-file gzip (otherwise it would need to call gzopen 
multiple times, as far as I understand).


This is also my use case: I know that my .gz files should contain only 
one file (X3D standard guarantees it for me), I want to ignore the 
remaining files (if any).




Parsing the .gz header is easy, and calling TCompressionStream and
TDecompressionstream over the payload should be easy, but only for the
first file in the .gz



I will probably have to implement it then. I was hoping to have 
something available ready, since ZStream contains things that are *so* 
close (but not quite) to what I want :)


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

Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

[Michalis Kamburelis]

Justin Smyth wrote:

I have converted the one from fpc to its own library to do streams , can
email it to you later if you wish


Yes, that would be appreciated. As long as everything you send me is 
covered by the same license as FPC RTL (LGPL with static linking 
exception), so that I can use it in my own code and also contribute it 
back to FPC :)


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

Re: [fpc-pascal] what happened to the contributed units listing?

[Michalis Kamburelis]

Michal Wallace wrote:

The database of contributed pascal code seems to have disappeared:

http://www.freepascal.org/contrib/db.php3

Anyone know where it went, or how to get it back? :)



It's on http://www.freepascal.org/contrib/contribs.html now. But some 
pages may still contain old links, see 
http://bugs.freepascal.org/view.php?id=23769 .


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

Re: [fpc-pascal] [Announcement] Castle Game Engine 4.0.0 release for FPC game developers

[Michalis Kamburelis]

Victor Matuzenko wrote:

Hi,

I have tried to compile it under Windows XP with «make all», and got the
errors:


[...]

Compiling src\opengl\windows\castleglwindowsfonts.pas
castleglwindowsfonts.pas(81,22) Error: Incompatible types: got
LongWord expected TWinCharSet


A bug slipped into the release, unit castleglwindowsfonts.pas didn't 
compile. You can either:


1. Comment out the line

  P.Targets.AddUnit('castleglwindowsfonts.pas');

inside fpmake.pp. This unit is not used by anything else, so everything 
will still compile and work Ok.


2. Or use latest engine 4.0.1 release, where this was corrected :) 
Download link is from the usual page 
http://castle-engine.sourceforge.net/engine.php .


Background: The CastleGLWindowsFonts unit is a little obscure, it was 
not used by any example program, it's not part of Lazarus packages and 
it's Windows-specific --- that is why this bug went unnoticed, I didn't 
test fpmake compilation on Windows. In 4.0.1 this is fixed, and the unit 
is also tested by one example program, so this bug will not happen again :)


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

[fpc-pascal] [Announcement] Castle Game Engine 4.0.0 release for FPC game developers

[Michalis Kamburelis]

Hi,

I would like to announce a release of Castle Game Engine 4.0.0, an 
open-source cross-platform 3D game engine for Object Pascal (only 
FPC/Lazarus):


  http://castle-engine.sourceforge.net/news.php?id=release-4.0.0

I'm letting myself post an announcement to lazarus and fpc-pascal 
mailing lists, as this engine release is really directed at ObjectPascal 
developers: we finally have a nice high-level game engine API, it's 
possible to make a 3D game really trivially easy, and everything is also 
very flexible. We also have a lot of new engine documentation (tutorial, 
classes overview etc.) and useful examples.


The engine reads many 3D model formats, focusing on VRML/X3D standards 
(so you can make 3D models in pretty much every 3D modeling software), 
but also supporting Collada and other popular formats. We use OpenGL for 
graphics, and we have many eye-candy features (shadows, mirrors, bump 
mapping, screen effects, shaders etc.). The engine is basically 
integrated into Lazarus (you can drop TCastleContol, and a couple of 
non-visual components, on the Lazarus form), although it can also be 
used without LCL (we have our own TCastleWindow). The engine license is 
modified LGPL (same license as FPC RTL), so you can make both open- and 
closed-source games with it.


We welcome developers that want to use our engine, and/or contribute of 
course :) If you want to make a game using our engine, give it a try :)


Links to downloads and documentation are on

  http://castle-engine.sourceforge.net/engine.php

Links to our tools and old games are on the main page, 
http://castle-engine.sourceforge.net/ .


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

Re: [fpc-pascal] Brook 1.0 - A new framework for web was born

[Michalis Kamburelis]

michael.vancann...@wisa.be wrote:

On Sun, 16 Dec 2012, Graeme Geldenhuys wrote:


On 15/12/2012 21:22, Sven Barth wrote:


Maybe because the authors prefered inline comments instead of fpdoc's
XML files...


A shame, because the more detailed the documentation, the more it
obfuscates the code.

eg: Documentation Insight, a popular Delphi IDE plugin for documenting
frameworks from inside the IDE's most requested feature... external
documentation files because good documentation means lots of text and
examples, thus lots and lots of code obfuscation.


Exactly the reason why fpdoc uses external XML.

A pasdoc-to-fpdoc conversion is on my TODO list. (tracker item 325689871
;))



(We're getting off-topic from Brook, sorry...)

A couple of answers (from the position of both PasDoc user and developer):

1. Although I personally prefer pasdoc, I was also thinking about 
implementing pasdoc output that produces fpdoc-compatible XML. This is 
quite easy to do in pasdoc (e.g. see our existing simplexml output), 
so if you want to do it this way, patches are surely welcome :) I wrote 
about it on http://pasdoc.sipsolutions.net/MichalisKamburelis#Fpdoc_output .


2. As for the discussion about whether it's better to have docs inside 
comments or as a separate files:


2.1. For what it's worth, you can place descriptions in separate files 
and still use PasDoc, see 
http://pasdoc.sipsolutions.net/ReadDescriptionFromFile . Whether this 
format is cleaner or not than fpdoc's XML file is up to the debate, 
anyway you *can* use separate files for the documentation. We also have 
features like introduction/conclusion where you write completely 
separate pages using pasdoc markup.


2.2. As for whether it's better to place documentation in comments or in 
separate files, I wrote about this on 
http://pasdoc.sipsolutions.net/MichalisKamburelis#Should_documentation_be_placed_inside_units_interface.2C_or_in_separate_files_.3F 
. And I still believe that generally the answer is it is a matter of 
taste.


It comes down to the fact that I don't mind having a large unit 
interface with long comments inside. I don't see this as code 
obfuscation, I see my comments and examples as crucial and useful 
information that I want to keep together with the interface. You no 
longer can easily see the list of all your methods at a glance, but 
you can see them in the pasdoc output, so no loss.


And the big advantage of keeping documentation inside source code is 
that it makes documentation easier to keep synchronized with code. 
Patches to the source code often naturally contain also changes to the 
related documentation in the interface. This keeps docs very up-to-date 
in my experience, which also means complete. YMMV of course, but I 
definitely know examples of PasDoc-produced documentation where it's 
very complete and useful.


With documentation in a separate file, there is a risk that you will see 
writing documentation as a separate task, where you need to go edit 
these other files. In such case, chances of getting contributions that 
update both the source *and* the relevant documentation are much lower, 
at least in my experience.


One practical note is also that documentation in source code approach 
is used by many tools in a lot of other languages too: Doxygen, 
OcamlDoc, JavaDoc, PhpDoc... Languages like Python and Lisp even 
recommend to place docs inside special strings in code (not just 
comments). So, somehow this approach can work Ok :)


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

Re: [fpc-pascal] Brook 1.0 - A new framework for web was born

[Michalis Kamburelis]

luciano de souza wrote:

Yes, there is a very nice tool. Its name is Pasdoc. Take a look here:
http://sourceforge.net/projects/pasdoc/
For this project, the author has changed the source code of Pasdoc.
Originally, it's compatible only with HTML 4, but the documentation
was released in HTML 5.




And the improvements will be (I'm counting on it :) contributed back to 
PasDoc and available in it's next version, see 
http://sourceforge.net/p/pasdoc/feature-requests/50/ :)


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

Re: [fpc-pascal] header translation question, 64 bit problem

[Michalis Kamburelis]

Bernd wrote:

(Almost) The only other small discontinuity was the PNG writer from
fcl-image needs to be explicitly told Indexed:=False on 64 bit while
on 32 bit this was not necessary.



Indexed is false by default in FPC = 2.6.1, see BTW and notes in 
http://bugs.freepascal.org/view.php?id=21835


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

Re: [fpc-pascal] Re: Playing sounds with standard components

[Michalis Kamburelis]

luciano de souza wrote:

I took a look in Openal examples. I need to confess that I expected
something easier. Perhaps, something like:

PlaySound('file.wav', 0)



You need to wrap OpenAL a little to get something so simple.

In my Castle Game Engine (http://castle-engine.sourceforge.net/), I have 
SoundEngine wrapper, with which you can play sound like


  Buffer := SoundEngine.LoadBuffer(FileName);
  SoundEngine.PlaySound(Buffer, false, ...);

See working example in SVN on 
http://svn.code.sf.net/p/castle-engine/code/trunk/castle_game_engine/examples/audio/alplay.lpr


You may want to look at the source (LGPL) to see how it's done :)

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

Re: [fpc-pascal] Re: Playing sounds with standard components

[Michalis Kamburelis]

silvioprog wrote:

Nice project. :)

castle_game_engine-3.0.0-src.zip = +-70MB.



Most of the size comes from the examples, they contain also example 3D 
data files (models, animations etc.). I prefer to give people full 
package :) For those who want to get parts, they can always check out 
appropriate directories from SVN.



Hm... you could send only the files to play audio? :/


The directories src/base/ and src/audio/ from the engine source code 
should be all you need. And examples inside examples/audio/, and 
examples/3d_sound_game/ (only in SVN), are probably useful :) Note that 
if you only get a subset of src/ directories, you will need to prepare 
also special Lazarus package to compile them (as the default package 
inside packages/castle_base.lpk includes other units, to deal with 3D, 
images, scripting and such), or compile only with ./xxx_compile.sh 
scripts (Unix or Cygwin required). It will be easier to just get the 
full zip/tar.gz archive, and simply ignore (don't look inside :) 
directories that don't interest you :)


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

[fpc-pascal] FpProfiler patch to compile with fpmake

[Michalis Kamburelis]

Hi,

I'm not sure if anyone is actively watching the Mantis issues for 
FpProfiler, so I thought I'll mention it here: I submitted a patch to 
fix the compilation with fpmake from command-line. It's on


  http://bugs.freepascal.org/view.php?id=21991

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

[fpc-pascal] FPC + valgrind massif problems

[Michalis Kamburelis]

Hi,

I wanted to debug where my program uses the most memory. (There are no 
memory leaks, but I want to optimize memory usage on some large inputs. 
As the code is quite large, simply guessing which part is responsible 
becomes quite hard :) In the past, I happily used valgrind's massif tool 
for such job, and it worked like a charm. But now, FPC 2.6.0 with 
valgrind 3.7.0, it seems valgrind/massif has problems:


$ fpc -gv trivial_alloc.pas
$ valgrind --tool=massif ./trivial_alloc

--7286-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 
(SIGSEGV) - exiting

--7286-- si_code=1;  Faulting address: 0xFFF7;  sp: 0x6298914c
valgrind: the 'impossible' happened:
   Killed by fatal signal

(Full output and trivial_alloc.pas attached.)

The code is compiled with -gv option. It works very fine with valgrind's 
callgrind tool. So I suspect this is a problem with valgrind, 
specifically massif, not related to FPC. Also, it seems to fail the same 
way with older/newer FPC versions (I tried 2.2.4, 2.4.4, 2.6.0, and 
2.7.1 from today 2012-05-11). Probably, some valgrind version broke 
massif for FPC binaries.


So, questions:

1. I want to report this as massif's bug. Any ideas what more 
information should I provide to valgrind's developers? I don't know if 
they are familiar with FPC. And simple C examples work fine, so it's 
probably something specific in FPC binaries.


- Maybe this problem is already reported?

- Maybe there's a workaround? IOW, can someone successfully use massif 
with FPC programs?


2. Is there any other reliable memory profiler for FPC? As you can swap 
memory manager in Pascal, and FPC can give you a backtrace, I suppose 
it's quite possible to just write a unit that works between your program 
and standard memory manager, and tracks memory usage this way. This will 
only measure memory use of Pascal code (external libs don't go through 
FPC memory manager), but that would be very fine for me --- I know 
(well, I'm 99% sure) that my Pascal code is the main memory eater here.


I didn't find any (good and maintained) memory profiler mentioned on 
http://wiki.lazarus.freepascal.org/Profiling#Memory_Profiling . (I tried 
FpProfiler, but it depends on inserting instrumentation code into Pascal 
sources. That's actually a very nice idea, but it means it's closely 
tied to what fcl-passrc can handle. And current fcl-passrc still lacks a 
couple of features (reported). Also FpProfiler seems to use an older, 
local fcl-passrc version.)


Thanks,
Michalis
==7310== Massif, a heap profiler
==7310== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==7310== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7310== Command: ./trivial_alloc
==7310== 
--7310-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
exiting
--7310-- si_code=1;  Faulting address: 0xFFF7;  sp: 0x627fb14c

valgrind: the 'impossible' happened:
   Killed by fatal signal
==7310==at 0x38028524: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38060AB6: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x380635FD: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38024CA2: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38025542: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x3807560D: ??? (in /usr/lib/valgrind/massif-x86-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==7310==at 0x402428C: free (in 
/usr/lib/valgrind/vgpreload_massif-x86-linux.so)
==7310==by 0x416D4C4: __libc_freeres (in 
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so)
==7310==by 0x4020466: _vgnU_freeres (in 
/usr/lib/valgrind/vgpreload_core-x86-linux.so)
==7310==by 0x805F113: SYSTEM_SYSTEM_EXIT (in /tmp/trivial_alloc)
==7310==by 0x8058819: SYSTEM_DO_EXIT (in /tmp/trivial_alloc)
==7310==by 0x805FA66: SI_PRC__FPC_PROC_START (in /tmp/trivial_alloc)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
var
  P: Pointer;
begin
  P := GetMem(1000);
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Group arguments from overloaded functions in fpdoc

[Michalis Kamburelis]

dhkblas...@zeelandnet.nl wrote:

When you have overloaded functions, fpdoc will group them on one page.
The arguments however are listed in two separate arguments sections. It
would be nice to have the arguments merged in one section. I do not know
how to display the arguments though (no idea what others do like pasdoc
or doxygen).


As for pasdoc:

PasDoc currently doesn't group overloaded functions in any way for 
display. They are just treated like two (or more) separate functions. 
Yeah, this sucks, I agree. Everyone is welcome to submit feature 
requests and, even better, patches of course :) I had a plan to 
implement one day grouping, so that a group of identifiers can be 
nicely displayed together with a single description (this could be used 
for overloaded functions, and also for explicitly marked groups by 
@groupXxx tags, see 
http://pasdoc.sipsolutions.net/MichalisKamburelis#Support_for_groups_of_items 
). This is probably the most important missing pasdoc feature for me 
personally, but still there's never time to implement it.


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

[fpc-pascal] Patch to add GLX 1.4 support

[Michalis Kamburelis]

Hi,

For people working with new OpenGL features: I just submitted a patch
to upgrade our GLX unit to GLX 1.4, add some new GLX extensions, and
add comfortable functions to check existence of a particular GLX
extension/version. This allows you to easily use modern GLX FB
config functions to initialize OpenGL context, and to use
glXCreateContextAttribsARB to request forward-compatible OpenGL
context (without deprecated stuff). The patch is on

http://bugs.freepascal.org/view.php?id=19953

The patch contains also modifications to glxtest example, to show new
context creation approach. There's a good description of modern OpenGL
context creation in the opengl.org wiki, see
http://www.opengl.org/wiki/Creating_an_OpenGL_Context and
http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_%28GLX%29

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

[fpc-pascal] Supports() only checks declared interfaces?

[Michalis Kamburelis]

Hi,

Consider the attached source code. I have a base interface (IA) and a
descendant interface (IB). Class TB is declared as

  TB = class(TInterfacedObject, IB) end;

Now I would expect that both

  Supports(TB, IA)
  Supports(TB, IB)

return true. After all, TB is forced to implement methods of both IA and
IB, as IB descends from IA. But to my surprise, Supports(TB, IA) returns
false.

Changing the declaration to

  TB = class(TInterfacedObject, IA, IB) end;

workarounds the problem (Supports(TB, IA) returns true), but seems
strange in my opinion.

I haven't found any explanation for this e.g. in docs
(http://freepascal.org/docs-html/rtl/sysutils/supports.html ,
http://freepascal.org/docs-html/ref/refch7.html ).

Is this the expected behavior? Documented anywhere? Or is this a bug,
and I should submit it?

Thanks,
Michalis
{$mode objfpc}

uses SysUtils;

type
  IA = interface
  ['{5E3D46A0-71B5-4561-B6B4-43A5BE5896EF}']
  end;

  IB = interface(IA)
  ['{19D68914-F2BA-4CFA-90A1-F561DB264678}']
  end;

  TA = class(TInterfacedObject, IA) end;
  TB = class(TInterfacedObject, IB) end;

begin
  Writeln(Supports(TA, IA)); // true
  Writeln(Supports(TA, IB)); // false
  Writeln(Supports(TB, IA)); // should be true, but is false ??
  Writeln(Supports(TB, IB)); // true
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Supports() only checks declared interfaces?

[Michalis Kamburelis]

Paul Ishenin wrote:
 06.01.2011 20:14, Michalis Kamburelis wrote:
 return true. After all, TB is forced to implement methods of both IA and
 IB, as IB descends from IA. But to my surprise, Supports(TB, IA) returns
 false.

 This is expected behavior. It works the same way as in delphi.
 

Thank you.

So, the natural next question: is there some construct similar to the
Supports() function, that avoids this problem? That is, something that
detects that class TB supports both IA and IB interfaces, even though
it's declared only as TB = class(TInterfacedObject, IB) ?

Or is my only choice to just declare TB = class(TInterfacedObject, IA,
IB) ?

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

[fpc-pascal] Code to send message from Python script to FPC's TSimpleIPCServer

[Michalis Kamburelis]

Just sharing, in case someone will find the below information useful,
or worthy to add to some wiki or docs anywhere:

I have here a daemon written in FPC that communicates with clients by
very nice TSimpleIPCServer class (in SimpleIPC unit). Of course it's
trivial to send a message to such server from another FPC program (see
fcl-base/examples/ipcclient.pp). Turns out it's also trivial to send
a message from a Python program. Attaching the Python code. You can
probably easily add alternatives for any other programming language to
this :)

Note that this is specific to Unix, where SimpleIPC just uses a named
pipe, so it looks just like a writeable file (/tmp/server_name) to any
other process. I don't know how it looks for other OSes.

Michalis
#!/usr/bin/python

# Test that you can write from Python to ipcserver named pipe.
#
# FPC handles messages by very nice and comfortable FPC unit simpleipc.
# See packages/fcl-process/src/unix/simpleipc.inc.
# Message send/received is represented by
#
# TMsgHeader = Packed record
#   Version : Byte; // always MsgVersion = 1
#   MsgType : TMessageType; // actually anything, server ignores it,
#   // but convention says SendStringMessage sets MsgType = mtString = 1.
#   // TMessageType is just LongInt.
#   MsgLen  : Integer; // length in bytes of following data
# end;
#
# FPC hides this from ipcserver, but in Python program we have to be able
# to encode such thing by hand.

import struct

def send_to_daemon(s):
f = open('/tmp/ipcserver', 'wb')
f.write(struct.pack('b', 1) +
struct.pack('l', 1) +
struct.pack('l', len(s)) +
s)
f.close()

send_to_daemon('blah')
send_to_daemon('')
send_to_daemon('Testing messad asd asd asdf asdfa sdf 123')
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Looking for SDL_opengl header

[Michalis Kamburelis]

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.
 

SDL_opengl.h is just (one of the) cross-platform ways to include OpenGL
stuff in C programs. We don't need it in FPC, just use GL, GLU, GLExt
units as usual.

(BTW, Jedi-sdl indeed includes also a version of GL, GLU, GLExt units,
but these are (at least, were not) suitable for FPC. See my notes at the
bottom of http://wiki.lazarus.freepascal.org/Talk:FPC_and_SDL).

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

Re: [fpc-pascal] Detecting what is the linux distro

[Michalis Kamburelis]

Marco van de Voort wrote:
 If your distro complies with the LSB standards (most popular distros
 do), then you should have a /etc/lsb-release text file that you can
 parse.
 
 FC11, no such file, but there is a dir lsb-release.d with the contents
 

You're not really supposed to be looking at /etc/lsb* files directly.
Rather you should run lsb_release. Try lsb_release  --all. For the
short name of the distribution, something like lsb_release --id
--short is appropriate, see the manpage.

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

Re: [fpc-pascal] playing sound files (linux and windows)

[Michalis Kamburelis]

Graeme Geldenhuys wrote:

I can't find an example for loading a .wav file.

[...]


Any hints or sample code. The sample included in FCL 2.4.1 loads MAD, A52,
OGG and ModPlug only. Google revealed a tutorial using AlutLoadWavFile(),
but that is in the unofficial utilities library, it's not part of the
standard OpenAL 1.1 spec, and not included in Linux.



ALUT is included in Linux, although usually in a separate package 
(libalut*). ALUT is somewhat official, that is it's development is 
coordinated on the same mailing list and, although separate to openal,
I don't think it will die so soon :) ALUT spec is on 
http://connect.creativelabs.com/openal/Documentation/The%20OpenAL%20Utility%20Toolkit.htm


That said, loading uncompressed WAV files is quite easy, you can see my 
code on 
https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/kambi_vrml_game_engine/src/audio/soundfile.pas

Look for TSoundWAV.CreateFromStream method.

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

[fpc-pascal] fcl-passrc example program, and a couple of bugreports

[Michalis Kamburelis]

All the talk about the Pascal parser in fcl-passrc got me interested
recently. I did some experiments, and I thought I mention here:

1. I added a simplest example how to use fcl-passrc to the wiki:

http://wiki.freepascal.org/fcl-passrc

2. And reported a couple of bugs found in fpdoc (tested on PasDoc's
testsuite):

http://bugs.freepascal.org/view.php?id=16340
http://bugs.freepascal.org/view.php?id=16341
http://bugs.freepascal.org/view.php?id=16342
http://bugs.freepascal.org/view.php?id=16343
http://bugs.freepascal.org/view.php?id=16344
http://bugs.freepascal.org/view.php?id=16345
http://bugs.freepascal.org/view.php?id=16346
http://bugs.freepascal.org/view.php?id=16347

Some other failures were found (see the testcase: ok_dispid_method.pas,
ok_dot_unitname.pas in pasdoc svn), but these were language features not
handled by the FPC at all for now.

Also, program files are not parsed by fcl-passrc, it's limited to units
for now. We would like to be able to eventually parse program files too.
Yes, they make sense even in a documentation generator, since you can
then e.g. gather all units used  by the program and get your list of
units to make docs from there. An optional, sure (in general, we could
pick too few or too many units) but for some situations a useful feature
(not finished in PasDoc, but planned).

fcl-passrc is quite capable already, it successfully parsed a lot of
quirky sources, so it's really great already :) Hope my reports hope to
push it even better :)

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

Re: [fpc-pascal] some new features to delphi prisem

[Michalis Kamburelis]

ik wrote:
 On Sat, Feb 20, 2010 at 20:01, Jürgen Hestermann
 juergen.hesterm...@gmx.de mailto:juergen.hesterm...@gmx.de wrote:
 
 
 
 y := case Other of
 bla : 'hello';
 foo : 'bye';
 baz : 'adius';
   end;
 
 
 What do you gain with this?
 Doesn't look much different to
 
 
 case Other of
  bla : y := 'hello';
  foo : y := 'bye';
  baz : y := 'adius';
  end;
 
 
 Shorter write imho.
 

Which also means less chance of mistake. For example, if you decide
later to change y to y1, you only have to change the code in one
place, not three. Functional case and if are not only from Ruby,
also from all functional languages (sml, ocaml), also Python and even C
have functional if.

I'm not saying that this is some revolutional or essential feature.
But just because we can work without it doesn't mean it's totally
useless :)

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

Re: [fpc-pascal] some new features to delphi prisem

[Michalis Kamburelis]

Graeme Geldenhuys wrote:
 On 21 February 2010 17:00, Michalis Kamburelis michalis.ka...@gmail.com 
 wrote:
 Which also means less chance of mistake. For example, if you decide
 later to change y to y1, you only have to change the code in one
 place, not three.
 
 
 Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'?
 
   http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit
 
 You only need to change one variable, and all other instances will
 change to. And syncron-edit applies to any selection of text. So
 already works in more cases.
 

Which is cool, but only if you and all your contributors use Lazarus for
all your editing. The fact that Lazarus makes something easier should
not be a reason to reject the language feature.

 
 I vote against adding this language feature. It's not pascal-like and
 actually makes the code harder to read. It also only applies to simple
 assignment. Case begin..end blocks can do much more than simple
 oneliners.
 

This is a matter of taste, I can imagine uses when at least functional
if would make code *more* readable. Noone forces programmers to
convert all their case/if to functional versions if they look
unreadable. The functional variants are supposed to be used in
particular situations, when they make sense.

Mind you, I'm not saying I'm a fan or a big proponent of this feature.
I do not own Delphi since a long time, being happy with FPC, so I'm also
not interested in compatibility.

Mostly, I'm playing devil's advocate here :), and I didn't see yet
a good argument against this feature (and I see cases when it would be
useful). The fact that it makes some cases less readable doesn't count
here imho (because it's optional, and can make other code more readable).

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

Re: [fpc-pascal] Assigning class method to procedure of object via class name in delphi mode

[Michalis Kamburelis]

cobines wrote:
 everything is ok. But I can also assign it using class name:
 
   CM.Callback := TContextMenu.ContextMenuSelect;
 

This is the way it's supposed to work in delphi mode, as far as I
remember Delphi allows it (disclaimer: I don't have Delphi now to check,
but it used to be so around Delphi 7).

This has actually one useful feature: when ContextMenuSelect is a class
procedure, this is a safe and valid operation (class procedures can be
safely called by only a class reference, that's their point after all).
In objfpc I achieve the same by the unclean trick CM.Callback :=
TContextMenu(nil).ContextMenuSelect;

Unfortunately, the way it's implemented in delphi, it also allows this
very unsafe assignment when ContextMenuSelect is a normal (not class)
method.

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

Re: [fpc-pascal] [OT] which editor - emacs?

[Michalis Kamburelis]

Hans-Peter Suter wrote:
 
 PS: thanks also to the other suggestions! And if somebody uses Emacs I
 am still interested to hear about how it goes. Thanks again!

I use Emacs most of the time to edit my Pascal (and all other :) ) code.
But it has it's learning curve. And, although there are various
code-completion and code-browser features, not much Pascal-specific
support is available (e.g. no Pascal on
http://cedet.sourceforge.net/languagesupport.shtml). So you end up using
generic code completion (e.g. by dabbrev, or
http://www.emacswiki.org/emacs/AutoComplete), which is very dumb
compared to how Lazarus completes.

So if you want code features that need integration with Pascal code
(code browser, code completion etc.), go with what everyone says: Lazarus :)

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

Re: [fpc-pascal] OpenCL

[Michalis Kamburelis]

Lourival Mendes wrote:
 FPC/Lazarus. Is there a project on it? Is there some thing working on
 Parallel programming on FPC?

There are OpenCL bindings submitted to mantis,
http://mantis.freepascal.org/view.php?id=15297, by Dmitry Boyarintsev.
I didn't test them, as I don't have capable GPU (yet) :)
But I'm waiting with anticipation for them to be applied :)
(I was playing with CUDA some time ago, which had basically the same
goal, although was NVidia-only.)

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

Re: [fpc-pascal] Re: Link libglx library.

[Michalis Kamburelis]

Guillermo Martínez Jiménez wrote:
 Jonas Maebe wrote:
 -klglx (note the extra l).
 
 I tried that:
 
 fpc -02 -Sh -FUlib/ -klglx /exbasic.pp -oexbasic
 
 But it returns that error:
 
 /usr/bin/ld: lglx: No such file: No such file or directory
 
 I look for a dev package for GLX (libgl1-mesa-glx-dev?) but I can't
 find it. Which packages should I install on Ubuntu?
 

Because it should be -k-lglx (additional - inside). -k tells FPC to
pass -lglx to the linker, and -lglx tells the linker to link with
libglx.so.

But honestly, I think that you're running blind here. You should never
link explicitly to libglx.so anyway, on Ubuntu you have libglx.so inside
/usr/lib/xorg/modules/extensions --- which is not something that an
ordinary program should link with. Your program should not need to link
explicitly with any glx library. At least with FPC's glx.pp, the library
is loaded dynamically, and actually (under normal Linux, not Mac OS X
Darwin) glX functions are loaded straight from libGL.so. Note also your
error message:

./exbasic: symbol lookup error: /usr/local/lib/libagl.so: undefined
symbol: glXQueryExtension

This says something strange, the linker for some reason is looking for
glXQueryExtension inside libagl.so. What exactly is
/usr/local/lib/libagl.so? (It couldn't come from Ubuntu packages.) How
(and why) are you linking with glX?

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

Re: [fpc-pascal] Re: Link libglx library.

[Michalis Kamburelis]

I wrote:
 Note also your error message:
 
 ./exbasic: symbol lookup error: /usr/local/lib/libagl.so: undefined
 symbol: glXQueryExtension
 
 This says something strange, the linker for some reason is looking for
 glXQueryExtension inside libagl.so. 

Actually, re-reading this error message, it looks like libagl.so wants
to be linked with something that provides glXQueryExtension. Try to
compile with -k-lGL.

If you don't fear to modify the FPC's sources, you can also try to
change rtl/unix/dynlibs.inc to pass RTLD_GLOBAL to dlopen call, then
recompile rtl and packages. Then the symbols from libGL (this includes
glX symbols) should be available to libagl.so too.

Hope this helps,
Michalis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to use OpenGL 2.0 features

[Michalis Kamburelis]

Lord Satan wrote:
 
 Nonetheless, I don't understand why the ARB version does not work.
 AFAIK it has the same entry points as the core functionality and
 OpenGL versions are required to support the ARB version of functions
 even if the non ARB version is in the core now.
 

No. OpenGL doesn't have to support the extension entry points, even when
it supports the same functionality in core already. Vendor is free to
remove the extensions, and support only the core functions.

Also, sometimes when functionality is promoted from ARB extension into
core it's slightly changed (although in 99% cases it stays the same).
Example is the GLSL shaders, that expose (very slightly) different API
through ARB extensions and through core 2.0 specification.

Basically, what is exposed through extensions is completely orthogonal
to what is exposed through core functionality, so they should be
initialized separately. In particular cases, you can make tricks like

  if glIsBufferARB = nil then glIsBufferARB := @glIsBuffer;

but this should be left to the final programmer that knows that
ARB_vertex_buffer_object behavior is identical to how it works in core.

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

Re: [fpc-pascal] How to use OpenGL 2.0 features

[Michalis Kamburelis]

Lord Satan wrote:
 On Sun, 10 May 2009 18:46:26 +0400 dmitry boyarintsev
 skalogryz.li...@gmail.com wrote:
 
 So it looks like I have to init all OpenGL versions from 1.2 to
 2.0 to make sure that all OpenGL 2.0 core functions are
 initialized. Is this true?
 Judging from glext, it's true.
 This makes no sense to me. I can submit a patch so that all lower
 version functions are loaded when the higher version is loaded (hope
 it is understood what I mean). I already modified the glext file and
 just want to know if there is any interest or if the current
 behaviour has any advantages I fail to see.
 

You mean you want to change Load_GL_version_2_0 to also call
Load_GL_version_1_5 under the hood, and then Load_GL_version_1_5 to call
Load_GL_version_1_4 under the hood and so on? I guess that's Ok, go for it.

Be aware that this will *not* work for OpenGL 3.x versions, where 3.0
deprecates and 3.1 removes some functions. Since 3.1, OpenGL versions
are *not* guaranteed to be backwards compatible. Programmer will have to
call Load_GL_version_3_1 and Load_GL_version_2_0 (or check
ARB_compatibility) separately, since these are orthogonal.

I guess this is the advantage of current approach: it doesn't assume
that OpenGL versions are backwards compatible, and indeed they don't
have to be since 3.1.

But for GL 2.x and lower, sure, this will work fine.

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

Re: [fpc-pascal] How to use OpenGL 2.0 features

[Michalis Kamburelis]

Lord Satan wrote:
 On Sun, 10 May 2009 23:47:07 +0200
 Lord Satan reimg...@web.de wrote:
 
 I uploaded the patch to the bug tracker as issue #0013687
 

Looking quickly at the patch, it doesn't seem to set Result values
correctly. For example, all Load_GL_version_xxx will always return true,
if only the first Load_GL_version_1_2 will return true. If you call
Load_GL_version_2_0, it will do Result := Load_GL_version_1_5. If it
set Result to true, then Result will remain true --- even if some gl 2.0
function, like glBlendEquationSeparate, will not exist and cause Exit.

Change this e.g. to follow each
  Result := Load_GL_version_1_5;
by
  if not Result then Exit;
  Result := FALSE;
... to make sure that Load_GL_version_2_0 returns true *only* if both
Load_GL_version_1_5 succeeded *and* all functions on level 2.0 succeeded.

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

[fpc-pascal] Workaround for #0011837 (FPC = 2.2.2 with GTK = 2.13)

[Michalis Kamburelis]

In case someone wonders how to workaround this bug
  http://mantis.freepascal.org/view.php?id=11837
(occurs with GTK = 2.13.4, e.g. on Ubuntu 8.10 we have GTK 2.14):

I found that the quick workaround that works is to pass --noinhibit-exec
to ld, that is -k--noinhibit-exec to FPC command-line. The ld will
then treat unresolved references as mere warnings, and will produce
working executable (assuming your program doesn't actually call
obsoleted GTK2 functions).

Of course, you can also upgrade to FPC from SVN. Above workaround is
useful only if you have to stick to released FPC 2.2.2.

(I know, this is hardly a rocket science discovery :) Just sharing in
case anyone else struggles with this, seeing as this is very common
problem.)

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

Re: [fpc-pascal] regex unit doesn't find matches???

[Michalis Kamburelis]

Graeme Geldenhuys wrote:
 Hi,
 
 I'm using the following regular expression:   'foob.*r'
 Calling MatchString() against each of the items in the stringlist, I
 expected it to match 3 items. Instead it only matches the first item
 and fails all the rest.  Why???
 
 
 --[  source code ]---
   sl := TStringList.Create;
   sl.Add('1st foobr Item');
   sl.Add('2nd Item');
   sl.Add('3rd Item');
   sl.Add('4th foobaoeuaor Item');
   sl.Add('5th foobar Item');
 
   r := TRegexEngine.Create('foob.*r');
   x := 0;
   y := 0;

You should reset x, y within the loop (before each r.MatchString), not here.

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

Re: [fpc-pascal] number of cpu cores

[Michalis Kamburelis]

Florian Klaempfl wrote:
 Mattias Gaertner schrieb:
 I need a default value of the number of maximum threads.
 Is there already some RTL function that can be used for that?

 For example if the program runs on a 2 x quad core it would be nice to
 get 8.
 Hyperthreading multipliers should be applied.
 
 No, but having some functions returning information about the CPUs would
 be nice.

Blender (http://www.blender.org/) source code has function to do that
(they needed this to set the default number of threads for renderer). So
you could try converting to Pascal the code of BLI_system_thread_count
function from:

https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenlib/intern/threads.c

Doesn't seem that complicated on 1st look. It's basically appropriate
GetSystemInfo call on Windows, sysctl on Mac OS, and sysconf (from Libc)
call on most Unixes.

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

[fpc-pascal] Unable to authenticate to update entry in contributed units

[Michalis Kamburelis]

Hi,

I just added an entry to contributed units (Kambi VRML game engine). 
Of course, two seconds later I wanted to correct it. But I can't --- 
looks like I cannot authenticate. And it seems it's a bug, not my bad 
memory. When I input my current (both now and at the time of submitting 
the entry) community username (just my email, 
[EMAIL PROTECTED]) and passwd, the system answers


No user match
Warning: Authentication failed.
Sorry, but the password you provided doesn't match the password in the 
database.



Funny thing is, when I really input wrong password or username, the 
answer is different: I get


Username not known in community system, please create an account first, 
or verify password


So it looks like it did recognize my correct password at some point, but 
then went bad?


Of course, I can login to community site with my password. It may be 
important to mention that a couple of minutes before submitting to 
contributed units I actually changed my email and password on 
community. I tried updating on contributed units with both my old and 
new passwords, and none works.


While I'm at it, some more issues with contributed units that I want 
to mention:


1. No email was generated, neither to fpc-announce nor to my private 
email. But I left both checkboxes on (Send me a mail with 
confirmation., and Send a mail to the announcement mailing list.) 
when submitting my entry.


2. Could we please get more space in the File URL: field? It's 
currently limited to 80 characters (which is actually what I wanted to 
correct in my particular entry, I pasted the URL and it got cut to 80 
characters, cutting of .gz extension from the URL and making it invalid).


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

Re: [fpc-pascal] Save image into BMP or JPEG using Free Pascal (Save screenshot of OpenGL scene)

[Michalis Kamburelis]

Marco van de Voort wrote:

Jakub Marian wrote:

The image format in the memory is clearly specified, as the main use of 
this unit is to cooperate with OpenGL (for loading images, textures, 
saving screenshots etc.). See TImage class comments, basically RawPixels 
is simply a pointer to an array of Width * Height pixel values, and each 
descendant of TImage specifies the exact layout of pixel --- e.g. for 
TRGBImage a pixel is just 3 bytes, for red/green/blue.


Is the latter a hard requirement of OpenGL? In the fpimage rework, I had
hoped to skip 24-bit color and use 32-bit for that.


There is GL_RGBA format, combined with GL_UNSIGNED_BYTE this makes 32 
bit pixel (with the last byte for storing alpha --- depending on what 
you actually do with your image data, you may be able to simply ignore it).




Also, does OpenGL support bottom up (lines other way around in memory)
layouts, or only top down?


AFAIK, no. That is, OpenGL images always have the lowest row first in 
the memory. Everyone simply swaps the rows in memory for OpenGL, since 
all image formats have this the other way around.


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

Re: [fpc-pascal] GLext in Free Pascal does not work?

[Michalis Kamburelis]

Jakub Marian wrote:

Hello, I've been trying to solve the problem with the unit GLext for some
time and I am getting mad. I need to use vertex shaders written in GLSL, but
I am a novice in that field so I may be doing domething wrong. I have glext
in my uses. I tried just to call glCreateProgramObjectARB but I've got
access violation in my program. So I looked into source of glext and there
are some functions which look like I could use them. So I tried
glext_LoadExtension('GL_version_1_4'). Same problem - access violation. So I
tried glext_ExtensionSupported with some parameters. Access violation. I am
really getting mad, I have no idea what to do. 


I am really opened to any suggestions :-)



glCreateProgramObjectARB is part of GL_ARB_shader_objects extension (see 
OpenGL extension registry on opengl.org). So what you want to call is

  Load_GL_ARB_shader_objects
or (equivalent)
  glext_LoadExtension('GL_ARB_shader_objects')
They both return boolean value, if true --- then your OpenGL supports 
this extension, and glCreateProgramObjectARB entry point is initialized 
to non-nil and you can call it without any access violations.


glext_LoadExtension('GL_version_1_4') loads OpenGL features that are 
standard in OpenGL 1.4, this has nothing to do with 
glCreateProgramObjectARB (ARB suffix says this is an extension).


OpenGL 2.0 introduced shaders as standard, so you may want to call 
Load_GL_version_2_0 and then use glCreateProgram instead of 
glCreateProgramObjectARB. But for now, using extension is a little safer 
(more chance that given OpenGL implementation will support it).


Oh, and if you have downloaded my engine mentioned in previous mail --- 
see kambi_vrml_game_engine/opengl/glshaders.pas, this is my unit for 
handling OpenGL shaders, see TGLSLProgram class.


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

Re: [fpc-pascal] GLext in Free Pascal does not work?

[Michalis Kamburelis]

Jakub Marian wrote:

Well, glext_LoadExtension('GL_version_1_4')  was just an example, of course
that I tried Load_GL_version_2_0 and some other functions. But I get access
violation when I try to call ANY function from glext. I would understand it
if I got just false as a return value of a function... But the program goes
down with Access violation message written into command line window. For
example if I call Load_GL_version_2_0, I get:

An unhandled exception occurred at $100279D9 :
EAccessViolation : Access violation
  $100279D9
  $0040769D



Ah, are you on x86_64 ? Then you're affected by 
[http://bugs.freepascal.org/view.php?id=10508], it's fixed in SVN.


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