Is there any YAML parser that exists for FPC? Couldn't seem to find one despite
YAML being a pretty popular format.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/li
I'm trying to get the pascal language server working on Visual Studio Code and
during testing I found that sending null values to the server is causing
problems. i.e.:
...
"processId": 3997,
"clientInfo": {
"name": "vscode",
"version": "1.47.3"
},
"rootPath": null
> On Aug 7, 2020, at 7:58 PM, Michael Van Canneyt
> wrote:
>
> By itself, fpJSON of course allows null values.
>
> What are you using as a serialization technologgy ?
I didn't write the serialization layer and this is my first time using the FPCs
RTTI system for this purpose. Having said th
> On Aug 7, 2020, at 8:31 PM, Michael Van Canneyt
> wrote:
>
> An option to allow nulls to be detected and handles would of course be a nice
> addition.
>
> For the time being, you can just set jdoIgnorePropertyErrors on the
> destreamer options.
Quick check right now and setting that optio
> On Aug 7, 2020, at 9:09 PM, Michael Van Canneyt
> wrote:
>
> try
>B:=Not Assigned(FOnRestoreProp);
I just rebuilt the compiler (couldn't figure out how to recompile just the
fpc-json package) and got the new changes but there seems to be a regression
and I'm not getting anything deser
> On Aug 8, 2020, at 7:37 PM, Michael Van Canneyt
> wrote:
>
> Confirm there was an error. Fixed, and added testcase.
>
> I also added jdoNullClearsProperty; a null will then clear the property with
> the 'natural' empty value. It has precedence over jdoIgnoreNulls.
Thanks again, I couldn't
> On Aug 8, 2020, at 8:24 PM, Michael Van Canneyt
> wrote:
>
> make clean make install PREFIX=/some/dir/on/your/system
what is the PREFIX part?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.
> On Aug 8, 2020, at 8:37 PM, Michael Van Canneyt
> wrote:
>
> I don't know, that depends on your system. It is the path where FPC is
> installed.
It's the compiler path? This is the same errors I got before which made me
rebuild the compiler (macOS btw)
packages$ sudo make clean make inst
I finally figured out how to get the Visual Studio Code extension working for
the language server. Does anyone want to test? I added some very brief
instructions but basically you need to:
1) build the language server (using latest trunk FPC and RTL). I want to
provide precompiled binaries even
Does anyone have any idea how this happened? I installed 3.2.0 from an
installer so why is the PPU version wrong?
PPU Loading /usr/local/lib/fpc/3.2.0/units/x86_64-darwin/fcl-process/process.ppu
PPU Invalid Version 208
Regards,
Ryan Joseph
___
> On Aug 12, 2020, at 4:07 PM, Sven Barth wrote:
>
> Does the compiler report the correct version? Namely 3.2.0? What if you
> compile a simple program with no used units with -vu and check what the
> compiler prints for the PPU version of the System unit?
>
You mean like that? That empty
> On Aug 12, 2020, at 5:39 PM, Tomas Hajny wrote:
>
> Yes. Please, provide the same output if you add "uses process;" to empty.pas.
> Also, please provide output of "ls -l
> /usr/local/lib/fpc/3.2.0/units/x86_64-darwin/fcl-process/process.ppu".
Here's that. Is it possible I overwrote the fil
Are semaphores actually supported in the RTL? I don't see they're available on
macOS (compiling with trunk even).
https://www.freepascal.org/docs-html/3.0.0/rtl/system/semaphoreinit.html
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pas
> On Aug 13, 2020, at 12:42 PM, Sven Barth wrote:
>
> The way to go with semaphores would be to implement the Delphi compatible
> TSemaphore in the unit SyncObjs.
Link? I'm looking at
https://www.freepascal.org/docs-html/fcl/syncobjs/index-4.html and I don't see
it.
Regards,
Ryan J
> On Aug 26, 2020, at 5:44 PM, Nico Neumann via fpc-pascal
> wrote:
>
> generic procedure Add;
> begin
> if GetTypeKind(T) = tkInteger then WriteLn('an integer');
> if GetTypeKind(T) = tkString then WriteLn('a string');
> end;
Question for the compiler team why doesn't the "is" operat
> On Aug 27, 2020, at 3:49 AM, Sven Barth wrote:
>
>> if T is integer then
>> ;
>>
>> and get something which is well optimized.
> Because there was simply no need for this.
Since the introduction of generics this would be a nice extension to add for
the is operator.
Regards,
Ryan
I've never used fpcmake before and instead relied on my own custom build system
solutions which are a pain to maintain and non-standard which it makes extra
work configuring the pascal language server I'm using now.
My first question of fpcmake is, can I package application bundles and copy
res
se it all the time for
> building production versions of lazarus programs and prior to packaging the
> programs and resources in .deb and .rpm files.
>
> On 01/09/2020 13:37, Ryan Joseph via fpc-pascal wrote:
>
Apparently there is fpmake and fpcmake, which I didn't know.
> On Sep 1, 2020, at 9:04 PM, Tony Whyman via fpc-pascal
> wrote:
>
> My primary motivation for going with fpcmake is that it is a very good fit
> with the debian package management system (and rpmbuild). My normal build
> target is Ubuntu and hence I want to generate .deb files in order to
> On Sep 7, 2020, at 6:07 AM, James Richters via fpc-pascal
> wrote:
>
> Does anyone have an example of how to use TFPObjectlist?
It just frees objects that are removed from the list (or when the list is
freed).
list:= TFPObjectlist.Create;
list.Add(TObject.Create);
list.Free;
in that ex
> On Sep 8, 2020, at 6:10 PM, James Richters via fpc-pascal
> wrote:
>
> I'm trying to figure out how TList works. I found the code example below by
> doing a search, but I can't compile it, I get Error: Illegal qualifier on
> the line
Do you want an array of pointers (objects allocated
> On Sep 21, 2020, at 2:16 PM, LacaK via fpc-pascal
> wrote:
>
> when I use in *uses* clause:
I never knew "in" even existed! This totally blows my mind. Was it something
added from Delphi that I never heard about?
Regards,
Ryan Joseph
__
I expected to get an assertion when I added the duplicate key "foo". What am I
doing wrong?
type
TSomeMap = specialize TFPGMapObject;
var
map: TSomeMap;
begin
map := TSomeMap.Create(true);
map.Duplicates := dupError;
map.Add('foo', TObject.Create);
map.Add('foo', TObject.Create);
Reg
> On Oct 1, 2020, at 7:00 PM, Vojtěch Čihák via fpc-pascal
> wrote:
>
> I looked to code, it gives error only when map is Sorted=True.
>
Thanks. Sneaky that sorted had to be set to true. Not sure why that would be.
Regards,
Ryan Joseph
__
Something that's bothered me for a while I wanted to ask about.
I have a package I want to distribute which has 2 or more units, all of which
are required to use the package. Technically all the code should be in one file
but because units are a nice feature of Pascal we like to keep our code
s
I have some dates formats like this which I would like to convert to TDateTime.
Are these supported in the RTL? I tried using the StrToDate functions but I got
errors.
program test;
uses
SysUtils;
begin
StrToDate('2001-12-14T21:59:43.10Z-05:00');
end.
Regards,
Ryan Joseph
_
> On Oct 3, 2020, at 10:37 AM, Michael Van Canneyt
> wrote:
>
> Do you ever read the documentation ?
>
> You might then have read why the above will never work.
>
> You probably need this:
>
> https://www.freepascal.org/docs-html/current/rtl/dateutils/iso8601todate.html
>
> or even this
>
> On Oct 3, 2020, at 2:15 PM, Winfried Bartnick via fpc-pascal
> wrote:
>
> Hi!
>
>
> Timezones are handled by the package PascalTZ.
>
> It is available through the Online Package Manager.
>
> Winni
Thanks. I think the format I had was ISO8601 but had decimal precision for the
seconds. A
I was going to do a YAML parser but I decided on TOML instead because:
1) appeared easier to parse
2) the format is simpler to understand/less bloated
3) looks nicer for config files (that's what it was designed for actually)
It's not as widely supported as YAML (which was been around since 2001)
I often need to use a function which reads a file into a string, as is so
common in so many scripting languages. Can it be considered to add something
like this to the RTL? Since we have a refcounted Ansistring type it's natural
for this to be a one-liner. Not saying we should use TStringList bu
> On Oct 5, 2020, at 3:23 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> So I think you're looking at 6 or even 8 versions of this hypothetical
> function...
Ouch. :)
I'm sure this code already exists in the RTL though, right? I assume it's part
of some classes like TStringList and we
> On Oct 5, 2020, at 5:08 PM, Jean SUZINEAU via fpc-pascal
> wrote:
>
> In my own code I use BlockRead/BlockWrite, but I'm wondering if I've not seen
> this somewhere in RTL.
>
>
This looks good to me what about the concerns raised by Michael? I don't know
enough about text formats but us
> On Oct 6, 2020, at 2:12 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I added the following functions to the sysutils unit (rev 47056):
Great, thanks Michael.
I've always used AnsiString so why is UnicodeString preferable here?
So is the idea we need to specify an UTF-8 encoding for
> On Oct 6, 2020, at 2:52 PM, Zamrony P. Juhara via fpc-pascal
> wrote:
>
> I use a secondary unit as alias of all separate units as Marco suggests in
>
> https://github.com/fanoframework/fano/blob/master/src/fano.pas
>
> However I am curious if merging units like this has drawback. AFAIK sm
Since we're on the topic how about another one-liner for reading all the files
in directory into a dynamic array? This has the added benefit of getting
enumeration for free. This is standard stuff for working with files in
scripting languages so I think the FPC RTL should include something like
> On Oct 6, 2020, at 1:42 AM, Jer Haan via fpc-pascal
> wrote:
>
> I use this function to read a file into a string:
Not sure how Michael implemented it but we have this in the RTL now, so we can
throw away our ReadFile functions. I have many of those littered around in
various projects so
> On Oct 7, 2020, at 2:19 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I see Delphi has something similar, so I will add an implementation. But I
> need to study the options they provide so we can make a reasonably
> compatible version :)
Excellent thanks. It looks like Lazarus has Fi
Here's another interesting option I considered. You can call Scandir which
returns a record with an enumerator. You can then use this to drop right into
the for loop. It doesn't allocate memory and you can break the loop to stop the
iteration. The benefit is you can avoid costly memory allocatio
I'm trying "uses in" which I never knew existed before.
The idea is that I provide a path to TOML.pas using -Fu then use the "in"
syntax to reference the units which are in a subdirectory. This makes it safe
from the project importing the unit so any private units in the subdirectory
don't over
> On Oct 7, 2020, at 11:02 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Only in FPC:
>
> {$unitpath sources}
> interface
> uses
> TOMLParser, TOMLTypes;
Some interesting stuff here, thanks. Almost there but for some reason
Scanner.pas is not found even though it's in the same directory
> On Oct 7, 2020, at 11:15 AM, Ryan Joseph wrote:
>
> Some interesting stuff here, thanks. Almost there but for some reason
> Scanner.pas is not found even though it's in the same directory as
> TOMLParser.pas. The compiler did find TOMLParser despite /sources not being
> explicitly included
> On Oct 8, 2020, at 5:14 AM, gabor via fpc-pascal
> wrote:
>
> You can define typed constant and assign it to variable.
>
> type
> TMyRecord = record
>X, Y: Integer;
>S: String;
> end;
>
> const
> MYDEFREC: TMyRecord = (X: 1; Y: 2; S: 'ABC');
I never understood why we can't init
> On Oct 6, 2020, at 2:12 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> // Read raw content as bytes
>
> Function GetFileContents(Const aFileName : RawByteString) : TBytes;
> Function GetFileContents(Const aFileName : UnicodeString) : TBytes;
> Function GetFileContents(Const aHandle : T
> On Oct 8, 2020, at 3:01 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Should be easy enough.
Great, glad this is happening. Let me know if you want some help with these
additions or if it's best for you to just blast through it on you own. Seems
like you know what's best for the RTL
> On Oct 8, 2020, at 4:58 AM, Bo Berglund via fpc-pascal
> wrote:
>
> OK,
> is it possible to define the TMyRecord with default values so that
> when I do Default(TMyRecord) it will be non-zero defaults written
> instead of zeros?
You need to make a method for tha. You can't even use construc
> On Oct 9, 2020, at 7:02 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> Writing a file should write the data in a temporary file and then rename the
> temporary file to replace the target file. Otherwise it might destroy the
> target file, without writing the new content, when there
Is this a bug in generics with default()?
=
type
TEnum = (Unused = '.');
generic TSomething = class
function Get: T;
end;
TEnumeratedSomething = specialize TSomething;
function TSomething.Get: T;
begin
// Range check error while evaluating constants (0 must be
> On Oct 21, 2020, at 2:08 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> See https://bugs.freepascal.org/view.php?id=34972 for some comments
> about Default. So this is a bug in the usage of Default, since Default
> cannot be guaranteed to return a valid value for a type.
I thought default woul
> On Oct 21, 2020, at 2:43 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> I tried to explain in the rest of my message why that cannot be done. It
> might be possible in some cases, but that would just create a false
> sense of security and unpredictable results (because no compile-time
> range c
Is it possible that the TypeInfo intrinsic could work with generic template
types or is this a bug? I get "Illegal qualifier" in the procedure below.
generic procedure DoThis(a: array of T);
begin
writeln(TypeInfo(T)^.name);
end;
Regards,
Ryan Joseph
_
> On Oct 29, 2020, at 12:27 PM, Ryan Joseph wrote:
>
> Is it possible that the TypeInfo intrinsic could work with generic template
> types or is this a bug? I get "Illegal qualifier" in the procedure below.
>
> generic procedure DoThis(a: array of T);
> begin
> writeln(TypeInfo(T)^.name);
>
> On Nov 1, 2020, at 8:45 AM, Zoë Peterson via fpc-pascal
> wrote:
>
> I'd like to have a generic objcclass that would add some extra functionality
> for multiple base types. I don't have a lot of experience with generics, but
> this compiles:
>
Waiting for Jonas to reply but I'm pretty c
> On Nov 2, 2020, at 1:30 PM, Zoë Peterson via fpc-pascal
> wrote:
>
> I have an NSView subclass with a bunch of fields and methods, and I wanted to
> be able to optionally swap that out with a parallel version derived from
> NSVisualEffectView without duplicating all of the code. I was hop
> On Nov 21, 2020, at 6:15 AM, Florian Klämpfl via fpc-pascal
> wrote:
>
> Large parts of FPC are memory throughput limited so I suspect the M1 is not
> that much better in this regard, not to mention that most likely the AAarch
> code generator is worse than the x86 one. x86 received a lot
> On Nov 21, 2020, at 9:18 AM, Jonas Maebe via fpc-pascal
> wrote:
>
> As to how to do build a compiler on macOS that uses the LLVM backend,
> that's the same as on Linux, except that you don't need special command
> line options to find libgcc: https://wiki.freepascal.org/LLVM
It sounds like
> On Nov 21, 2020, at 9:23 AM, Florian Klämpfl via fpc-pascal
> wrote:
>
> All. FPC typically uses several ten MBs and accesses it rather randomly.
Wow 10-100 MB is enough to limit speed due to memory access times? I understand
there is some limit to how much memory can be accessed per X per
> On Nov 21, 2020, at 9:33 AM, Florian Klämpfl via fpc-pascal
> wrote:
>
> L1 cache is typically only a few ten kB, L2 several hundred kB, L3 several MB.
Oh I see what you mean. Yeah cache miss is a problem that would be not feasible
to fix in the compiler for the most part.
I guess this me
> On Nov 22, 2020, at 4:08 AM, Florian Klämpfl via fpc-pascal
> wrote:
>
>> Well... If the compiler can make such a difference,
>
> This are the big low hanging fruits, their are only a few :) In particular
> the compiler benefits a lot from this as it iterates linked lists a lot.
Just curi
Just for fun I wanted to see what people thought about a potential "pair" type
added to the compiler. Dictionaries have proven themselves to be a fundamental
type we use often and they are appearing as built-in syntax in many languages,
especially scripting languages that allow dynamic object co
> On Dec 16, 2020, at 10:50 AM, Sven Barth wrote:
>
> This can simply be done using existing language constructs, no need to
> introduce anything new.
>
That's what I thought you'd say. ;) It's basically syntactic sugar surrounding
a generic record, so yes technically it is. It's just somet
We had talked about this some time ago and it's been rattling around in my
brain so I wanted to write it down into a formal proposal where we can discuss
it and hopefully agree upon a syntax. Everything is preliminary and tentative
but this is a syntax which allows a "composition over inheritanc
> On Feb 10, 2021, at 12:32 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Instead of trait you might as well use simply "object", so basically we
> could simply state that instead of an interface, you can also specify an
> object
> in the class definition:
>
>
> TMyClass = class (TPar
> On Feb 10, 2021, at 8:41 AM, Michael Van Canneyt
> wrote:
>
> I heavily object to this; We have way too much keywords as it is already. So
> unless there really is no other way I don't think we should introduce
> even more.
I guess the first question is whether a "trait" is a new construct
> On Feb 10, 2021, at 9:06 AM, Michael Van Canneyt
> wrote:
>
> You said it yourself: internally it will just be an object. Just make it
> formally so.
>
> I also think the argument of reusing existing objects deserves consideration.
Is it strange that there are extra things in the object w
> On Feb 10, 2021, at 10:17 AM, Martin Frb via fpc-pascal
> wrote:
>
> The example exposes another aspect:
>
>> trait SayWorld {
>> public function sayHello() {
>> parent::sayHello();
>
> In this case the trait has access to the object/class into which it is
> embedded. (otherwi
> On Feb 10, 2021, at 11:09 AM, Ryan Joseph wrote:
>
> type
> TSomeTrait = trait
> public
> parent: TObject;
> procedure DoThis;
> end;
>
> procedure TSomeTrait .DoThis;
> begin
>// ??? here is our issue. Is this good enough to call the
> TBaseClass.DoThis?
>TBaseClass(pare
> On Feb 10, 2021, at 12:17 PM, Ryan Joseph wrote:
>
> Thinking about this more I don't think there's even a reason for it since
> Object Pascal doesn't let you do stuff like this anyways. If you want to call
> the super class you need to use "inherited" from within the class body. The
> ex
> On Feb 10, 2021, at 12:40 PM, Martin Frb via fpc-pascal
> wrote:
>
> type
> TSomeTrait = trait
> public
> procedure DoTraitFoo;
> end;
>
> TSomeClass = class(TObject)
> private
> trait: TSomeTrait; // whatever syntax is used so that the trait is added
> public
>
> On Feb 10, 2021, at 1:51 PM, Martin Frb via fpc-pascal
> wrote:
>
> I don't have a pro/contra agenda on whether that feature should be part of
> the fpc trait or not.
> I just saw it, and thought I raise it.
>
These issues you are raising are more related to general type
safety/compatibi
> On Feb 10, 2021, at 2:42 PM, Ryan Joseph wrote:
>
> We should keep it as simple as possible imo.
It's not as elegant as other ideas we may think of but I think it's good enough
to let users write boilerplate methods to resolve naming conflicts. We don't
need to introduce new syntax or con
> On Feb 10, 2021, at 10:17 AM, Martin Frb via fpc-pascal
> wrote:
>
> - One might have to think about how to declare what a trait can access?
>Just allow anything in the code, and attempt to resolve when the trait is
> embedded? IMHO maybe not?
Sorry Martin you said a lot and I missed
> On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal
> wrote:
>
> In that case IIRC, it was said traits are not allowed constructors. Why?
Traits are meant to be a way to import fields/methods and is based off of
"object" (so it's on the stack). This is also important for using propertie
> On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal
> wrote:
>
> I understand it is for conflict resolution only. But see my example => as
> soon as you need to repeat a trait with just a change in name, you always
> need conflict resolution.
Please post the code snippet again. I'm not
> On Feb 10, 2021, at 9:05 PM, Martin Frb via fpc-pascal
> wrote:
>
> Maybe Something like (aliasing / no need to copy implementation)
> TDesignerList = trait(TEmployeList)
> function FindDesigerByUnallocateWorkTime: TEmploye; aliases
> FindByUnallocateWorkTime; // no body /just a name r
> On Feb 13, 2021, at 12:38 PM, Sven Barth wrote:
>
> Right now, Ryan, your suggestion looks like a solution in search of a
> problem, or a "hey, look at that feature in language X, I so must have that
> in Pascal as well". Those concepts more likely then not tend to end in
> problems or shou
> On Feb 13, 2021, at 5:09 PM, Ben Grasset via fpc-pascal
> wrote:
>
> This seems possibly a *little* too similar to the existing Interface type in
> Object Pascal, however, I *would* really like to see some kind of
> functionality that basically amounts to "has the same capabilities as
> I
> On Feb 14, 2021, at 5:30 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Interfaces means an extra object per interface, so more objects on the heap
> with all the extra memory management that implies.
You mean COM interfaces? I've only ever used CORBA style ones which I thought
were
> On Feb 14, 2021, at 9:16 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I didn't propose using an interface; For me the
>
> property Test: TTestImpl read fTest implements TTestIimpl;
>
> Where TTestImpl is an object (tp style) or advanced record (delphi style) is
> ample.
That was d
> On Feb 14, 2021, at 10:20 AM, Sven Barth via fpc-pascal
> wrote:
>
> To be fair, that *is* how inheritance works for example if you try to use OOP
> in C... (though it would be more like "sphere.parent.parent.Draw()")
and that was bad. :) in PHP you're forced to use this-> instead of impli
> On Feb 14, 2021, at 9:55 AM, Sven Barth via fpc-pascal
> wrote:
>
> No, interfaces by *themselves* don't mean that. An interface instance is
> merely a shifted Self pointer that points to the static VMT of which the
> entries correct the Self pointer again upon the method call. This can be
> On Feb 14, 2021, at 11:14 AM, Sven Barth via fpc-pascal
> wrote:
>
> It's a runtime conversion, but normally you don't do the conversion for every
> method call, but instead cache the interface (or work solely with the
> interface), thus the performance impact through the conversion amorti
> On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal
> wrote:
>
> Same names should be rejected. Providing a new implementation can be
> controlled using the interface alias:
>
> === code begin ===
>
> type
> TMyClass = class(TInterfacedObject, IMyIntf)
> private
> fMyRecord: T
> On Feb 15, 2021, at 9:08 AM, Marcos Douglas B. Santos via fpc-pascal
> wrote:
>
> As I understand, this is not a method hiding, but just to tell the
> compiler which method to implement the interface—the interface could
> have method names which are very very common to use and this syntax
>
> On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal
> wrote:
>
> Again, the point of the interface would be to control which methods and
> properties of the delegated type would be available. Also it would allow for
> seamless integration with the RTTI as it's possible to query the im
> On Feb 16, 2021, at 6:51 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> Interfaces are extremely slow. Virtual method calls are also slow. I have
> been using interfaces for reference counting, and have been thinking to
> replace it all with managed records because they are so slow
> On Feb 16, 2021, at 11:44 AM, Sven Barth wrote:
>
> I wasn't saying anything that contradicts this, only that the original
> mechanism of the delegation will be available even with the default modifier
> and this mechanism will in fact be necessary to access them through RTTI.
>
Can you
> On Feb 16, 2021, at 11:48 AM, Sven Barth wrote:
>
> If you need to create 1000 class instances each frame then you have a flaw in
> your logic in my opinion.
>
You can reuse classes and reset fields but getting a new piece of memory could
be faster. These things do happen and adding on c
> On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> And there often is a lot of unintentional deep copying. This is also why a
> property returning a record is fairly useless except for extremely small
> records like TPoint (and even that is not optimal no
deep cop
> On Feb 16, 2021, at 2:43 PM, Sven Barth via fpc-pascal
> wrote:
>
> FPC currently does not yet support class types not to mention records and
> objects which is what I had mentioned earlier already.
Yes I see this on https://freepascal.org/docs-html/ref/refse47.html. Why isn't
this suppor
> On Feb 16, 2021, at 3:35 PM, Benito van der Zander via fpc-pascal
> wrote:
>
> But it is not calling the method, it is calling the wrapper function
what you say wrapper function do you mean the ref counting functions when you
pass around the interface?
I guess for ref counting you're supp
> On Feb 17, 2021, at 6:17 AM, Sven Barth wrote:
>
> No. With wrapper function he means the thunks that are responsible for
> adjusting the instance pointer of the interface to the instance pointer of
> the class before jumping to the method of the class.
Oh, so this is some extra code that
> On Feb 17, 2021, at 6:10 AM, Sven Barth wrote:
>
> Simply because no one has come around to implement it yet. The class type
> case is more complicated than the interface case. (Same would be true for
> record and objects)
> So, yes, we'll need to implement this first which would finally br
> On Feb 17, 2021, at 8:27 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> var c: ITest;
> begin
> c := TTest.Create(123);
> c.println;
So this is where you're getting your performance penalties? Correct me if I'm
wrong but two things happen here:
1) Implicit cast to ITest which d
> On Feb 17, 2021, at 11:11 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> just open the disassembler window in Lazarus and single step through all the
> instructions. Then you see everything
>
> create alone calls a bunch of methods:
>
> TInterfacedObject.NewInstance
> TObject.NewI
> On Feb 17, 2021, at 4:51 PM, Benito van der Zander via fpc-pascal
> wrote:
>
> I benchmarked it years ago, I do not remember the details.
>
> But InitInterfacePointers was bad. Just look at it:
>
That's not great for sure. Fillchar could be a big culprit also actually. I for
one would li
> On Feb 17, 2021, at 9:59 AM, Adriaan van Os via fpc-pascal
> wrote:
>
> 1. multiple inheritance is nice to have, but it has the big issue that the
> inheritance tree becomes an inheritance graph and that makes overrules
> ambiguent.
> 2. interfaces don't have this issue with multiple inhe
> On Feb 18, 2021, at 10:40 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> Traits are like reverse type helpers. With the type helper you first declare
> the class and then the extending helper.
Indeed, but with the crucial distinction that helpers don't allow fields, only
methods.
> On Feb 18, 2021, at 12:33 PM, Martin Frb via fpc-pascal
> wrote:
>
> TMyFoo = class(specialize TTrait)
> procedure Foo;
> end;
>
> Of course that can get out of hand, if you want to include many traits.
I'm not really understand this at all. You're still using subclassing, which i
> On Feb 18, 2021, at 3:07 PM, Sven Barth wrote:
>
>> So "class type method resolution" is what's missing? I never used the
>> interface method resolution so I don't really understand this feature. What
>> needs to happen as far as the compiler is concerned?
>
> The problem is this: if you h
> On Feb 18, 2021, at 11:30 PM, Sven Barth wrote:
>
> The only thing that will not work and which will continue not to work is that
> m_circle.Draw will not be called if you access the TMyShape through a
> TShape.Draw call. For that one needs to use an explicit declaration:
>
> === code begi
201 - 300 of 424 matches
Mail list logo
