Re: [fpc-devel] New feature announcement: constant parameters for generics

[Anthony Walter via fpc-devel]

Thank you Ryan and Sven. Your work is much appreciated as usual.

However, Michael beat me to it in asking how this feature is useful. I am
sure there might be use cases, but for right now I am coming up without any
real advantages. Could anyone with better insight than me please explain?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Class management operators

[Anthony Walter]

Ryan, I believe the compiler already has management support for complex
types. That is for BOTH records and classes. All that is required is you
have a supported version of the compiler and you add the sugar in the form
of AddRef, Initialize, and Finalize. See this page for more information:

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

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Oh and might as well add dot product and cross product for vectors as well

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

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

On a related note, since a lot of the discussion here seems related to
vector types, I seem to recall someone recently published an mmx,
sse1/2/3/4, simd set of routines related to vector operations. I don't use
much asm other than just being familiar with the basics of ia32 from long
ago, but I do know there have been many enhancements for the instruction
sets I mentioned which specifically greatly increase both the speed and
parallelism of vector operation, including their combination with matrix
math manipulation and vector transforms. I also know that the people in the
mono project enhanced their compiler with special simd vector optimizations:

https://www.mono-project.com/news/2016/12/20/system-numeric-vectors/

Having said that, might it be possible if we could incorporate official
vector and matrix type and optimizations with the compiler? I think
everyone would benefit from officially supported types of this nature that
could have more eyes on them to ensure their operations are best optimized
for the various types of computers and architectures free pascal supports.
I can think of quite a few operations that would benefit from everyone
contributing either their own ideas of the best optimizations or reporting
problems or suggestions.

Here is what I would suggest as a start. Use 4 component float (single and
perhaps additionally double precision) vectors (X, Y, Z, W), 4x4 matrix
type to match.

For vectors we need these operations:
add, subtract, multiply, divide, normalize, transpose

For matrix types we need:
identity, scale, rotate, translate, sheer, multiply (matrix * matrix),
transform (vector * matrix), transpose, invert

That's just a start, but these operations ought to have official simd
support IMO

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

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

You are not required to dereference pointers to write to them.

var
  P: PPoint;
begin
  P := AlignedArray[0];
  P.X := 3; // can be okay
  AlignedArray[0].Y := 4;  // can be okay as well
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

1) In you example you are writing this with normal arrays:

A[0].X := 0;

And in my implementation it's exactly the same. Regarding writing the
entire type directly

A[0]^ := V;

If using the caret symbol ^ or an Item property is a deal breaker, then
this can be simplified using a custom smart pointer type similar to how the
aligned array type was implemented resulting in the same syntax as in the
first example.

2) As I've implemented them aligned array is compatible with dynamic
arrays. They implicitly convert between the two with no loss of data. If
you truly want to share the data within each, then you can define functions
to work on referencing the data types they hold, allowing the same function
to serve either type.

For example:

procedure VectorTransform(Matrix: TMat4; FirstVertex: PVec3; Count:
Integer);

and then

Matrix.Rotate(12.5, 0, 0);
VectorTransform(Matrix, AlignedData[0], AlignedData.Length);
VectorTransform(Matrix, @DynamicArray[0], Length(AlignedData));

Or you can even overload VectorTransform if you don't want to see @
symbols.

procedure VectorTransform(Matrix: TMat4; FirstVertex: var TVec3; Count:
Integer); overload;

3) Regarding Hi, Lo, Length, I prefer to put these functions on types. For
example

for I := A.Lo to A.Hi do A[I].X := I;

Is that such a deal breaker?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Denis,

The more that I think about it, the more I am believe that using my
approach is probably the best solution. Hear me out please.

First, it would be fairly easy to implement copy on write logic with a
custom record class.

Second, because it's Pascal code, it's entirely possible to fully customize
how it operates now and into the future, without the need to modify the
compiler. Suppose later you decide that also want the ability allocate the
storage memory of using the same array interface, but with a vertex buffer
object as the mechanism for allocating storage. Maybe at a later time you
want to allow an arrays type to back a memory mapped file.

In all cases, user code would be the proper avenue to implement these
features. Unless these is some special feature unique to an intrinsic type
that makes working with a user code type significantly more difficult, why
bother adding more complexity to the compiler and more complexity rigidly
into the built in types?

Now that we have management operators, type helpers, generics,
implicit/explicit conversions, and operator overloading, why not use what
we already have and make it better? Can you, or anyone for that matter,
find a real problem with a type or other construct that user code solution
can solve trivially with approximately the same syntax? If so then yes I am
all for addling to the language and compiler. In all other cases when can
use what the nice compiler and language developers have created for us and
do everyone a favor by reporting and helping to fix the bugs those features
might still have.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Inside the type I have:

  TAlignedArray = record
  public
type
  TReference = ^T;
  TValue = T;
...
procedure Push(const Item: TValue);
function Pop: TValue;
property Length: Integer read FLength write SetLength;
property Reference[Index: Integer]: TReference read GetReference;
default;
property Item[Index: Integer]: TValue read GetItem write SetItem;
...
  end;

So the default property indexer returns references and not values. If you
want values specifically you can use the Item property indexer.

This way we can either access fields directly on the items withing the
array like so:

A[0].X := SomeValue;

Or if you need fast access to quickly populate the values, support we want
to write 3 component vertex data, you could write:

type
  TVertexBuffer = type TAlignedArray;
var
  Buffer: TVertexBuffer;
  V: TVertexBuffer.TReference;
begin
  Buffer.Length := VertexCount(ModelStream);
  V := Buffer[0];
  for I := 1 to Buffer.Length do
  begin
V.X := ReadX(ModelStream);
V.Y := ReadY(ModelStream);
V.Z := ReadZ(ModelStream);
Inc(V);
  end;
  ...
end;

Which probably ends up being faster than continually accessing array
dynamic values by index.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Ryan, actually ...

A.Length := 1;
A[0].X := 100;

... does work in my implementation.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Gareth,

There is a bounty for this? I wonder if my solution is acceptable.

Also, my solution, or any for that matter, could be enhanced to make the
alignment size configurable per each array aligned array. That is, memory
alignment starting position and page size could be defined by each array.
This would allow for more flexibility and would be trivial enough to adapt
to what I've provided.

Finally, these methods could be added to the type, making it like a super
array or list:

{ Returns the lower bounds of the list }
function Lo: Integer;
{ Returns the upper bounds of the list }
function Hi: Integer;
{ Reverses the items in the list }
procedure Reverse;
{ Swap two items by index in the list }
procedure Exchange(A, B: Integer);
{ Adds and item to the end of the list }
procedure PushRange(const Collection: array of T);
{ Remove an item randomly from the list }
function PopRandom: T;
{ Return a copy of the list with items passing through a filter }
function Filter(Func: TFilterFunc): TArrayList;
{ Return the first item matching a condition }
function FirstOf(Func: TFilterFunc): T;
{ Removes an item by index from the list and decreases the count by one
}
procedure Delete(Index: Integer);
{ Sort the items using a comparer }
procedure Sort(Order: TSortingOrder = soAscend; Comparer: TCompare =
nil);
{ Attempt to find the item using DefaultCompare }
function IndexOf(const Item: T): Integer;
{ Join a the array into a string using a separator }
function Join(const Separator: string; Convert: TConvertString =
nil): string;
{ Returns true if ther are no items in the list }
property IsEmpty: Boolean read GetIsEmpty;
{ First item in the list }
property First: T read GetFirst write SetFirst;
{ Last item in the list }
property Last: T read GetLast write SetLast;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Here is the full implementation of aligned arrays, let me know if it works
for you.

https://www.getlazarus.org/arrays/

Here is another example:

uses
  AlignArrays;

procedure Test;
var
  VertexData: TAlignedArray;
  V: PVec3;
  I: Integer;
begin
  VertexData.Length := 100; // page sized and aligned memory allocated here
  V := VertexData[0]; // get a reference to the first item
  for I := 0 to V.Length - 1 do
  begin
V^ := ComputeVertex(I); // write to vertex data faster via a pointer
Inc(V);
  end;
  for V in VertexData do // array like enumerators are supported
PrintVertex(V);
  V.Item[6] := ComputeVertex(Random(100)); // you can write directly using
this syntax
  V[7]^ := ComputeVertex(Random(100)); // or write by dereferencing  the
