Re: [fpc-pascal] specify variable name with string variable
> On Jul 7, 2019, at 3:58 PM, James Richters > wrote: > > This might sound silly, but is it possible to somehow specify a variable > with a string containing the name of the variable? Does you mean like RTTI so you can get a pointer to a local variable by name? I was actually curious about this recently also, does FPC have local variable RTTI? That would be useful to have actually. I know it exists for classes but not sure about locals. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc errors
> On Oct 15, 2019, at 5:26 PM, Benito van der Zander wrote: > > you could do > > var > it: pointer; > obj: TObject absolute it; > begin > for it in list do > begin > // continue on like before using “obj” instead of “it" > end; > That is a clever solution but it’s basically a sneaky trick around the compilers excessively strict typing. The programmer knows the correct type but there’s no way to tell that to the for loop. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc method/function invocations
Another related question about functions. In unit files there is a InterfaceSection/ImplementationSection in TPasModule and I can use those to get a list of functions (because they descend from TPasSection). In a program file there only seems to be a InitializationSection but this doesn’t contain the same list of functions. So, how do I find the functions in a program module? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc method/function invocations
> On Oct 15, 2019, at 5:02 PM, Mattias Gaertner via fpc-pascal > wrote: > > When parsing a program the module is a TPasProgram, which has a > ProgramSection. Of course, thanks. A couple other questions if you don’t mind: 1) Are there any examples of the resolver? I’m looking through the unit and it looks pretty dense. 2) Can the parser take strings as input or just files? I ask because I have a string without a file and currently I’m saving it into a temporary file and giving that to the parser. 3) Can the parser handle code fragments? If not is that something I can possible extend it to accommodate? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc errors
> On Oct 15, 2019, at 6:13 PM, Michael Van Canneyt > wrote: > > Of course there is: make the list the correct type. No typecasting needed > then. I guess I’ll get used to it but we have lots of code like this (snippet I posted earlier from the parser): Declarations: TFPList; // list of TPasElement // Declarations contains all the following: Attributes, // TPasAttributes Classes,// TPasClassType, TPasRecordType Consts, // TPasConst ExportSymbols,// TPasExportSymbol Functions, // TPasProcedure Properties, // TPasProperty ResStrings, // TPasResString Types, // TPasType, except TPasClassType, TPasRecordType Variables // TPasVariable, not descendants : TFPList; where we have generic lists that we cast later to get the correct type. All these now are going to require new specializations for each class and changing the declarations. In fact this means using TFPList is not really a good idea at all anymore unless you don’t plan to use for..in loops. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Dynamic loading to static?
Maybe a stupid question but I thought I’d asked before I potentially waste a bunch of time. I have code to dynamically load functions using Dynlibs.LoadLibrary, for example: type _Py_Initialize = procedure; cdecl; _PyImport_ImportModule = function(module: pchar): PPyObject; cdecl; var […] Py_Initialize := _Py_Initialize(GetProcAddress(handle, 'Py_Initialize')); The problem is I would like to change this to static linking now but I only have function pointers instead of declarations. Is there a way I can get the compiler to statically link these function pointers or do I need to manually change them all by hand to be things like: function PyImport_ImportModule(module: pchar): PPyObject; cdecl; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic loading to static?
> On Oct 25, 2019, at 12:02 PM, Michael Van Canneyt > wrote: > > You need to manually change them. > > if you look in the packages, you'll see that many library import units exist > in 2 > flavours. One static, one dynamic. That’s what I was afraid of. btw, I why does ObjFPC mode not allow this but Delphi mode does? GetProcAddress returns a pointer and I get a type error which can’t be solved because the type of Py_Initialize is anonymous, i.e. there is no formal declaration. Is there a way to cast around this in ObjFPC mode? It would be lots of extra work to add the extra types in because the original code was Delphi. var Py_Initialize: procedure; cdecl; begin Py_Initialize := GetProcAddress(handle, 'Py_Initialize'); Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic loading to static?
> On Oct 26, 2019, at 4:26 AM, Sven Barth via fpc-pascal
> wrote:
>
> CodePointer(Py_Initialize) := GetProcAddress(handle, 'Py_Initialize');
Thanks that works.
I don’t think I’ve ever cast a left side value before in Pascal and honestly I
didn’t think it was even possible. In fact didn’t we just have a big talk about
for loop iterators and how they can’t be type cast? I thought that was because
casting the left side value was illegal. Very confused now. ;)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic loading to static?
> On Oct 26, 2019, at 12:55 PM, Sven Barth via fpc-pascal > wrote: > > tmpenum := y.GetEnumerator; > while tmpenum.MoveNext do begin > x := tmpenum.Current; > // ... > end; Ok, I understand how you guys are seeing this now. I wasn’t thinking of it as a while loop so casting just made sense to me from an efficiency standpoint. 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
> On Oct 6, 2019, at 5:40 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> Which test? Please post a sample.
>
> generic procedure DoThis(a:T; b:T);
> begin end;
>
> begin
> DoThis(1,200); // 1 sets T to shortint, so the 200 gives a warning
> end;
>
What is the preferred behavior? I’m getting an error in ObjFPC mode.
{$mode objfpc}
{$modeswitch implicitfunctionspecialization}
program timpfuncspez16;
generic procedure DoThis(param1: T; param2: T);
begin
end;
begin
DoThis(1, 200);
end.
>
>>> 3.
>>> timpfuncspez2.pp
>>> DoThis
>>> DoThis
>>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
>>> selects the one with only one param. IMO this is dangerous, it
>>> should give an error.
>
> generic function DoThis(a: T): T; overload;
> begin end;
> generic function DoThis(a: T): U; overload;
> begin end;
>
> begin
> DoThis(3); // both fits, should give an error
> end;
This is debatable I think but I understand why "Ambiguous call to DoThis” would
make sense. I’m pretty sure C# does this also.
What is the rule then? I’ll have to think about that some more.
>
>
>> [...]
>>> 4.
>>> Why does timpfuncspez6 fail?
>>> It works in Delphi.
>>> The comment has an explanation, which looks wrong to me:
>>>
>>> generic procedure DoThis(msg: T; param1: U; param2: TObject);
>>> begin
>>> end;
>>>
>>> begin
>>> DoThis('aa', 'aa', TObject.Create);
>>> // wil be specialized as DoThis(msg: integer; param1:
>>> TObject; param2: TObject)
>>> // so we expect an incompatible type error
>>> DoThis(1, 1, TObject.Create);
>>> end.
>>
>> That doesn’t make sense to me either so I need to study it. Both
>> should fail actually as I designed it (for now).
>
> Why?
I think my logic is different from what you expect though and I’m happy to
change it if we need to.
There’s the comment I left in the code for the “try_implicit_specialization”
function.
{ find generic procsyms by param count, starting from
number of parsed params. if a procsym is found then
validate via tcallcandidates and build list of *unique*
types for use when specializing.
inferred generic types are evaluated by inserting
non-repating types into the list in linear order.
(1,'string') =
(1,2,3,4,5,6) =
('a','b') =
('string',1) =
('a',1,'b',2,'c') =
}
I think for this example my logic does: T = integer, U = TObject because the
first 2 integers params are repeating so they both consume the single T and
then the TObject consumes the U. That means the second param “1” is being
passed for a TObject type.
generic procedure DoThis(msg: T; param1: U; param2: TObject);
DoThis(1, 1, TObject.Create); // DoThis(msg: integer; param1: TObject; param2:
TObject);
I used this logic because it works for repeating patterns but it’s not very
intuitive in cases where the arguments are the same number as the generic
parameters.
What should be the rule here?
>
>
>> How does Delphi implicitly specialize this?
>
> DoThis(1,1,nil); // T and U become shortint
> DoThis('aa','aa',nil); // T and U become string
So Delphi seems to match by index so param 1 = generic param 1. With repeating
patterns this breaks downs but maybe it’s a special case if the function
parameter count matches the generic parameter count?
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
Thanks for testing. I don’t have access to Delphi so I need help to make it
Delphi compatible.
> On Oct 6, 2019, at 2:06 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> 1.
> FPC allows default params, Delphi does not. Nice.
> I see no tests for this though, so maybe this was not on purpose?
Probably an oversight if you can believe it. I’ll test that.
>
> 2.
> DoThis(1,200) gives range check warning instead of error. A warning
> means there are some rare cases, where this code is correct. Is this a
> todo or do you see a useful case?
Which test? Please post a sample.
> 3.
> timpfuncspez2.pp
> DoThis
> DoThis
> Delphi gives an error "Ambiguous call to DoThis". FPC silently selects
> the one with only one param. IMO this is dangerous, it should give an
> error.
This sounds familiar from C# also. Is that the problem case? I feel like we
already went over this but it was months ago..
generic procedure DoThis(msg: T);
begin
writeln('DoThis$1#1:',msg);
end;
generic procedure DoThis(msg: T; param1: T);
begin
writeln('DoThis$1#2:',msg,' ',param1);
end;
>
> 4.
> Why does timpfuncspez6 fail?
> It works in Delphi.
> The comment has an explanation, which looks wrong to me:
>
> generic procedure DoThis(msg: T; param1: U; param2: TObject);
> begin
> end;
>
> begin
>DoThis('aa', 'aa', TObject.Create);
>// wil be specialized as DoThis(msg: integer; param1: TObject;
> param2: TObject)
>// so we expect an incompatible type error
>DoThis(1, 1, TObject.Create);
> end.
That doesn’t make sense to me either so I need to study it. Both should fail
actually as I designed it (for now).
How does Delphi implicitly specialize 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] generic proc inference
> On Oct 6, 2019, at 5:42 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> I meant:
>
> generic procedure DoThis(param1: T; param2: word = 100);
> begin
> end;
That works then. Added a test:
{$mode objfpc}
{$modeswitch implicitfunctionspecialization}
program timpfuncspez15;
generic procedure DoThis(param1: T; param2: integer = 100);
begin
writeln(param1, ' = ', param2);
end;
begin
DoThis('hello');
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 proc inference
> On Oct 6, 2019, at 5:03 PM, Ryan Joseph wrote: > >> On Oct 6, 2019, at 2:06 PM, Mattias Gaertner via fpc-pascal >> wrote: >> >> 1. >> FPC allows default params, Delphi does not. Nice. >> I see no tests for this though, so maybe this was not on purpose? > > Probably an oversight if you can believe it. I’ll test that. Yeah this didn’t work so I need to think about it. Should it even be allowed though? That means the type can only be specialized the same as the constant? generic procedure DoThis(param1: string; param2: T = 100); 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 proc inference
> On Oct 7, 2019, at 5:39 AM, Mattias Gaertner via fpc-pascal > wrote: > > I'm baffled. That's more basic algorithm than I expected. ;) All contributions are welcome. It sounds like we need make some changes or overhaul the entire thing. > > This means you don't support: > generic procedure Run(a: T; b:S); overload; That’s correct, this breaks the logic entirely. This to me looks like a sneaky way to trick the compiler and since it’s trying to infer something from the programmer it doesn’t make sense. If you have a better algorithm please post. > > And the following compiles, but fails on run, as T becomes an array > instead of the element type: > generic procedure Run(a: array of T); overload; > Good catch, that’s a bug. var a: array of integer; begin Run(a); 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
Right now this gives an error because you can’t add normal functions AFTER
generic functions with the same name in the same scope. I can’t find the bug
report but I think Sven fixed this recently or gave a better error at least.
generic function DoThis(a: T): T; overload;
begin
end;
generic function DoThis(a: T): U; overload;
begin
end;
// overloaded identifier "DoThis" isn't a function
function DoThis(a : integer): integer; overload;
begin
end;
That bug aside the rule is that non-generic overloads always win over generics.
I remember this was discussed at length if we can find the old thread.
{$mode objfpc}
{$modeswitch implicitfunctionspecialization}
program timpfuncspez14;
type
TMyClass = class
end;
procedure DoThis(msg: TObject);
begin
writeln('DoThis:',msg.ClassName);
end;
generic procedure DoThis(msg: T);
begin
writeln('DoThis:',msg.ClassName);
end;
begin
DoThis(TMyClass.Create);
DoThis(TObject.Create);
end.
prints:
DoThis:TMyClass
DoThis:TObject
> On Oct 7, 2019, at 8:37 AM, Michael Van Canneyt
> wrote:
>
> I think sven means if you have e.g. 3 functions:
>
> generic function DoThis(a: T): T; overload;
> begin end;
>
> generic function DoThis(a: T): U; overload;
> begin end;
>
> function DoThis(aInt : Integer) : Integer;
>
> 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 proc inference
> On Oct 7, 2019, at 1:54 AM, Sven Barth via fpc-pascal > wrote: > > There is nothing debatable here. If a generic parameter is not used in the > parameter list (cause it's used in the result type (either directly or to > specialize something else), only the body of the routine or even not at all), > then that routine must not be used for implicit specialization. > Yeah I got it now. I’ll make an ambiguous error message in this case. Right now the cases the will trigger it are: 1) generic functions that have the same name/parameter list, regardless of generic parameters. This is an “Ambiguous call to DoThis” error. generic function DoThis(a: T): T; generic procedure DoThis(a: T; b: integer = 100); generic function DoThis(a: T): U; generic procedure DoThis(a: T); var field: S; 2) Parameter not in function parameter list. Not sure yet but something like “DoThis can not infer specialization from parameter list”. generic function DoThis(a: integer): T; If there’s more let me 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] generic proc inference
> On Oct 7, 2019, at 12:42 PM, Mattias Gaertner via fpc-pascal > wrote: > >> I mean what happens here? The non-generic functions wins right? >> >> procedure Run(a:T; b: word); >> procedure Run(a: word; b: T); >> procedure Run(a: word; b: word); > > Only for > Run(word(1),word(2)); Ok, then I got this wrong and I need to make significant changes. As I did it if there is a non-generic it always wins regardless of parameters. For example: procedure Run(a: integer; b: string); begin end; generic procedure Run(a: S; b: T; c: integer); begin end; // fails because the non-generic Run() will always be picked and the parameter count will be wrong. Run(1,1,1); 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
> On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal > wrote: > > Note that in Delphi the "non-generic-wins" rule is per parameter: > > procedure Run(a:T; b: word); > procedure Run(a: word; b: T); I mean what happens here? The non-generic functions wins right? procedure Run(a:T; b: word); procedure Run(a: word; b: T); procedure Run(a: word; b: word); 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
> On Oct 9, 2019, at 6:21 PM, Sven Barth via fpc-pascal > wrote: > > Hmmm, I thought letting that dummy sym pass through would have lots of > adverse affects in various places. I’ll have to study this later in the > debugger. > > In that case the necessary parts would need to be made more resilient. > As a general matter could you explain the reasoning behind resolve_generic_dummysym()? 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
> On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal > wrote: > > I checked again. The thing is that in the compiler overload handling is done > inside htypechk.tcallcandidates. Your patch weakens/changes that. So you'll > have to completely rethink your solution to fit it into tcallcandidates (that > should for example collect all suitable generics in addition to the > non-generic ones (if any)). What is the entry point for this? My design was to intercept the dummy symbol and attempt to perform the specialization at that point and return a valid procsym so the parser could continue with its current code path. Are you saying I should allow the tcallcandidates.create to accept a dummy symbol instead of a procsym? Sorry if that doesn’t make sense but I’m a little foggy as to how this all works. Any advice would be great but I’ll think about this more later. Btw, the overloading stuff is in try_implicit_specialization but maybe that Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Catalina upgrade changes
Upgraded to Catalina 10.15 and had some breaking changes that I’d like to share: 1) /Developer directory has moved and can not be restored. Apple decided that the root directory / can only contain system directories and is not writeable by the user, period. The installer will move the affected files to /Users/Shared/XXX. I personally relied on this path in many places as it was a standard location for Mac developers. 2) /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk not longer exists so you need to change the SDK location to Xcode.app (see below), otherwise you’ll get the crt1.10.5.o linker error. The fpc.cfg file probably should be changed on your system and in future FPC releases. -XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk 3) Not FPC related but all 32-bit programs have been disabled so be careful about that. 4) Apps need to be notarized now. Here is my bash script which you can use https://github.com/neurolabusc/NotarizeFPC. This is for command line tools but can be modified for .app bundles by removing the info.plist part and zipping instead of making a disk image. Installing Xcode 11.1 and command line tools didn’t have any side effects at least. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Catalina upgrade changes
My apologies, I sent this to the wrong list (it’s macOS related). Please disregard. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Building complier fails in itolitlsreader.pas
Updated from svn just now (r43157) and tried to build but I get this error.
Pasted below is the source from itolitlsreader.pas and it appears it’s totally
mangled. Are other users seeing this also or did my SVN break something?
itolitlsreader.pas(385,24) Error: Identifier not found "Sta"
itolitlsreader.pas(385,48) Fatal: Syntax error, ";" expected but "identifier
UNKNOWN1" found
Fatal: Compilation aborted
while ChunkIndex <> -1 do
begin
Chunk.Position:=0;
fStream.Position:= Sta unknown1 : dword; //
always -1
nrblock: dword; // Number of blocks
treedepth : word; // The depth of the tree of
blocks (1 if no index blocks, 2 one level of index blocks, ...)
nrkeywords : dword; // number of keywords in the
file.
codepage : dword; // Windows code page identifier
(usually 1252 - Windows 3.1 US (ANSI))
lcid : dword; // LCID from the HHP file.
ischm : dword; // 0 if this a BTREE and is
part of a CHW file, 1 if it is a BTree and is part of a CHI or CHM file
unknown2 : dword; // Unknown. Almost always
10031. Also 66631 (accessib.chm, ieeula.chm, iesupp.chm, iexplore.chm,
msoe.chm, mstask.chm, ratings.chm, wab.chm).
unknown3 : dword; // unknown 0
unknown4 : dword; // unknown 0
unknown5 : dword; // unknown 0
end;
PBTreeBlockHeader = ^TBtreeBlockHeader;
TBtreeBlockHeader = packed record
Length : word; // Length of free space at
the end of the block.
NumberOfEntries: word; // Number of entries in the
block.
IndexOfPrevBlock : dword; // Index of the previous
block. -1 if this is the first listing block.
IndexOfNextBlock : dword; // Index of the next block.
-1 if this is the last listing block.
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 proc inference
> On Oct 9, 2019, at 1:51 AM, Sven Barth via fpc-pascal > wrote: > > Yes, exactly that. It could also be that the parser picks up a non generic > overload from another unit (due to the order of units in the uses section) > and then you can *only* handle that in tcallcandidates. > Hmmm, I thought letting that dummy sym pass through would have lots of adverse affects in various places. I’ll have to study this later in the debugger. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building complier fails in itolitlsreader.pas
> On Oct 9, 2019, at 3:50 PM, Christo Crause wrote: > > My guess is you have a corrupted file. According to the SVN info that file > was last changed in 2013. Viewing the file via the online viewer shows > nothing peculiar around line 385: > https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/chm/src/itolitlsreader.pas?view=markup#l385. > I have also updated via svn (r43158) and that came through good. It is > busy building but no problems so far. > Thanks. I’ll download the sources again. 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
> On Oct 6, 2019, at 12:18 PM, Mattias Gaertner via fpc-pascal > wrote: > > Ryan, is patch_3_25.diff the latest patch? > > I get a lot of merge conflicts. > What fpc revision is needed for this? > > And what is the git repo > https://github.com/genericptr/freepascal/tree/generic_implicit > ? > It does not contain the modeswitch. > > Mattias It’s the latest patch but that’s many months old already so nothing is up to date. I failed multiple times to update my branch from the “upstream" so I can't fix errors easily (there was a long thread some months ago but I gave up). Look at the changes page on Github and search for m_implicit_function_specialization. https://github.com/graemeg/freepascal/compare/master...genericptr:generic_implicit 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
> On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal > wrote: > > A patch for it by Ryan Joseph exists ( > https://bugs.freepascal.org/view.php?id=35261 ), but I've not yet found the > time to review it. > I’m eager to use this also but it’s been sitting there for about 6 months now, and I don’t remember well, but I think it had some questionable design that Sven wasn’t sure about. The patch for "generics in constants" has been reviewed well and being tested for some months already. Can that be integrated first so we can move forward to implicit function specialization? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-passrc errors
More tests with the parser but it seems like it doesn’t know quite a bit of
syntax. Are these not implemented yet?
1) class operators for records
EParserError: Expected "procedure" at token "operator" in file
/Users/ryanjoseph/Developer/Projects/FPC/GLCanvas/GLCanvas.pas at line 115
column 7
class operator TVertex3.= (constref a, b: TVertex3): boolean;
begin
result := (@a = @b);
end;
2) For..in loops
EParserError: Expected := or in at token "(" in file
/Users/ryanjoseph/Developer/Projects/FPC/NewEngine/Sources/Examples/EmptyWindow.pas
at line 138 column 14
for pointer(entity) in entities do
begin
entity.Update;
entity.Draw(renderer);
renderer.PushBox(entity.GetHitBox, TRGBA.RedColor);
end;
3) {$i settings} will not find the file “settings.inc”. This is valid in FPC
but the parser seems to have other rules.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc errors
On Oct 12, 2019, at 6:43 PM, Michael Van Canneyt wrote:1) class operators for recordsEParserError: Expected "procedure" at token "operator" in file /Users/ryanjoseph/Developer/Projects/FPC/GLCanvas/GLCanvas.pas at line 115 column 7class operator TVertex3.= (constref a, b: TVertex3): boolean;beginresult := (@a = @b);end;This can be.It’s a bug then? I found another advanced record bug below.2) For..in loopsEParserError: Expected := or in at token "(" in file /Users/ryanjoseph/Developer/Projects/FPC/NewEngine/Sources/Examples/EmptyWindow.pas at line 138 column 14For in loops should be supported, but I've never seen this before:for pointer(entity) in entities doWhat is for pointer(entity) in entities supposed to do ?It can be that this syntax is not supported (no surprise, since I don't havea clue what this is supposed to do).Just type casting because the array is an array of pointers. I get these errors otherwise "Incompatible types: got "Pointer" expected “TEntity"”. I could use a proper type in a generic array but I don’t always do that. I actually just posted to the list about this earlier. begin entity.Update; entity.Draw(renderer); renderer.PushBox(entity.GetHitBox, TRGBA.RedColor); end;3) {$i settings} will not find the file “settings.inc”. This is valid in FPC but the parser seems to have other rules.They should be the same.As said, pas2js uses fcl-passrc, and pas2js handles inifiles just as FPCdoes.Another bug then. Should I make a bug report for these?Here’s another one I found. No section headers in records?Expected "," or ":" at token "Identifier IDSize" in file /Users/ryanjoseph/Developer/Projects/FPC/NewEngine/Sources/Base/UImage.pas at line 94 column 4 TGAHeader = packed record private IDSize: uint8_t; // Size of ID info following header colorMapType: uint8_t; // Whether this is a paletted image imageType: uint8_t; // type of image 0=none, 1=indexed, 2=rgb, 3=grey, +8=rle packedRegards, Ryan Joseph___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc errors
> On Oct 13, 2019, at 5:58 AM, Sven Barth via fpc-pascal > wrote: > >> Delphi does not allow it: >> >> [dcc32 Error] Project1.dpr(18): E1019 For loop control variable must be >> simple local variable >> >> I don't think this should be allowed, either. > > Same. Why not? I just had this problem on 9/26, search for “for-in loop cast”. What if I have a list of TObjects I want to iterate? I know TMyClass is safe to use but the compiler complains so I override it with a typecast. If you take that away I’ll have to do tons of casting outside of the loop. var arr: specialize TFPGObjectList; obj: TMyClass; begin arr := specialize TFPGObjectList.Create; arr.Add(TObject.Create); // Incompatible types: got "TObject" expected "TMyClass" for obj in arr do 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] fcl-passrc errors
> On Oct 13, 2019, at 6:18 AM, Michael Van Canneyt
> wrote:
>
>>> Well spotted. I didn't notice that the extension was missing.
>>>
>>> That will definitely not be done in fcl-passrc.
>
> To be clear:
>
> here I meant that 'currently that will definitely not be done in fcl-passrc.'
This is a problem then because I wanted to make a language server for FPC but
if the parser doesn’t understand accepted FPC syntax the whole thing falls
apart. Can you make an FPC complient mode or something then? IMO if the parser
included with the compiler doesn’t understand the same syntax as the compiler
then we’re in trouble.
Here’s basically what I’m doing to parse. Nothing special and the engine is
just a template that does just the minimum (like the examples in the package).
module := ParseSource(engine, ’bugs.pas', 'darwin', 'x86_64');
- This is a new version from 3 days ago.
- The record sections failed because they are inside a function. If I pull the
record out of the function they work.
- Please test the operator because I don’t think the parser understands it.
{$mode objfpc}
{$modeswitch advancedrecords}
program bugs;
type
TMyRecordA = record
class operator = (constref a, b: TMyRecordA): boolean;
end;
class operator TMyRecordA.= (constref a, b: TMyRecordA): boolean;
begin
result := (@a = @b);
end;
procedure DoThis;
type
TMyRecordB = record
private
x, y, z: integer;
end;
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] fcl-passrc errors
> On Oct 13, 2019, at 12:30 PM, Michael Van Canneyt > wrote: > > Ahah... > > That needs to be tested then. This seems to be a bug. Can you please create > a bug with a compilable example ? > >> - Please test the operator because I don’t think the parser understands it. > > OK, that's strange, because I can see the code for handling operators, and > operators are definitely parsed, the RTL/FCL are riddled with operators... > > Then this needs to be tested and possibly fixed too. Please report this also > as a bug with a testcase, so I don't forget. > > I'll try to fix them ASAP. I’m out of time today but I’m make some examples later. Where do you want me to post them? Sorry I don’t get "sed s/bug/bugreport/“. heres’ the list: 1) allow omission of extension for $include macro 2) record class operators 3) record sections in records nested in routines Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-passrc method/function invocations
One of my tasks for the language server is determining “references” to a symbol, which means for functions I need to know all the times they were called. Given the syntax tree the parser creates how do I know when a function was called? I see there is a TPasImplSimple that seems related but I’m not sure exactly. It’s probably possible that it’s not always possible to know because there are unresolved types so: a := clss.DoThis; maybe be a function call or accessing a proeprty/member variable. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-passrc errors
> On Oct 13, 2019, at 11:11 AM, Sven Barth via fpc-pascal > wrote: > > Then specialize the list with the correct type. > > This issue *will* be fixed and is not up to discussion. > Here’s some code from the parser today. TFPList is being used because it’s a generic storage for various different kinds of classes. public Declarations: TFPList; // list of TPasElement // Declarations contains all the following: Attributes, // TPasAttributes Classes,// TPasClassType, TPasRecordType Consts, // TPasConst ExportSymbols,// TPasExportSymbol Functions, // TPasProcedure Properties, // TPasProperty ResStrings, // TPasResString Types, // TPasType, except TPasClassType, TPasRecordType Variables // TPasVariable, not descendants : TFPList; What do I do when I want to iterate over this now? I know that these types all descend from TPasElement so I want to use that, but no, the compiler complains I *must* use a pointer for the iterator. Why can’t I as the programmer tell the for loop I know what the enumerator is going to return? var element: TPasElement; begin // ERROR! for element in module.InterfaceSection.Functions do begin end; I guess we’re supposed to just do our typecasts inside the loop now but how is this any better? Sorry I’m really not getting this. var element: pointer; begin for element in module.InterfaceSection.Functions do begin writeln(TPasElement(element).Name, ‘’, TPasElement(element).DoSomething); 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] fcl-passrc errors
> On Oct 14, 2019, at 8:02 AM, Sven Barth via fpc-pascal > wrote: > > No. Nothing of that. There is a variable in the for-in-loop and nothing more. > Anything else currently is a bug and *will* break. > I don’t disagree with anything you’re saying but this is going to make for-in loops much harder to work with. Pascal isn’t like C++, C#, Python etc… where there are “auto” vars we can use for the iterator. Since I don’t want to typecast every single time I access the iterator I’m probably going to make a temporary iterator and then assign it to the real variable inside the loop. var it: pointer; obj: TObject; begin for it in list do begin obj := TObject(it); // continue on like before using “obj” instead of “it" end; That’s our realistic best use case now but it requires 2 extra steps. I hope there’s a better solution to keep the for-in loops as easy to use as before. 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
[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
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
[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] 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
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
[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] 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
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] 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
[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] 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] 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
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
[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
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
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
[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=xml=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] 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] 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] 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] 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
[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] 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] 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] 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
[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
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] 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
[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 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 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 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
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 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 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
[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] -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
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
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] 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
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] 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
[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
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
