Re: [fpc-pascal] First Version Vector Toolkit in OpenGL

[Benjamin Rosseaux via fpc-pascal]

I'm curious to see how it compares with my vector-based UI framework stuff
at PasVulkan ( https://youtu.be/YR0KruyQbx4 ), where the GPU itself renders
everything by shader, where nothing is bitmap-based, if one ignores the 2D
vector signed distance field textures for fonts and so on. The CPU pushes
just roughly basic draw information to the GPU, where the fragment
übershader itself applies the corresponding design look with help of 2D SDF
math in an always antialiased way then.

On Wed, Nov 3, 2021 at 11:45 AM Anthony Walter via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> @code
>
> It's a bit weasely to claim immediate or retain based on how the
> underlying implementation works. The UI toolkit is drawn using a vector
> based OpenGL library. The library uses hardware vertex buffers, render
> buffers, and a hardware stencil buffer (for anti-aliasing) to draw lines
> and shapes. With regards to what people familiar with OpenGL would
> consider, this is the opposite of immediate mode.
>
> However, these vertex buffers are repopulated every frame and where the
> entire scene is redrawn. This makes it seem to fall under the auspice of
> immediate mode.
>
> BUT
>
> If you read up a few messages back, I described how you can enable render
> buffers to save your work, and it's quite possible and even I'd say easy to
> do with my framework. But it's an opt-in step.
>
> HOWEVER
>
> This UI toolkit is only an incidental part of the library I am writing.
> The actual purpose of the library is to provide users with a very fast 2D
> graphics system with a hardware accelerated backend to render vector
> graphics. Further work will also include a Pascal object oriented interface
> to the fairly robust, fast, and powerful Chipmunk2D physics engine. My
> creating of this UI toolkit is only meant to give people writing physics
> simulations, games, or graphical demos a means to select, input, or change
> options for their physics simulation, game, or graphical demo. It is not
> meant to be used as a general purpose UI toolkit.
> ___
> 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] Default record const values

[Benjamin Rosseaux]

I'm using this solution myself for the vector and matrix data types at

https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.pas
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector2.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector2.Swizzle.Implementations.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector2Helper.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector2Helper.Swizzle.Implementations.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector3.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector3.Swizzle.Implementations.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector3Helper.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector3Helper.Swizzle.Implementations.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector4.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector4.Swizzle.Implementations.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector4Helper.Swizzle.Definitions.inc
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.Math.TpvVector4Helper.Swizzle.Implementations.inc

without any bigger issues, except that the Delphi IDE has some runtime
CodeInsight record lookup issues from time to time.


On Wed, Nov 28, 2018 at 8:47 PM Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Am 28.11.2018 um 20:27 schrieb Benjamin Rosseaux:
>
> program Test123;
> {$ifdef fpc}
>   {$mode delphi}
> {$endif}
>
> type
>   TTest = record
>   public
> a: LongInt;
> b: LongInt;
>   end;
>
>   TTestHelper = record helper for TTest
>   public
> const Default: TTest = (a: 1; b: 2);
>   end;
>
> var
>   Test: TTest;
> begin
>   Test := TTest.Default;
> end.
>
> That is indeed a good idea and with the extension to allow multiple
> helpers there wouldn't even be a negative impact... 樂
>
> Regards,
> Sven
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default record const values

[Benjamin Rosseaux]

program Test123;
{$ifdef fpc}
  {$mode delphi}
{$endif}

type
  TTest = record
  public
a: LongInt;
b: LongInt;
  end;

  TTestHelper = record helper for TTest
  public
const Default: TTest = (a: 1; b: 2);
  end;

var
  Test: TTest;
begin
  Test := TTest.Default;
end.

On Sat, Nov 10, 2018 at 10:06 AM Ryan Joseph 
wrote:

