> On Apr 25, 2020, at 2:02 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> I have FindCodeContext working correctly I believe because ProcName
>> from TCodeContextInfo returns the correct name of the function. In
>> TCodeContextInfoItem the params string list is nil though. Shouldn't
>>
I have FindCodeContext working correctly I believe because ProcName from
TCodeContextInfo returns the correct name of the function. In
TCodeContextInfoItem the params string list is nil though. Shouldn't that
contain the list of parameters? Not sure how this intended to be used if that
list of
In the FPC streaming system with published properties, what type do I use for
an array of strings? I've tried TStringList and TCollection but they give me
errors like:
:: <~~ pascal-language-server 1: {'message': ' : Unsupported JSON type for
object property: "jtArray"', 'code': -32603}
> On Apr 24, 2020, at 9:44 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> I assumed it was just a
>> reference to the current file which corresponds to the line/column
>> numbers.
>>
>> Sorry, what do you want to see a demo of? The language server?
>
> Yes.
The first message has the
> On Apr 24, 2020, at 9:28 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Still FindFile instead of LoadFile?
>
> Do you get all mails from this list?
I don't know what the code buffer technically is but FindFile works after the
source was set previously. I assumed it was just a
> On Apr 24, 2020, at 4:54 PM, Ryan Joseph wrote:
>
> I'm not able to get this one working then. Is the buffer the current file?
> This is what I'm doing:
>
>
>URI := ParseURI(textDocument.uri);
>Code := CodeToolBoss.FindFile(URI.Path + URI.Document);
>X := position.character;
>
> On Apr 24, 2020, at 5:28 PM, Joost van der Sluis wrote:
>
> I did not have a look at your code, but if you have serialization-issues, you
> might consider looking at Cerialization.
> (https://gitlab.freepascal.org/Joost/cerialization)
>
> It is what I use for my debugging-project. And it
> On Apr 24, 2020, at 4:49 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> When I hover over a function in Lazarus I get a function definition
>> and unit location. Is that coming from TCodeManager.FindSmartHint?
>
> Yes
I'm not able to get this one working then. Is the buffer the current
> On Apr 24, 2020, at 4:35 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> codetools that scans Lazarus packages.
>
> In Short: You can omit LAZARUSDIR.
>
> Setting PP might be useful.
>
> You can add unit and include paths:
>
When I hover over a function in Lazarus I get a function definition and unit
location. Is that coming from TCodeManager.FindSmartHint?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> On Apr 24, 2020, at 4:25 PM, Arjan Adriaanse wrote:
>
> Indeed with the current way JSON streaming is handled, optional values
> are not considered. This needs more work and the issue is tracked
> here https://github.com/arjanadriaanse/pascal-language-server/issues/7
> [1].
We may need to
> On Apr 24, 2020, at 3:59 PM, Arjan Adriaanse wrote:
>
> FPCDIR="/usr/lib/fpc/3.2.0/source"
> LAZARUSDIR="/usr/share/lazarus"
I see now! I didn't know that but it's easy to document once we get that far.
btw, I'm having a problem with the fact that published un-set properties are
being set
> On Apr 24, 2020, at 3:32 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Are there any ppu files left after "make distclean"?
I just trashed the entire thing and started over. It was easier that way, much
easier. It's working now so I'm happy. :)
I'm still getting that code tools error
> On Apr 24, 2020, at 2:54 PM, Michael Van Canneyt
> wrote:
>
> What do you want to omit exactly ?
For example, I'm not a lazarus user but I'm getting strange errors that don't
relate to my single file program. That's going to confuse users like it did me.
I'd like to omit the need to
> On Apr 24, 2020, at 2:37 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> fpextres.ppu is installed by default on darwin.
> Maybe you didn't setup codetools for your fpc units. Because of the
> vast amount of fpc units, codetools needs to scan them once. There is a
> simple init function,
> On Apr 24, 2020, at 1:47 PM, Ryan Joseph wrote:
>
>end else begin
> if CodeToolBoss.ErrorMessage<>'' then
>writeln(stderr, 'Parse error: ',CodeToolBoss.ErrorMessage)
> else
>writeln(stderr, 'Error: no context');
>end;
In my test I'm getting an error at this
> On Apr 24, 2020, at 12:46 PM, Michael Van Canneyt
> wrote:
>
> I fixed TCustomJSONRPCDispatcher not to add a Null in case of V2. But V1
> needs it.
> see https://www.jsonrpc.org/specification_v1
>
> Committed in revision 45047.
Nice, it was a bug. :)
So the Sublime Text people explained
> On Apr 24, 2020, at 10:23 AM, Ryan Joseph wrote:
>
> Just tested on my language server and the problem is you provided a null
> error key, which is not in the protocol.
>
> I've never seen the fpjsonrpc unit before so I don't know where this got
> inserted but it needs to be removed.
I
> On Apr 24, 2020, at 9:52 AM, Ryan Joseph wrote:
>
> LSP: invalid response payload {'id': 1, 'result': {'capabilities':
> {'completionProvider': {'triggerCharacters': None, 'allCommitCharacters':
> None, 'resolveProvider': False}, 'textDocumentSync': {'openClose': True,
> 'change': 1}}},
OK, I just downloaded the laz sources and rebuilt from scratch (as usual) and
it's building with the 3.3.1 now.
I'm testing the server in Sublime Text and first thing I get is:
LSP: invalid response payload {'id': 1, 'result': {'capabilities':
{'completionProvider': {'triggerCharacters':
> On Apr 23, 2020, at 10:07 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Please post the last couple of lines, e.g. starting at the last
> ppcx64 call.
>
/bin/cp -f Makefile.compiled units/x86_64-darwin/nogui/IDEIntf.compiled
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C
> On Apr 23, 2020, at 9:51 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> You have old ppu files.
>
> For example:
> make distclean all
ok, did this and now getting:
/Users/ryanjoseph/Developer/lazarus/components/lazdebuggergdbmi/gdbmidebugger.pp(63,16)
Fatal: (10022) Can't find unit
I just tried update my lazarus sources using "svn up" and now I'm getting
another strange error when using lazbuild.
/Users/ryanjoseph/Developer/lazarus/components/ideintf/ideintf.pas:11:3: fatal:
Can't find unit LazarusPackageIntf used by IDEIntf
Do I need to do something else to get the
> On Apr 23, 2020, at 9:11 PM, Arjan Adriaanse wrote:
>
> lazbuild --compiler=/usr/lib/fpc/3.2.0/ppcx64 pasls.lpi
is there a macOS installer for 3.2? I found a link to a FTP server but I don't
see this exists. Maybe fix that bug in trunk is the better idea. My lazarus
sources are old also
> On Apr 23, 2020, at 9:11 PM, Arjan Adriaanse wrote:
>
> The CodeToolBoss actually keeps a cache of files which are loaded at
> the 'textDocument/didOpen' notification. When the user changes text at
> the client side, even without saving, a 'textDocument/didChange'
> notification is sent
> On Apr 23, 2020, at 9:11 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> If LSP updates parser_test.pas, then codetools will notice.
>
> If LSP only sends changes, then you have to apply these changes to
> codetools codebuffers:
> Code.Insert/Delete/Replace/Move
>
> Modified codebuffers
> On Apr 23, 2020, at 8:20 PM, Arjan Adriaanse wrote:
>
> Perhaps not all the used generics features are available yet in older
> FPC versions. I use the most recent release candidate from
> ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/ [2], but will
> investigate if older versions also
> On Apr 23, 2020, at 6:29 PM, Arjan Adriaanse wrote:
>
> Also, any feedback on my existing code is welcome, especially since
> this is my first Pascal project.
You did a nice job structuring it I think and providing a template to scale up
from. What language(s) are you coming from and why
> On Apr 23, 2020, at 3:49 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>>
>> 3) Class/record member completions.
>
> I guess you mean identifier completion after a dot.
Exactly. Fields or methods and helpers even if possible. I assume that exists.
Btw, the names you're giving like
> On Apr 23, 2020, at 3:00 PM, Michael Van Canneyt
> wrote:
>
> I think the decision to use the codetoolboss is the best, see above as to why.
Very well. I assume the code tools parses the entire project and keeps the
symbols in a database? That was something I was going to have to
Arjan, I briefly skimmed over your code and it looks like instead of using the
"DocParser" unit that I was using the parse the files, you're directly using
the Lazarus "CodeToolBoss" which I don't have any experience with.
I think it was Michael actually who instructed me to use this parser but
> On Apr 23, 2020, at 2:08 PM, Michael Van Canneyt
> wrote:
>
> VSCode has omnipascal ?
> (The TMS Web core VS Code studio plugin uses this, and it seems pretty
> complete)
yes it does but they don't support ObjFPC mode syntax very well which means
things like the "generic" keyword and "is
yes! Pascal *badly* needs this to be productive outside of Lazarus. I use
Sublime Text and frequently now VSCode but not having good code tools is
getting painful.
In fact I already started a language server some months ago (and since been
busy with out stuff) but I think you've made more
I just came across another related issue to this thread. Is it not possible to
init dynamic arrays from static arrays? I remember there being more
compatibility between the 2 types but I may have forgotten.
var
a: array[0..1] of integer;
d: array of integer;
begin
d := a;
end.
Regards,
> On Apr 12, 2020, at 11:16 AM, Ryan Joseph wrote:
>
> I just did svn up and got r44689, rebuilt the compiler but I still get the
> same error format. Was it supposed to be changed?
ok, I think we're confused here. Just actually tested gcc and got this format:
> On Apr 11, 2020, at 9:50 PM, Ryan Joseph wrote:
>
> Thanks, I could swear this was a bug that was already fixed but I'll rebuild
> the compiler tomorrow and see if it went away.
I just did svn up and got r44689, rebuilt the compiler but I still get the same
error format. Was it supposed
> 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.
> On Apr 11, 2020, at 1:17 PM, Michael Van Canneyt
> wrote:
>
> My guess is you have a config file lying around that causes this to look
> different (-Fr option?), or you have a custom-made errore.msg file built-in.
Interesting, so I overrode the default format in the trunk somehow. I can't
Sorry to ask this yet again but I keep forgetting or remembering wrong. I
thought this was a one time error that was fixed but I'm still getting
different error formats with the trunk (as of today) vs 3.0.4.
Can anyone please confirm which it the correct format I should rely on?
> On Apr 3, 2020, at 10:09 PM, Sven Barth wrote:
>
> No. The "[...]" for an open array parameter means "open array constructer"
> *not* "dynamic array constructor". And this on-the-fly open array is in fact
> constructed on the stack.
Ok, I see now. Excellent. I thought this was another
> On Apr 3, 2020, at 3:43 PM, Sven Barth wrote:
>
> They are neither. They are simply a pointer to the first element and a hidden
> size argument. For the pointer it is not important where it comes from: a
> single element, a dynamic array, a static array.
>
Ah, I see. In the example
> On Mar 16, 2020, at 5:40 AM, Sven Barth wrote:
>
> The message of the compiler is a bit misleading. It's a *dynamic* array that
> is created there, not an *open* array. Open arrays only exist when being
> passed directly to a parameter.
I forgot to ask. Are open arrays constants, or are
I hope you're all having a lovely Coronavirus lockdown-vacation and keeping
safe. :)
I finally got around to the overhaul of {$modeswitch
implicitfunctionspecialization} as according to feedback in this thread. I
attached a patch in the bug tracker which should apply without conflicts. In
> On Mar 24, 2020, at 8:39 PM, Michal Wallace via fpc-pascal
> wrote:
>
> Hi Ryan,
>
> It's possible. Just change your declaration of `c`:
>
> var c: TBase;
>
> It still prints TMyClass at the end.
>
> Of course, you're only going to have access to methods that are declared in
> TBase.
>
Free Pascal - General mailing list wrote
> Is it possible to achieve this dynamically without resorting to type
> casting? It feels like classes should have a builtin type for each class,
> like TClassType, which similar to TObject.ClassType but is a compile time
> type.
I didn't think enough
Is it possible to achieve this dynamically without resorting to type casting?
It feels like classes should have a builtin type for each class, like
TClassType, which similar to TObject.ClassType but is a compile time type.
=
{$mode objfpc}
program test;
type
TBase = class
//
> On Mar 21, 2020, at 10:15 PM, Sven Barth via fpc-pascal
> wrote:
>
> For the primitve types you need to know the sizes at compile time (e.g.
> SizeOf(Word), SizeOf(LongInt), etc.) and check what type the field has using
> the field list in the record's RTTI. You also have to keep in mind
> On Mar 21, 2020, at 10:05 AM, Anthony Walter via fpc-pascal
> wrote:
>
> I think what Ryan is asking about is how to find the size of the variant part
> of TTypeData as used in the "case TTypeKind of" section. As in:
Yes. It says a field is "tkInteger" but what size is that? I know it's 4
> On Mar 21, 2020, at 9:39 AM, Ryan Joseph via fpc-pascal
> wrote:
>
> I'm going to loop through the fields of the record and get the size of each
> field so I can serialize the record. Am I not on the right track?
No answers on this so I'm thinking maybe I need to us
I'm going to loop through the fields of the record and get the size of each
field so I can serialize the record. Am I not on the right track?
-
Regards,
Ryan Joseph
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
Are there any functions in the RTL to get the sizeof the type specified in
TTypeKind? https://www.freepascal.org/docs-html/rtl/typinfo/ttypekind.html
I'm truing to use record RTTI and I needed to know the size of the field in the
record.
Regards,
Ryan Joseph
> On Mar 18, 2020, at 1:31 AM, Kevin Monceaux wrote:
>
>> It's 2020 and the mail list is starting to really show its age.
>
> With age comes wisdom.
No need to discuss this further, everyone loves the mail list. I'll try using
the forums instead.
Regards,
Ryan Joseph
Ok, that makes sense now. Dynamic arrays can't be passed to static arrays. I
remember when I tried to make aligned dynamic arrays I got to look around in
the code and it seems plausible you could just make a memcpy call in the RTL
for dynamic arrays being passed to static arrays. Seems deceptively
> On Mar 16, 2020, at 12:36 AM, fredvs via fpc-pascal
> wrote:
>
> Hello.
>
> You may use http://free-pascal-general.1045716.n5.nabble.com/
>
> This forum is an archive for the mailing list
> fpc-pascal@lists.freepascal.org
>
> Fre;D
Looks like everyone here likes the mailing list. Very
> On Mar 15, 2020, at 8:53 PM, Howard Page-Clark via fpc-pascal
> wrote:
>
>
> With recent FPCs you can however do this:
>
> program test;
> var
> data: array[0..2] of Integer;
> tmp: array of Integer = Nil;
> begin
> tmp := [1,2,3];
> Move(tmp[0], data[0], SizeOf(data));
> end.
It's 2020 and the mail list is starting to really show its age. I don't get
first messages from gmail and my personal web host is whitelisted, messages
bounce when I use the wrong account by accident, hard to search the archives,
can't post images and code easily (big problem!), messages gets
Why doesn't it compile to pass an open array to a static array of the same
size? That would nice if this worked since it makes assigning values so easy.
program test;
var
data: array[0..2] of integer;
begin
// Incompatible types: got "{Array Of Const/Constant Open} Array of ShortInt"
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
> 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
> 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
>
> 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
> 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
>
>
> 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
> 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 i
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
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
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
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
//
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
> 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
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;
> 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
> 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
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
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 -
> 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
> 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
> 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
> 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
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
___
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
> 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
>
> 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
>
> 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
> 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
> 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
> 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
> 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:
>
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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:
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
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:
> 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
> 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
301 - 400 of 421 matches
Mail list logo
