[fpc-pascal] Generic operator overload problem
Is this a bug or did I do something wrong? The minus operator overload seems to
be getting confused and I get a "Can't determine which overloaded function to
call" error as a result.
{$mode objfpc}
{$modeswitch advancedrecords}
program generic_vector;
uses
Math;
type
generic TVec2 = record
x, y: TScalar;
function Magnitude: TScalar;
function Distance (vec: TVec2): TScalar;
class operator - (left, right: TVec2): TVec2;
class operator - (left: TVec2; right: TScalar): TVec2;
end;
TVec2f = specialize TVec2;
TVec2i = specialize TVec2;
function TVec2.Magnitude: TScalar;
begin
result := (x ** 2) + (y ** 2);
end;
function TVec2.Distance (vec: TVec2): TScalar;
begin
// ->>> ERROR: Can't determine which overloaded function to call
result := (self - vec).Magnitude;
end;
class operator TVec2.- (left, right: TVec2): TVec2;
begin
result.x := left.x - right.x;
result.y := left.y - right.y;
end;
class operator TVec2.- (left: TVec2; right: TScalar): TVec2;
begin
result.x := left.x - right;
result.y := left.y - right;
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Generic type conflicts
I've wanted to make a generic version of a vector for a while but I always give
up because it seems not very possible. It's probably not even a great idea
because many methods don't translate between float and integer but I wanted to
prevent other code duplication if possible.
Here's an example of how things break down. Are there any solutions for this
currently? I feel like generics need to support some compiler directives so
different blocks of code can specialize different depending on the type.
{$mode objfpc}
{$modeswitch advancedrecords}
program generic_vector_2;
uses
Math;
type
generic TVec2 = record
x, y: TScalar;
function Normalize: TVec2;
end;
TVec2f = specialize TVec2;
TVec2i = specialize TVec2;
function TVec2.Normalize: TVec2;
var
fac: TScalar;
begin
// Can't determine which overloaded function to call
// Incompatible types: got "Extended" expected "LongInt"
fac:=Sqrt(Sqr(x) + Sqr(y));
if fac<>0.0 then begin
// Incompatible types: got "Single" expected "LongInt"
fac:=1.0/fac;
result.x:=x*fac;
result.y:=y*fac;
end else begin
result.x:=0;
result.y:=0;
end;
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic type conflicts
> On Nov 2, 2019, at 11:06 AM, Cyrax via fpc-pascal > wrote: > > You need to do a explicit typecasting. > > ... > fac:=Sqrt(Sqr(TScalar(x)) + Sqr(TScalar(y))); > ... > fac:=1.0/TScalar(fac); Doesn't work. Try running the example. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic type conflicts
> On Nov 7, 2019, at 12:28 PM, Ben Grasset via fpc-pascal
> wrote:
>
> {$IF GetTypeKind(T) in [tkInteger, tkInt64, tkQWord]}
> Result := A div B
> {$ELSEIF GetTypeKind(T) = tkFloat}
> Result := A / B
> {$ELSE}
> Result := Default(T);
> {$ENDIF}
This is what I hinted in my post. Has anything like this been considered
before? It seems necessary to me but it looks like Sven had some fancy work
around using pointers. Either way the compile time directive would be faster
and avoid the conditional statements.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic operator overload problem
> On Nov 8, 2019, at 5:32 PM, Sven Barth via fpc-pascal > wrote: > > This indeed appears to be a bug, but fixing it leads to some compilation > problems in Generics.Collections that need to be solved as well. So please > report this as a bug so that I don't forget it. Great, thanks. https://bugs.freepascal.org/view.php?id=36285 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Generics in Objective-C mode bug?
Is this a bug I should report? Knowing what I do about generics now I think the
type check needs to be suspended until the type is actually specialized.
{$mode objfpc}
{$modeswitch objectivec2}
program test;
type
generic TCocoaObject = objcclass (NSObject)
// ERROR: The type "TCocoaObject$1.T" is not supported for interaction with
the Objective-C and the blocks runtime.
m_obj: T;
function obj: T; message 'obj';
end;
function TCocoaObject.obj: T;
begin
result := m_obj;
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics in Objective-C mode bug?
> On Nov 11, 2019, at 1:25 PM, Sven Barth via fpc-pascal > wrote: > > Generics are not considered supported with Objective Pascal types. > There's really not any reason they shouldn't though. If you specialized with "string" for example that wouldn't be anything out of the ordinary so why does it matter if it's generic or not? Maybe Jonas has a reason I don't know about. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Add API to official documentation search
Could FPC make an API for the official documentation search at https://www.freepascal.org/docsearch/docsearch.var so we could make calls like: https://www.freepascal.org/docsearch/docsearch.var?word=List and get back a JSON object that had the search results? This is important for integration with 3rd party IDE's. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Add API to official documentation search
> On Nov 17, 2019, at 5:20 PM, Michael Van Canneyt > wrote: > > That would be me. > > And there already is an API. How else ? This is Free Pascal ! Sorry for the late response. Nice this is exactly what I wanted. However when I started to look at the actual results I'm confused. For my example of searching for "list" here is the first result: FCL units reference tfpobjectlist.html Return the first non-nil object in the list What is this exactly? I expected to get results like from https://docs.getlazarus.org where it would say this is a class or a method etc... and a description of the class. I had been using their API (Anthony is responsible for the project I think) but its got bugs and I haven't been able to contact the developer to fix them. What if I want to see the reference for TStringList? If I enter that term I get lots of results but all I have to go on is the "context" which doesn't really tell me what the result is how to filter it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Add API to official documentation search
> On Nov 18, 2019, at 1:15 PM, Michael Van Canneyt > wrote: > > As with all things FPC, the sources are available: > > svn co https://svn.freepascal.org/svn/html/docsearch docsearch > > Feel free to suggest improvements. It should be easy enough to add a first > element that contains an exact match on one or more identifiers by looking > for a file with the correct name, given an initial directory. Where are the doc pages generated from? For example https://www.freepascal.org/docs-html/rtl/classes/tstrings.html has a nice header "Class to manage arrays or collections of strings" and also at the top-right: Reference for unit "classes". There is even a "Description" section which is pretty good to know. Can you not get those back from the search results? Sorry if it's obvious but I don't know how you did the search. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] get_caller_frame
I came across get_caller_frame in some unrelated code and I was just curious about this so I wanted to ask. What does get_caller_frame return exactly? Is this a pointer to a stack frame that could be copied to the heap? I'm still interested in how we could add some form of coroutine like behaviors to pascal and so I was wondering if we could copy/restore the current stack pointer so that SetJmp and LongJmp would not blow things up. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] get_caller_frame
> On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal > wrote: > > It returns the address of the caller's frame pointer. See also > https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html > > It's mainly used in context of raising exceptions with the help of a second > function. See here: > https://freepascal.org/docs-html/current/ref/refse112.html#x227-24900017.1 > I guess I don't know what a frame pointer is. I thought it meant a pointer to the current stack frame and so I was curious if the RTL could include a way to copy the stack with the pointer and restore it later. Is that not how it works? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Add API to official documentation search
> On Nov 20, 2019, at 5:25 AM, Anthony Walter via fpc-pascal > wrote: > > You said, "but its got bugs and I haven't been able to contact the developer > to fix them" > > What are the bugs you want fixed? There you are. ;) There are stray tags which are messing things up. For example: https://docs.getlazarus.org/?method=codesearch&format=xml&phrase=List notice all the tags that are breaking up the titles. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] cvar external symbol name
Do cvars not allow external symbol names like functions do? With function I can declare a name but for cvar I'm getting an error. PyBaseString_Type:PPyTypeObject; cvar; external name 'somename'; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] get_caller_frame
> On Nov 21, 2019, at 1:41 AM, Sven Barth via fpc-pascal > wrote: > > No. On x86 it's essentially the content of the EBP/RBP register which is > (assuming no optimizations are done) essentially the ESP/RSP register of the > calling function. This is only used by the exception handling to have the > exception appear to be raised somewhere else. So what's missing then to be able make saving a stack frame to the heap and then restoring it? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cvar external symbol name
> On Nov 21, 2019, at 3:40 PM, Jonas Maebe wrote: > > The only thing cvar does is to mangle symbol name using the default > C-style name mangling. Specifying an explicit symbol name would just > overwrite whatever effect "cvar" has, so combining both is useless and > rejected. Thanks I see now. Btw just because I have your attention I made a bug report (https://bugs.freepascal.org/view.php?id=36333) that's ObjC related in case you didn't see it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate C macros which use stringification?
> On Nov 23, 2019, at 2:47 AM, Gabor Boros wrote: > > Can I do the same thing with FPC in a simple way? I translate some C source > to FPC and try to follow the original code. 99% certain this can't be done. I don't even think there's RTTI for local variable names but I could be wrong. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Pre-allocated TFPGList or similar
I need a pre-grown list which I can put (not insert!) items into at indexes without getting "List index out of bounds" errors. For example I want to start with a list that has 10 empty indexes: list := TList.Create(10); // 10 empty slots! list[5] := someItem; Is this possible using any list type in the RTL? Actually I'd rather just disable all the out of bounds errors because I need some performant which isn't making more checks than need be. I want to use a heap-based list because the it may need to grow later. Thanks guys. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Variant part in objects?
Is there a reason that objects don't support variant sections like with records? Maybe they mess with the VMT table when virtual methods are added? I just posted my "advanced objects" patch (https://bugs.freepascal.org/view.php?id=36350) and all it does is add "class operators" to objects but I was curious about the variant records because it appears to be the only other thing from records that aren't in objects. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pre-allocated TFPGList or similar
> On Nov 24, 2019, at 3:57 AM, Sven Barth via fpc-pascal > wrote: > > What you're looking for is the Count property. Setting it is supported by the > untyped lists in Classes, the generic ones in FGL as well as those in > Generics.Collections. > > === code begin === > > list := TList.Create; > list.Count := 10; > list[5] := someItem; I was trying that but with capacity and not count. Thanks. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Static linking to C library on Linux
I'm trying to link to a static library (built from Python sources) in Pascal and having troubles on Linux. On Mac where I have experience I successfully link and every works as expected but on Linux I get slews of linker errors in what appear to be standard C library functions. For example: /usr/bin/ld.bfd: /home/chris/pas/PythonBridge-master/sources/libpython3.7m.a(bytearrayobject.o): in function `memcpy': /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34: undefined reference to `memcpy' /usr/bin/ld.bfd: /home/chris/pas/PythonBridge-master/sources/libpython3.7m.a(typeobject.o): in function `_PyType_Name': /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:417: undefined reference to `strrchr' /usr/bin/ld.bfd: /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:107: undefined reference to `strlen' /usr/bin/ld.bfd: /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:108: undefined reference to `strncmp' /usr/bin/ld.bfd: /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:103: undefined reference to `strrchr' /usr/bin/ld.bfd: /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:107: undefined reference to `strlen' /usr/bin/ld.bfd: /home/chris/Downloads/Python-3.7.4/Objects/typeobject.c:108: undefined reference to `strncmp' Do I need to link to other system libraries when building on Linux? I'm also confused because I thought the purpose of the static libraries was to contain all the code they needed to run and thus these system functions like "memcpy" would be present also. I used to same make command I did on Mac to build the library but maybe I did something wrong on Linux. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Static linking to C library on Linux
> On Nov 27, 2019, at 11:25 AM, Karoly Balogh (Charlie/SGR)
> wrote:
>
> Yes. By Default, FPC doesn't link against libc on Linux by default, only
> when some more advanced things, say, threading is used. To the contrary on
> Darwin (macOS), we always link against libc. There comes your difference
> from. You can just try to add {$LINKLIB C} to your code, and see if that
> helps.
>
Thanks that makes sense now. {$LINKLIB C} did help some of the errors but I'm
still getting others. I'm aware of 'ldd' to show dependancies for dynamic
libraries but how can I do this for static libraries on Linux? I'm getting
defined references for math functions like pow, cos etc.. and some pthread ones
also. There's probably more but how can I know?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Static linking to C library on Linux
> On Nov 27, 2019, at 2:22 PM, Jonas Maebe wrote: > > There is no tool that can show this, because a static library is just a > collection of random object files. It does not contain any metadata > about where these symbols are supposed to come from (and they could o, > fact come from anywhere, be it individual object files, object files > collected in another static library, or a dynamic library). That's what I had originally thought. Can static libraries have dependancies on other static libraries? I noticed that when I linked a 12MB library my final binary was only 5MB so I presume there were duplicate symbols that were ignored. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Static linking to C library on Windows
Moving on to Windows now and more basic problems. I've built from Python
sources again but I'm not sure about static libraries on Windows. There is a
.dll which is a dynamic library and .lib which I assume is the static library.
Again I link using:
{$linklib python37.lib}
But I get: "Error: Invalid DLL XXX/python37.lib, Dos header invalid".
I see the compiler found the library but I may not have made the library
correctly. How can I know if this .lib is what I think it is?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Two possible generics bugs
Testing on 3.3.1. Are these both bugs? I wanted to ask first before filing a
report.
{$mode objfpc}
program test;
uses
FGL;
// No Error specializing TFPGList in parameter list...
generic function CopyList(source: specialize TFPGList): specialize
TFPGList;
begin
end;
// ... but getting an error specializing TFPGObjectList in parameter list
// Class type expected, but got "T"
generic function CopyList(source: specialize TFPGObjectList): specialize
TFPGObjectList;
begin
end;
begin
end.
===
{$mode objfpc}
program test;
uses
FGL;
// Type identifier expected
// Internal error 2019112401
generic function CopyList(source: specialize FGL.TFPGObjectList):
specialize FGL.TFPGObjectList;
begin
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Two possible generics bugs
> On Nov 28, 2019, at 6:38 PM, Sven Barth via fpc-pascal
> wrote:
>
> TFPGObjectList has a constraint to class types, so you need to constrain your
> T as well using ": class".
>
> Please note however that you'll likely encounter another bug then once you
> move your function to a unit: https://bugs.freepascal.org/view.php?id=35943
A better error would be nice but I guess I can't do this anyways until the
other bug is fixed.
> The "specialize" is part of the generic identifier, so it must be
> "FGL.specialize TFPGObjectList".
>
> That said however an internal error should not happen (especially the one I
> just added some days ago ^^'). Please report this one.
>
That doesn't look right to my eyes but ok. I filed a report
(https://bugs.freepascal.org/view.php?id=36377).
It looks like my plan was foiled so I made a non-generic attempt. Can you
explain why I get the EListError at runtime? I checked the itemSize property
and it's the same for both lists.
{$mode objfpc}
program test;
uses
FGL;
type
TNode = class (TInterfacedObject)
end;
TNodeObjectList = specialize TFPGInterfacedObjectList;
function CopyList (source: TFPSList): TFPSList;
begin
result := TFPSList(source.ClassType.Create);
result.Assign(source);
end;
var
a, b: TNodeObjectList;
begin
a := TNodeObjectList.Create;
// EListError: Incompatible item size in source list
b := CopyList(a) as TNodeObjectList;
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Two possible generics bugs
> On Nov 29, 2019, at 2:00 AM, Sven Barth via fpc-pascal > wrote: > > Why? It does say that a class type is expected. And the column of the error > should point to the correct location. > That's the same error you'd get when specializing outside of a generic with a > non-class type. I think you're right, my fault for not looking at the column close enough. > > > > The "specialize" is part of the generic identifier, so it must be > > "FGL.specialize TFPGObjectList". > > > > That said however an internal error should not happen (especially the one I > > just added some days ago ^^'). Please report this one. > > > > That doesn't look right to my eyes but ok. I filed a report > (https://bugs.freepascal.org/view.php?id=36377). > > The idea is that "specialize" belongs to the identifier just like "generic" > does. This comes especially apparent for nested specializations: > > SomeUnit.specialize SomeType<... >.specialize SomeFunc<... > What's your plan to make an implicit specialize modeswitch? I remember you said you wanted to and it sounds like low-hanging fruit I could maybe help with. The specialize keyword is a bit much in my opinion and it sounds like it could be omitted like Delphi mode does. > > begin > a := TNodeObjectList.Create; > // EListError: Incompatible item size in source list > b := CopyList(a) as TNodeObjectList; > end. > > Can't tell right now from looking at it. Will need to test that later on. > Anyone else have any idea? Doesn't make any sense to me. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Two possible generics bugs
> On Nov 30, 2019, at 1:04 PM, Sven Barth via fpc-pascal
> wrote:
>
> Well, if you want you can find any place where the _SPECIALIZE and _GENERIC
> tokens are used and checked against mode Delphi to check against a new
> modeswitch instead ("GENERICKEYWORDS") which must be enabled by default in
> all modes except the Delphi ones.
So to get Delphi mode style generics in ObjFPC mode you need to disable the
modeswitch? That's kind of backwards from what mode switches usually do but it
makes sense. How do you even disable a mode switch?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Two possible generics bugs
> On Nov 30, 2019, at 12:58 PM, Sven Barth via fpc-pascal > wrote: > > This can't work. ClassType is of type TClass and TClass.Create calls > TObject.Create, *not* the constructor of your list type, cause the > constructor chain is not virtual. Ok, so if the constructor was virtual this would work as expected? I guess that make sense. We really need implicit function specialization already but I don't want to bog down your review process anymore than I have. Removing the generic keyword will at least make this a little nicer to work with in the mean time and that's low hanging fruit. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Two possible generics bugs
> On Nov 30, 2019, at 12:58 PM, Sven Barth via fpc-pascal > wrote: > > This can't work. ClassType is of type TClass and TClass.Create calls > TObject.Create, *not* the constructor of your list type, cause the > constructor chain is not virtual. > > What you can do is this: > > === code begin === > > generic function CopyList (source: T): T; > begin > result := T.Create; > result.Assign(source); > end; > > var > a, b: TNodeObjectList; > begin > a := TNodeObjectList.Create; > b := specialize CopyList(a); > end. > > === code end === Found yet another internal compiler error trying your code: https://bugs.freepascal.org/view.php?id=36388 The previous day was another internal compiler error with inline functions in case you missed it. ;) https://bugs.freepascal.org/view.php?id=36381 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Confusing crash in System.WaitFree
I have a crash that I'm not able to replicate in a simple program and appears to be related to threading. All I have to go on is this back trace but it doesn't give any context into the calling code, just that it's in the FPC system unit. Does anyone have any idea what this may be related to so I could better track it down? I'm using POSIX threads and I wonder if I'm omitting something required for the FPC RTL. Process 13929 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000100020e07 Syndicate`SYSTEM_$$_WAITFREE_VAR$PMEMCHUNK_VAR + 23 Syndicate`SYSTEM_$$_WAITFREE_VAR$PMEMCHUNK_VAR: -> 0x100020e07 <+23>: movq 0xb8(%rdx), %rdx 0x100020e0e <+30>: movq %rdx, 0x18(%rax) 0x100020e12 <+34>: movq 0x8(%rax), %rdx 0x100020e16 <+38>: movq %rax, 0xb8(%rdx) Target 0: (Syndicate) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x000100020e07 Syndicate`SYSTEM_$$_WAITFREE_VAR$PMEMCHUNK_VAR + 23 frame #1: 0x000100020efa Syndicate`SYSTEM_$$_SYSFREEMEM_VAR$PFREELISTS$PMEMCHUNK_VAR$$QWORD + 42 frame #2: 0x000100020fdd Syndicate`SYSTEM_$$_SYSFREEMEM$POINTER$$QWORD + 109 frame #3: 0x00010001fe6f Syndicate`SYSTEM_$$_FREEMEM$POINTER$$QWORD + 15 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 21, 2019, at 10:49 AM, Adriaan van Os wrote: > > I had hoped that procedure IMyInterface2.P2 would now be visible as a method > of TMyClass. This would be quite helpful in implementing > multiple-inheritance. But no, the implements specifier completely hides it. I > assume this has been discussed before. That's exactly what I was ranting about some months back with the idea of "default properties". I would expect that syntax to pull the methods names into the current namespace and this would be very helpful. It's by design as Sven pointed out but this makes no sense whatsoever to me. If the compiler team agrees I will personally make a mode switch or whatever is permitted to accomplish this. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 22, 2019, at 5:26 AM, Sven Barth via fpc-pascal > wrote: > > You don't seem to understand what implementing an interface means in Object > Pascal. It means that a class can be cast to an interface. It does *not* mean > that the interface's methods are available from that class. I guess I'm not seeing the design pattern which they was invented for and I've never come across it in my own work. Not against the idea in any way however. My mind went in the same direction as Adriaan's did when I saw "implements" I thought that one class could be built from many smaller classes but share the same namespace (like in multiple inheritance or entity/component designs). If a class implements an interface via a delegate then I would expect this to function the same as inheritance, i.e. the namespaces are merged and share functions. Doesn't that make sense? Maybe what I mean to say is that there's a need for a delegation syntax that functions like multiple inheritance and avoids the traps of deeply nested single inheritance hierarchies. Does anyone else agree? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 23, 2019, at 2:02 AM, Sven Barth via fpc-pascal > wrote: > > What might be more interesting in this context than multiple inheritance is > the concept of aspects (aka aspect oriented programming though you might also > want to look for "mixin"; there's an old thread about that: > https://lists.freepascal.org/fpc-pascal/2009-December/023815.html). If we > could find an agreeable syntax and implementation for that then we'd be > potentially inclined to include that as a new feature as there had been > experiments for that in the past. > I never heard of "mixin" before but I'll study the wiki. I assume that the compiler team has decided multiple inheritance is a bad idea correct? Personally I don't have enough experience to know but I see there is a need to delegate work between classes and share a common namespace. I'm happy with any way to achieve that. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 23, 2019, at 7:57 PM, Ryan Joseph wrote: > > I never heard of "mixin" before but I'll study the wiki. > > I assume that the compiler team has decided multiple inheritance is a bad > idea correct? Personally I don't have enough experience to know but I see > there is a need to delegate work between classes and share a common > namespace. I'm happy with any way to achieve that. Here's what I got from reading. I saw this concept of "trait" from PHP (didn't even know it existed until now) and I think it would look like this in Pascal. From what I gather the "trait" is new kind of object that merely is injected into an object but it can't itself be allocated or assigned. Does that sound like what you had in mind? program mixin; type TBrain = trait procedure Eat; procedure Fight; end; type TPhysics = trait x, y, z: float; procedure Apply; end; type TBase = class use TPhysics, TRendering, TBrain; end; begin end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 24, 2019, at 1:16 AM, Sven Barth via fpc-pascal
> wrote:
>
> Basically, yes, though of course syntax, implementation and behavior need to
> be nicely defined first. For example there is the difference whether
> something is added at declaration time of the class or the creation time of
> the class (though that might be the difference between mixins and aspect
> oriented programming).
>
I hope you're all having a wonderful Christmas season. :)
Some more thoughts on this:
- My initial thought was that importing would happen at definition time simply
because I don't know what the difference would be to import at declaration time.
- Importing fields/properties is easy because we can just add symbols to the
symbol table but I'm not sure what it means in terms of the compiler to import
a method from another class. The method needs to be cloned or perhaps
synthesized as I've seen the term used in the compiler. Because the traits
aren't actually allocated like a class or record we need to copy the code out
into the class that uses them.
program mixin;
type
TBrain = trait
procedure DoStuff; virtual;
end;
procedure TBrain.DoStuff;
begin
writeln('do something');
end;
type
TBase = class
use TBrain;
end;
// TBase.DoStuff is synthesized from TBrain.DoStuff
procedure TBase.DoStuff;
begin
writeln('do something');
end;
begin
end.
- What about generics? Looks complicated and dubious so maybe that could be a
feature added later simply in the interest of taking things in small steps.
program mixin;
type
generic TBrain = trait
procedure DoStuff(param: T); virtual;
end;
type
generic TBase = class
private
use specialize TBrain;
public
procedure DoStuff(param: T); override;
end;
begin
end.
- Is overriding allowed? This presents a dilemma because we need to synthesize
the method from the trait (or whatever they will be called) and allow an
additional method which can call "inherited" and get the super method in the
same class. This would be new functionally for the inherited keyword since the
overriding is happening in the same class.
program mixin;
type
TBrain = trait
procedure DoStuff; virtual;
end;
procedure TBrain.DoStuff;
begin
writeln('do something');
end;
type
TBase = class
use TBrain;
procedure DoStuff; override;
end;
// TBase.TBrain_DoStuff is synthesized from TBrain.DoStuff
// and renamed to prevent name collisions
procedure TBase.TBrain_DoStuff;
begin
writeln('do something');
end;
procedure TBase.DoStuff;
begin
// inherited calls TBase.TBrain_DoStuff
inherited;
writeln('do more stuff');
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 27, 2019, at 8:21 AM, Adriaan van Os wrote: > > The code of a "mixin" or "trait" or "delegate" (or whatever > implementing-something) can be referenced and it can put virtually into the > namespace of an object. The one thing you cannot do however, is copy the > code, because then the basic problem of mutiple-inheritance pops-up again --- > which is what route for virtual methods to take in a multiple-inheritance > "tree" that is no longer a tree but a graph. For the same reason, methods > overriding methods imported from the implementing-something will still > actually override the methods in the implementing-something, even if they > virtually seem to be in the namespace of the importing object. Should the traits/aspects even be overridable then? If they are it sounds like they need to be implemented the same as inheritance and this would basically just make them a different syntax for multiple inheritance. I don't think that's what Sven had it mind and if he did why not just do proper multiple inheritance using the existing syntax that interfaces uses? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 27, 2019, at 10:01 AM, Sven Barth via fpc-pascal
> wrote:
>
> To be clear: with declaration time I mean when the type is written (" = class
> ... end") versus creation time (either "var x: tmyclass" or "x := tmyclass
> .create"). The difference would be that the user of the class would decide
> what is supported instead of the declarer of the class. Adding something at
> creation time would of course require that the functionality can only be
> accessed dynamically (similar to GetInterface, though like that it can be
> hidden behind e.g. the "as" operator) and that the functionality needs to be
> independant of the existing class.
Got it.
>
>> - Importing fields/properties is easy because we can just add symbols to the
>> symbol table but I'm not sure what it means in terms of the compiler to
>> import a method from another class. The method needs to be cloned or perhaps
>> synthesized as I've seen the term used in the compiler. Because the traits
>> aren't actually allocated like a class or record we need to copy the code
>> out into the class that uses them.
>
> You don't need to do any copying of the functions. You need to partition the
> instance so that fields that belong to a specific trait are grouped together
> and then you pass an adjusted self pointer to the trait's methods so that
> this only sees accesses its own fields (and properties are the same as
> methods or field access: use the correct Self part).
Can you explain or gives some function names of where/how the importation of
fields/methods happens for inheritance? For fields I'm seeing that the struct
data size expands when a super class is parsed and then in searchsym_in_class
the correct symbol is found but I don't know what happens after that. The data
must be copied at some point but I don't know when.
For method calling I think you're saying we merely pass a different self
pointer depending on which class in the hierarchy makes the call.
>
> What I'm still missing however is a real use case. What you have presented as
> an example can just as easily be done with the existing delegates. And just
> to avoid having to cast the instance to the interface is in my opinion not
> enough reason for a new feature.
It's really just about the namespace and avoiding deeply nested this.that.do
kind of syntax. We could accomplish this using just plain records, no need to
even get involved with the complicated interface syntax. According to the wiki
https://en.wikipedia.org/wiki/Trait_(computer_programming) lots of other
languages are having this need to build component like systems and want a
syntax that formalizes the concept.
Adriaan, what was your idea you had in mind when you brought this up?
program test;
type
TBrain = record
procedure Eat;
procedure Fight;
end;
type
TPhysics = record
x, y, z: float;
procedure Apply;
end;
type
TPerson = class
physics: TPhysics;
brain: TBrain;
end;
var
p: TPerson;
begin
p.brain.DoThis;
p.physics.x += 1;
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 27, 2019, at 10:29 AM, Ryan Joseph wrote: > > It's really just about the namespace and avoiding deeply nested this.that.do > kind of syntax. We could accomplish this using just plain records, no need to > even get involved with the complicated interface syntax. According to the > wiki https://en.wikipedia.org/wiki/Trait_(computer_programming) lots of other > languages are having this need to build component like systems and want a > syntax that formalizes the concept. I also wanted to mention this article which talks about default interface implementation (protocols in Swift) which exists in at least C# and Swift. Is that a viable route perhaps since we already have interfaces? http://machinethink.net/blog/mixins-and-traits-in-swift-2.0/ Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface delegates and the implements property specifier
> On Dec 27, 2019, at 1:39 PM, Adriaan van Os wrote: > > etcetera. The disadvantage of this approach is that for example a default > DoKeyCommand must be written three times, for TApplication, TDocument and > TView, where the code for TDocument.DoKeyCommand and TView.DoKeyCommand is > identical. > > Identical code is clumsy. Therefore my wish that a helper object could > somehow be put in the namespace of the importing object, including the > ability to override the imported methods. I hope that answers you question. This makes perfect sense to me but see what Sven says. I've encountered this same problem many times over the years where you want code modularity but can't use inheritance. There is absolutely a need for this syntax in my opinion and that fact Apple is holding developer conferences over it further shows this (https://developer.apple.com/videos/wwdc/2015/?id=408). The interface delegation has so much boiler plate and doesn't help with the namespace issues so I'm not sure why it's better then making your TQDGraphPort and TEventHandler records and just including them as fields in the main class. I think they were designed for some other pattern that I'm not familiar with myself. The idea of traits/aspects is similar but falls under the umbrella of class composition as an alternative to inheritance. The article I posted before (http://machinethink.net/blog/mixins-and-traits-in-swift-2.0/) actually has some good use case examples including pretty charts and pictures. Swift uses protocol extensions to accomplish "Protocol-Oriented Programming" which would be the equivalent of interface helpers in Object Pascal. We can't use fields in interfaces or helpers though so this won't work for us I'm afraid. program mixin; type IBrain = interface procedure Eat; end; type IPhysics = interface procedure Apply; end; type TPhysicsHelper = interface helper for IPhysics procedure Apply; end; procedure TPhysicsHelper.Apply; begin // ... we can't add fields in helpers or interfaces! end; type TPerson = class(IBrain, IPhysics) end; begin // calls TPhysicsHelper.Apply via the IPhysics interface in TPerson person.Apply; end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Error format changes between compilers
Notice how the format of the error changes between ppcrossx64 (built for iPhone simulator) and ppcx64. Is this a bug? It broke my regex for capturing errors and that's why I'm asking btw. Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcrossx64 -Tiphonesim -vbr /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas Free Pascal Compiler version 3.3.1 [2019/12/28] for x86_64 Copyright (c) 1993-2019 by Florian Klaempfl and others Target OS: Darwin/iPhoneSim for x86_64 Compiling /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas:4:2: error: Syntax error, "BEGIN" expected but "identifier F" found error: Compilation aborted Ryans-MacBook-Pro-2:output ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcx64 -vbr /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas Free Pascal Compiler version 3.3.1 [2019/11/26] for x86_64 Copyright (c) 1993-2019 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas /Users/ryanjoseph/Developer/Projects/FPC/CocoaTouchExamples/test.pas:4: error: 2: Syntax error, "BEGIN" expected but "identifier F" found error: Compilation aborted Ryans-MacBook-Pro-2:output ryanjoseph$ Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Calling function pointer to main program
I need to override the main program function and then call back the main program later. I know I can use -XM to set another function name besides "main" but then how do I call back the original function "main" later? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling function pointer to main program
> On Jan 2, 2020, at 2:51 PM, Sven Barth via fpc-pascal > wrote: > > What exactly are you trying to accomplish on which platform with which > version? > I'm making an iOS platform layer in the style of SDL which needs to use iOS's main loop which never returns until the program stops execution. Within the iOS callbacks I need to then callback into the programs main begin..end block so the user can establish their own event loop (which then uses threads to synch between the 2 event loops). I've got the SDL source code but I'm not understanding how they get control back to the user even using the -XM flag. They have a function: extern C_LINKAGE int SDL_main(int argc, char *argv[]); which they call from within the iOS event loop and that calls the programs main functions which was defined using -XMSDL_main Sorry if that doesn't make sense but I barely understand the problem myself. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling function pointer to main program
> On Jan 2, 2020, at 2:57 PM, Ryan Joseph wrote: > > extern C_LINKAGE int SDL_main(int argc, char *argv[]); > > which they call from within the iOS event loop and that calls the programs > main functions which was defined using -XMSDL_main I still can't figure out how -XM works. Can anyone provide an example? When ever I try to use it I get linker errors. I've basically just started with a trimmed down program that does nothing but define an external new main function (like SDL does). From the SDL sources I thought that it would now point to the main program body but I can't get past linker errors. fpc main.pas -XMuser_main Undefined symbols for architecture x86_64: "_P$TEST_$$_USER_MAIN$LONGINT$PCHAR$$LONGINT", referenced from: _PASCALMAIN in main.o "_main", referenced from: start in crt1.10.5.o (maybe you meant: _user_main) program test; uses ctypes; function user_main(argc: cint; argv: pchar): cint; external; begin user_main(0,''); end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling function pointer to main program
> On Jan 3, 2020, at 11:35 AM, Jonas Maebe wrote:
>
> Additionally, you will also have to link in an object/library that does
> define a regular "main" function. And note that this will only work on
> libc-based targets (afaik only Darwin, Solaris, and AIX at this point).
So there needs to be a function named "main" that is linked to directly or can
it just be in a unit? I tried doing this but still get linker errors (tested on
MacOS of course). My example program is below.
It's possible I think -XM does something it doesn't also so here's is the main
function for the SDL/ios bindings. Note how UIApplicationMain is called which
then never returns control until the program exists. After that within the iOS
event handlers a call is made to SDL_main (see the external definition) which
if I understand correctly is set using -XP and this then in turn calls the
begin..end block of the main Pascal program. Is that correct?
extern C_LINKAGE int SDL_main(int argc, char *argv[]);
int main(int argc, char **argv)
{
int i;
/* store arguments */
forward_argc = argc;
forward_argv = (char **)malloc((argc+1) * sizeof(char *));
for (i = 0; i < argc; i++) {
forward_argv[i] = malloc( (strlen(argv[i])+1) * sizeof(char));
strcpy(forward_argv[i], argv[i]);
}
forward_argv[i] = NULL;
/* Give over control to run loop, SDLUIKitDelegate will handle most things
from here */
@autoreleasepool {
UIApplicationMain(argc, argv, nil, [SDLUIKitDelegate
getAppDelegateClassName]);
}
/* free the memory we used to hold copies of argc and argv */
for (i = 0; i < forward_argc; i++) {
free(forward_argv[i]);
}
free(forward_argv);
return exit_status;
}
Later on in the event handler called from UIApplicationMain:
// call the user program main function so they can enter their own event loop
logic
exit_status = SDL_main(forward_argc, forward_argv);
=
here is my test case:
fpc main.pas -XMuser_main
unit umain;
interface
uses
ctypes;
function user_main(argc: cint; argv: pchar): cint; cdecl; external;
function main(argc: cint; argv: pchar): cint;
implementation
function main(argc: cint; argv: pchar): cint;
begin
result := user_main(args, args);
end;
end.
program main;
uses
umain;
begin
writeln('called user main');
end.
The linker error I can't get past:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.5.o
(maybe you meant: _user_main)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calling function pointer to main program
> On Jan 3, 2020, at 12:29 PM, Jonas Maebe wrote: > > So add 'cdecl; public;" to its declaration and definition. Nice the demo program compiles now. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] -WP compiler macro?
Is there a compiler macro which is set to the value of -WP? It would be useful to know which SDK I'm targeted while compiling so I can omit certain code at compile time. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Delphi generics bug?
Is this a bug or intended behavior? I would think there should a type mismatch.
{$mode delphi}
program test;
type
TFooA = class
end;
type
TFooB = class
end;
type
TList = class
procedure Foo;
end;
procedure TList.Foo;
begin
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi generics bug?
> On Jan 14, 2020, at 8:04 PM, Sven Barth via fpc-pascal > wrote: > > It's a bug because constraints should not be allowed in definitions, only in > declarations. > ok, I'll file a report if you want me to. I'll just leave it as it is for the constants because the fix will probably encompass both of them. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi generics bug?
> On Jan 14, 2020, at 11:44 PM, Sven Barth via fpc-pascal > wrote: > > Indeed. And yes, please file a bug. > https://bugs.freepascal.org/view.php?id=36584 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Interface type error
Why doesn't this compile? IClassName2 descends from IClassName1 so shouldn't
TClassName be compatible with IClassName1?
{$mode objfpc}
{$interfaces corba}
program test;
type
IClassName1 = interface
end;
IClassName2 = interface(IClassName1)
end;
type
TClassName = class(IClassName2)
end;
procedure Pass(int: IClassName1);
begin
end;
var
c: TClassName;
begin
// Incompatible type for arg no. 1: Got "TClassName", expected "IClassName1"
Pass(c);
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface type error
> On Feb 2, 2020, at 3:23 PM, Sven Barth via fpc-pascal > wrote: > > As I had explained in the other thread some months ago interfaces in Object > Pascal mean literally that the type can be cast to the specified interfaces. > Parent interfaces are *not* part of this. If you want this you need to first > cast the class to IClassName2, then the "interface inheritance" mechanism can > take over. > Hmm, isn't that inconsistent given how classes work? if TClassName implements IClassName2 then doesn't it also implement IClassName1 by definition? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Property write access on records
In the snippet below why isn't it an error to write to a field of the read-only property? I was hoping this would give me some type safety but it just writes to a temp variable and does nothing. Not very helpful if you ask me. = type TSheet = record m_tableSize: TVec2i; function GetTableSize: TVec2i; property TableSize: TVec2i read GetTableSize; end; var sheet: TSheet; begin // why isn't this an error? sheet.x := 1; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Objective-C mode switch overrides open arrays?
The for loop thinks the open array of NSObject is an ObjectiveC array and thus
gives me an error. Is this a bug?
=
{$mode objfpc}
{$modeswitch objectivec2}
program test;
uses
CocoaAll;
procedure Test(input: array of NSObject);
var
obj: NSObject;
begin
// Incompatible types: got "{Open} Array Of NSObject" expected
"NSFastEnumerationProtocol"
for obj in input do
;
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Passing static arrays to open arrays
Here's another issue I found with open arrays. Why isn't the static array of
NSArray compatible with "array of pointer"? You can assign NSArray to pointer
so why is the open array different?
===
{$mode objfpc}
{$modeswitch objectivec2}
program test;
uses
CocoaAll;
procedure Test(input: array of pointer);
begin
end;
var
list: array[0..10] of NSArray;
p: pointer;
begin
// no problem!
p := list[0];
// Incompatible type for arg no. 1: Got "Array[0..10] Of NSArray", expected
"{Open} Array Of Pointer"
Test(list);
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property write access on records
I didn't get this reply on the mail list and just looked on the mail list archive and found it! Not sure what happened or if it's going to happen again. Sven's reply: === I assume you mean "sheet.TableSize.x"? Otherwise your example makes no sense... In that case: you are working on a temporary copy of the record. It does not affect the TSheet instance anymore (that's essentially the same reason why C operators or var parameters are not allowed for properties). === Yes, it's a temporary variable but doesn't it make sense to give an error because the property is read only? It's basically a no-op like it is now and defeats the purpose of read-only properties. It also creates a nasty bug because the programmer thinks they've written to something but they actually didn't. Can we consider changing this behavior? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Cannot find system type "__m64"
I'm continuing this from the bug tracker. Also please note that for some reason the mail list server has stopped sending me replies to gmail so I need to look at https://lists.freepascal.org/pipermail/fpc-pascal/ for replies until this get fixed. Maybe time to get rid of gmail? My private web host email was also failing though. :P ~/Developer/ObjectivePascal/fpc-git/compiler/x86_64/pp test.pp error: Cannot find system type "__m64". Check if you use the correct run time library. Can anyone explain this error? I have a trunk repository which I update from svn and a dev repository that I update from git (and build using the supplied lazbuild projects). After I updated the trunk compiler I started getting this error when building the dev compiler. Sven says "you need to cleanly rebuild your trunk system with a release compiler." I tried: make clean all FPC=/usr/local/lib/fpc/3.0.4/ppcx64 OPT='-XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk' but this doesn't seem to help. Tried deleting the lazbuild units and trying again also but that doesn't work. Are the wrong RTL files be used or something? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property write access on records
> On Mar 5, 2020, at 2:24 PM, Ryan Joseph wrote: > > Can we consider changing this behavior? from https://lists.freepascal.org/pipermail/fpc-pascal/2020-March/057434.html On 05/03/2020 08:24, Ryan Joseph via fpc-pascal wrote: > Yes, it's a temporary variable but doesn't it make sense to give an error because the property is read only? It's basically a no-op like it is now and defeats the purpose of read-only properties. It also creates a nasty bug because the programmer thinks they've written to something but they actually didn't. > > I think there is already an open bug report for this. Jonas I looked on the bug tracker for "properties" and didn't see this so I'll make one but I wanted to confirm first it's not intended behavior. Jonas seems to hint that it is but Sven didn't mention it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cannot find system type "__m64"
> On Mar 6, 2020, at 2:04 PM, Sven Barth via fpc-pascal > wrote: > > Yes, that is the problem. When Florian had merged the SIMD intriniscs branch > those types were enabled, but they weren't ready yet. Thus he disabled them > later on again (a day or two later). If you had compiled trunk during that > time you can get mixed results, though it's strange that it does... > If clean doesn't help (maybe even use the "svn cleanup" or whatever) you > could try to increase the PPULongVersion in compiler/ppu.pas, rebuild, then > lower it again and rebuild again. Ok, I got this reply finally so maybe something else went wrong. I'm tempting to try another account with some free email service because Gmail never shows my initial post, which is annoying. The development repo I use is from GitHub and I haven't updated it since a month ago or so but I guess it's still using RTL units from the trunk (the trunk, 3.3.1 is from SVN). I'll try to clean and rebuild the actual trunk and see if that helps. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property write access on records
> On Mar 7, 2020, at 5:15 AM, Sven Barth wrote:
>
> I've found two bug reports related to this (I searched for "property" and
> only those reports that are neither closed nor resolved):
> - https://bugs.freepascal.org/view.php?id=23620
> - https://bugs.freepascal.org/view.php?id=14534
>
> And I noticed that the following already does generate an error:
Yes, you're right this does trigger the correct error. My example was actually
bad because I didn't notice that my problem was coming from a more complex
situation.
Given the code I get no error because the "width" property of the helper is
writeable but the "point" property is read-only. This should still give the
error because even though "width" is writable the "point" is read-only and the
assignment will still go to temporary memory, thus failing silently.
Should I file a new bug report for this?
{$mode objfpc}
{$modeswitch advancedrecords}
program test;
type
TPoint = record
x, y: integer;
end;
type
TSizeHelper = record helper for TPoint
procedure SetWidth(newValue: integer); inline;
procedure SetHeight(newValue: integer); inline;
function GetWidth: integer; inline;
function GetHeight: integer; inline;
property Width: integer read GetWidth write SetWidth;
property Height: integer read GetHeight write SetHeight;
end;
procedure TSizeHelper.SetWidth(newValue: integer);
begin
x := newValue;
end;
procedure TSizeHelper.SetHeight(newValue: integer);
begin
y := newValue;
end;
function TSizeHelper.GetWidth: integer;
begin
result := x;
end;
function TSizeHelper.GetHeight: integer;
begin
result := y;
end;
type
TThing = record
m_point: TPoint;
function GetPoint: TPoint;
property point: TPoint read GetPoint;
end;
function TThing.GetPoint: TPoint;
begin
result := m_point;
end;
var
t: TThing;
begin
// no error!
t.point.width := 0;
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property write access on records
> On Mar 7, 2020, at 3:39 PM, Sven Barth wrote: > > Helpers indeed don't help there (pun intended :P). Please report, yes. And > add a reference to the two bug reports I mentioned. > https://bugs.freepascal.org/view.php?id=36768 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] modeswitch multihelpers precedence problem
> On Mar 10, 2020, at 11:57 AM, Anthony Walter via fpc-pascal
> wrote:
>
> To demonstrate, if I have MyUnit.pas that defines a string type helper with
> EndsWith() and an IntToStr() function then consider the following code:
>
> program Test;
>
> uses
> MyUnit, SysUtils;
>
> begin
> 'hello'.EndsWith('lo'); // invokes MyUnit.TStringHelper.EndsWith()
> IntToStr(12); // invokes SysUtils.IntToStr()
> end.
>
I think the problem here may be because SysUtils doesn't enable the mode
switch. In that example above I would expect EndsWith to be used from the last
unit, that is SysUtils. If you remake the example without SysUtils and define
the type helpers in 2 units that both enable multihelpers does it work
correctly?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] modeswitch multihelpers precedence problem
> On Mar 10, 2020, at 8:09 PM, Anthony Walter wrote:
>
> An issue has been submitted here
> https://bugs.freepascal.org/view.php?id=36783 under the FPC compiler with
> tags "type helpers".
Can you make up an example that doesn't use SysUtils? Here's something I made
up really quick but I don't see the bug.
All I did with multi helpers was continue the search which stopped at the first
hit so all the normal overloading rules should apply as normal.
===
{$mode objfpc}
{$modeswitch typehelpers}
{$modeswitch multihelpers}
program test;
uses
umultihelpers_precedence0,
umultihelpers_precedence1;
begin
'hello'.EndsWith('lo');
IntToStr(12);
end.
===
{$mode objfpc}
{$modeswitch typehelpers}
{$modeswitch mutlihelpers}
unit umultihelpers_precedence0;
interface
type
TStringHelper = type helper for string
function EndsWith(str: string): boolean;
end;
function IntToStr(int: integer): string;
implementation
function TStringHelper.EndsWith(str: string): boolean;
begin
writeln('EndsWith - umultiplehelpers_precedence0');
end;
function IntToStr(int: integer): string;
begin
writeln('IntToStr - umultiplehelpers_precedence0');
end;
end.
===
{$mode objfpc}
{$modeswitch typehelpers}
{$modeswitch mutlihelpers}
unit umultihelpers_precedence1;
interface
type
TStringHelper = type helper for string
function EndsWith(str: string): boolean;
end;
function IntToStr(int: integer): string;
implementation
function TStringHelper.EndsWith(str: string): boolean;
begin
writeln('EndsWith - umultiplehelpers_precedence1');
end;
function IntToStr(int: integer): string;
begin
writeln('IntToStr - umultiplehelpers_precedence1');
end;
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Error format in trunk changed (again)
Here's an example of 2 error formats which changed across compiler version (I think -vbr gives the gcc style output). The first format is the one I thought was standard but the last time I updated trunk it changed to the second format (line:column:). Was this a mistake or did I mess something up myself? GLPT_IPhone.inc:97: error: 20: Identifier idents no member "touchID" Main.pas:88:1: error: Identifier not found "f" Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Pass open array to static array?
Why doesn't it compile to pass an open array to a static array of the same
size? That would nice if this worked since it makes assigning values so easy.
program test;
var
data: array[0..2] of integer;
begin
// Incompatible types: got "{Array Of Const/Constant Open} Array of ShortInt"
expected "Array[0..2] Of LongInt"
data := [1,2,3];
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Killing the mail list
It's 2020 and the mail list is starting to really show its age. I don't get first messages from gmail and my personal web host is whitelisted, messages bounce when I use the wrong account by accident, hard to search the archives, can't post images and code easily (big problem!), messages gets lost or un-threaded when subjects are incorrect, and the list goes on (pun not intended). Has there ever been any discussion into replacing it with a modern web based forum? I don't know how to manage this migration but it should be a goal for the future in my opinion. Personally I really like the format used in forum.sublimetext.com which is from www.discourse.org. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
> On Mar 15, 2020, at 8:53 PM, Howard Page-Clark via fpc-pascal > wrote: > > > With recent FPCs you can however do this: > > program test; > var > data: array[0..2] of Integer; > tmp: array of Integer = Nil; > begin > tmp := [1,2,3]; > Move(tmp[0], data[0], SizeOf(data)); > end. yeah I figured you can do something similar with generics: generic procedure Move(source: array of T; var dest); var bytes: SizeInt; begin bytes := length(source) * sizeof(T); Move(source, dest, bytes); end; begin specialize Move([0.0, 0.5, 0.0, -0.5, -0.5, 0.0, 0.5, -0.5, 0.0], data.verts); end. but why doesn't open arrays already do this? an open array is just a constant array so the compiler should know the arrays are compatible for assignments. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Killing the mail list
> On Mar 16, 2020, at 12:36 AM, fredvs via fpc-pascal > wrote: > > Hello. > > You may use http://free-pascal-general.1045716.n5.nabble.com/ > > This forum is an archive for the mailing list > fpc-pascal@lists.freepascal.org > > Fre;D Looks like everyone here likes the mailing list. Very well then. Thanks, this looks really helpful. How does this nabble.com site work? It looks like it can intercept the messages from the mail list or something. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
Ok, that makes sense now. Dynamic arrays can't be passed to static arrays. I remember when I tried to make aligned dynamic arrays I got to look around in the code and it seems plausible you could just make a memcpy call in the RTL for dynamic arrays being passed to static arrays. Seems deceptively easy. :) Shouldn't it be a constant array though? I'm not sure how the compiler works but from the programers perspective I thought I was getting something without runtime allocation because the array contained only constant values. -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Killing the mail list
> On Mar 18, 2020, at 1:31 AM, Kevin Monceaux wrote: > >> It's 2020 and the mail list is starting to really show its age. > > With age comes wisdom. No need to discuss this further, everyone loves the mail list. I'll try using the forums instead. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] sizeof TTypeKind?
Are there any functions in the RTL to get the sizeof the type specified in TTypeKind? https://www.freepascal.org/docs-html/rtl/typinfo/ttypekind.html I'm truing to use record RTTI and I needed to know the size of the field in the record. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sizeof TTypeKind?
I'm going to loop through the fields of the record and get the size of each field so I can serialize the record. Am I not on the right track? - Regards, Ryan Joseph -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sizeof TTypeKind?
> On Mar 21, 2020, at 9:39 AM, Ryan Joseph via fpc-pascal > wrote: > > I'm going to loop through the fields of the record and get the size of each > field so I can serialize the record. Am I not on the right track? No answers on this so I'm thinking maybe I need to use TManagedField^.FldOffset to get the information I need about the field size. Is that correct way to get the field size using record RTTI? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sizeof TTypeKind?
> On Mar 21, 2020, at 10:05 AM, Anthony Walter via fpc-pascal > wrote: > > I think what Ryan is asking about is how to find the size of the variant part > of TTypeData as used in the "case TTypeKind of" section. As in: Yes. It says a field is "tkInteger" but what size is that? I know it's 4 bytes on my system put I don't want to make a lookup table since there's surely a better way to do this. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sizeof TTypeKind?
> On Mar 21, 2020, at 10:15 PM, Sven Barth via fpc-pascal > wrote: > > For the primitve types you need to know the sizes at compile time (e.g. > SizeOf(Word), SizeOf(LongInt), etc.) and check what type the field has using > the field list in the record's RTTI. You also have to keep in mind that some > types are grouped. E.g. tkInteger is for all integer types that are smaller > than 64-bit. The real type is then available as TTypeData.OrdType and you > need to handle that size accordingly. For structured types like records the > size is contained in the RTTI. The FldOffset field is important to get the > correct offset of a field, because padding might be involved depending on the > platform (except if your record is "packed"). ok, I guess I need to make a lookup table for tkInteger etc... or just take the field type names directly and map them myself. Btw, I was thinking that the new custom attributes could be used to add RTTI to record fields but it appears to be limited to classes, and other class definitions. Is that correct? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Chaining method calls
Is it possible to achieve this dynamically without resorting to type casting?
It feels like classes should have a builtin type for each class, like
TClassType, which similar to TObject.ClassType but is a compile time type.
=
{$mode objfpc}
program test;
type
TBase = class
// TClassType should be the type of the current class
private type TClassType = ...;
public
function AndThis: TBase;
end;
function TBase.AndThis: TBase;
begin
result := self;
end;
type
TMyClass = class (TBase)
end;
var
c: TMyClass;
begin
// error: Incompatible types: got "TBase" expected "TMyClass"
c := TMyClass.Create.AndThis;
writeln(c.classname);
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Chaining method calls
Free Pascal - General mailing list wrote > Is it possible to achieve this dynamically without resorting to type > casting? It feels like classes should have a builtin type for each class, > like TClassType, which similar to TObject.ClassType but is a compile time > type. I didn't think enough before sending this because this clearly isn't a compile time issue. Currently this probably isn't possible unless there is an "AnyClass" type or something like that. Not sure if that exists in Pascal but methinks not. - Regards, Ryan Joseph -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Chaining method calls
> On Mar 24, 2020, at 8:39 PM, Michal Wallace via fpc-pascal > wrote: > > Hi Ryan, > > It's possible. Just change your declaration of `c`: > > var c: TBase; > > It still prints TMyClass at the end. > > Of course, you're only going to have access to methods that are declared in > TBase. > You can also approach this sort of thing with interfaces... > True, but then we're stuck in a typecasting game where I need to cast "c" back to TMyClass. :) I probably brought this up years ago and forgot but Objective-C has an "id" type which is "can assign to any class type". It seems like something that would be standard for OOP but I don't recall ever seeing it in Pascal or C++. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generic proc inference
I hope you're all having a lovely Coronavirus lockdown-vacation and keeping
safe. :)
I finally got around to the overhaul of {$modeswitch
implicitfunctionspecialization} as according to feedback in this thread. I
attached a patch in the bug tracker which should apply without conflicts. In
particular, Mattias, if you remember any of this please re-test and see if it
works better now (I didn't include any tests yet). As for Sven I've left my
design notes for you to review. I think I did what you wanted and the
overloading works correctly now.
from the bug tracker:
https://bugs.freepascal.org/view.php?id=35261
I've done an overhaul on the previous design so I'm posting a patch which is a
draft version (with debug writeln's as placeholders for proper error messages).
If the design is sane I will clean everything up and probably inline some
functions.
1) the entire inference process is redone according to feedback (see
try_implicit_specialization).
- array types and function pointers can be used for specialization.
- templates can appear in any order now DoThis(a: U; b: T);
2) as was requested by Sven the dummy syms are now valid procsyms and are
passed along to tcallcandiates for overloading.
3) The inference is done at one location in do_proc_call but we could possibly
move that inside tcallnode.pass_typecheck if it were better for some reason.
4) I added a tprocsym.add_generic_candiate to associate procsyms with dummy
procsyms but I wasn't sure if this was good design so it's not cpu compliment
and thus specialization from units will fail.
5) non-generic overloads are filtered in htypechk.is_better_candidate but I
don't feel like I integrated my check in the right place due to me not really
understanding that function.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
> On Mar 16, 2020, at 5:40 AM, Sven Barth wrote: > > The message of the compiler is a bit misleading. It's a *dynamic* array that > is created there, not an *open* array. Open arrays only exist when being > passed directly to a parameter. I forgot to ask. Are open arrays constants, or are they essentially dynamic arrays also? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
> On Apr 3, 2020, at 3:43 PM, Sven Barth wrote: > > They are neither. They are simply a pointer to the first element and a hidden > size argument. For the pointer it is not important where it comes from: a > single element, a dynamic array, a static array. > Ah, I see. In the example below the open array is still a dynamic array right? As you said earlier dynamic arrays are never constant/static (for now at least) and therefore [1,2,3] is a dynamic. procedure DoThis(a: array of integer); ... DoThis([1,2,3]); Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
> On Apr 3, 2020, at 10:09 PM, Sven Barth wrote: > > No. The "[...]" for an open array parameter means "open array constructer" > *not* "dynamic array constructor". And this on-the-fly open array is in fact > constructed on the stack. Ok, I see now. Excellent. I thought this was another dynamic array being created and destroyed. > > If your DoThis would be declared with a dynamic array parameter (e.G. > "specialize TArray") then you'd in fact have a temporary dynamic > array constructed on the heap. > > Also I didn't say that dynamic arrays can't be constant, but that they only > are so if declared in a const section. > can you post an example of a const dynamic array? I tried and it thinks it's a set so I can't assign to an open array. Also that made me think, is it possible for an open array parameter to be written to if its source was a static array? You said it's a pointer so I wonder if it's possible to use them instead of passing a static array pointer with an additional parameter for the length. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Error format question
Sorry to ask this yet again but I keep forgetting or remembering wrong. I thought this was a one time error that was fixed but I'm still getting different error formats with the trunk (as of today) vs 3.0.4. Can anyone please confirm which it the correct format I should rely on? Ryans-MacBook-Pro-2:~ ryanjoseph$ fpc -vbr /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:6: error: 1: Identifier not found "f" /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:7: error: 4: There were 1 errors compiling module, stopping error: Compilation aborted Ryans-MacBook-Pro-2:~ ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcx64 -vbr /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas Free Pascal Compiler version 3.3.1 [2020/04/11] for x86_64 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:6:1: error: Identifier not found "f" /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:7:4: error: There were 1 errors compiling module, stopping error: Compilation aborted Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
> On Apr 11, 2020, at 1:17 PM, Michael Van Canneyt > wrote: > > My guess is you have a config file lying around that causes this to look > different (-Fr option?), or you have a custom-made errore.msg file built-in. Interesting, so I overrode the default format in the trunk somehow. I can't find any -Fr options but who knows what file I may have corrupted. What's the best way to get back to the default format then? At some point I thought the format changed so I altered a bunch of my regex patterns in various areas and it's causing me many headaches. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
> On Apr 11, 2020, at 8:12 PM, Florian Klämpfl wrote: > > I fixed this for trunk. You can very easily test and see what gcc outputs to > verify what's correct. Thanks, I could swear this was a bug that was already fixed but I'll rebuild the compiler tomorrow and see if it went away. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
> On Apr 11, 2020, at 9:50 PM, Ryan Joseph wrote: > > Thanks, I could swear this was a bug that was already fixed but I'll rebuild > the compiler tomorrow and see if it went away. I just did svn up and got r44689, rebuilt the compiler but I still get the same error format. Was it supposed to be changed? Ryans-MacBook-Pro-2:fpc ryanjoseph$ /usr/local/lib/fpc/3.3.1/ppcx64 -vbr /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas Free Pascal Compiler version 3.3.1 [2020/04/12] for x86_64 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Darwin for x86_64 Compiling /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:6:1: error: Identifier not found "f" /Users/ryanjoseph/Developer/Projects/FPC/Various/stratch_pad.pas:7:4: error: There were 1 errors compiling module, stopping error: Compilation aborted Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
> On Apr 12, 2020, at 11:16 AM, Ryan Joseph wrote: > > I just did svn up and got r44689, rebuilt the compiler but I still get the > same error format. Was it supposed to be changed? ok, I think we're confused here. Just actually tested gcc and got this format: /Users/ryanjoseph/Developer/Projects/C++/Tests/test:10:6: error: expected expression This means that FPC 3.0.4 is giving the wrong format and I guess we're stuck with that like it is. That means trunk is and was fine like it is. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pass open array to static array?
I just came across another related issue to this thread. Is it not possible to init dynamic arrays from static arrays? I remember there being more compatibility between the 2 types but I may have forgotten. var a: array[0..1] of integer; d: array of integer; begin d := a; end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
yes! Pascal *badly* needs this to be productive outside of Lazarus. I use Sublime Text and frequently now VSCode but not having good code tools is getting painful. In fact I already started a language server some months ago (and since been busy with out stuff) but I think you've made more progress than me so I'll help to develop yours if you would like. I was even asking on the list about Lazarus code tools and was showed how to FPC's official parser works. Please let me know what else needs to be done and I'll see if I can contribute. Thanks, really. > On Apr 23, 2020, at 7:13 AM, Arjan Adriaanse wrote: > > I am new to Pascal programming and since I like using Emacs, I wanted > to try to improve its support for editing Pascal code. I decided to > implement an LSP server which text editors can use as back-end for > providing IDE features. The server is implemented in Free Pascal and > uses the CodeTools package for doing the actual work. > > The implementation is still incomplete and unstable but so far I > managed to get code completion working. Apart from improving > stability and adding features, I am sure there are more possible > improvements, since this is my first Pascal project. The project can > be found at https://github.com/arjanadriaanse/pascal-language-server > [1], any help and feedback is welcome. > > A module is provided for using the server from Emacs, but it should be > straightforward to add support for other LSP clients such as Visual > Studio Code. > > Regards, > > Arjan > > [1] https://github.com/arjanadriaanse/pascal-language-server > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 2:08 PM, Michael Van Canneyt > wrote: > > VSCode has omnipascal ? > (The TMS Web core VS Code studio plugin uses this, and it seems pretty > complete) yes it does but they don't support ObjFPC mode syntax very well which means things like the "generic" keyword and "is nested" to name a couple, break the parser and render the entire document invalid. It's also closed source and likely to be for profit eventually which is a deal break imo. A language server for FPC is too important to be allowed to be within a single companies control. > >> >> In fact I already started a language server some months ago (and since been >> busy with out stuff) but I think you've made more progress than me so I'll >> help to develop yours if you would like. I was even asking on the list about >> Lazarus code tools and was showed how to FPC's official parser works. >> >> Please let me know what else needs to be done and I'll see if I can >> contribute. > > Very nice ! > > I suppose this can be used as a back-end for Atom and VS Code as well then ? > That would be really cool ! yes exactly. See the docs https://microsoft.github.io/language-server-protocol/specifications/specification-3-14. I think currently he supports just code completion but there's a whole lot more. LSP is a good idea and thankfully backed by a large company but it's painfully slow because the client needs to send the entire document in plain text to the server which then needs to be parse the entire thing, and this happens every time the document changes at all. That means with every keystroke the document is parsed and analyzed. The FPC parser doesn't support this anyways but the protocol doesn't even support sending partial changed text offsets. I talked in length with the LSP people at Sublime Text and this is just how it's going to be for now. LSP is very new however so expect it to improve in the future. > > A good excuse to dive into Atom package development using pas2js :-) > Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
Arjan, I briefly skimmed over your code and it looks like instead of using the "DocParser" unit that I was using the parse the files, you're directly using the Lazarus "CodeToolBoss" which I don't have any experience with. I think it was Michael actually who instructed me to use this parser but I also think he said the Lazarus code tools use this under the hood. What are the implications of using the code tools as opposed to implementing the parser directly? If you have documents you could direct me to about the code tool units that would be helpful. I have an ok understand of LSP now and I want to make sure the code tools is able to supply everything we need. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 3:00 PM, Michael Van Canneyt > wrote: > > I think the decision to use the codetoolboss is the best, see above as to why. Very well. I assume the code tools parses the entire project and keeps the symbols in a database? That was something I was going to have to implement myself so it's good to not have to now. I'm using the parser with "TPasElement" so I think that's fcl-passrc. It's a shame to have so many competing parsers but yours looked really solid to me. Here the basics which code tools needs needs to provide: 1) Basic identifier completions like function, class, types names etc... these should be scope sensitive based on the document offset we receive from LSP. 2) Function parameter completions. 3) Class/record member completions. 4) Identifier references, i.e return all locations "DoThis" was called in the current workspace. (Workspace is the LSP term for the project). Code tools thus needs to parse all files in the workspace upon initialization. 5) Go to definition/declaration in workspace. I would like to implement "code lens" which shows the context of a symbol in a popup window but I think only VScode supports this feature and it's no common so code tools may not be able to retrieve. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 3:49 PM, Mattias Gaertner via fpc-pascal > wrote: > >> >> 3) Class/record member completions. > > I guess you mean identifier completion after a dot. Exactly. Fields or methods and helpers even if possible. I assume that exists. Btw, the names you're giving like "FindDeclaration" where can I find these? Maybe there's a wiki or unit header I can look at. > >> I would like to implement "code lens" which shows the context of a symbol in >> a popup window but I think only VScode supports this feature and it's no >> common so code tools may not be able to retrieve. > > What do you mean with "context"? Codetools can give you all kind of context. For example VScode lets you hover over a symbol name like TObject and a window will popup that shows the declaration in code, like a mini-editor that goes to the line where the declaration starts in that file. It's basically the same as opening a new tab/window but it's more for really quick references. I'm not sure how it's implemented in LSP but maybe you could return the line number and file name and the client does the rest. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 6:29 PM, Arjan Adriaanse wrote:
>
> Also, any feedback on my existing code is welcome, especially since
> this is my first Pascal project.
You did a nice job structuring it I think and providing a template to scale up
from. What language(s) are you coming from and why did you decide to make a
language server for Pascal if you're not a Pascal user? Just curious.
I wrote my list of missing protocol implementations so that is what I'll be
focusing on initially.
I'm trying to build this now using lazbuild on macOS and get some strange
errors including:
lsp.pas:154:12: error: Identifier not found "specialize"
How could this be? {$mode objfpc} is declared right at the top.
Another curios one is:
lsp.pas:134:33: error: Incompatible types: got "" expected ""
I'm not usually a Lazarus user but I think lazbuild should work. Here's the
command I use:
lazbuild "./pasls.lpi" --cpu=x86_64 --widgetset=cocoa
I use the cocoa widgetset on Mac because I get errors otherwise. That shouldn't
be related though.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 8:20 PM, Arjan Adriaanse wrote:
>
> Perhaps not all the used generics features are available yet in older
> FPC versions. I use the most recent release candidate from
> ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/ [2], but will
> investigate if older versions also work.
Lazbuild used FPC 3.0.4. How do I make lazbuild choose the trunk instead of
3.0.4?
The first thing to address is TCompletion.Process and how it interacts with
code tools. For example:
URI := ParseURI(textDocument.uri);
Code := CodeToolBoss.FindFile(URI.Path + URI.Document);
X := position.character;
Y := position.line;
Line := Code.GetLine(Y);
GetIdentStartEndAtPosition(Line, X + 1, PStart, PEnd);
CodeToolBoss.IdentifierList.Prefix := Copy(Line, PStart, PEnd - PStart);
How LSP is intended to work is that a text buffer which contains the current
state of the file is sent to the server and then this buffer is parsed. I think
what the code above does is only operate on the file on disk. This maybe be
fine for certain completions but it will be static until the user saves the
file in the client. Worse yet is that the text offset we receive from the
client is going to be out of sync.
Here's an example request:
{
"method" : "textDocument/didChange",
"jsonrpc" : "2.0",
"params" : {
"textDocument" : {
"uri" : "file:///Users/ryanjoseph/Desktop/FPCLS-Test/parser_test.pas",
"version" : 1
},
"contentChanges" : [
{
"text" : "..."
}
]
}
}
and a hover request which shows the problem. Line 10 is from the didChange
request, not line 10 from the file on disk.
{
"method" : "textDocument/hover",
"jsonrpc" : "2.0",
"id" : 3,
"params" : {
"textDocument" : {
"uri" : "file:///Users/ryanjoseph/Desktop/FPCLS-Test/parser_test.pas"
},
"position" : {
"line" : 10,
"character" : 13
}
}
}
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 9:11 PM, Mattias Gaertner via fpc-pascal > wrote: > > If LSP updates parser_test.pas, then codetools will notice. > > If LSP only sends changes, then you have to apply these changes to > codetools codebuffers: > Code.Insert/Delete/Replace/Move > > Modified codebuffers are not auto updated from disk, until you Revert or > Save. This is what we need to do then otherwise nothing will work. LSP for some insane reason doesn't even provide a changed text, just the full document every time. I guess we need to use Replace every time. I talked with the Sublime Text people and they since isn't even supported from their API so even if LSP supported it there will be clients that don't provide the information anyways. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 9:11 PM, Arjan Adriaanse wrote: > > The CodeToolBoss actually keeps a cache of files which are loaded at > the 'textDocument/didOpen' notification. When the user changes text at > the client side, even without saving, a 'textDocument/didChange' > notification is sent which is used to update the cache. The > CodeToolBoss seems to only use the file path as identifier, but the > contents of the files and changes are provided by the client. Excellent, I didn't see that yet. Ugh, I rebuild using trunk 3.3.1 and now get this error: /Users/ryanjoseph/Developer/lazarus/lcl/./include/custompage.inc:139:34: error: Operator is not overloaded: "Class Of TCustomTabControl" and "Boolean" I guess we need to use 3.2 and nothing else. I didn't even know 3.2 existed so I need to download it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 9:11 PM, Arjan Adriaanse wrote: > > lazbuild --compiler=/usr/lib/fpc/3.2.0/ppcx64 pasls.lpi is there a macOS installer for 3.2? I found a link to a FTP server but I don't see this exists. Maybe fix that bug in trunk is the better idea. My lazarus sources are old also so perhaps this was fixed? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
I just tried update my lazarus sources using "svn up" and now I'm getting another strange error when using lazbuild. /Users/ryanjoseph/Developer/lazarus/components/ideintf/ideintf.pas:11:3: fatal: Can't find unit LazarusPackageIntf used by IDEIntf Do I need to do something else to get the sources updated? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
> On Apr 23, 2020, at 9:51 PM, Mattias Gaertner via fpc-pascal > wrote: > > You have old ppu files. > > For example: > make distclean all ok, did this and now getting: /Users/ryanjoseph/Developer/lazarus/components/lazdebuggergdbmi/gdbmidebugger.pp(63,16) Fatal: (10022) Can't find unit PropEdits used by GDBMIDebugger svn up says "At revision 63051." Never an easy time building lazarus for me. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
