10);
where the vec2 type has operator overloads for common operations? This kind of
thing is very common in graphics math and I bet there's some clever ways you
could compress that operation down. Curious how the C++ compilers do this
also...
Regards,
d of thing.
I'm not saying any of this to discourage the idea though since I think it's
interesting.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
cially said absolutely no to the idea of overloading
the "." operator so I tend to think this idea won't go far.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ly used with properties currently).
I would say an operator would be most likely to be accepted, such as:
class operator Call();
because it could be overloaded easily and doesn't present any new syntax.
Personally I like this idea but I tend to f
Thank you for continuing work on this, we all really appreciate your efforts.
> On Dec 23, 2021, at 1:16 AM, Blaise--- via fpc-devel
> wrote:
>
> 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
> reported for:
Regards,
.
>
>> How did Free Pascal/Jonas accomplish this in the LLVM backend?
>
> FPC generates LLVM IR which is then compiled using clang. It does not link to
> the LLVM libraries in any way.
>
That's what I thought but that's certainly beyond the scope of what I could do.
?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
nk version
within a month or so even.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I see the old bug reporter has been taken down now. Can anyone explain how to
see my old bug reports now? I went to
https://gitlab.com/groups/freepascal.org/fpc/-/issues and filtered by my
username "genericptr" but nothing came up.
Regards,
R
> On Jul 17, 2021, at 4:09 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> Yes.
ok, thanks.
https://bugs.freepascal.org/view.php?id=39238
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepasc
eld
containing "genericptr"? I guess this process is automated. I have a number of
open reports I'd like transferred over.
Does this mean the Mantis reporter is going be shut down or are users simply
encouraged to not post new reports there?
Regards,
Ryan Joseph
___
% of the dev world is using GitHub now
so it's a pity to have to learn new tools if we don't have to. I'm very happy
with GitHub myself and use it often.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.
hose with a github account can normally
> also use that account to log in with gitlab, see the gitlab login page.)
I thought the plan was to move to GitHub? I never used GitLab before so can you
explain the reasoning here?
Regards,
Ryan Joseph
_
> On May 10, 2021, at 3:18 PM, Ryan Joseph wrote:
>
> Lets focus on the record approach for now then. I don't think I know enough
> to understand where are the pitfalls are.
This was another thing I wanted off my mind since a couple years ago already so
I got a prett
> On May 15, 2021, at 10:49 AM, Ryan Joseph wrote:
>
> Also it looks like ChangeOwnerAndName isn't making the compiler happy.
Sorry for the noise, I figured out it was because the name had spaces. How
should I make the name then? I'm doing this for now which is certainly unique
> On May 15, 2021, at 10:27 AM, Ryan Joseph wrote:
>
> Looking at this again today and I have yet another question to confirm. I
> create one of the types using ctypesym.create but the others were just
> references from the system unit. We only want to change owner of the sym
ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
end;
if newtype=nil then
internalerror(2021020904);
result:=newtype;
end;
Regards,
Ryan Joseph
___
fpc-devel maillis
as FOwner nil so calling TFPHashObject.ChangeOwner
crashes. Did I not make the symbol correctly or do I need to do something
before calling ChangeOwner?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/
making this
possible as return type means we can chain the calls together and make it a one
line statement. It's just a nice thing from Objective-C which we use heavily to
manage memory and it works very well.
Regards,
Ryan Joseph
___
fpc-d
y useful if the ^ "operator" is hoisted as well.
I meant to say pointers to records so yes the ^. would need to be there. I
haven't looked into how this would be implemented but I got it working with
classes for now. It would be nice to make pointers to records be possible for
smart pointers so I'll look into that later.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
should we decide
to go this route for "start pointers".
https://bugs.freepascal.org/view.php?id=38872
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
t. Records aid
this by not allowing casting but you could enforce some kinds of checks for
managed classes if you wanted to. Doesn't seem like a deal breaker to me if you
add new type rules for passing/assigning.
Regards,
Ryan Joseph
___
fpc
I need to think of something else.
3) What about allowing type pointers as default properties? This should be
possible and is in the spirit of the feature anyways, that is ref counting. We
may need to add some additional logic to properties (just interna
at exactly do you mean? Please post a single line code snippet even.
Thanks.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
in C++.
https://github.com/genericptr/freepascal/wiki/Default-property
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
can't do this in Pascal without a new
permissive return type.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
se the same set of circular references exists but I'm not sure about
your concern about mixing managed types yet.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
could
easily cause hard to fix memory leaks just like normal classes. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
class
private
someClass: TMyObject;
public retained
someClass: TMyObject;
otherClass: TObject; // this would give an error because class is not
compiled for ARC
end;
{$RETAINED-}
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On May 7, 2021, at 9:40 AM, Benito van der Zander via fpc-devel
> wrote:
>
> the classic Delphi way was to use an interface for freeing. It only requires
> one type and nothing blows up.
>
That's clever but even try..finally is less overhead.
Regards,
an implement and it
works with management operators already. This covers 90% of the use cases for
memory management and doesn't introduce all sorts of unpredictable stuff.
What about that?
Regards,
Ryan Joseph
___
fpc-devel maillist -
an "Any"
return type to Pascal which is a type that is compatible with any class? This
relies on an event loop that can capture this garbage and dispose of it but it
goes a LONG way in helping with common memory management problems.
Regards,
Ryan Joseph
___
e years ago already and it
got rejected in favor of record operators.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On May 6, 2021, at 7:14 PM, Ryan Joseph wrote:
>
> This can be detected at compile and at least give a warning. "a" is a member
> of TR and the element type of "a" is TR, then we're assigning TR to said
> array. It's that simple I think.
It also
:= x;
> end.
This can be detected at compile and at least give a warning. "a" is a member of
TR and the element type of "a" is TR, then we're assigning TR to said array.
It's that simple I think.
Regards,
Ryan Joseph
___
it). it's
kind of frustrating that we have ref counted types but that isn't extended to
classes. Hopefully that's something we can tackle one of these days...
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https
e
the code to run at the end of the block? My understanding of the defer keyword
is that is was just a fancy way to move some code into a block which always
gets run with a function exits.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@li
s. I'll start using try..finally and see how that
works for me.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
even affects ref counting of existing types because it all
it does it move the statement to the end of the block. Maybe I'm not
understanding your point though.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https:/
ksforgeeks.org/defer-keyword-in-golang/
procedure DoStuff;
begin
obj := TObject.Create;
defer objects.Free;
while true do
begin
// don't worry, obj will be freed safely
if not obj.TrySomething then
exit;
end;
end;
Regards,
Callback = function(a: T; b: U): integer;
function Compare(a: TSomeClass.TElem; b: string): integer;
begin
result := 1;
end;
generic procedure DoThis(aClass: specialize TAnyClass; callback:
specialize TCallback);
begin
callback(1, 'string');
end;
begin
DoThis(TSomeClass.Create, @Comp
> On Apr 22, 2021, at 9:52 AM, Ryan Joseph wrote:
>
>> Got this all integrated and put up the changes to
>> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
>> final review. :)
>
> The next thing to do now is to handle a memory leak.
e created and destroyed with
absolutely no value to the program whatsoever.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e the real closures.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
for all strings types by default right?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote:
>
> Got this all integrated and put up the changes to
> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
> final review. :)
The next thing to do now is to handle a memory leak. From the bug
ric*
record inheritance in Pascal. Is this seen as a problem or something that
people would make a generic inheritable record type? Without this we have
stupid things like having to reimplement TVec2, TVec3, TVec4 etc...
because we can't simply inherit from the previous type.
Regards,
> On Apr 20, 2021, at 11:38 PM, Sven Barth wrote:
>
> All four string types provide built in > and < operators:
On a side note how do you even make overloads (or type helpers for that matter)
for short strings because String[10] isn't the same type as String[100]?
Regard
that's
why I wanted to fix it. Same with Objects as Benito has just pointed out again.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
nored without explanation since 2019. This is still the only way we
can use operator overloads for generic objects and objects are the only way to
have record inheritance so it's a critical missing feature in my opinion.
Regards,
Ryan Joseph
___
fp
): boolean;
class operator in (left: TSelf; right: TRight): boolean;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
strictions on the type of operator.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Apr 16, 2021, at 2:44 AM, Sven Barth via fpc-devel
> wrote:
>
> Yes, do that for now.
>
Got this all integrated and put up the changes to
https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
final review. :)
Regards,
> On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote:
>
> It works but it thinks this array is array of const also so it's too strict I
> believe.
>
> ['aaa', 'bbb'];
About this, shouldn't we just be doing this? Any array constructor that has
elements which are which are inco
ck to reject
array of const. Everything else is done AKAIK unless we discover more bugs in
the tests (which I've uploaded on the bug tracker).
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepa
lso so it's too strict I
believe.
['aaa', 'bbb'];
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I'll just leave it as is for now then. By the time the overloading happens
it must know the array constructor is array of const but it should ideally be
known by the time tarrayconstructornode.pass_typecheck is executed.
Regards,
Ryan Joseph
___
fpc
> On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote:
>
> Just checked and pass_typecheck is called before overloading but
> ado_IsVariant is simply never set for that array. In tarraydef.GetTypeName
> you can see that "array of const" is associated with many flags so
> On Apr 10, 2021, at 9:18 AM, Ryan Joseph wrote:
>
> I checked before and here's what I got. Maybe pass_typecheck hasn't been
> called yet? If not I'll have to reproduce that code and determine how it
> knows the elements are not uniform. Thanks.
Just checked and pass_type
writeln('ado_IsVector: ',ado_IsVector in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsGeneric: ',ado_IsGeneric in
tarraydef(caller_def).arrayoptions);
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists
meter to a generic
> function (those will be unnamed as well).
Maybe the email didn't go through? How to identify this "array of const
constructor" type. I want to reject these for implicit specialization but I
can't identity them.
DoThis([
1,
'string',
'c',
TObject.C
sue I raised in the other email? Once
that's done I'll submit another very patch. Getting very close now unless I
missed some test cases...
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org
'string',
'c',
TObject.Create
])
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
st_longstring:
internalerror(2021040801);
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_t
ight now (and probably not very
correct in design). Moving that to a public space would be sensible also I
think.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote:
>
> Ok, so with $H+ constant strings will be specialized as AnsiStrings. And
> there is another unicode string mode I should do a similar thing with? Also
> if you happen to know where I can get the state of $H+ that w
end;
begin
DoThis(1,1); // DoThis
end.
=
generic procedure DoThis(a:T; b: word);
begin
end;
generic procedure DoThis(a: word; b: T);
begin
end;
begin
DoThis(1,1); // Can't determine which overloaded function to call
end.
=
Regards,
lar thing with? Also if you
happen to know where I can get the state of $H+ that would be helpful otherwise
I need to track it down in the debugger. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.fre
newtype:=search_system_type('UNICODESTRING');
end;
'Hello World' is parsed as st_shortstring so we use System.ShortString for
specialization. Given that I don't think I need to do anything with $H+.
Regards,
Ryan Joseph
___
));
These both appear to be equal as far as is_better_candidate is concerned.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
er_candidate res = -1
Writeln(Test(42)); // is_better_candidate
res = 1
Writeln(Test(String(42))); // is_better_candidate res = -1
I'm struggling to see how the operator influenced the result. Res is -1 in both
cases so how do we know which Test we want t
nd;
begin
Writeln(Test('Hello World', 1));// prints "2"
end.
====
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
wants to provide some explanation as to where the colors were added
I'll enable them on mac and test them myself.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
er can just replace the call with
> the relevant string at compile time, but that's a long way off!
That would great. Hopefully this gets finished some day.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https
,#&033,'[',0,'m');
end;
// prints a blinking, bold red text on a white background
PrintColor([ANSI_BACK_WHITE, ANSI_FORE_RED, ANSI_STYLE_BLINK, ANSI_STYLE_BOLD],
'Hello World');
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@
> On Nov 22, 2020, at 8:57 AM, Jonas Maebe via fpc-devel
> wrote:
>
> It's only enabled on Linux and Windows currently.
Why is that? Mac has colors in the terminal also.
Regards,
Ryan Joseph
___
fpc-devel maillist
ere any
> particular reason why "Warning" is in magenta? Normally the convention is
> that it's yellow (and "Error" in red). Granted, it's purely cosmetic.
>
> Gareth aka. Kit
What version of the trunk is this in and what's the flag to enable it? My trunk
is maybe 30 d
> On Oct 13, 2020, at 7:06 AM, Michael Van Canneyt via fpc-devel
> wrote:
>
> This is planned, we wait for 3.2.2 and then we move to git.
will it go on GitHub also and replace the old mirror site we've been using or
will you host it on the free pascal website?
Regards,
> On Oct 1, 2020, at 10:37 AM, J. Gareth Moreton via fpc-devel
> wrote:
>
> In situations where a nested function has no parameters, is it feasible and
> beneficial to programmatically merge it into the main procedure
What do you mean by "merge"? Like inlining?
Reg
> On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel
> wrote:
>
> It will work if you start your build with FPC 3.2.0 instead of 3.0.4.
yes, that worked. thanks. 3.0.4 is officially not possible to use for
bootstrapping I guess.
Regards,
ll as this one
which seems to be causing the problem. I'll wait until those guys resolve it.
Thanks.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
f
you use the correct run time library.
Fatal: Compilation aborted
make[5]: *** [ppcx64] Error 1
make[4]: *** [next] Error 2
make[3]: *** [ppc1] Error 2
make[2]: *** [cycle] Error 2
make[1]: *** [compiler_cycle] Error 2
make: *** [build-stamp.x86_64-darwin] Error 2
Regards,
R
> On Sep 17, 2020, at 7:23 PM, Ryan Joseph wrote:
>
> Certainly. I think it depends on what the solution is. It's a known short
> coming of the [] property and if the solution is as easy as allowing a var
> param variant then maybe it's feasible.
I'm remembering now I
I sense they want to avoid feature bloat
> that became a bit of an issue with Delphi.
Certainly. I think it depends on what the solution is. It's a known short
coming of the [] property and if the solution is as easy as allowing a var
param variant then maybe it's feasible.
Regards
and autoderef
writeln('x: ', a[0].x);
// WRONG: to copy the record out of the array we need to derefence the pointer
r := a[0]^;
writeln('r.x: ', r.x);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
osed to redeclare a pointer to T:
type generic TMyArray = record
type
TP = ^T;
public
Data: TP;
Length: PtrUInt;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
reference counted type now but as I mentioned that are some drawbacks, some of
which I'd like to correct if the compiler team allowed it.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/
s.
2) I think for the [] operator to work with arrays of records you need to
return pointers and enable the "autoderef" modeswitch to avoid the deref syntax
(which is how dynamic arrays always work). Are there performance implications
of this or do we get the same code as dy
/debugger and I go into how that works with Pascal but obviously you
could do this with Lazarus (I prefer the debugger in VSCode so I use that when
I'm doing debugger heavy work).
https://www.youtube.com/watch?v=eqUCPJYoEAo
Regards,
Ryan Joseph
eone help me setup so I can start to study the code and see how I can
> start working on it?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
elf (this was discussed at
length with Sven) so at the very least =, >, < etc... should be supported. If
the first patch ever gets accepted I would like to extend it to do that also.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lis
uld cause
extra scrutiny over the feature which was already in question. I have other
patches which are not contested at all and are just sitting there for months so
I think there's a very slim chance advanced objects (in any form) gets accepted
at this point.
r Svens request). If there are any other code
reviewers available I can finally get it cleaned up and submitted. specialize
CARD(variable) is really verbose in ObjFPC mode so it would be nice to
get this cleaned up.
https://bugs.freepascal.org/view.php?id=35261
Regards,
ton you'll get a URL like this:
https://github.com/graemeg/freepascal/compare/master...genericptr:static_array_init
That shows the commits and changed files as a diff. It happens all
automatically so all you have to do is push changes (in your git client or what
ever you use).
Reg
function, but it's nowhere
> near ready for general use.
Do you have GitHub? if so put your work into a feature branch and we can browse
your changes by looking at diffs.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists
.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Apr 26, 2020, at 4:02 PM, Michael Van Canneyt
> wrote:
>
> Fixed-length arrays are the only practical use I can think of.
I think you're right. Here's what I'll say next time: They're for composing
types of dynamic size at compile time. :)
Regards,
VALUE : 0 : 4);
end;
begin
Test();
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
r. ;)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
:)
https://bugs.freepascal.org/view.php?id=36350
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
1 - 100 of 328 matches
Mail list logo