default indexer
end; // there is no need to free the memory, it is taken care of for you by
finalize
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Here is a brief follow up. I am working on other projects at the moment,
but I am confident this a simple solution. Please tell me if this somehow
will not fit you needs.

Create a new type that is compatible with Array where Array = type
array of T.
Define implcit conversions between the to types and similar methods
Create a Push and Pop methods, well as a read write Length property and two
indexers.
Indexer named Reference is default and provides a memory reference to Tn
Indexer named Item is available and provides a copy of Tn

So we would have ...

  TAlignedArray = record
type TReference = ^T;
type TValue = T;
FPage: Pointer;
FLength: Integer;
procedure SetLength(Value: Integer);
function GetReference(Index: Integer): TReference;
function GetItem(Index: Integer): TValue;
procedure SetItem(Index: Integer; const Value: TValue);
  public
procedure Push(const Item: TValue);
procedure Pop: TValue;
property Length: Integer read FLength write SetLength;
property Reference[Index: Integer]: TValue read GetReference; default;
property Item[Index: Integer]: TValue read GetValue write SetValue;

Examples usages:

type
  TVertexArray = TAlignedArray;

// and later

var
  Vertices: TVertexArray;
begin
  Vertices.Length = 1000; // okay, request a page aligned memory
  Vertices[0].X := X; // okay, we are working with references
  Vertices.Item[1] := Vec3(X, Y, Z); // okay, we are setting a value
  Vertices.Length = 0; // clean up


When the vertex array need to grow, it uses the POSIX posix_memalign (or
the _aligned_malloc on Windows) to request a 4 KB aligned and sized page
adequate to contain all the items. The newish allocate and release
mechanisms can further be used to simply the management of the
TAlignedArray type.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Aligned dynamic arrays

[Anthony Walter]

Ryan, this is just a thought. Do you need the flat memory address to start
on an even 4 KB boundary or are you okay with the memory address starting
at any DWORD address and spanning an even 4 KB after that address?

In the latter case I have an easy solution for you. If the former I am
unsure how to allocate memory at a specific address but could create a
simple enough solution which may waste some space at the start yet give the
array a starting address of a number divisible evenly by 4 KB. Let me know
and I'll write an implementation which I am pretty sure you'll find either
solution more than adequate.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?

[Anthony Walter]

I thought I'd add a point about compiling and memory. On the Raspberry Pi,
I know for a fact that building the compiler can fail after a while due to
insufficient memory. When this happens the problem with no memory doesn't
present itself as such. Rather you're left with an error indicating a
problem with the source. I've gotten around this problem by making the
compiler without a desktop environment running and re configuring the swap
size.

Might this problem be related in some way to the discussion in this thread?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

[Anthony Walter]

Maciej,

I am sorry to see you go. I understand sometimes people here can seem
stubborn or rude, and I hope in the end cooler heads prevail. The
contributions you've made to the sparta docked form designer and smart
pointers are much appreciated by me personally. From me to you, thank you.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Okay, I found a nice work around to allow for circular references on record
types:

record helpers

type
  JSValue = record
  ...
  end;

  JSObject = record
  ...
  end;

  JSValueHelper = record helper for JSValue
function AsObject: JSObject;
  end;

  JSObjectHelper= record helper for JSObject
function GetProperty(const Name: string): JSValue;
procedure SetProperty(const Name: string; Value: JSValue);
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Thanks for replying. I'd like to chime in with a few thoughts..

I believe manged types beyond string, dynamic array, and interface as
important. In my use case worked around the problem by using records with
private interface as I already mentioned. This solution is less than
optimal as it requires defining 3 types when 1 would do. Also, stakc based
types like record and object are useful because they don't require dynamic
allocation, but have some serious drawback because they do not support
forward declaration.

Consider this situation I am currently working though. I have script
context, object, and value types. both objects and values need to know
about their context, and both value and objects need to know about each
other.

function JSValue.IsObject: Boolean;
function JSValue.ToObject: JSObject;

-and -

procedure JSObject.SetProperty(const Name: string; Value: JSValue);
function JSObject.GetProperty(const Name: string): JSValue;

In this design a value can contain and object, and an object can have
properties that are values. When using records to represent JSValue and
JSObject, this design is simply not possible, because you cannot forward
declare a record.

To work around this using classes (which can be forward declared)  without
a management instead of records is more than cumbersome because of the need
to track all intermediate busy data and manually free each one.

Interfaces by themselves aren't optimal either because you cannot define
conversions or operators on them.

Consider this:

  JSString = record
  ...
  public
class operator Implicit(const S: string): JSString;
class operator Implicit(S: JSString): string;
class operator Equal(A, B: JSString) : Boolean;
class operator Equal(A: JSString; const B: string) : Boolean;
property Length: Integer read GetLength;
  end;

- or -

  JSContext = record
  ...
  public
class operator Implicit(C: JSContext): JSContextRef;
  end;

If I were to use interfaces exclusively, it would be more cumbersome to
work with the JSC API, as it requires ObjectRef types for everything,
including strings. I would have to call methods to convert to, and a
separate set of method to convert from. Where as with records, objects, and
classes, you can write implicit conversions when no data loss takes places,
but types are converted implicitly, removing a lot of needless code
complexity.

In short, because you cannot forward declare record or object types,
because you would to free classes manually in many places, and because
interface types cannot convert to intrinsic types like string or pointer,
managed types for classes is the best solution in this use case.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Okay great. Thanks for the information. I'll experiment with the smart
pointers and their potential performance impact. In the interim I've
created a solution using the approach of records containing private
reference counted interfaces. Here is an example of my JSContext record:


   1.   JSContext = record
   2.   private
   3. FRef: IJSContext;
   4.   public
   5. class function Create: JSContext; static;
   6. class function Retain(C: JSContextRef): JSContext; static;
   7. class operator Implicit(C: JSContext): JSContextRef;
   8. function EvaluateScript(const Script: string): JSValue;
   9. function CreateFunction(const Name: string; Callback: JSFunction):
JSObject;
   10. function CreateMethod(const Name: string; Callback: JSMethod):
   JSObject;
   11. function CreateUndefined: JSValue;
   12. function CreateNull: JSValue;
   13. function CreateBoolean(Value: Boolean): JSValue;
   14. function CreateNumber(Value: Double): JSValue;
   15. function CreateString(const Value: string): JSValue;
   16. function CreateJSON(const Value: string): JSValue;
   17.   end;

So you could use it to embed a javascript engine in your free pascal
application like so:


   1. function TestCallback(Context: JSContext; Args: JSValues): JSValue;
   2. begin
   3.   Result := JSContext.CreateString('You passed ' + IntToStr(Args.
   Length) + ' arguments');
   4. end;
   5.
   6. function MessageBoxCallback(Context: JSContext; Args: JSValues):
   JSValue;
   7. begin
   8.   if Args.Length > 0 then
   9. ShowMessage(Args[0].AsString);
   10.   Result := JSContext.CreateUndefined;
   11. end;
   12.
   13. procedure TForm1.Button1Click(Sender: TObject);
   14. var
   15.   C: JSContext;
   16.   R: JSValue;
   17. begin
   18.   C := JSContext.Create;
   19.   C.CreateFunction('test', TestCallback);
   20.   C.CreateFunction('messageBox', MessageBoxCallback);
   21.   R := C.ExecuteScript(
   22. 'let s = test(123, "hello");' +
   23. 'messageBox("test gave us:" + s);' +
   24. 'let result = "okay, we are done.";');
   25.   Caption := R.AsString;
   26. end;

Note, using my records with interfaces we don't have to clean up anything,
and the javascript context is destroyed when Button1Click exits. The only
problem I have right now is you cannot forward declare records, so with
pascal it's not possible for two records to use each other in their type
definitions.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Here is a video overview of this message


I've run into an almost must have use case for FPC smart pointers as
described and implemented by Maciej. I wanted to know from the people who
make decision about what to merge, what's the status of rolling his
enhancements at following location into FPC trunk?

svn ls https://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers/

My use case is for adding a free pascal interface to Webit's
JavaScriptCore. The JSC objects all follow Apple's design pattern where C
style API functions return and operate on ref pointer types that must be
destroyed using specific API calls for each type.

It seems like a natural fit with smart pointers, such that record types
could be used to hold onto things such as JSStringRef, JSClassRef,
JSValueRef, and more, retaining and releasing them for you automatically
with the appropriate JSC API when they go out of scope using the smart
pointer Initialize, Finalize, and Copy operators.