> Should’t this work? This would be a good way to set default record values
> but it doesn’t seem to be supported.
>
>
> type
> TMyRecord = record
> public
> a: integer;
> b: string;
> const
> default: TMyRecord = (a: 100; b: 'foo');
> end;
>
> var
> r: TMyRecord = TMyRecord.default;
>
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Semaphores removed from the rtl?

[Benjamin Rosseaux]

You could use TPasMPSemaphore from my PasMP project (
https://github.com/BeRo1985/pasmp/ and respectively
https://github.com/BeRo1985/pasmp/blob/master/src/PasMP.pas ) which is also
cross-platform-capable.

On Wed, Jul 19, 2017 at 6:29 PM, Anthony Walter  wrote:

> Thanks for that bit of information Charlie. I should have searched the svn
> logs.
>
> As a note to this, I am using semaphores quite a bit in SDL2 to guard
> against things like changes to audio banks in the ui thread and reading
> audio sample bits in the audio mixer thread, which SDL2 sets up whenever
> you play audio. There are other places where I use semaphores, but the
> point is SDL2 implements semaphores across all platforms and they work
> consistently.
>
> https://wiki.libsdl.org/SDL_CreateSemaphore
>
> It just seems to me like the concept of a semaphore has been well
> established in CS for decades and it's a bit weird to remove them from the
> rtl. They are native to all platforms (I just checked). Sure they we not
> used by any rtl internal functions/objects (in TThread for example), but I
> don't believe that should have been reason enough to get rid of them.
>
> In other words, just because a one group of developers don't use a tool,
> that shouldn't dictate its removal.
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Benjamin Rosseaux]

All SupraEngine.Math matrices are also compatible with OpenGL (and Vulkan,
of course). SupraEngine.Math's TMatrix3x3 and TMatrix4x4 implementation
have also advanced stuff as such as lerp, nlerp, slerp interpolation method
functions, decomposing (into Perspective, Translation, Scale, Skew and
Rotation components), recomposing (from Perspective, Translation, Scale,
Skew and Rotation components). And SupraEngine.Math have also GLSL-style
and in the most cases GLSL-Function-Parameter-compatible functions as such
as Cross, Dot, Normalize, FaceForward, Reflect, Refract, Clamp, Mix, Step,
SmoothStep, etc.

Example usages:

FaceNormal := (p2 - p0).Cross(p1 - p0).Normalize; // or alternatively also:
FaceNormal := Normalize(Cross(p2 - p0,p1 - p0));
if FaceNormal.Dot((Normals[NormalIndices[0]]+
   Normals[NormalIndices[1]]+
   Normals[NormalIndices[2]]).Normalize) < 0.0
then begin
   FaceNormal := -FaceNormal;
end;

 TriangleTangent:=((p2-p0)*(uv1.v-uv0.v))-((p1-p0)*(uv2.v-uv0.v));
 TriangleBitangent:=((p2-p0)*(uv1.u-uv0.u))-((p1-p0)*(uv2.u-uv0.u));
 
TriangleTangent:=(TriangleTangent-(TriangleNormal*TriangleTangent.Dot(TriangleNormal))).Normalize;
 
TriangleBitangent:=(TriangleBitangent-(TriangleNormal*TriangleBitangent.Dot(TriangleNormal))).Normalize;
 if (TriangleBitangent.Cross(TriangleTangent)).Dot(TriangleNormal)<0.0 then
