Re: [fpc-pascal] Traits Proposal
Btw, here's point of reference for this other proposed syntax. https://github.com/genericptr/freepascal/wiki/Default-Implements-Property Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
> On Feb 19, 2021, at 11:01 AM, Sven Barth via fpc-pascal > wrote: > > Your example is not quite correct and it's also not really complete: if a > class implements an interface there *must* be a parent class mentioned (at > least TObject). Also your example should demonstrate that one can call > TMyShape.Draw without having to retrieve the interface (after all that's the > point of the interface property). > TObject is always the root class I thought? Why is it different here? > Additionally support for raw interfaces (aka Corba) should be added for > interface delegation if it isn't already supported. (Otherwise your TMyShape > either needs to inherit from e.g. TInterfacedObject or one of the involved > types needs to implement the methods of IInterface. > They work already fortunately. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
> On Feb 19, 2021, at 3:14 PM, Sven Barth via fpc-pascal > wrote: > > TObject *is* always the root, but the first entry of the inheritance list of > a class *must* be a class as well. I'm testing interface delegation now in ObjFPC mode and I don't see that including TObject is required. 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 routines for both dynamic array and other collections
> On Feb 20, 2021, at 5:19 AM, Виктор Матузенко via fpc-pascal
> wrote:
>
> Hi,
>
> I am trying to write some generic routines for working with containers. For
> example, GetLength function:
>
>
>
> unit u;
>
> {$MODE FPC}
> {$MODESWITCH DEFAULTPARAMETERS}
> {$MODESWITCH OUT}
> {$MODESWITCH RESULT}
>
> interface
>
> generic function GetLength(const V: TContainter): SizeUInt;
>
> implementation
>
> generic function GetLength(const V: TContainter): SizeUInt;
> begin
> Exit(V.Count);
> end;
>
> end.
The helper needs to be in the unit file so that GetLength() knows about 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 routines for both dynamic array and other collections
> On Feb 20, 2021, at 7:52 PM, Виктор Матузенко via fpc-pascal > wrote: > > And how do I write generic helper for all possible dynamic arrays? By hand sadly. The RTL has added type helpers for many types but I don't think they added these for dynamic arrays. I agree that dynamic arrays should have a "Count" method by default and the RTL should provide "array of T" for all intrinsic types. 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 routines for both dynamic array and other collections
> On Feb 21, 2021, at 2:59 PM, Sven Barth wrote: > > You are supposed to use Length(X). There is no need for a "property". One > doesn't need to objectify each and everything! Yes but programmers tend to be neurotic and obsessive. :) I think many of us would appreciate a matching "Count" method that is consistent with TList. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
> On Feb 19, 2021, at 8:50 AM, Ryan Joseph wrote: > > I just realized another potential problem. If we use the "default" keyword > that means there could be multiple "defaults" unless we limit the property to > 1 per class, which would kind of defeat the purpose of the feature (like the > issue we had with helpers and made multi-helpers for). Can you respond to this concern? It could be a deal breaker for the syntax. 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 routines for both dynamic array and other collections
> On Feb 22, 2021, at 4:21 PM, Виктор Матузенко via fpc-pascal > wrote: > > Example of such an algorithm is binary search. I am able to access elements > with [] operator of both > arrays and objects, but I cannot get length in a generic way. > Length(T) is what you want right? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
Ok my summary thus far with this syntax (default interface delegation) is that composition is possible (which is very nice) but polymorphism is not really possible so it's not exactly an alternative to multiple inheritance. Besides the complications of implementing method resolution for classes (no idea what's involved here) I would say it's a pretty low time investment to get a good chunk of what people want from multiple inheritance, although not a full fledged alternative like adding a new "trait" syntax would provide. I want to add more examples to the GitHub page so we don't forget. The most important thing to get right is not allowing any possibility to write have ambiguous methods. Here are some common ones I could think of. Are these correct? Anything to add? I guess the compiler just gives "already declared" errors for each method with a conflict. Does the visibility of the property matter in subclasses (I assume yes)? () type ICircle = interface procedure Draw; end; type TCircle = record procedure Draw; end; type TMyShape = class(ICircle) private FCircle: TCircle; public property Circle: TCircle read FCircle implements ICircle; default; end; type TOtherShape = class(TMyShape) public // ERROR - draw is already declared procedure Draw; end; () type TMyShape = class(ICircle) private FCircle: TCircle; public property Circle: TCircle read FCircle implements ICircle; default; // ERROR - Draw already declared procedure Draw; end; () type TMyShape = class(ICircle) private FCircle: TCircle; public property Circle: TCircle read FCircle implements ICircle; default; // Conflict is resolved, we can now redeclare Draw and Circle.Draw will point to TMyShape.Draw instead of TCircle.Draw procedure ICircle.Draw = Draw; procedure Draw; end; () type ISquare = interface procedure Draw; end; type TSquare = record procedure Draw; end; type TOtherShape = class(TMyShape, ISquare) private FSquare: TSquare; public // ERROR - Draw is already declared property Square: TSquare read FSquare implements ISquare; default; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Unicode chars losing information
I came across a bug which was caused but a unicode character losing information and narrowed it down to this. Why doesn't the chars[1] print the same character as appeared in the string? var chars: UnicodeString; begin chars := '⌘⌥⌫⇧^'; writeln(chars); writeln(chars[1]); end. Prints: ⌘⌥⌫⇧^ ? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
> On Mar 7, 2021, at 9:31 AM, Marco van de Voort via fpc-pascal > wrote: > > Probably it is not in the BMP and thus needs more position than one. Isn't char[1] a 2 byte wide char? Not sure I understand "more position than on" though. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
> On Mar 7, 2021, at 10:11 AM, Marco van de Voort via fpc-pascal > wrote: > > > Yes it is. And there are about 1114000 unicode codepoints, or about 17 times > what fits in a 2-byte wide char. > > https://en.wikipedia.org/wiki/Code_point > > https://en.wikipedia.org/wiki/UTF-16 I thought unicode strings "just worked" but maybe that's UTF-8 and the character I want is maybe UTF-16. What are you supposed to do then? UnicodeString knows how to print the full string so all the data is there but I can't index to get characters unless I know their size. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
> On Mar 7, 2021, at 10:21 AM, Ryan Joseph wrote: > > I thought unicode strings "just worked" but maybe that's UTF-8 and the > character I want is maybe UTF-16. What are you supposed to do then? > UnicodeString knows how to print the full string so all the data is there but > I can't index to get characters unless I know their size. Since this looks like it could be complicated here is what I was actually trying to do with the FreeType library. This works for ASCII but broke down with those unicode chars. I'm confused now because you say the character are more than 2 bytes so I don't know what the actual size of an element is. for glyph in '⌘⌥⌫⇧^' do FT_Load_Char(m_face, ord(glyph), FT_LOAD_RENDER); Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode chars losing information
So I was indeed able to solve the problem using {$codepage utf8} and using the
CWString unit. Does this do anything besides change the backend of the
UnicodeString/UnicodeChar type? I using other string types in that unit and I'm
curious if I've put some kind of performance burden on the other strings.
I agree it would be nice to have some warning that indexing the unicodeString
wouldn't work as expected.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Extraneous generic parameters
This program compiles, but is it a bug? I would think the specialization should
fail because "S" in TArray is not specified.
{$mode objfpc}
type
generic TArray = array of T;
generic procedure DoThis(param: specialize TArray>);
begin
end;
begin
specialize DoThis([[1],[2],[3]]);
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extraneous generic parameters
> On Mar 15, 2021, at 12:42 AM, Sven Barth wrote: > > The TArray generic type is part of the ObjPas unit, so the compiler simply > picks that instead of that of your program. ;) Sneaky but that explains the issue. Btw since we're on the topic of arrays. Are short strings and static arrays not able to be generics? I tried that and got parser errors. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Hide warning number
Is there a way to hide a warning for all files from the command line? The "not inlined" warnings (6058) are too numerous to even be useful anymore so I'd like to disable it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Usage of FieldAddress
I'm trying to see fields by name but TObject.FieldAddress doesn't seem to be working. Do I have that correct I should be using FieldAddress to return the pointer of the published property? Some how I can't seem to find an example of FieldAddress on Google type TSomething = class(TPersistent) private m_scale: integer; published property scale: integer read m_scale write m_scale; 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] Usage of FieldAddress
> On Apr 4, 2021, at 12:10 PM, Sven Barth via fpc-pascal
> wrote:
>
> FieldAddress only works on published fields. Just like MethodAddress only
> works on published methods.
>
> For private fields extended RTTI is required which is not yet implemented.
I don't understand this at all I guess. I thought the properties made them
published and I get a "Symbol cannot be published, can be only a class" if I
put the field itself in the published section.
Just trying to do this:
PInteger(theClass.FieldAddress('foo'))^ := 10;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of FieldAddress
> On Apr 4, 2021, at 1:07 PM, Sven Barth via fpc-pascal > wrote: > > Only classes or interfaces are supported as published *fields*. > > And the visibility of the *property* does not change the visibility of the > *field*, after all the property could be provided by a method. > I know FPC can deserialize JSON with TJSONDeStreamer so maybe I need to use the RTTI functions in TypInfo.pas? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of FieldAddress
> On Apr 4, 2021, at 2:36 PM, Sven Barth via fpc-pascal > wrote: > > The RTTI streaming relies on *published properties* (and published methods > for the event handlers). Sorry Sven, I'm not understand what I'm doing wrong. From original example "scale" is a published property right? So FieldAddress only works on published fields, which are not supported unless they are classes/interfaces. type TSomething = class(TPersistent) private m_scale: integer; published property scale: integer read m_scale write m_scale; end; I have used published properties like this for JSON streaming, i.e.: type TVectorObject = class(TPersistent) private components: array[0..2] of integer; published property x: integer read components[0] write components[0]; property y: integer read components[1] write components[1]; property z: integer read components[2] write components[2]; end; which works just fine so I assume I can use the RTTI functions, just not FieldAddress. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Generic class aliases
With normal classes you can make aliases to other units but with generics you get an error. Am I doing this wrong or is this not supported? type TList = UOther.TList; // Generics without specialization cannot be used as a type for a variable Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Abstract classes ignored
From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive." Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Background info on Generics in FPC
> On Apr 17, 2021, at 1:07 PM, Graeme Geldenhuys via fpc-pascal > wrote: > > Hi > > I'm looking at the wiki and official FPC language documentation. What was > the reason for the decision to make the FPC syntax so verbose regarding > Generics? There is a plan to make these optional via a mode switch but it hasn't happened yet. Personally I like the "generic" keyword but the specialize keyword is annoying if you don't make a type alias (and for function calls of course). Implicit function specialization is already ready so at least we won't need to use <> at all for function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> On Apr 17, 2021, at 3:09 PM, Sven Barth wrote: > > The compiler will generate a warning in case you instantiate a class that is > abstract or has abstract methods. You can escalate these warnings to errors > if you need: It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> On Apr 18, 2021, at 5:00 AM, Sven Barth wrote: > > As I have said: Delphi compatibility. This would have been a good candidate to put behind the delphi mode switch but I'm sure there is a reason for this also. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> On Apr 18, 2021, at 11:28 PM, Sven Barth wrote: > > Nowadays: backwards compatibility. backwards compatibility strikes again. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] How does TFPGMap key compare work?
I have a question I was just curious about. From what I can tell TFPGMap uses CompareByte to compare keys of arbitrary type, which is clever but how does this work for ShortStrings? I have tried to use this method myself and I find it always fails because short strings have garbage at the end and so even if you zero out the memory (which is allocated) a short string passed as a parameter to a function will have garbage and thus fail to compare. Any ideas how this works for TFPGMap then? function TFPSMap.BinaryCompareKey(Key1, Key2: Pointer): Integer; begin Result := CompareByte(Key1^, Key2^, FKeySize); 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] How does TFPGMap key compare work?
> On Apr 20, 2021, at 3:10 PM, Sven Barth wrote: > > If you look at TFPSMap' code you'll see that BinaryCompareKey and > BinaryCompareData are only used in the way of method pointers OnKeyPtrCompare > and OnDataPtrCompare. In TFPGMap<,> these are then set to compare methods > specific to the specialization, most importantly TFPGMap<,>.KeyCompare if no > custom compare function is set. There's no many levels of indirection here I got confused. I see this method below and so maybe the <> operators are overloaded for short strings? function TFPGMap.KeyCompare(Key1, Key2: Pointer): Integer; begin if PKey(Key1)^ < PKey(Key2)^ then Result := -1 else if PKey(Key1)^ > PKey(Key2)^ then Result := 1 else Result := 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] [fpc-devel] Nested function closures
> On Apr 27, 2021, at 9:58 AM, Michael Van Canneyt > wrote: > > Wait. > > I asked Sven to make sure that nested functions are under ALL circumstances > usable as closures or can be used instead of anonymous functions. > > Pas2js already supports this, and I want FPC and Pas2JS to be compatible in > this regard. > > So as Sven wrote, you would be duplicating effort, needlessly, since it has > to work always... If the compiler can decide that the heap interface is not > needed and optimize it away: so much the better. But I doubt this will be > possible. Maybe we're misunderstanding each other then. I'm responding to Sven when he says: > Getting rid of the interface only works in very narrow circumstances that are > so seldom in real world code that it is not worth the effort. I.e. all closures will be interface based because there are not enough real world use cases to support any alternative. Which is contrary to what you're saying that nested functions/closure will be compatible types. Sven can clear this up for us I guess. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> On Apr 27, 2021, at 2:17 PM, Sven Barth via fpc-pascal > wrote: > > It will *always* create an interface. It's just how the compiler will wrap it. But why would it do that when we could use an alternate code path that uses nested functions instead? Maybe I'm not being clear but we can do BOTH depending the situation when one is better than the other. This is just an optimization that leverages existing features that are already in the compiler anyways. Seems like a no-brainer 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] [fpc-devel] Nested function closures
> On Apr 27, 2021, at 2:23 PM, Ryan Joseph wrote: > > But why would it do that when we could use an alternate code path that uses > nested functions instead? Maybe I'm not being clear but we can do BOTH > depending the situation when one is better than the other. This is just an > optimization that leverages existing features that are already in the > compiler anyways. Seems like a no-brainer to me. Here's what I'm proposing. Closures and nested functions should be symmetrical so that anonymous function bodies can be used without relying on the interfaces when they're not needed. type TComparator = procedure (a, b: TEntity): Integer is nested; procedure TMyClass.SortEntities(comparator: TComparator); begin end; for i := 0 to entities.Count - 1 do begin value := entities[i]; value.SortEntities(function(a, b: TEntity): integer begin // do stuff 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] [fpc-devel] Nested function closures
> On Apr 27, 2021, at 4:53 PM, Graeme Geldenhuys via fpc-pascal > wrote: > > Why must the anonymous function repeat all that information again, > as shown in the quoted code above? Can't the compiler figure all > that out simply by inference? All the developer should have to do > is give the 2 parameters a name, and a function body (block of > code). Thus you could end up with something like this: > > > value.SortEntities((a, b) -> > begin > // do stuff with a and b, then > // return some integer. > end > ); I agree it's verbose but the syntax is already decided upon and implemented already. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> On Apr 27, 2021, at 11:36 PM, Sven Barth wrote: > > Anyway, it would in principle be possible to convert an anonymous function to > a "is nested" function, but that will only come *after* the whole > implementation is here so that the chance for messing that core functionality > (!) up is reduced. Sorry I'm struggling with all these new terms myself. Yes that is what I'm proposing and what I demonstrated in that GitHub branch. We talked about this in 2018 but you said to wait until the "real thing" was finished so I let it be. I brought this up again now to say that when, and not before, the closures are finished and in trunk I will see how to integrate the "nested anonymous functions" into the new system. To clarify for myself, we have a few concepts here: - Closures: blocks which capture variables in scope and wrap them into a container (nested functions use a record I think and closures will use an interface). - Anonymous procedures: Simply an anonymous procedure/function body which lacks a name and can be declared inside code blocks. - 2 Procedure types: "reference to" and "is nested". On the caller side these are what control which kind of closure is used is used. Is that correct? So the anonymous function doesn't really become a closure until it's passed to a "reference to" or "is nested" variable. So once the current work is done we have 2 kinds of closures but only one of those is compatible with anonymous functions and this is why I want the other closures (nested functions) to have the same pair of functionality. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> On Apr 28, 2021, at 10:43 AM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Couldn't such verbose syntax be limited to {$mode delphi} behaviour,
> and then leave {$mode objfpc} free to experiment and introduce new
> less verbose syntax in the language.
Sven is having none of this and for good reason. This feature has been
collecting dust as "almost done" for years now so I would consider ourselves
lucky to get anything at all.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> On Apr 29, 2021, at 12:01 AM, Sven Barth wrote:
>
> To be precise there are two more: function/procedure variables (no special
> designator) and method variables ("of object"). Depending on what a anonymous
> function captures (or for the sake of it a nested function) it would be
> possible to assign it to such a type as well (for a function variable only
> global variables may be used, for a method variable additionally Self may be
> used).
As I remember the capturing code for nested functions and the new closures are
not shared. That means when the parser encounters an anonymous function it
needs to decide which type of capture it will use, right? In that case the user
may need to state that the anon function is "nested" otherwise it will use the
wrong capturing method.
>
> So once the current work is done we have 2 kinds of closures but only one of
> those is compatible with anonymous functions and this is why I want the other
> closures (nested functions) to have the same pair of functionality.
>
> Once anonymous functions are supported we can improve their compatibility
> with other constructs.
>
Great, that's what I wanted to do. It's well worth the time to get anon
functions for callbacks that return immediately, list.ForEach, list.Sort etc
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Array range overflow in properties
Is this a bug in properties and I should be getting an error? type TPixel = record components: array[0..3] of byte; property R: byte read components[10] write components[10]; 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] Array range overflow in properties
> On Apr 29, 2021, at 11:22 PM, Sven Barth wrote: > > Well, there should *at least* be a warning and an error if range checks are > enabled... Please file a bug report. https://bugs.freepascal.org/view.php?id=38829 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 50 years of Pascal, by the the author himself
> On May 12, 2021, at 12:30 PM, Ralf Quint via fpc-pascal > wrote: > > Thought this was kind of interesting, though it leaves short of mentioning > the later Object Pascal evolution and thus Delphi and FreePascal... Isn't Free Pascal and Delphi basically the only Pascal compilers left? I used THINK Pascal and Metrowerks Pascal in the distant past but those are all long dead. You can't really talk about Pascal in 2021 without mentioning those 2 compilers. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 50 years of Pascal, by the the author himself
> On May 12, 2021, at 4:00 PM, Sven Barth wrote: > > There's also Oxygene as one of the current ones. > Oh that's right, that's a pretty cool one. I hope once closures are finished we can use them to implement async/await like Oxygene or JavaScript. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> On Jun 1, 2021, at 12:20 PM, denisgolovan via fpc-pascal > wrote: > > Hi all > > I am trying to implement Option type in FPC. > > type > generic TOption = record >case IsSome:boolean of >true: ( some: T ); >false: (); > end; You need to use a constraint like: type generic TOption = record case IsSome:boolean of true: ( some: T ); false: (); end; Not sure why though. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> On Jun 1, 2021, at 12:56 PM, denisgolovan wrote: > > That would limit supported types to class instances. > I'll like to avoid that. > Ideally TOption type should allow any type (primitives, strings, objects, > class instances, etc). What are you trying to make that requires a variant record? I don't know what "TOption" 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] Option type
> On Jun 1, 2021, at 5:05 PM, Henry Vermaak wrote: > > https://en.wikipedia.org/wiki/Option_type Yeah just use Nullable then since it sounds like that's the closest we're going to get in FPC. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Management operators memleaks
> On Jun 13, 2021, at 7:48 AM, denisgolovan via fpc-pascal > wrote: > > Could anybody reply? > > Am I doing something wrong? > Are management operators supported or not? Maybe reduce the test down to a smaller footprint and isolate the memory leak? That would be helpful to knowing what may 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] Management operators memleaks
> On Jun 13, 2021, at 11:35 PM, Sven Barth via fpc-pascal > wrote: > > I have not looked at your test case yet, but it *might* be related to issue > #37164 ( https://bugs.freepascal.org/view.php?id=37164 ). His tests didn't have an enumerator and for..in loop like in that bug report so I'm not sure. Most importantly Denis needs to isolate this into a small single program which prints out the operators like in the bug report Sven listed. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Tuples as variant arrays
Is it possible something like this could work? Seems like it should but I get
an error (got MyRecord expected variant).
{$mode objfpc}
program unit_name;
type
TTuple = array of variant;
type
MyRecord = record
end;
var
t: TTuple;
r: MyRecord;
i: variant;
begin
t := [1,'string', r];
for i in t do
begin
writeln(i);
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] How does FPC perform in the FASTEST Computer Language Race
> On Jul 9, 2021, at 11:40 AM, Wayne Sherman via fpc-pascal > wrote: > > Current standings at the time of this video > Iterations per sec: > Ada: 67 > Pascal: 143 > Fastest language: 7301 > Slowest language: 1 So Pascal failed pretty bad it looks like. ;) 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 does FPC perform in the FASTEST Computer Language Race
> On Jul 10, 2021, at 4:16 AM, Guillermo via fpc-pascal
> wrote:
>
> Hi,
>
> I remember years ago a similar test in a web page. Pascal was way low
> in the list, even below Java and Python! but we (in a forum) found that
> it wasn't Pascal fault: most versons program were optimised in code
> while Pascal used brute force (also compiling using -O3 made it way
> faster than the web proclaimed so we suspect they used -O- or even
> worse a relic compiler [Turbo Pascal 1?]). Once fixed it was almost
> unoticeably behind C in both FPC and Delphi (Delphi result was a bit
> faster).
Here's the C++ version that won. Looks like the magic comes from constexpr,
which I don't understand very well in C++ except that it's a constant
expression. Can anyone explain how constexpr works here?
// ---
// PrimeCPP_CONSTEXPR.cpp : Taking advantage of compiler optimizing constants
// ---
#include
#include
#include
#include
#include
#include
#include "Sieve.h"
using namespace std;
using namespace std::chrono;
struct RESULTS
{
unsigned long long upTo;
int count;
};
constexpr RESULTS resultsDictionary[] = {
{10LL, 4}, // Historical data for validating our results - the number of
primes
{100LL, 25}, // to be found under some limit, such as 168 primes under 1000
{1000LL, 168},
{1LL, 1229},
{10LL, 9592},
{100LL, 78498},
{1000LL, 664579},
};
constexpr int find(const unsigned long long val)
{
for (const auto d : resultsDictionary)
{
if (d.upTo == val)
return d.count;
}
return -1;
}
constexpr int countPrimes(const Sieve &sieve)
{
return sieve.count();
}
constexpr bool validateResults(const Sieve &sieve)
{
const auto sieveSize = sieve.size();
const auto result = find(sieveSize);
if (-1 == result)
return false;
return result == countPrimes(sieve);
}
void printResults(const Sieve &sieve, bool showResults, double duration, int
passes, int threads)
{
const auto sieveSize = sieve.size();
if (showResults)
printf("2, ");
int count = (sieveSize >= 2); // Starting count (2 is prime)
for (int num = 3; num <= sieveSize; num += 2)
{
if (sieve.contains(num))
{
if (showResults)
printf("%d, ", num);
count++;
}
}
if (showResults)
printf("\n");
printf("Passes: %d, Time: %lf, Avg: %lf, Limit: %llu, Count1: %d, Count2:
%d, Valid: %d\n",
passes,
duration,
duration / passes,
sieveSize,
count,
countPrimes(sieve),
validateResults(sieve));
printf("\n");
printf("flo80_constexpr;%d;%f;%d;algorithm=base,faithful=no,bits=1\n",
passes, duration, threads);
}
void run(uint64_t upperLimit, const Sieve &checkSieve, int numberOfThreads = 1,
int runtimeSeconds = 5)
{
unsigned int passes = 0;
printf("Computing primes to %llu on %d thread%s for %d second%s.\n",
upperLimit,
numberOfThreads,
numberOfThreads == 1 ? "" : "s",
runtimeSeconds,
runtimeSeconds == 1 ? "" : "s");
const auto tStart = steady_clock::now();
while (duration_cast(steady_clock::now() - tStart).count() <
runtimeSeconds)
{
vector threadPool;
for (unsigned int i = 0; i < numberOfThreads; i++)
{
threadPool.push_back(thread([upperLimit]
{
auto sieve = Sieve(upperLimit);
sieve.runSieve();
}));
}
for (auto &th : threadPool)
th.join();
passes += numberOfThreads;
}
const auto tEnd = steady_clock::now();
printResults(checkSieve, false, duration_cast(tEnd -
tStart).count() / 100.0, passes, numberOfThreads);
}
int main(int argc, char **argv)
{
uint64_t upperLimit = 1'000'000L;
constexpr int runtimeSeconds = 5;
if (argc > 1)
{
upperLimit = std::max((uint64_t)atoll(argv[argc - 1]), (uint64_t)1);
assert(upperLimit < Sieve::maxSize);
}
auto checkSieve = Sieve(upperLimit);
checkSieve.runSieve();
const auto result = validateResults(checkSieve) ? checkSieve.count() : 0;
const auto numberOfThreads = thread::hardware_concurrency();
thread::hardware_concurrency();
run(upperLimit, checkSieve, numberOfThreads, runtimeSeconds);
run(upperLimit, checkSieve, 1, runtimeSeconds);
return result;
}
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 does FPC perform in the FASTEST Computer Language Race
> On Jul 9, 2021, at 4:56 PM, Ryan Joseph wrote: > >> Current standings at the time of this video >> Iterations per sec: >> Ada: 67 >> Pascal: 143 >> Fastest language: 7301 >> Slowest language: 1 > > So Pascal failed pretty bad it looks like. ;) I just ran that unit with -O2 and got nearly ~6000 passes on my 2020 MacBook. The C++ solution #1 got about the same. I guess that video is totally false or I'm missing 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] How does FPC perform in the FASTEST Computer Language Race
> On Jul 10, 2021, at 11:18 AM, Jonas Maebe via fpc-pascal > wrote: > > A constexpr function means that it must be computable at compile time if > all of its arguments are also constexpr. So like the "pure" functions that Gareth was working on? Seems to have moved on from the idea but I thought it was pretty interesting. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess read buffer size
I have some code the basically does: while bytesRead > 0 do bytesRead := process.Output.Read(buffer^, kBufferSize); but bytesRead is only ever 512 per call to Read. Is this a system imposed limit or something that's part of TProcess? Setting kBufferSize to anything larger than 512 has no affect. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess read buffer size
> On Jul 15, 2021, at 3:07 PM, Marco van de Voort via fpc-pascal > wrote: > > Not of TProcess as far as I know, it probably depends on the OS pipe > implementation and maybe the granularity that the processes that you run > outputs data. (buffers its I/O iow calls write() in 512 byte increments ) In this case the command is a PHP script that reads a file in 64k chunks and writes the text to stdout (in PHP fread returns 64k chunks as expected). TProcess looks like a pretty thin wrapper around pipes and common unix system calls so I don't know where the 512 limit could come from. How could I test this further? I think something is wrong but I don't know where to look. I'm on macOS btw. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess read buffer size
> On Jul 15, 2021, at 8:33 PM, Dennis Lee Bieber via fpc-pascal > wrote: > > https://flylib.com/books/en/3.126.1.111/1/ > > """ > Only writes below PIPE_BUF bytes in size are guaranteed to be atomic. > PIPE_BUF is 512 bytes on Mac OS X. The fpathconf() system call can be used > to retrieve the value of PIPE_BUF given a pipe descriptor. > """ > > Granted you seem to be reading -- but the other end may be what is > controlling the size of each packet (and may somehow even have set the pipe > overall size to just one "buffer"). > > Unless you can examine the writing side, or source code of your read > method... Yes I think you're right. ~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2784 virtual memory (kbytes, -v) unlimited It's just a PHP script that dumps 64k chunks but if the pipe buffer is 512b then I'm stuck. Is there a lower level library I can use to set the pipe size? I was curious if this is a bottle neck for me. Currently it takes about 7 seconds to read a 600MB file from one process to another, which is insanely slow. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Better way to handle callback types
FPC has a number of function pointer types and eventually will have another in
"reference to" closures. This presents a problem of how the programmer can make
a function that is type agnostic so that we can use different types of
callbacks.
Currently this is the best solution I can think of but it's still a real mess
and tedious to setup. Here's a little snippet of a list class that has a Sort
method.
It feels to me like the compiler needs a new type which wraps all the callbacks
for us but maybe there's a better way?
type
generic TSList = class
type
TComparator = record
private type
TFuncProc = function (constref left, right: T; context: pointer):
integer;
TFuncNested = function (constref left, right: T; context: pointer):
integer is nested;
TFuncObject = function (constref left, right: T; context: pointer):
integer of object;
private
index: TFuncType;
public
function Call(constref left, right: T; context: pointer): integer;
case byte of
0: (proc: TFuncProc);
1: (nested: TFuncNested);
2: (obj: TFuncObject);
end;
...
procedure Sort(callback: TComparator.TFuncProc; context: pointer = nil);
procedure Sort(callback: TComparator.TFuncNested; context: pointer = nil);
procedure Sort(callback: TComparator.TFuncObject; context: pointer = nil);
end;
...
procedure TSList.Sort(callback: TComparator.TFuncProc; context: pointer);
var
comparator: TComparator;
begin
comparator.proc := callback;
comparator.index := TFuncType.IsProc;
{ do sorting and call comparator.Call(left, right, context); which routes to
the correct callback }
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] Better way to handle callback types
> On Aug 21, 2021, at 12:08 PM, Jonas Maebe via fpc-pascal > wrote: > > You can pass global functions to "is nested" procvars, so at least these > two don't need to be separate. > > OTOH, there's another type: cblocks :) So up to 4 types are needed: "is nested", "of object" and "reference to" (for cblocks and eventually closures). Ouch. This is certainly a mess and results in tons of boiler plate for functions that use callbacks. Shouldn't the compiler have a meta-type like I made? We should be able to write a single function which takes a callback and then have the compiler figure out which type is provided on the caller side. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better way to handle callback types
> On Aug 21, 2021, at 1:30 PM, Michael Van Canneyt > wrote: > > "Reference to" can be used for the others as well. How do you mean? Reference to is currently only available for cblocks on macOS I think so I'm not sure how this would look. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better way to handle callback types
> On Aug 21, 2021, at 3:09 PM, Michael Van Canneyt via fpc-pascal > wrote: > > As in Delphi 'reference to' will also be used for all references where an > anonymous functon can be used. But you can perfectly use methods and local > functions for that. So it will function a like a catch-all procedural type. > > When Sven is done with the anonymous methods, you'll see it in action. But isn't this going to make the interface wrapper and allocate a class? Maybe Sven can explain how that works. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Lazbuild error on Windows
I'm trying to build a Lazarus project on Windows and I've ran into a problem. Since I barely know Windows all I have known to do is download the latest version of the compiler and Lazarus then install them via their installers. I expected then to be able to use lazbuild like I do on macOS but I got an error that some file is missing. Here's the part which fails. How could lazfileutils.pas not be found? I actually see the .ppu file where it should be so it feels like the compiler and the version of Lazarus are not matching or something. Free Pascal Compiler version 3.2.2 [2021/05/15] for i386 Copyright (c) 1993-2021 by Florian Klaempfl and others (1002) Target OS: Win32 for i386 (3104) Compiling weblaz.pas (3104) Compiling fpideexteditorinsertfilenameunit.pas (10001) PPU Loading C:\lazarus\components\lazutils\lib\i386-win32\lazfileutils.ppu (10011) PPU Source: lazfileutils.pas not found (10011) PPU Source: lazutils_defines.inc not available (10011) PPU Source: lazfileutils.inc not available (10011) PPU Source: winlazfileutils.inc not available (10028) Recompiling LazFileUtils, checksum changed for C:\FPC\3.2.2\units\i386-win32\rtl\system.ppu C:\lazarus\components\fpweb\fpideexteditorinsertfilenameunit.pas(37,22) Fatal: (10022) Can't find unit LazFileUtils used by fpIDEExtEditorInsertFileNameUnit Fatal: (1018) Compilation aborted Error: C:\FPC\3.2.2\bin\i386-Win32\ppc386.exe returned an error exitcode Error: (lazarus) Compile package weblaz 1.0: stopped with exit code 1 Error: (lazarus) [TLazPackageGraph.CompileRequiredPackages] "Exit code 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] Writing Pascal Physics and Vectors
> On Oct 16, 2021, at 5:18 AM, Anthony Walter via fpc-pascal > wrote: > > Source code for the test scene is included on that page. If you want to help, > I need to bounce ideas off people as well as test on Raspberry Pi, Mac, and > Windows. Message me and maybe we can try to meet on a Discord channel. > Just seeing this now but this looks pretty useful. I once made a Pascal wrapper for Box2D but this looks like a better more complete solution. Do you have the Pascal unit for Chipmunk2D where we can download and try 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] Lazbuild error on Windows
> On Oct 28, 2021, at 9:39 PM, Dennis Lee Bieber via fpc-pascal > wrote: > > Are you actually running on a 32-bit system? You appear to have > installed a 32-bit compiler. I think I may have downloaded the 32 bit version of the compiler and then the 64 bit Lazarus! That would make sense it would fail then. Let me try downloading the correct version and I'll report back. If Lazarus installed the compiler also maybe I just need to update my paths so "fpc" points to the version in Lazarus... Thanks. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing Pascal Physics and Vectors
> On Oct 29, 2021, at 4:25 AM, Anthony Walter via fpc-pascal > wrote: > > Thanks for the interest Ryan. I am preparing to push my code to a public git > repository with a FOSS license. In order to get this out soon it will be > broken into a few releases. Nice let us know when it's finished. What I did some years ago was make a plain c wrapper around Box2D so that I could then call it from Pascal (it was c++ originally). I think the library you used is already C so it should be easy to call from Pascal anyways event without the OOP wrapper. Much better than Box2D which was C++ only. https://github.com/thealchemistguild/Box2DC Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazbuild error on Windows
Sorry I didn't look up high enough in the output to see this before. It looks like lazbuild can't find the correct version of the compiler that is packaged. I can confirm that path exists but I think the variable $Lazarusdir may be wrong. What could be wrong here? I got Lazarus via an installer so I don't know how else to set it up. PS C:\Users\Ryan Joseph\Desktop\Developer\pascal-language-server> C:\lazarus\lazbuild.exe pasls.lpi SetupCompilerFilename: The compiler path "$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe" => "C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe" is invalid (Error: file not found) Searching a proper one ... SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=fpc.exe File=C:\FPC\3.2.2\bin\i386-Win32\fpc.exe > On Oct 29, 2021, at 9:46 AM, Ryan Joseph wrote: > > I think I may have downloaded the 32 bit version of the compiler and then the > 64 bit Lazarus! That would make sense it would fail then. Let me try > downloading the correct version and I'll report back. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazbuild error on Windows
> On Oct 29, 2021, at 2:01 PM, Mattias Gaertner via fpc-pascal > wrote: > > Lazarus uses macros of the form $(LazarusDir) . > > Did you check the fpc path in Lazarus? > Tools / Options / Environment So what happened here is that I as a new user on Windows decided I needed the compiler first so I downloaded the most recent version 3.2.2. After that I wanted to use lazbuild and some Lazarus libraries so I installed that next. Problem was Lazarus uses "fpc" as the compiler path and due to the installation order that pointed to the newer version of FPC which wasn't compatible with the 3.2.0 units compiled in Lazarus. Maybe Lazarus should by default point to the version of the compiler that comes packaged with it? That would eliminate a bunch of the confusion I had and when I wanted to change the compiler version I would have had to set it explicitly myself and triggered the error but at least then I would know it was because of something I did. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String error on Windows
> On Oct 31, 2021, at 10:50 AM, Alexander Grotewohl via fpc-pascal > wrote: > > Because += is a mistake and hopefully it's irreparably broken. > > Does using just s:=s+';'; work? > I thought they were behind a mode switch called "c operators" or something but either way I don't see why Windows would disable them. They're all over my program which runs on macOS and I don't want to remove them (like that operator 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] String error on Windows
> On Oct 31, 2021, at 2:53 PM, Jonas Maebe via fpc-pascal > wrote: > > The compiler itself does enable them by the default on any platform. However, > the fpc.cfg file that gets installed with FPC on all platforms does enable > them by default (it contains -Sgic). Compile with -vt and check where the > compiler is getting its configuration file from. Thanks, I see -Sc now but I've always taken for granted it was always there. What confused me is that it's a command line option instead of a mode switch like other language features. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> On Oct 31, 2021, at 4:57 PM, Anthony Walter via fpc-pascal > wrote: > > As mentioned before, this library will be released to a git repository soon > with a FOSS license. It will be able to run on Windows, Mac, Linux, and Pi > including the new Pi Zero 2 W. > Thanks, please post when it's up. An open question I have with OpenGL based UI libraries is how (or if) composting happens. For example, are you rendering an entire window to a frame buffer and then updating that when one of the controls requests changes, or are you just drawing the entire window and controls every frame? I made a similar UI library which is loosely based on Cocoa but I didn't use any compositing so the entire window needs to redraw itself each frame. This is good enough for basic UI's in games but it's terribly inefficient so I wanted to tackle the problem of a composition layer (frame buffer) which updates only when controls request it and update only that portion of the window. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> On Nov 1, 2021, at 5:12 PM, Anthony Walter via fpc-pascal > wrote: > > I plan to add: Write a `redmond` win95 style theme. Write a few example > custom controls. Add modal window support and dialog box functions. > How are you doing themes? I made a MacOS 8 theme by slicing up tons of old screenshots and packing them into texture atlases then pushing them into a sprite batcher. I wonder if making a bitmap context backend when have been easier. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ExtractStrings by line in Windows
> On Nov 3, 2021, at 8:17 PM, Bart via fpc-pascal > wrote: > > Maybe use SomeString.Split([LineEnding'], ...)? > Split has an overload that takes an array of string as first paramter. Thanks, I guess I need to use a different way to work on all platforms. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Keeping current with FPC Source on gitlab
> On Nov 6, 2021, at 7:09 AM, James Richters via fpc-pascal > wrote: > > Do I need to use the source to re-install FPC every time I want to update it? > If so how is this accomplished? > You need to rebuild the compiler every time it's updated. It can installed to a "trunk" location so that it doesn't overwrite existing stable compiler releases. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> On Nov 5, 2021, at 10:41 PM, Benjamin Rosseaux via fpc-pascal > wrote: > > I'm curious to see how it compares with my vector-based UI framework stuff at > PasVulkan ( https://youtu.be/YR0KruyQbx4 ), where the GPU itself renders > everything by shader, where nothing is bitmap-based, if one ignores the 2D > vector signed distance field textures for fonts and so on. The CPU pushes > just roughly basic draw information to the GPU, where the fragment übershader > itself applies the corresponding design look with help of 2D SDF math in an > always antialiased way then. I really like the text rendering part. I've been picking away at that problem recently and it's pretty difficult to do correctly. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Inline function parameters
Is there anyway a function parameter could be inlined in FPC? This would go a long way in helping to parameterize functions that have tight loops in them. If there isn't I wonder if this is an area where the proposed "pure" function modifier could be used to make it possible. === type TSomeFunc = function: boolean; procedure DoThis(func: TSomeFunc); begin if func then ; end; function MyFunc: boolean; inline; begin end; begin DoThis(MyFunc); 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] Inline function parameters
> On Nov 7, 2021, at 2:17 PM, Jonas Maebe via fpc-pascal > wrote: > >> Is there anyway a function parameter could be inlined in FPC? This would go >> a long way in helping to parameterize functions that have tight loops in >> them. > > It's theoretically possible through constant propagation. I understand simple constant propagation cases but how does this apply to inlining entire functions? I think C++ can do this with closures so it's something worth looking in to for the future. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal
> wrote:
>
> And there you have it (simplified obviously). As long as the compiler can
> determine *at compile time* the code of the function (and the function is
> inlineable) it should in theory be able to inline it. This is true no matter
> if it's a function variable, a method variable (pointing to a non-virtual
> method) or an anonymous function. However if somewhere between passing in the
> function address and calling the function inlining does not work for one
> reason or the other (e.g. due to open array parameters which are currently
> not supported by inlining) then the compiler obviously can't inline the
> provided function either.
Interesting, so the inlining the containing function is the key. I guess if the
container were not inlined it would basically be like a generic where a new
function body would be generated which contained the inline function pointers
body with arguments replaced.
For example:
function Map_MultBy2(aArr: TLongIntArray): TLongIntArray;
begin
SetLength(Result, Length(aArr));
for i := 0 to High(aArr) do
Result[i] := aArr[i] * 2; { MultBy2 is inlined here }
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] Inline function parameters
> On Nov 8, 2021, at 11:20 PM, Sven Barth via fpc-pascal > wrote: > > I don't know what you mean with "new function body". If a function is inlined > its code is contained within the surrounding function and if it's not inlined > then nothing changes. > I mean if in theory you were to inline that function variables code into the function it would need to generate a new function (I guess the name also, so the entire thing) because the function being passed in could change on per-call basis (like a normal generic function). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> On Nov 9, 2021, at 1:09 PM, Sven Barth via fpc-pascal > wrote: > > No, because the function that is called with a function pointer needs to be > inlined itself (thus becoming part of its caller) so that constant > propagation works at all for the parameters. If a function isn't inlined then > there won't be any change and the passed in function variable will be called > as usual. I mean in theory if the compiler were to support inlining function pointers that is how it could be done. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Named optional arguments
This was discussed before some years ago with no conclusion (https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html) but I'd like to bring it up again. Can we consider extending the variant dispatch call named parameters to normal functions? The majority of the infrastructure is already there so it needs to merely be extended. This is what the syntax would look like: SetupCanvas(width := 500, height := 500, eventCallback := @HandleCanvasEvents, options := [TCanvasOption.VSync]); The reason for this is of course to handle functions with many parameters so we don't need to look at the function definition to know which params mean what thing. C# has effectively added optional named parameters along with other languages I use and I consider this a solid development at this point. My complaints come with languages like Swift where the parameter names are meant to be part of the function signature and really clutter up the language in my opinion so I'd like to avoid that by making it opt-in, like C#. The basic idea: - Opt-in design so if you name the first parameter in a function all following parameters must be named, and the inverse, if the first parameter is not named the following parameters can not be named either. - Consider the parameter name during overloading resolution so that even if the values are correct the names must match also. - Enabled with a mode switch? - Parameters can be specified in any order? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 26, 2021, at 3:31 PM, Michael Van Canneyt > wrote: > > That seems like a fake argument: Of course you need to look, because you need > the names ? > Secondly, the IDE will simply tell you what the names are when the cursor is > on them. It's mainly useful when reading code so you don't need to review the function definition, using code tools or any other method. I've been enjoying it in other languages when it's not compulsory and FPC already supports the syntax so I thought it would be 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] Named optional arguments
> On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote: > > It's mainly useful when reading code so you don't need to review the function > definition, using code tools or any other method. I've been enjoying it in > other languages when it's not compulsory and FPC already supports the syntax > so I thought it would be low hanging fruit. I wanted to add a little case study from the compiler itself to see how to make some really long function more readable. 1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor. Either way you're going to be spending time try to figure this one out. candidates:=tcallcandidates.create(symtableprocentry,symtableproc,left,ignorevisibility, not(nf_isproperty in flags),cnf_objc_id_call in callnodeflags,cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],cnf_anon_inherited in callnodeflags,spezcontext); 2) Adding some line breaks helps a lot but it's still not clear what some of the params are unless you jump to the function definition or get a tool tip on the constructor and then even so you need to count the params to see which is which, and this takes time and effort. candidates:=tcallcandidates.create(symtableprocentry, symtableproc, left, ignorevisibility, not(nf_isproperty in flags), cnf_objc_id_call in callnodeflags, cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], cnf_anon_inherited in callnodeflags, spezcontext); 3) Clearly defined names each on their own line is obviously the easiest to read at a glance. Even if no line breaks were present the editor could style the param names a different color and they would be easy to read. candidates:=tcallcandidates.create(sym:=symtableprocentry, st:=symtableproc, ppn:=left, ignorevisibility:=ignorevisibility, allowdefaultparas:=not(nf_isproperty in flags), objcidcall:=cnf_objc_id_call in callnodeflags, explicitunit:=cnf_unit_specified in callnodeflags, searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], anoninherited:=cnf_anon_inherited in callnodeflags, spezcontext:=spezcontext); 4) For contrast here's a bad example of named params which we want to avoid. Languages like Swift encourage this kind of thing and I think it's less readable and adds clutter. pt := MakePoint(x:= 1, y := 2); // cluttered and doesn't add any useful information pt := MakePoint(1, 2);// normal calling syntax, easy to read and clean Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 27, 2021, at 5:00 PM, Sven Barth wrote: > > The compiler does not know which routine is called upon parsing the parameter > declarations (which would mean that error reports would need to be deferred > until the lookup of the routine failed). My idea was to not actually have it affect overloading except in the case where the param names don't match which would ignore the call (so in your example below nothing changes). Otherwise if the name was actually part of the overloading we would have to allow functions with the same parameter type but different names, i.e.: procedure Foo(Arg1: String = ''); procedure Foo(Arg2: String = ''); and that would be a big change to the language and have all sorts of implications. So it's really just a minor hint to make the call more readable in the case of long function names. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 27, 2021, at 5:03 PM, Sven Barth wrote: > > candidates:=tcallcandidates.create(sym:=symtableprocentry, > st:=symtableproc,ppn:=left, > ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in > flags),objcidcall:=cnf_objc_id_call in > callnodeflags,explicitunit:=cnf_unit_specified in > callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], > anoninherited:=cnf_anon_inherited in callnodeflags,spezcontext:=spezcontext); > > So you've gained *nothing*. I wouldn't say nothing but it's still really hard to read. My only thought there was that it would open the door for some syntax coloring on the parameter name so you can scan them easier. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal > wrote: > > What do you mean? Is there already some call by arg names in some > mode(switch)? I mean all the plumbing is there so the feature could easily be extended from IDispatch to work with normal function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 7:01 PM, Sven Barth wrote: > > Anything that relates to picking functions *must* be part of the overload > handling. You can easily see this with your named argument proposal when not > all arguments are named (and then the compiler also needs to check that > unnamed parameters aren't used for named ones as well, this gets more > complicated if the overloads have different argument names). > > You should have already learned this lesson when I pointed you in the right > direction for the implicit function specializations. > I'm not proposing we necessarily allow the reordering of arguments or allow omitting of values. In the simplest scenario they're just optional names but the parameters still need to be provided in the correct order. Very simply to make reading long functions easier at the call site. Yes I understand that the overloading happens after parsing. In your first example if arbitrary order was allowed new overloading rules would need to be applied so that you got an ambiguous function error. Not a big deal to resolve that I would think but it doesn't have to go in that direction either. Personally I'm not in favor or changing the overloading rules, just that some calls were easier to read by glancing over them. In fact I have seen IDEs which have a feature which inserts the param name into the editor for this very reason. As an aside, is it even useful to allow arbitrary parameter order? I don't recall ever wanting this and would open the door to some functions being called in different order across a codebase, which sounds like a big problem unto itself (C# allows this btw). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Dec 1, 2021, at 4:56 AM, Sven Barth wrote: > > If you don't allow to skip parameters then this feature can be considered > absolutely useless. Who would voluntarily write more when many users already > cry about Pascal being so verbose? I thought the option of improved readability made sense for a language like Pascal. > >> Yes I understand that the overloading happens after parsing. In your first >> example if arbitrary order was allowed new overloading rules would need to >> be applied so that you got an ambiguous function error. Not a big deal to >> resolve that I would think but it doesn't have to go in that direction >> either. >> >> Personally I'm not in favor or changing the overloading rules, just that >> some calls were easier to read by glancing over them. In fact I have seen >> IDEs which have a feature which inserts the param name into the editor for >> this very reason. > > You still don't get it. This is not about "changing the overloading rules" > but about this feature fitting into the existing overload selection > functionality. No I really do understand what the situation is if you can believe me. I don't see this is a big problem or too complicated to tackle but if you really dislike the idea so much then we'll leave it at that. There's more important potential features to work on anyways. btw kind of off topic did you like my idea of default properties for records so we can implement smart pointers? I got a good chunk of that done months ago but never heard anything about 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] FPC and WebAssembly
> On Dec 24, 2021, at 8:13 PM, Michael Van Canneyt via fpc-pascal > wrote: > > Our little contribution to a Merry Christmas for everyone... Nice work. I have a hard time wrapping my head around this. Can you just write plain HTML to STDOUT using writeln and that's enough? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Case statement for class introspection
I saw a new syntax in Swift which I thought was clever and fits a pattern I've seen before. Basically it's a case statement for class types which lets you branch depending on which class type the class instance is at run time. I wonder if this could be implemented in FPC? The syntax would be kind of clumsy though since you can't declare scoped variables in Pascal so you would need to do lots of casts but it's still cleaner than the equivalent code as if statements. = case monster of TZenChan: TZenChan(monster).DoThis; TPulPul: TPulPul(monster).DoThat; otherwise monster.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] Case statement for class introspection
> On Jan 15, 2022, at 8:30 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>> I saw a new syntax in Swift which I thought was clever and fits a pattern
>> I've seen before. Basically it's a case statement for class types which
>> lets you branch depending on which class type the class instance is at run
>> time.
>
> I think Scala did it before Swift.
What did it look like? Seems like an obvious feature any OOP language should
have.
Swift has a compound switch statement which does lots of things. It's a little
messy but it accomplishes this well. For example here they have a "case is" and
"case let _ as" which tests for class type or casts to a local variable using
"as".
switch object {
case is Message:
break
case let content as MessageContent:
break
case let attachment as Attachment:
break
default: break
}
Problem for Pascal is how to handle the casting mess. C languages (and Delphi
now I guess) can do inline variable declarations to avoid the casting.
Come to think of it this a similar problem with for-loops where you want to
loop over a collection of only certain types. For example:
for monster in monsters do
if monster is TZenChan then
TZenChan(monster).Dothis;
Swift does something similar as the switch which would look kind of like this:
for case monster as TZenChan in monsters do
TZenChan(monster).Dothis;
That syntax is not so nice but I like they're trying to help us manage class
introspection using existing language constructs.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 15, 2022, at 3:24 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I don't see how an inline variable helps with the casting mess. You'll
> always need a cast.
>
> What I do is Var
> MyInstance : TObject;
> MyNeededClass : TMyNeededClass absolute myInstance:
Yes that's the best option.
Anyways, the case statement in FPC allows for strings which basically fold down
into an if-else statement for comparing strings and this same logic could be
expanded for class types. Seems like a smart extension to add but does the
compiler team support this?
Something like this:
case o.ClassType of
TObject: writeln('TObject');
TInterfacedObject: writeln('TInterfacedObject');
end;
Converts to:
if o.ClassType = TObject then
writeln('TObject')
else if o.ClassType = TInterfacedObject then
writeln('TInterfacedObject');
There is a possibility for using "as" operator also though
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 16, 2022, at 9:21 AM, Ryan Joseph wrote: > > There is a possibility for using "as" operator also though oops I mean "is" operator. Not sure if these are technically different from ClassType = ClassType though... Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 16, 2022, at 2:35 PM, Michael Van Canneyt via fpc-pascal > wrote: > > > They are. > > No "is", because then the order of the label will start to matter, and that > runs contrary > to the case statement's intent. oh of course they are, I don't know why I forgot that. :P Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
I had some fun today on my day off and managed to actually implement this based
on the if-statement based string case labels. Is the compiler team interested
in this feature? I think it's a clearly useful addition to OOP and an
appropriate new use of the case statement.
https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref
Here's an example of what I did. To keep it simple you use "ClassType" to
branch off of possible class types.
o := TInterfacedObject.Create;
case o.ClassType of
TObject: writeln('TObject');
TInterfacedObject: writeln('TInterfacedObject');
TAggregatedObject: writeln('TAggregatedObject');
otherwise
writeln('OTHER: ',o.ClassName);
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 16, 2022, at 8:38 PM, Marco van de Voort via fpc-pascal > wrote: > > What does it print in this case? I mean tobject matches, and > tinterfacedobject too. > > The most logic solution would be to only run the most specialized case? It would print the name of the class if it didn't exist in the list. It's an incomplete code snippet but if the class was another type it would be captured there of course. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 16, 2022, at 8:18 PM, Ryan Joseph wrote:
>
> https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref
I just realized too late that the way I implemented this may be not the best
idea. If the class type had an ordinal representation then you could use a
normal case statement instead of making a big if-else block and doing equality
comparisons for each type. That would be faster right?
Assuming the memory address of the type worked you could do something like this
behind the scenes:
case PtrUInt(o.ClassType) of
4500656856: writeln('TObject');
end;
If so, I would have to rethink this then and come back to it 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] Case statement for class introspection
> On Jan 16, 2022, at 9:01 PM, Ryan Joseph wrote:
>
> case PtrUInt(o.ClassType) of
>4500656856: writeln('TObject');
> end;
I may have spoken too soon and without thinking the through clearly (it's
getting late here!). For this to work we would need a unique ID in the RTTI,
right? I don't think that exists so unless it does we need to do equality
comparisons for each case.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 16, 2022, at 11:15 PM, Sven Barth wrote:
>
> The class type already is a unique "ID" for each class type when doing an
> equal comparison. You can essentially take the address of the VMT as the
> constant values that the loaded value is compared against.
Does that look something like this then? and if so, this is better then doing
the if-statement block, like string case statements?
case PtrUInt(o.ClassType.ClassInfo) of
PtrUInt(TObject.ClassInfo): writeln('TObject');
end;
Question then is how you get the VMT address as a constant 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] Case statement for class introspection
> On Jan 17, 2022, at 1:55 PM, Sven Barth wrote: > > Question then is how you get the VMT address as a constant at compile time. > > I'll need to get back to you with that. > I didn't test yet but I think what you're saying is that VMT writer would need to have generated this address in advance of doing tcasenode.pass_1, which could presumably get this address in some integer form. Is that basically what you're thinking is possible? If it's a big problem I guess the question is if the if blocks are really that bad compared to alternative ( I would need to basically redo the entire thing also). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 17, 2022, at 5:09 PM, Sven Barth wrote: > > The VMT writer already does that, cause the VMT pointer is required for each > constructor call. > The pointer to the VMT table is just PVmt(self) right? If I make a program and do: writeln(PtrUInt(TObject.ClassType)); the address changes every time the program reloads (as expected) so how do you use a constant memory address which would map to 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] Case statement for class introspection
> On Jan 18, 2022, at 5:28 AM, Sven Barth wrote: > > The values will have the same differences between each other upon each start > so ideally this would work anyway, but if one also throws dynamic packages > into the mix things would get messed up. So better stay with the if-clauses. Here's my issue and feature branch linked + tests. Please leave any comments since I wasn't 100% sure in a few places. https://gitlab.com/freepascal.org/fpc/source/-/issues/39535 Now that the compiler is moved to GitLab do you prefer merge requests? I assumed no and that it would clutter up the system but I'll make a merge request if you want. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 19, 2022, at 1:26 PM, Sven Barth wrote: > > We also take merge requests. If you have a fork anyway, then a merge request > is probably easier. Though you need to have your repository set up to use > rebasing instead of merging, see here: > https://wiki.freepascal.org/FPC_git#Update Sorry I'm not following. Before starting this branch I did a pull from the main branch so I'm up to date. What other steps do I need to do? If I do a "git pull --rebase" on the feature branch does that even do anything? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 19, 2022, at 4:15 PM, Michael Van Canneyt > wrote: > > It's explained in the page that Sven referred to ? > > It's only when you merge into your feature branch from the main branch that > you will see an effect. Still not following this. Do you need me to do a pull-rebase from main and then make my pull request? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> On Jan 19, 2022, at 4:19 PM, Ryan Joseph wrote: > > Still not following this. Do you need me to do a pull-rebase from main and > then make my pull request? I used git at work everyday but I'm still a newbie in many ways. Reading this now but I'm confused because it seems too late. Please provide exact steps. :) https://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