e.g. JSClassRetain, JSClassRelease

For those interested, the JSC library works on all platforms and allows for
integrations between native code applications, and a high performance java
scripting engine. The same engine powering webkit browsers. The API allows
you to expose your native code functions as javascript functions or
classes, as well as providing a virtual machine to execute javascript.
Properly confiruged, the javascript can callback your pascal code
optionally passing javascript objects are arguments to your native code.

All of these operations would be much easier to program against with stack
based types (record or object) if smart pointer support was present in FPC.

Finally, with JSC it's quite easy and possible for developers to embed
webkit webview windows in their desktop applications, and optionally grant
any web page the ability invoke free pascal code you decide to expose, and
for free pascal in return invoke arbitrary javascript objects or functions.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Anthony Walter]

If you were going to patch I'd also consider allowing:

program Test;
var
  B, C: Integer = 0, 1;  // sets B = 0, and C = 1
begin
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fix CamelCase in unit and method names

[Anthony Walter]

Yes, I agree, both for unit names, but also for methods and arguments. The
exceptions should be for code related that are imports or extensions of
existing APIs, for example:

cairo_create should remain the same
glGenBuffers should remain the same
gtk_window_new should remain the same
dlopen should remain the same

But in the RTL or LCL here are some of many pure pascal functions or
procedures that could have their case changed:

abs should be Abs
arctan should be ArcTan
getdir should be GetDir
intpower should be IntPower
hexstr should be HexStr
strcan should be StrScan

And with RTL or LCL unit names:

keyboard should be Keyboard
math should be Math
strutils should be StrUtils
cthreads should be CThreads

Same applies to function/procedure/method arguments. If they're a pure
pascal original, then arguments should be CamelCase. If they are part of an
API imported, then they should remain the way the original API declares
them.

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

Re: [fpc-devel] x86-64 optimizations

[Anthony Walter]

J,

Thanks for the contribution. I looked over your patch and seems reasonable,
though I didn't try building fpc with it. We need more  people like you
helping to improve the compiler. Thanks!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

[Anthony Walter]

Out of curiosity, is there any strategy that is or can be employed to
ensure new language features and mode switches automatically work with
codetools and by extension the Lazarus IDE?

Or is duplication of effort the only way to get codetools properly parsing
new language features?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

[Anthony Walter]

Ondrej,

I agree 100%. Many +1s. Thank you.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Cannot trap divide by zero in xmm register

[Anthony Walter]

Wow, that fixed it. Thanks Henry!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Cannot trap divide by zero in xmm register

[Anthony Walter]

I am having a problem with unrecoverable errors in external code,
presumably generated by the video driver, crashing my programs. I cannot
trap these errors with try..except blocks. Here is a capture of the
assembler window with ** marking the line where the error occurs.

  7FFFEA79016F 4898 cltq
**7FFFEA790171 f20f5e44c430 divsd  0x30(%rsp,%rax,8),%xmm0
  7FFFEA790177 f20f118424f800   movsd  %xmm0,0xf8(%rsp)
  7FFFEA790180 f20f118424f000   movsd  %xmm0,0xf0(%rsp)
  7FFFEA790189 f20f118424e800   movsd  %xmm0,0xe8(%rsp)

In pascal code I am attempting to link a glsl program (part of OpenGL) when
the uncatchable and unrecoverable error occurs.

*function* TShaderProgram.Link: Boolean;
*var*
  I: GLint;
  S: string;
*begin*
  *if* Flinked *then*
Exit(False);
  *if* FAttachCount < 2 *then*
Exit(False);
  FLinked := True;
  *// Sometimes the uncatchable error happens here*
  glLinkProgram(FHandle);
  glGetProgramiv(FHandle, GL_LINK_STATUS, @I);
  FValid := I = GL_TRUE;
  *if* *not* FValid *then*
  *begin*
FErrorObject := Self;
glGetProgramiv(FHandle, GL_INFO_LOG_LENGTH, @I);
*if* I > 0 *then*
*begin*
  SetLength(S, I);
  glGetProgramInfoLog(FHandle, I, @I, PChar(S));
*end*
*else*
  S := 'Unknown error';
FErrorString := S;
  *end*;
*end*;

In this code I am attempting to link user defined glsl vertex and fragment
shaders to generate a valid glsl program object. Sometimes either the
vertex or fragment shader contains bad code, but it shouldn't bring down my
entire pascal application. I've written and used these same shaders in c#
using mono and I've never had them crash my mono applications. Is there
some setting in fpc or in lazarus to handle these types of errors in the
XMM registers gracefully?

To give you an idea of what I am doing, here is a screen recording of made
earlier of these same shader programs running without crashing my
application when using mono.

http://cache.getlazarus.org/videos/bare-csharp.mp4
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

[Anthony Walter]

Do the source and dest types need to match? How about:"CopyFrom"? As it is
right now you already have type parity between types such as floats <-
integer and string <- char, so why not between TBar <- TFoo?

class procedure TBar.CopyFrom(constref Source: TFoo; var Dest: TBar);

Then this begs question, what's the difference between AutoCopy/CopyFrom
and:

class operator TBar.Implicit(const Value: TFoo): TBar;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Anthony Walter]

The biggest problem I ran into has to do with asset lifetime management.
That is, allowing for ad-hoc creation or loading and unloading of (list to
follow):

Textures
Models
Storyboards
Skeletons
Scripts
Audio Samples
Fonts
Skyboxes
Shaders/Shader programs

... and anything else which a game developer might want to create/destroy,
or load/unload.

To cope with this generics can be quite handy. A master asset manager class
can hold these types of things for you so that you don't need to declare
instances of each type in a class. The asset manager can also hold copies
for you so that you don't need to recreate then when they are needed. Some
examples.

// Change the texture of a sprite to a ghost
Sprite.Texture := Assets.Textures[SGhostTexture];
Sprite.Shader := Assets.ShaderPrograms[SEtherealShader];
// Add a scary sound sample to an audio bank and loop it
AudioBank := Audio.Banks.Add(Assets.Sounds[SScaryMusic]);
AudioBank.Looping := True;
AudioBank.Play;
// Load up a slimy looking font
FontWriter.Font  := Assets.Fonts[SSlimeFont];


Where Assets is a global TAssetManager containing all possible assets

type
  TAssetManager = class(TManaged)
  public
property Sprites: TManagedCollection read GetSprites;
property Textures: TManagedCollection read GetTextures;
property Sounds: TManagedCollection read GetSounds;
// and so on
  end;

The problem then comes in where you have certain sprites/sounds allocated
at different times, for example changing/advancing game levels. One
solution is just to load every possible asset before the game starts, but
this is kind of wasteful and also possibly not feasible due to hardware
resource constraints. Perhaps you have a game selections screen. There is
no reason the assets specific to that screen should be taking up audio
banks and texture memory after you start the game. Okay then you need a
clean way to group all the assets for different stages together such that
they can all be loaded and unloaded en mass when preparing to enter or exit
a scene. Then things can get a little messy from there.

Now this where managed types can help. If the asset manager can hold a
reference count to asset items (via a managed collection class), and a
class can also hold the same references directly, as in not inside a
container but declared directly, then grouping assets can be simplified a
bit. Perhaps a TGameSelectScene can hold direct copies of the assets it
needs and use Assets (TAssetManager) to request them, The scene can then
hold references to these assets and remove them from the asset manager, but
when the scene is released so are its very specific assets.

I really haven't come up with an acceptable solution to this problem yet. I
also need better integration with a compression library to store assets
before they are uncompressed and loaded from some kind of WAD file (like
how Doom used to handle this stuff). For now assets are compressed and
linked directly into the exe/application, but I feel they should be in
separate compressed files. Perhaps grouped by scene (TGameSelectScene would
have it's own WAD).

https://en.wikipedia.org/wiki/Doom_WAD

Anyhow the point is to make managing game of assets as transparent as
possible to the game programmer, where he can request textures, shaders,
fonts, 3D models, or whatever, without the burden of remembering when to
create and destroy these things.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Anthony Walter]

I am really looking forward to runtime package support. :)

As far as game engine design, I wanted/prefer a KISS style similar to XNA.
That is you just derive a game class and override two methods: Logic() and
Render() and each is passed a Stopwatch class representing time. One you
fill in with game state (Logic), the other you fill in with drawing stuff
(Render). Finally the engine provides a lot of functionality to help you
with both such as Sprite classes for both collision
detection/movement/storyboarding or a canvas class for vector graphics in a
3D world.