begin
   TriangleTangent:=-TriangleTangent;
   TriangleBitangent:=-TriangleBitangent;
 end;

 Matrix := Transform.Matrix * Matrix;

 Vector := Matrix * Vector; (like at GLSL)
 Vector := Vector * Matrix; (in the other way transposed mul like at GLSL)

 Vector := Quaternion * Vector;
 Vector := Vector * Quaternion; (with the same transposed-matrix-like
effect)

 Vector := DualQuaternion * Vector;
 Vector := Vector * DualQuaternion; (with the same transposed-matrix-like
effect)

 RightVector := Matrix.Right.xyz;
 UpVector := Matrix.Up.xyz;
 ForwardVector := Matrix.Forwards.xyz;
 TranslationVector := Matrix.Translation.xyz;

 Matrix := Matrix.Normalize;
 Matrix := Matrix.OrthoNormalize;
 Matrix := Matrix.RobustOrthoNormalize;

 Quaternion := Matrix.ToQuaternion;

 QTangent := Matrix.ToQTangent;

 Matrix3x3 := Matrix4x4.ToMatrix3x3;

 ModelMatrix := Matrix4x4Identity;
 ViewMatrix := TMatrix4x4.CreateTranslation(0.0, 0.0, -4.0);
 ProjectionMatrix := TMatrix4x4.CreatePerspective(45.0, Width / Heighz,
1.0, 1024.0);
 ModelViewMatrix := ModelMatrix * ViewMatrix;
 InverseModelViewMatrix := ModelViewMatrix.Inverse;
 ModelViewProjectionMatrix := ModelMatrix * ViewMatrix * ProjectionMatrix;
 InverseModelViewProjectionMatrix := ModelViewMatrixProjection.Inverse;
 TangentSpaceRotationMatrix := ModelViewMatrix.Inverse.Transpose;
 InverseTangentSpaceRotationMatrix := TangentSpaceRotationMatrix.Transpose;

 ClipMatrix := CreateProjectionMatrixClip(ProjectionMatrix, ClipPlane);

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

Re: [fpc-pascal] GLM library alternative?

[Benjamin Rosseaux]

On GitHub I've already some SupraEngine subprojects, for example:

   - https://github.com/BeRo1985/pasmp My
   parallel-processing/multi-processing library for Object Pascal
   - https://github.com/BeRo1985/kraft My newer 3D physics Engine for
   Object Pascal
   - https://github.com/BeRo1985/pasvulkan Vulkan header generator and
   Vulkan OOP-style API wrapper for Object Pascal (it had also news articles
   on
   
http://www.phoronix.com/scan.php?page=news_item=PasVulkan-Vulkan--Pascal-Bind
   and https://www.khronos.org/news/tags/tag/Pascal  )
   - https://github.com/BeRo1985/pasdblstrutils Pascal library for
   cross-compiler consistent and exact conversion between double-precision
   floating point number values and strings
   - https://github.com/BeRo1985/pasenet Pascal port of ENet with IPv6
   support
   - etc.

But the SupraEngine main core project itself is still closed source (as
long as it is not yet ready), except these already excerpt-uploaded (for
users of this mailing list) zlib-licensed Math units, because SupraEngine
will have a UE4-style licensing model, say, when it will be released, it
will be free and quasi-open-source for free projects (it does not matter
whether it are open source or closed source projects), but it will be
revenue-share-based for non-free paid projects. A lawyer (a corresponding
lawyer I have already in the selection) will formulate the appropriate
license text for it, but this will be the last task, just before the
release.

But because the engine market is already largely saturated, it will be
primarly for projects (at least for the first time), for example,
Supraleiter (here some prototype videos with the old OpenGL-based engine:
https://www.youtube.com/watch?v=SWanRYNNTUA=PLoqdQblnX8vS11pAzGXOak3nsC4UoaC4-=4
and
https://www.youtube.com/watch?v=dR8OJoHWuGs=3=PLoqdQblnX8vS11pAzGXOak3nsC4UoaC4-
and https://youtu.be/_SVL0_Z3WL8 and https://youtu.be/-mi2wOnks_A   ), a
StarTrek Voyager first-person-shooter (here some prototype videos, which
had made my graphic-artist-contact testwise with UE4:
http://www.indiedb.com/games/voyager-game-project/videos/scorpion#imagebox
and
http://www.indiedb.com/games/voyager-game-project/videos/deltaflyer-12-10-2016#imagebox
and
http://www.indiedb.com/games/voyager-game-project/videos/bridge-preview-9#imagebox
 ),
etc.

And I've testwise partly-reverse.engineered and partly-reimplemented the
first two Original WipeOut titles (in ObjectPascal of course):
https://youtu.be/MI_jtU2kiQk  and https://youtu.be/zKpAWaByyyc for to test
my newer physics engine in a real test game, as preparation for usage in my
Supraleiter game project with the then new Vulkan-based SupraEngine.





On Sun, May 28, 2017 at 10:22 AM, denisgolovan <denisgolo...@yandex.ru>
wrote:

> 28.05.2017, 09:55, "Benjamin Rosseaux" <benja...@rosseaux.com>:
>
>
> I've put some units of my still work-in-progress UE4-style SupraEngine on
> my root server, after I've read this mailing list thread =>
>
> http://rootserver.rosseaux.net/stuff/supraengineunits/
>
>
>
> Looks nice. Thanks for sharing.
> How about publishing it on Github with small readme to ease contributions?
>
> --
> Regards,
> Denis Golovan
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Benjamin Rosseaux]

I know that issue, so that the record constructors in the
SupraEngine.Math.pas are fully optional, so therefore you do must not using
these :-)  It's just a optional option for key-tap-lazy peoples, since all
record member fields are also free directly accessible and public visible.

On Sun, May 28, 2017 at 9:28 AM, Ryan Joseph <r...@thealchemistguild.com>
wrote:

>
> > On May 28, 2017, at 1:54 PM, Benjamin Rosseaux <benja...@rosseaux.com>
> wrote:
> >
> > I've put some units of my still work-in-progress UE4-style SupraEngine
> on my root server, after I've read this mailing list thread =>
>
> Thanks for sharing. The GLM functions I wanted seem to be here so I’m
> going to try them.
>
> Btw, I’m not sure Sven fixed this or is going to but we found out record
> constructors were not producing optimal instructions when compared to
> static inline class functions so you may want to change those. I had to go
> back and make changes to some low-level record constructors after I found
> this out also.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Benjamin Rosseaux]

Fixed, repacked & reuploaded as ZIP in the same directory

On Sun, May 28, 2017 at 10:32 AM, Ryan Joseph 
wrote:

>
> > On May 28, 2017, at 3:22 PM, denisgolovan 
> wrote:
> >
> > Looks nice. Thanks for sharing.
> > How about publishing it on Github with small readme to ease
> contributions?
> >
>
> There’s some dead 403 links also btw.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Benjamin Rosseaux]

I've put some units of my still work-in-progress UE4-style SupraEngine on
my root server, after I've read this mailing list thread =>

http://rootserver.rosseaux.net/stuff/supraengineunits/

where the SupraEngine.Math.pas + SupraEngine.Math.*.inc +
SupraEngine.Types.Standard.pas will be maybe interesting for you.

It's a complete 3D Math unit based on overloaded operators, advanced
records, etc. and even with GLSL-style swizzle support, where you can type
something like My3DVector.xzy := MyOther3DVector.yyx; My4DVector.zyx :=
TVector3.Create(3.0, 2.0, 1.0); or even My2DVector.yx := My3DVector.yz; etc.

Furthermore many routines are SSE optimized for the x86-32 and x86-64
targets.

This is the result of many years of evolution-based work, starting from the
original math routines of my old PAPPE physics engine, which I've always
further developed over the years (incl. many refactorings and rewrites).

And if you will do using it, then you add the following line to your start
of your code (where the Math unit must be in the uses clause):

SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow,
exUnderflow, exPrecision]);

for disable some floating point exceptions, which could occur at 3D stuff,
especially divide-by-zero exceptions at speed-SIMD-optimized normalization
operations.

And credits would be nice :)

Regards,
Benjamin 'BeRo' Rosseaux


On Sat, May 27, 2017 at 12:37 PM, Ryan Joseph 
wrote:

>
> > On May 27, 2017, at 5:16 PM, Mark Morgan Lloyd <
> markmll.fpc-pas...@telemetry.co.uk> wrote:
> >
> > But working from a hazy recollection of such things, it's possible to
> merge the translation/rotation matrices so that the final transformation
> can be reduced to a single operation.
>
> Oh I’m sorry, I’m using 3.x core and the fixed pipeline has been removed
> which glRotate etc… were part of. I’m using this now but I wanted to learn
> the “new” stuff some.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Benjamin Rosseaux]

The ECMAScript standard uses 64-bit double-precision floating
point numbers, and a double-precision floating point value can represent
absolute integer values up to of less than or equal to 2^53, without any
loss of accuracy, since an IEEE 754 64 bit double-precision floating point
number has a mantissa with a size of 52 bits (plus 1 bit implied).

On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu> wrote:

> Hi,
>
> On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:
>
> > I love how they say multiple times in the video:
> >
> >"... and completely secure."
> >
> > Umm, didn't they say the exact same thing about Java Applets, Flash,
> > Silverlight etc. :)  I guess time will tell, but if history is anything
> > to go buy, security issues *will* pop up.
>
> Yes, but it is important to know there's a difference with Java Applets,
> Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
> VM which runs everything Javascript in the browser. So the browser vendors
> have full control on the code which runs there.
>
> Also, WebAssembly is a descendant of asm.js, which was basically striped
> down Javascript with some integer/pointer type tagging. As far as I know,
> the main problem with JS from a computing point of view, that it handles
> all numbers as floats for "simplicity", but with some code in other
> languages, this can have real side effects (for example some integers
> cannot be exactly expressed as floats, which means slight differences in
> computation results accumulate over time, etc), and it's much slower on
> most CPUs. This is why I'm a bit relucant to accept High Level language
> translators to JS - there could be too many sideeffects hidden in any
> algorithm, just because of this one thing.
>
> This is the main problem asm.js, and now WebAssembly is addressing. It can
> work with the same integer and float types the hardware underneath is
> using, and can avoid all the float handling and various range/index etc
> checks. This is what provides the performance part. And obvously a lot of
> other "shortcuts" to work around JS language requirements, which another
> language might not need.
>
> And it fits in the process, how they gradually opened up the underlying
> hardware to the browser. Another great example is WebGL, which is also a
> very thin layer on top of the hardware, to skip through the billion "who
> cares about that" CSS and JS canvas layers, and go directly to the GPU, to
> get some decent performance...
>
> So all in all, despite its problems, it's still the best effort to provide
> some sane bytecode standard for the web. (If a web bytecode can be
> anywhere near sane, that is.)
>
> Charlie
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Javascript in Desktop Applications

[Benjamin Rosseaux]

Am 07.02.2011 15:16, schrieb Andrew Brunner:

On Mon, Feb 7, 2011 at 7:35 AM,michael.vancann...@wisa.be  wrote:

A cross-platform solution is to use one of libsee or BESEN.

The latter is implemented in 100% native Object Pascal.

Michael.

BESEN is very, very, very  well written but I can't seem to get any
indication how to use it in my project.  I would love FPC to include a
JIT system for JS or Pascal.  IMO, FPC absolutely needs a scripting
FCL going forward.  BESEN seems like the right guy for the job, but I
suspect he's burned out :-(  I think he had memory concerns too.

Does anyone have any BESEN examples that integrated actual FPC units?
It seems like all the samle js units are self contained with no
interface to system or GUI units.

Including JS support on my project would enable people to leverage
exiting proven technologies which would make for easier/allowable
for adoption in working groups / houses where selection of language is
restricted to language of the day :-)  Taking this statment and
applying this across the board, it would be an easier sell for
adoption of FPC/Lazarus with JIT support.  Personally, I'm thinking
along the lines of Web RAD down the road...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Have you looked at the BESENShell.dpr/BESENShell.lpr? Because that 
contains the most important part, how you can integrate own API stuff. 
And the last commit to the BESEN SVN was just a few days ago with a few 
weeks pause, because I've found no bugs and got no bugreports in that time.


Benjamin 'BeRo' Rosseaux

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