I think the popularity of Unity is due to it providing a single toolkit
which can target all devices including render in a webpage canvas using a
common core. Sure the tooling helps, but I think it's more along the lines
of everything for all platforms works without a whole lot of finangling,
rather than having built in visual editors for stuff. I mean if anyoen is
at all serious their going to need external programs like Gimp/Photoshop
for creating sprite sheets and textures, a 3D modeler like modo for
creating models and  UV maps, a bone editor like Spine to create
animations, something like Audactity for editing sound, and if their like
me they'll probably end up writing their own external tools like a level
editor:

http://cache.getlazarus.org/images/showcase/windows.mushroom.editor.jpg

Plus a whole lot more external tools. So from my perspective (and maybe a
lot of others as well) a game engine IDE should primarily be focused on
making compilation and targetting of many platforms transparent. In that
regard Lazarus/FPC still needs some work. Setting up the IDE and compiler
to get a GL context working on Android/iOS or every transpiling to
Javascript for web ... yeah we're not there yet (I am working on
distributing the Android part).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Anthony Walter]

Looks really good. Why did you feel the need to have IDE integration? From
my perspective (having written a game toolkit) the only point I needed IDE
integration was a project template to add a reference to my game engine
package and create a source code file. All the tools which can be used to
work with a game engine, such as an asset manager to add/remove textures,
models, sound clips, scripts, and animation storyboard are best written as
tools external to the IDE. That is you can slice up an image into sprites
textures without needing to open the IDE.

Anyhow if your still interested in this stuff I'm using SDL 2 and GL ES 2
which works across all platforms. Mostly I like the idea of using this
stuff for 2D games, with 3D capabilities.

https://www.youtube.com/watch?v=lOUB4pqRLjY
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Anthony Walter]

Maciej,

A game engine? What happened to it? I've moved my game engine to OpenGL ES
2.0 for all platforms and am looking to create a FPC Android starter
template.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Anthony Walter]

Maciej,

I've done a little testing on your smart pointer branch but haven't found
any issues recently. Can you tell me if there is a tag for this feature in
mantis yet and/or if there are any known issues?

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

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

I put up a testing page for your modifications here:

http://www.getlazarus.org/language/smart/

The tests are rather simple and sloppy, but so far the few tests I've
written have passed using revision 33384. If anyone wants to add/change the
test source code you can use the edit feature on that page. I will post
your test/results when I run them myself.

A note about keyboard shortcuts for the editor on my website.

Select editor text and pressing [Ctrl >] or [Ctrl <] alternates your
selection through headings and paragraphs of differing sizes.

Putting backticks [`] around text allows you to insert syntax highlighted
source code. Selecting from backtick to backtick and pressing [Ctrl Enter]
converts the selection to syntax highlighted source code, while selecting
text with backticks inside is converted to inline snippets when you press
[Ctrl Enter]

You and I can see your edits, but I need to merge them before everyone can
see them.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

Should I file mantis bug reports for personal branches such as this or is
mailing list notification sufficient?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

Maceij,

I did a build using your revision 33381. Compilation with "make all" worked
with fpc 3.0.0 as a starting compiler. However my first test with it
revealed a pretty serious bug:

program mytest;

{$mode delphi}

type
  TFoo = record
  private
class operator Initialize(var aFoo: TFoo);
class operator Finalize(var aFoo: TFoo);
  public
F: Integer;
  end;

  TFooArray = array of TFoo;

class operator TFoo.Initialize(var aFoo: TFoo);
begin
  WriteLn;
  WriteLn('TFoo.Initialize');
  aFoo.F := 1;
end;

class operator TFoo.Finalize(var aFoo: TFoo);
begin
  aFoo.F := 3;
  WriteLn('TFoo.Finalize');
  WriteLn;
end;

procedure Test;
var
  Foos: TFooArray;
begin
  SetLength(Foos, 5);
  WriteLn('Foos[0].F = ', Foos[0].F);
  WriteLn('Foos[1].F = ', Foos[1].F);
  WriteLn;
end;

begin
  Test;
end.

Outputs:

Foos[0].F = 0
Foos[1].F = 0

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

Notice:

TFoo.Initialize is never invoked.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

Maciej,

Please let me know when you apply Sven's recommendations to the make
commands and I'll test. Thanks..
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

Maciej,

Just a note, I attempted to compile your smart_pointer branch revision
33229 on a Raspberry Pi 3 Raspbian Jessie (with the latest updates) and the
build failed.

make all OPT="-dFPC_ARMHF"

Sorry, I didn't capture the output error messages.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[Anthony Walter]

Thanks for you work Maciej. Can someone please remember to make an
announcement in this mailing list when some/any of this is merged into
trunk?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Property overloading vs. property array enumerators

[Anthony Walter]

Here is a preferable solution:

property Controls: IControlEnumerator read GetItems;

This allows for both:

  for C in Test.Controls do ShowMessage(C.Name);
  // or
  for I := 0 to Test.Controls.Count - 1 do ShowMessage(Test.Controls[I]);

That is you can access the property as either an enumerable collection, or
and an indexed collection. Note it has support for a default indexer
property and a count property.

This is where where:

  IControlEnumerator = IIndexedEnumerator;

And:

type
  IIndexedEnumerator = interface(IEnumerator)
function GetEnumerator: IIndexedEnumerator;
function GetCount: Integer;
function GetItem(Index: Integer): T;
property Count: Integer read GetCount;
property Item[Index: Integer]: T read GetItem; default;
  end;

And finally putting together Test object as a simple example. Note that
TTest has full private access to the underlying container FList:

type
  TTest = class
  private
FList: TList;
function GetItems: IControlEnumerator;
  public
constructor Create(Controls: array of TControl);
destructor Destroy; override;
property Controls: IControlEnumerator read GetItems;
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Random thread-safe

[Anthony Walter]

Make it use lazy instantiation please.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

> Unlike Delphi, we have TCompare class and TEquals class, which is used
> for manual interfaces (together with TRawInterface and
TComTypeSizeInterface).
> Additionally (unlike in Delphi which has hidden regular functions for
this in
> implementation section with fake self parameter) TCompare and TEquals can
> be used in custom comparers.

I've just like to point out that with Svens new support for generic
functions, we actually have template like functionality in Free Pascal. You
can now write functions which will verify at compile time the support of a
method or operator for a particular type. This somewhat obviates the need
to register or pass compare or equal functions or interfaces.

For example, you can now write a in a type "TArray = array of T" sorting
implementation:

procedure Sort(var Items: TArray);
var
  A, B: T;
  I: Integer;
begin
  for I := Low(Items) to High(Items) - 1 do
  begin
A := Items[I];
B := Items[I + 1];
if A > B then
begin
 Items[I] := B;
 Items[I + 1] := A;
end;
  end;
end;

Obviously this is a terribly inefficient sorting algorithm, but it
demonstrates the feature clearly. The condition "if A > B then" will be
cause the compiler to verify at compile time whether or not the T being
used support comparison through the "<" operator. The same kind of support
extends to the "=" operator as well.

If you using symbols are unclear, the above routine could be altered to use
a CompareTo method. For example:

  if A.CompareTo(B) < 0 then

This would then cause the compiler to check the type B for a CompareTo
function with the appropriate signature. This can then be paired with type
helpers to add CompareTo methods to any type including the intrinsic ones.

Just so you know ...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

Maciej,

Wouldn't it be possible to take my idea and start developing a new library
which contains the generic containers you need? I have a nice generic
container unit you could use or just pull out the classes you need out of
the existing FPC generics unit, duplicate them in their your own unit, and
ship that unit separately.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

Tomas,

> Alright. So what is the authorship of the default units and how does it
> fit to Delphi compatibility?

At some point (soon) I hope Free Pascal and Lazarus will expand beyond
being Delphi compatible. In my recommendations I did not mean to infer that
Delphi compatibility should be broken or removed, but that new units or
even a new library can be added to Free Pascal or Lazarus which could be
considered a new "Core" set of Pascal libraries. This "Core" library would
offer a much improved Pascal coding experience with extensions to intrinsic
types like string or array or integer.

I posted on these lists previously about my very quick string library, both
in terms of execution speed and also in ease of use. The string type helper
extensions I've written make tasks like parse test or html relatively ease
with functions like FirstOf, SecondOf, LastOf, BeginsWith, EndsWith,
Contains, Split, Join, and so on. I also make good use of implicit
conversions in both my Array and ArrayList types as well as in the
Networking area.

So to answer that question, my proposal would not impact migrating from
Delphi to Lazarus, nor would it prevent you from using theses Core
libraries in Delphi (as long as the languages are the same).

> Nobody prevents vendors to use their namespace now, right?

Dotted namespaces weren't supported officially by FPC until two months ago
with the release of FPC 3.0. And it wasn't until recently that most of the
code tools and documentation issues with dotted namespace units were fixed.
I sent a patch just this month to fix allow for dotted names in the
documentation tool chain. Now that we're a few months past that point I
think we should look towards integrating them, and that is why I am raising
this subject now and not one year ago.

> The reason of current distribution is primarily due to multiple sources.
> See http://wiki.freepascal.org/Unit_categorization (now certainly
> incomplete, but still showing the point). Certain functionality gets to
> the FPC codebase due to compatibility with Delphi, etc., other stuff is
> added by us due to missing functionality (which may get added under a
> different name and to a different unit in Delphi later), etc. Lazarus
> decides on what to add where independently based on their needs. And so
> on. How could namespaces solve that?

You're kind of making my point, and that is some units and the functions in
them are reserved for Delphi compatibility. Great, we can have Delphi
compatibility, but for added on specific functionality it should probably
be noted as such "Core.Text". And this makes it very plain, if the code is
going to be original to and to be maintained by the Free Pascal team
members, then "Core.Text" is where all string related functions would go.
If you need something a bit more specific, then it goes under that, for
example "Core.Text.Encoding". This addresses the problem of "where does
this function I wrote go" much better than the current system we have
(SysUtils, StrUtil, LCLProc, LazUTF8).

> Not really - it would be easier only until the point when someone else
> than the original inventor of the naming system comes with something not
> fitting either of the categories perfectly (guaranteed to happen sooner or
> later). You may be perfectly clear where it belongs, while somebody else
> may have a different view / expectation. There is no golden rule, as
> simple as that. The only way to keep one consistent system is having the
> system managed centrally, but that doesn't work if there are at least
> three independent sources (FPC, Delphi and Lazarus).

Okay so what I am saying is clean it up, which is where you're going there
with centrally managed. The hub is "Core" and things go under that like
Networking, Graphics, Files, Text and so on. If anyone write a function
that checks for something having to do with the a file, like a funtion
FileCompare, then it goes somewhere under "Core.Files". It actually make
picking units to put stuff in easier.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

Michael,

I see the many benefits of dotted namespace units.

1) Authorship.

Instead of using cryptic prefixes (Rx, Syn, Id, and so on) if we promoted
the use of namespaces we might someday the full names denoting ownership
more clearly. That and there would be less me creating unit names conflicts
(My StrTools vs your StrTools).

2) Discovery

If you have groups of related functionality from a vendor it's easier to
discover with code insight tools using dots. For example Indy (dot)  Log (dot)  Debug (Out of
Indy.Log.Files, Indy.Log.Stream, Indy.Log.Event)

3) Organization

I have a set of string manipulation routines. The LCL has a set of string
manipulation related routines in a few units. Other people have string
manipulation routines in their units. Wouldn't it be nice if I could find
all string related routines under a one category like "Text", rather than
trying to find the string functions I need either from SysUtils, or
StrUtils, or LCLProc, LazUTF8, or Regex, or MyOwnStrUtils. When Core.Text
ought to cover all the basics of Text, Core.Regex would cover regular
expression, and maybe we could add a Core.Text.Encoding if needed.

4) Maintenance

I don't know about you, but when working with the LCL I often have trouble
deciding where some new or extra functionality should go. There was a
recent issue with this and the IsIdentifier function in mantis. Did it go
into LCLProc, or StrUtils, or where? With buckets like Core.Text, it would
sure make it easier to decide.

4) Grouping

Wouldn't it be nice if controls came under their own group first rather
than at the end? Currently people names units things like ShellCtrls,
GridCtrls, or DbCtrls. Wouldn't it be nice if you could find all possible
control units in source code by simple typing "Lazarus.Forms.Controls
(dot)" and seeing things like "Grids, Shell, and Database" in the list of
available units? Or maybe if you were dealing with web rendering toolkit it
might be "Lazarus.Web.Controls".

Perhaps you think this is too much typing, but code tools allows you to
pick a value after a few keystrokes. Also consider the typing saved in not
having to type TWebEdit or TWebGrid or TWebCheckBox or whatever you're
calling your web engine visuals. You can simply call it TEdit and TGrid and
TCheckbox. Think about all that typing saved (you only need to add a uses
clauses once in a unit, but how many times do you need TEdit? Sometimes
it's quite a lot.).

If you want some examples, look at my Bare library structure:

http://www.baregame.org/#bare_game
http://www.baregame.org/#bare_geometry
http://www.baregame.org/#bare_text
http://www.baregame.org/#bare_text_xml
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

I guess this is good time to ask, how would the community feel about
setting a new standard for Free Pascal units going forward? I am thinking
that since FPC 3.0 is now official we don't really have a good excuse to
start using many of the great new language features it brings, such as
dotted name spaces, type helpers on intrinsic types, and of course the now
good working generics.

I would propose we start migrating new units to this type of standard:

unit Core.Text;

New string related routines go here, including type helper extensions to
the string type. It may incorporate my fast unicode string search and
splitting engine along with the type helper StringHelper with methods such
as Split, Join, BeginsWith, EndsWith, and so on.

unit Core.Collections;

New generic container types go here including Array, ArrayList, and
possibly my multicast delegate TDelegate (see this page
http://www.codebot.org/delphi/?doc=9568).

unit Core.Network;

New basic socket class with other socket or network types such as
TAddressName (record type with implicit conversion from string and Resolve
method). Also the unit would includes an interface type for asynchronous
network requests.

The "Core" part of the namespace indicates that these units are officially
maintained by the Lazarus and Free Pascal committee members (those with svn
commit rights) and are included with every distribution of Free Pascal. I
think we could create several of these "Core" units to better organize a
Pascal library which incorporates many of the newer and useful language
features added since FPC 2.6.4.

What do you think about this idea of adopting this new Free Pascal library
standard which I believe would result in a cleaner organization of files
and perhaps better discovery of functionality for users?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Anthony Walter]

I'd also like to add that there might be more names under a namespace than
just two (e.g "Core.Text"). For example:

unit Core.Collections;
unit Core.Collections.Specialized;
unit Core.Text;
unit Core.Text.Xml;
unit Core.Text.Regex;
unit Core.Network;
unit Core.Network.Http;
unit Core.Network.Ftp;
unit Core.Network.Storage;
unit Core.Encryption;

And so on.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Capability CPUARM_HAS_BLX_LABEL with ARM instruction set

[Anthony Walter]

Sven, the FPC community is not that large as that of C, or Java, or Go. Our
figurative slice of potential users is reduced further when qualified as
FPC on the Raspberry Pi. My response to Garry was a sort of "Hey we both
like FPC and Pi, maybe some of us can band together to benefit FPC on Pi".
My thinking  was that splitting the conversation into separate thread would
create more fracture and less union.

It is up to Gary to decide if my comment was an unwanted diversion. Gary,
if you are reading this and feel I was diverting your original message in
an unwanted manner, then I apologize.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Capability CPUARM_HAS_BLX_LABEL with ARM instruction set

[Anthony Walter]

Hello Gary and thanks go out to both the FPC and Lazarus teams as well. I
don't want to hijack your thread, but I too am using FPC on the Pi, albeit
not to the level you've gone.

I believe the FPC community has the opportunity to expand to a new younger
audience with the Pi. With this in mind I believe it's important we call to
action as many knowledgeable people involved with FPC and Lazarus. We can
work together on materials or enhancements when presenting FPC and Lazarus
to Pi users. For example creating worksheet oriented tutorials showing the
easy and strength of FPC in an exciting way.

To that end I've created two friendly reduced footprint FPC 3.0 and Lazarus
Pi setup scripts. One script installs a minimal FPC 3.0 compiler (it
doesn't interfere with existing FPC per usual me), and the other is a
reduced FPC and Lazarus (again no interference).

Minimal FPC 3.0 for P bundled as tar.gz:
http://cache.getlazarus.org/archives/fpc-3.0.0.raspberry-min.tar.gz
Reduced FPC 3.0 + Lazarus bundled as a pure script:
http://www.getlazarus.org/download/?platform=raspberry

I've also been working on two graphics + inputs systems which operate
outside of the windowing system. One built around creating full screen
graphics with GLESv2, the other built around full screen graphics with
OpenVG. In my development so far I'm impressed both with the speed and
complexity of graphics the Pi2 GPU hardware + drivers can deliver, and with
how nice the FPC language can be in creating an object oriented class
library to simplify everything. I plan to create a Raspberry Pi worksheet
section for both at http://www.getlazarus.org.

In the end I think when presented correctly, FPC should be the obvious
choice to Pi users over C/C++, Python, Java, or Go, and that we (our
community) should be working together to achieve the best possible Pi user
experience with regards to FPC and Lazarus.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Lazarus] FPC Pestering Peacock (3.0.0) release

[Anthony Walter]

Sweeet! For Linux users here is a complete FPC 3.0 release + Lazarus from
svn build script:

http://cache.getlazarus.org/download/linux/install-3.0.sh
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI

[Anthony Walter]

Can someone refer me to a document regarding the whats planned for FPC RTTI
improvements? Is it aiming to support the current Delphi RTTI improvements
(attributes, virtual method intercepts, location and tvalue) or something
else?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Generic functions, procedures and methods

[Anthony Walter]

Sven, fair enough. I'll test out what you've published and if I find
anything interesting (strange compiler errors, edge cases, useful
scenarios) I'll post replies.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.0-rc2 release

[Anthony Walter]

Jonas, when FPC 3.0 release is ready will the Lazarus team also be
releasing a tandem version?

I ask because Ondrej's patch for this issue still isn't in SVN:

http://bugs.freepascal.org/view.php?id=22235
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

[Anthony Walter]

Okay, I'll check into more a bit later.

As a package manager, where is the description of packages? How is anyone
to know what webdesign is and what it does other than by just looking at
the package name and perhaps trying to google it?

The first google result for "fpc webdesign package" leads to a copy of a
mailing list question asking what the package does. After a bit more
googling it would seem that the OP is the author of the package.

To be of any value IMO, a package manager it ought to provide brief of
descriptions next to package names, otherwise people will have no idea what
they are looking at.

webdesign  add new form designer to Lazarus which can be used to build
websites

Also packages ought to be organized in such that the user knows what they
depend on or what is optional.

webdesign depends on lnet, gecko, embweb; optional jquery

I had to guess at the above and might be wrong. The only reason I picked
those packages is because they are only one which show up when libs isn't
configured they way fppkg expects.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

[Anthony Walter]

I got it working, somewhat.

It would seem that you have to duplicate the entire FPC lib tree
underneath {UserDir}.fppkg/

The instructions at the page referenced in my last post are very unclear
about that.

I suppose under normal fpc install this is needed because the lib files are
typically only create as root under some folder other than your $HOME (done
during install). This copy (assuming everything in fpc/lib is needed)
results in an extra 900MB of files duplicated and eating up disk space (I
use small SSDs on my laptop),

However, since I always clone FPC and Lazarus from sources and build
somewhere under my $HOME folder (normally $HOME/Development/Base or
$HOME/Development/FreePascal), I was able to set LocalRepository
and GlobalPrefix in ~/.config/fppkg.cfg to my FPC folder
( $HOME/Development/Base/fpc) and then fppkg worked, sort of.

I found that almost all package were already "installed". I take installed
to mean the package source were are already included with FPC and compile
when I ran "make all" some time ago.

Of the 6 package not installed, I could only compile half. The rest
complained with results similar to the following:

Target OS: Linux for x86-64
Compiling custembweb.pp
PPU Loading
/home/gigauser/Development/Base/fpc/lib/fpc/3.1.1/units/x86_64-linux/lnet/lnetssl.ppu
PPU Source: lnetssl.pp not found
Recompiling lNetSSL, checksum changed for openssl
lnetssl.pp(43,57) Fatal: Can't find unit lNetSSL used by lhttp
Fatal: Compilation aborted
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.0-rc1 release

[Anthony Walter]

Regarding the FPC 3.0 what's new language features, I think there is are
more new than what's listed on the wiki. Off the top of my head here two
language features not present in 2.6.4:

* Helpers now work on intrinsic types such as string and integer (eg.
StringHelper = record helper for string)
* Support for generic constraints (eg. TEmployee
= class)

If anyone else knows of other new to 3.0 language features not on the wiki,
please respond with a description of said language feature.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Thank You Sven Barth

[Anthony Walter]

Sven,

I noticed you recently fixed many compiler issues which were in the bug
tracker. I wanted give you a hearty 'Thank You' and let you know we
appreciate your work.

Thank You!

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

[fpc-devel] BUG: type aliases in records/classes cannot be used as fields without specialization

[Anthony Walter]

Report filed here:

http://bugs.freepascal.org/view.php?id=25236
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] A lot of stuff broke, looking for advice

[Anthony Walter]

I have a problem and am looking for advice. The problem is I had been
developing on 64-bit Linux using a trunk version of fpc from maybe 2-3
months back and now much of my core library no longer works when I use the
latest trunk version of fpc.

Here is what I am doing...

I am working towards publishing the next version of my minimal cross
platform game library (http://baregame.org) which includes static linking
by default, android support, video textures, programatic audio effects plus
3d sound mixing, post processing effects, much improved vector graphics
(everything is done with glsl shaders now), and much more.

I had two tasks for the week.

1) Make builds and test the IDE/framework installer for 32/64bit Windows
and Linux including a publish to an Android device
2) Make a series of videos demonstrating what coding with my framework
looks like showing what and it does and how the various systems within it
fit together on all platforms.

Working on task #1 I have all items working and all my milestones met on
64-bit Linux. I am now trying to recompile and test on 32-bit Linux and
then will move on to Windows. While working on testing my changes on 32-bit
Linux I encountered some problems I had mentioned in a previous email and
bug list (records with interfaces not being initialized/finalized
correctly). I decided test an upgraded compiler (which I will need to
support eventually) and now a lot of what I've written breaks.

My System and Types unit define a quite a few of generic base classes in
the Delphi style including generic constraints. I have types such as:

TEnumeratorT = class(TInterfacedObject, IEnumeratorT)
TArrayListT = record
TCollectionTItem = class(TInterface, IEnumerableTItem)
TInterfaceCollectionTItem: IInterface = class(TCollectionIInterface)
TOwnerCollectionTItem: TObject = class(TCollectionTItem)
TOwnerNamedCollectionTItem: TObject = class(TOwnerCollectionTItem,
INamedEnumerableTItem)
TListTItem = class(TAssignable, IEnumerableTItem, ICloneableTObject)
public
  type ItemType = TItem;
  function GetEnumerator: IEnumeratorItemType;
TIndexedListTItem = class(TListTItem)
TObjectListTItem: TObject = class(TIndexedListTItem)
TNamedObjectListTItem: TObject = class(TObjectListTItem,
INamedEnumerableTItem)
TStringList = class(TIndexedListstring)
IStringEnumerable = IEnumerablestring
TStringKeys = class(TInterface, IStringEnumerable)

ect...

All units my framework uses these types and those two units heavily, and
with an updated fpc trunk compiler they break in a big way. I suspect it
may take a quite a bit of effort on my part to get my codebase and working
with the current trunk version of fpc based on the number and types of
errors I am seeing, some of which are related to generics working
differently (I still have a problem with interfaces in not being
initialized properly at times). I am not sure how to proceed in fixing
these as I feel like this will happen again with another future release of
fpc breaking compatibility with the generics I've written. What should I do?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] A lot of stuff broke, looking for advice

[Anthony Walter]

Here is an example:

{ TObjectListTItem: TObject = class(TIndexedListTItem) }

bare.types.pas(1176,1)  procedure/function constructor Create(Boolean);An
unhandled exception occurred at $0816975E:
bare.types.pas(1182,1)  procedure/function procedure Clone:TObject;
Fatal: Compilation aborted
Error: ppc386 returned an error exitcode

{ TObjectListTItem }

constructor TObjectListTItem.Create(OwnsObjects: Boolean);
begin // line 1176
  inherited Create;
  FOwnsObjects := OwnsObjects;
end;

function TObjectListTItem.Clone: TObject;
begin
  Result := TObjectListTItem.Create(False);
  Assign(Result, Self);
end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Linux x86_64 trunk fails to build

[Anthony Walter]

For testing purposes I downloaded the Ubuntu 13.04 64bit version (which
came out today) and tried to build the fpc trunk. I encountered the
following problem during make all:

/home/username/fpc-2.6.2/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems
-Fu/home/username/fpc/fpc/rtl/units/x86_64-linux -Fix86_64 -FE.
-FUx86_64/units/x86_64-linux -Cg -dRELEASE-dx86_64 -dGDB -dBROWSERLOG
-Fux86 -Sew pp.pas
nx64flw.pas(32,37) Error: Identifier not found tcgraisenode
nx64flw.pas(32,37) Error: class type expected, but got erroneous type
nx64flw.pas(33,17) Error: There is no method in an ancestor class to be
overridden: tx64raisenode.pass_generate_code;
nx64flw.pas(52,1) Fatal: There were 3 errors compiling module, stopping
Fatal: Compilation aborted

I had this error twice. The first time I tried using Ubuntu's fpc package
(sudo apt-get install fpc) which gave me fpc version 2.6.0.

After that first failure I removed the fpc package and tried using version
2.6.2 (from http://sourceforge.net/projects/freepascal/?source=dlp) to make
the trunk version. I encountered the same error when attempting make all
again.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Linux x86_64 trunk fails to build

[Anthony Walter]

That looks like it did it, getting the older revision. I should have
thought of that myself. Thanks.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Does FreePascal support named parameters?

[Anthony Walter]

Frank,


The Javascript in Delphi code depends on active script engine. and
component of Windows. So no, the example I provided does not run on Linux.

But, and dynamic methods and properties (as well as named optional
arguments) are supported in Free Pascal, as long as you use a Variant (or
OleVariant) type which references an IDispatch instance. You can your your
own implementation of IDispatch on any platform, and the example I provided
does that. See TScriptlet which converts a TComponent derived instance into
an IDispatch and is thus compatible with dynamic and properties methods
when addressed via a Variant.

Example: MyVariant := TYourDispatchImplemention.Create as IDispatch; { and
later } MyVariant.SomeMethod(12.5, 'ParamOne' := EditControl.Text); { Calls
TYourDispatchImplemention GetIDsOfNames() passing 'SomeMethod', then
Invoke() with the dispid from the prior method and arguments packed into a
variant array }
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Does FreePascal support named parameters?

[Anthony Walter]

Name parameters are supported through variants.

procedure Test(V: Variant);
begin
  V.SomeMethod(12, ParamOne := '', ParamTwo := 12.5);
end;

Internally what happens is V is checked to for IDispatch, next
GetIDsOfNames is called to find the dispid of SomeMethod, then a variant
array of arguments is constructed (with the names), and finally Invoke is
called.

This comes from the Microsoft COM concept of automation,
though automation encompasses a bit more than IDispatch, including
marshalling, remoting, and error handling; passing errors back from a
remote machine for example.

People don't really use this stuff much anyone, nor is their much demand
for people with knowledge of the inner workings of COM. But if you want,
you can write your own objects which implement IDispatch.

See the source code in the download link on this page:
http://www.codebot.org/delphi/?doc=9573

ScripTools.pas class TScriptlet which exposes arbitrary pascal methods and
properties to a Javascript engine.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Type helpers in delphi mode

[Anthony Walter]

In the latest trunk of fpc are their any plans to allow for type helpers
and {$mode delphi}?

I ask this because I want to mix in a single unit both the delphi style
generics and type helpers and it seems that this is currently not supported.

Also, is there a single online 'living' reference everyone is maintaining
to describe both old and new languages features in the current build? I get
the feeling that maybe I have missed some improvements to fpc language
feature and can only discover them by searching through the archives of
this mailing list.

If not, would it be possible to get everyone on the same page and make this
happen? For example, by implementing a policy forcing people to update a
current version of fpc wiki before accepting language changing features.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Type helpers in delphi mode

[Anthony Walter]

Regarding my original question, the according to the wiki page (which is
now working), delphi  mode can use record helper instead of type helper,
and that seems to function correctly.

About the wiki page itself, I think it's missing some new features. I
believe type constraints on generics is new, and I don't see it on the
wiki. Which leads to me believe there could be other unlisted fpc language
enhancements, of which I wouldn't know.

Would it be possible get an enforceable policy on this point? I really
appreciate the time and care contributors make in language enhancements,
but it seems like their efforts can be diminished if the only way to know
about some of them is to constantly keep up messages tucked away in this
mailing list (or go back through the archives for new people).

Thanks


On Fri, Mar 29, 2013 at 10:11 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote:


 On 29 Mar 2013, at 15:02, Anthony Walter wrote:

 Also, is there a single online 'living' reference everyone is maintaining
 to describe both old and new languages features in the current build?


 http://wiki.freepascal.org/FPC_New_Features_Trunk and the corresponding
 pages for previous releases it links to (although the wiki seems to be down
 currently)


 Jonas

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


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

[fpc-devel] Sven, please look into cannot return generic derived class issue

[Anthony Walter]

Sven,

When you have the time could you look at issue #22019 titled Cannot return
generic derived class? I think it's kind of a big issue because it
prevents anyone from returning a subclass of a generic type. I just want to
know that's you've read the bug report and see/understand the issue.

In a nutshell you currently cannot write something like:

function TListT.GetEnumerator: TEnumeratorT;
begin
  // TListEnumeratorT inherits from TEnumeratorT
  return TListEnumeratorT.Create(Self);
end;

There are other examples, but I think the above and the details provided in
the bug report should be enough to convey the problem.

Thanks Sven! We all very much appreciate your work!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay Sven I'll be using the bug tracker with the generics to assist in
the best way I can. I just added an issue for the problem I mentioned which
I believe was previously an undocumented issue.

Issue #22019
http://bugs.freepascal.org/view.php?id=22019
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Generics are still broken

[Anthony Walter]

Generics still have a lot of problems.  I know they've been in the works
for years but they still fail easily. Consider the Delphi mode below, I get
Error: Generics without specialization cannot be used as a type for a
variable

I could easily write up a whole bunch of test cases were generic still
fail, both in Fpc and Delphi modes. If someone is considering working on
the compiler to fix the problems with generics I can happily send them a
bunch of test cases where the compiler currently fails.

{$mode delphi}

{ TEnumeratorT }

type
  TEnumeratorT = class abstract
  protected
function DoGetCurrent: T; virtual; abstract;
function DoMoveNext: Boolean; virtual; abstract;
  public
property Current: T read DoGetCurrent;
function MoveNext: Boolean;
  end;

{ TEnumerableT }

  TEnumerableT = class abstract
  protected
function DoGetEnumerator: TEnumeratorT; virtual; abstract; // Error:
Generics without specialization cannot be used as a type for a variable
  public
function GetEnumerator: TEnumeratorT;
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay, i'll try getting trunk sources from svn and building. I'll reporting
back shortly.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

The example problem I listed seems to be fixed in trunk. I'll write a few
more examples. Thank you FPC development team!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics are still broken

[Anthony Walter]

Okay with the latest trunk version I tried compiling my generic classes. It
seems there is a problem with fpc generics in that you cannot use a generic
as a type parameter. e.g type TDictionaryK,V =
class(TEnumerableTPairK,V) ...

Given:

type
  TCollectionT = class
  end;

  TPairK,V = class
Key: K;
Value: V;
  end;

// Test

var
  TestA: TCollectionTPairString,Integer; // Fatal: Syntax error, ,
expected but  found
  TestB: TCollectionString; // Okay

The same problem occurs with classes

type
  TDictionaryAK,V = class(TCollectionTPairK,V)  // Fatal: Syntax
error, , expected but  found
  end;
  TDictionaryBK,V = class(TCollectionInteger)  // Okay
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Jump to So here are some of the problems I've found with fpc generics if
you don't want to read the backstory.

I haven't been active in the FPC for a while, but last week I was asking
some questions about the upcoming Delphi FireMonkey project which is
supposed to allow broader development with Pascal/Delphi. My first question
to a newsgroup was, what about FPC, is the FireMonkey project going to work
with it? I was redirected to this article:

http://wiki.freepascal.org/FPC_New_Features_Trunk

Great, these were the new features I was looking for, bridging Delphi and
FPC {$mode delphi} features. So then last week I switched my laptop windows
SSD for my linux SSD and got the latest sources of FPC and Lazarus sources.
I wrote a new XML wrapper around both libxml and msxml, and then dove into
converting my Delphi generics library. My eventual goal is to create the
best cross platform game engine ever based on Delphi/Pascal.

I filled out a few bugs on the issue tracker for Lazarus where the new
generic syntax for  {$mode delphi} broke CodeTools. Then sent a few patches
to fix those issues myself (yeah me).

But then on Saturday I started out porting my generics library, and quickly
began to fall into depression. It seems FPC have a lot of problems with
generics. I had to take a break from all my language testing due to all the
problems I kept running into which made my head spin after each session of
tryng to figure out what the problems are.

On Sunday I sat down again and started hashing out how to get by with FPC
generics. In the evening I finally was able to focus in on the core problems
with the way generics work in FPC.

I'd like to contribute to fixing these problems, but honestly I have no idea
how to modify the compiler. I managed to send some patches off for
CodeTools, but believe the compiler is a whole other level that needs gross
amounts of fixings when it comes to generics. Something I'm not capable of.

Jump: So here are some of the problems I've found with fpc generics.

This does not include all the bugs that cause the compiler to act irrational
one moment and a different irrational the next moment. This is simply a list
of the things FPC generics can't do. I mention these rather than the generic
compiler bugs, because IMO if the way generics work aren't changed, it's not
even worth fixing the compiler bugs the existing syntax brings.

You can't write a generic method in a non generic class. The syntax
'TMyForm.ShowContentsT' is invalid is invalid in both objfpc and delphi
modes. You are forced to define a generic class if you want to use a generic
method.

type
  TStringConverterT = function(Item: T): string; // okay delphi mode, in
objfpc this line should begin with generic

  TMyForm = class(TForm)
procedure ShowContentsT(List: TListT; Converter:
TStringConverterT);

...

// Having a generic method is not okay
procedure TMyForm.ShowContentsT(List: TListT; Converter:
TStringConverterT);
var
  Item: T;
begin
  ListBox.Items.BeginUpdate;
  try
ListBox.Items.Clear;
for Item in List do
  ListBox.Items.Add(Converter(Item));
  finally
ListBox.Items.EndUpdate;
  end;
end;

You can't use generics without specialization.

// This is not okay. Instead you have to specialize TListT and
TStringConverterT inside TMyTestObjectT
procedure TMyTestObjectT.DumpContents(List: TListT; Converter:
TStringConverterT);
var
  Item: T;
begin
  FStrings.BeginUpdate;
  try
FStrings.Clear;
for Item in List do
  FStrings.Add(Converter(Item));
  finally
FStrings.EndUpdate;
  end;
end;

Specialization leads to problems, as specialized types from one class cannot
be share with another class. Also you cannot use specialization inside an
interface.

  IMyInterfaceT = interface
function GetCurrent: T;
// because of we specialization can't use other generics in an interface
function CurrentString(Converter: TStringConverterT): string;
procedure TakeFirst(List: TListT);
property Current: T read GetCurrent;
  end;

The solution:

Get rid of the whole specialization concept in fpc. Generics should be able
to be declared at any point using the type or a generic parameter. You
should be able to simply say things like:

type TMyClass = class List: TListInteger; end;

or

type TMyClass = class procedure CountDistinctT(List: ListT); end;

or

type TMyClass = class function Combine(List: Liststring): string; end;

or

type TMyInterfaceT = function MyMethod(List: ListT;
Converter: TStringConverterT): Integer; end;

And if someone ever does intent to fix generics in FPC, there are a whole
slew of errors that they already bring into the compiler. I'll make a list
of examples of those errors at a later time, but they inner workings of
generics should be redone to remove the specialization requirement before
those errors are addressed.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

On Mon, Aug 29, 2011 at 10:15 AM, Paul Ishenin webpi...@mail.ru wrote:

 Yes. These are known problems and you would found even more a year ago.
 Sven Barth now trying to fix exising problems and implement missing things.

 If you wish to try fix them yourself you need to study how parser part of
 the compiler works.

 Best regards,
 Paul Ishenin.


Paul, thanks for the reply. Did you mean to say that the generics are
actually being improved ... that is that someday you might be able to say:

procedure TMyNonGenericClass.MyGenericMethodT(List: TListT);

Or that the random seeming bugs with the existing way generics works is
being fixed?

I think the way generics work needs to fixed first, to allow code like above
to work. Then the strange bugs surrounding the new way they work can be
addressed.

One thing that basically needs to go away is the need to specialize a
generic. This causes problems even in {$mode delphi}.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Oh, and FPC generics really need the ability to add constraints ...

e.g. type TObjectListT: TObject = class TListT ... end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Thanks Jonas. Btw, where would be a good place to follow your progress on
JVm support?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

On Mon, Aug 29, 2011 at 11:19 AM, Sven Barth pascaldra...@googlemail.comwrote:

 Hi!

 As Paul and Jonas already told you, I'm currently working on improving the
 compilers generic implementation. As you have noticed it currently doesn't
 support generic methods and constraints at all. Also the generic
 implementation in mode Delphi isn't working correctly as you've noticed.
 Inline specialications (those without using type foobar = foobar) don't
 work either.

 For this I have found the following tasks:
 * allow declaring and implementing generics with the Delphi syntax while
 keeping the FPC syntax supported (this is an important point regarding
 backwards compatibility); state: working
 * allow the declarations of multiple generics with the same name (e.g.
 foot =... foo t, s = ...); state: mostly working
 * allow inline specializations; state: partly working inside
 implementations; inside declarations this needs to be tested
 * allow nested specializations: not started
 * allow nested generics: not started
 * implement generic methods: not started
 * implement constraints: not started

 My plan is to merge the changes from my branch to trunk after the first
 three points are done (the third one at least mostly as inline
 specializations are rather fragile) to reduce the differences between those
 to branches. Then I'll start working on either generic methods or
 constraints (depends on my mood then).

 Please keep in mind that working on the generics feature isn't an easy
 task, so I can't give you an estimate when the one or other improvement will
 be available.

 If you want you can test around with my branch, but please keep in mind
 that it's a work in progress and that compilation of the compiler or the RTL
 might also be broken from time to time (currently the fgl unit doesn't
 compiler for example).


  And if someone ever does intent to fix generics in FPC, there are a whole
 slew of errors that they already bring into the compiler. I'll make a list
 of examples of those errors at a later time, but they inner workings of
 generics should be redone to remove the specialization requirement before
 those errors are addressed.


 If you do such an error list then please provide a single program for each
 problem you encounter so that it might be integrated into FPC's test suite
 which will ease fixing the problem.

 Regards,
 Sven


Wow, Sven, thanks for the reply, and most definitely thanks for working on
FPC. Anything I can do to help I'll do. Last week I sent patches to fix
issues with Lazarus CodeTools and the new generic syntax which basically
caused a lot of problems in the IDE.

I'll be on freenode irc in both #fpc and #lararus-ide for the next few weeks
at least. Where do you want me to send some unit tests/test program source?
The issue tracker? One issue for each test that or all in all tests in one
issue?

Also be sure to let me know if there is anything I can do for you. I don't
have much experience with OSS collaboration, but am motivated to get things
done and done the right way.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics in FPC have many problems

[Anthony Walter]

Sven,

Tonight I tried to make all from your branch and wasn't able to build.
This is a the output I got:

http://pastebin.com/GQh5XA2w

I am guessing your build requires a working version of your fpc binary to
build itself.

Also, I wrote a few of pretty clean test cases in Delphi 2010 Today when I
had some downtime from my other work. I'd be interested in integrating them
cleanly into your tests and helping the fpc community any way I can.

Finally, I think I looked at your change log. I guess the last check in you
did was on July 16? I I reading that right?


r18005 | svenbarth | 2011-07-16 12:19:33 -0400 (Sat, 16 Jul 2011) | 1 line

Rebase to revision 18000

r18004 | svenbarth | 2011-07-16 10:13:56 -0400 (Sat, 16 Jul 2011) | 1 line

pexpr.pas, sub_expr: Added support for as and is operators if the right
hand side is an inline specialization (currently detected by the next token
being a ). This could potentially introduce some problems if the right
hand side isn't a specialization but a  comparison together with some
overloaded operators (I still need to find a case for such a problem)...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel