that doesn’t
// actually exist at any static address.
a := specialize TList.Create(10);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
sure why there would be any resistance to this. Making a mode switch
for “advanced objects” seems sensible enough to me (unless you want to make a
whole new keyworld like “struct” or something).
Regards,
Ryan Joseph
___
fpc-devel m
11:35 AM, J. Gareth Moreton
> wrote:
>
> Ryan Joseph requested that I reply to this to show that it's in the mailing
> list. Hopefully the technical problems can be resolved!
Regards,
Ryan Joseph
___
fpc-devel maillis
).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
gt; fpc-devel maillist - fpc-devel@lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
>>
>
I’ve tried to resend a message 3 times now but I still don’t see it. Not sure
if everything’s working ok.
Regards,
Ryan Joseph
_
> On Jun 12, 2019, at 9:39 AM, Ryan Joseph wrote:
>
> { resending this, I think it got lost during the server move since I’m not
> seeing it in the archives }
{ I think the server is back up so I’m resending this for the 3rd time to see
if it gets through. }
Another question.
don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ut at the class
level (compile time). TObject has ClassType but a compile time construct would
be a nice companion.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
);
writeln('create: ', sizeof(result^));
end;
constructor TBase.Initialize;
begin
writeln('create tfoo')
end;
type
PChild = ^TChild;
TChild = object (TBase)
y: string;
end;
var
c: PChild;
begin
c := PChild(TChild.Create);
Regards,
gt; c: TObject;
> begin
> c := TObject.Create;
> end.
>
> Did you try with trunk? Cause I fixed something related to that a few weeks
> ago.
>
Yeah in trunk it says impossible overload for equal types.
Regards,
Ryan Joseph
__
left: TSelf; right: integer): TSelf;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
create tfoo')
end;
type
PChild = ^TChild;
TChild = object (TBase)
y: string;
end;
var
c: PBase;
begin
c := TChild.Create;
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt
> wrote:
>
> Records do. Objects not.
Ooops forget the mode switch. :) I’m seeing objects have properties. Are you
sure? Maybe they got added recently.
Regards,
Ryan Joseph
_
> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt
> wrote:
>
> (same for properties, BTW)
Just noticed this. Yes, why don’t records have properties? Seems like an
omission.
Regards,
Ryan Joseph
___
fpc-devel maillist
ted to extend that to the legacy “new” function
which just looks wrong now as a result. Is there anything we could do to make
“new” more modern look like classes?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
right: TObject): TObject;
begin
writeln('custom :=');
end;
var
c: TObject;
begin
c := TObject.Create;
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e; (* boom! *)
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
al operators? Sorry I don’t understand. The := operator is
already overloadable but the left side isn’t passed in. Same goes for other
binary operators where the destination variable is not passed it even though
that could have been useful information.
Regards
> On Jun 9, 2019, at 9:17 PM, Ben Grasset wrote:
>
> On Sun, Jun 9, 2019 at 11:23 AM Ryan Joseph wrote:
> var
> a: ^integer;
> begin
> DoThis(a0);
>
> I'm assuming "a0" was just a typo there?...
>
typo.
Regards,
Ryan Joseph
___
is is just a historical relict
the didn’t stand up to the test of time.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
) then
; // allocate new
else
; // delete old and return new (or mutate)
end;
var
c: TMyClass;
begin
c := 100; // c := TMyClass.:=(c, 100);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
> On Jun 9, 2019, at 11:25 AM, Florian Klämpfl wrote:
>
> Yes, but this has *nothing* to do with the output of -vp. Nothing.
Sorry my mistake.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal
teger;
begin
DoThis(a0);
He just wants function parameters to declare the new pointer type inline.
procedure DoThis(i: ^integer);
begin
end;
var
a: ^integer;
begin
DoThis(a0);
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.fr
so.
Ah, I see now. That’s even better. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
a to make generics a mode switch. That probably will improve compiler
times.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
other voices on this would be welcome.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
=
All the postfix operator allows is “.” access. That’s like 90% less intrusion
into the compiler. Much smaller can of worms. Sorry C++ had the smarter idea
here. Limit the access to “.” and if the user wants assignments or equality
etc… they overload other operators. Please tell me how
s of expressions containing specializations that mode ObjFPC
> supports.
Then maybe it could be optional within type declarations? Delphi mode achieves
this so I think ObjFPC could also. Yet another modeswitch like “autoderef”? :)
Regards,
Ryan Joseph
__
> On Jun 7, 2019, at 4:47 PM, Sven Barth via fpc-devel
> wrote:
>
> Am 07.06.2019 um 22:41 schrieb Ryan Joseph:
>> Does that make sense? I’d like to scratch the idea of default properties and
>> do this instead if it was permitted.
> No. FPC is not going down tha
an exception to the rule?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
dition to type declarations though because it makes it
more clear what they are.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
nagement operators …
class operator postfix: T;
end;
class operator TAuto.postfix: T;
begin
result := m_obj;
end;
var
a: TAuto;
begin
writeln(a.ClassName); // a.m_obj.ClassName
Regards,
Ryan Joseph
___
fpc-devel maillist - f
are just as "inline", I'd say) work
> just fine.
>
I don’t get this either. It feels to me like ^ is a modifier more than an
actual new type. That’s just me feeling though as a long time Pascal programmer.
Regards,
Ryan Joseph
___
fp
> On Jun 2, 2019, at 4:36 PM, Sven Barth via fpc-devel
> wrote:
>
> Am 02.06.2019 um 16:39 schrieb Ryan Joseph:
>> I just tried to declare these 2 procedures in 3.3.1 and got an error. You
>> can declare them in the reverse order with no problem. A bug?
>>
>
;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e);
end;
generic procedure DoThis(msg: T);
begin
writeln('DoThis:',msg.ClassName);
end;
begin
DoThis(TMyClass.Create);
DoThis(TObject.Create);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://l
> On May 30, 2019, at 4:18 PM, Ryan Joseph wrote:
>
> I didn’t realize generic functions were in the trunk. I’m not sure I got this
> implemented properly so it requires some code review but can we try to
> include “implicitfunctionspecialization” mode switch in the next r
remarkably well (nested proc vars already do all the work required but they
used records for the backing store).
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Operator overloads simply aren’t
enabled for objects because apparently they’re a legacy syntax but as you
pointed out they’re still useful. Being able to use subclassing for TVec2 ->
TVec3 -> TVec4 objects would be really useful. I hope the compiler team
reconsid
ads it’s not possible.
Also, since we’re not getting ARC classes it looks like, management operators
for objects would make it possible to use a base class for “boxing” managed
classes.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel
}
I thought FPC was trying to keep them alive? Objects are still the only way to
do inheritance for records but they lack operator overloads. The syntax for
new/dispose certainly feels legacy but that’s not as important as the class
operators.
Regards,
routes to variety of different functions based on the type
and could simply be extended like it was for records. I liked the idea of
management operators for classes because users can opt in for classes that
aren’t doing performance critical stuff.
Regards,
Ryan Joseph
_
I was thinking
enabling management operators for classes would have basically the same
performance impact as those compiler types (which is actual ARC in Pascal
unless I misunderstand).
Regards,
Ryan Joseph
___
fpc-devel maillis
.g. to a TNotifyEvent or store it in a
> TStringList's Objects property.
Isn’t this what fully ARC languages like Swift do though? I would think this
would be an interesting option to at least be available for particular use
cases.
Regards,
Ryan Joseph
ult properties.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
to support
classes also. I already spent a good amount of time working on “default
properties” but that was done in leu of the fact that only records support
management operators.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel
TMyObject.Destroy;
begin
end;
var
o: TMyObjectPtr;
begin
// new(o, Create);
o := TMyObject.Create;
// what to do here???
o^.destroy;
// implicit free method?
o^.free;
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel
it all
tested and it’s fully functional now (another user has been tested it also as
you’ll see in the notes).
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo
s just
> "lazy programming", like it or not...
>
> Ralf
Then should all if statements have an else? Should constructors give warnings
if you don’t initialize all fields? It’s a slippery slope.
Regards,
Ryan Joseph
__
> On May 18, 2019, at 11:41 AM, Blaise Thorn wrote:
>
> Saturday, May 18, 2019 8:32 PM +03:00 from Ryan Joseph
> :
>> After 2 months now I’ve not been able to get the required sources to help
>> finish the closures branch.
>> The author Blaise did manage to
o
compile (look at the files in tests/test/ to see what I mean).
}
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
edure THelper2.DoThis(msg: string);
begin
writeln('DoThis:', msg);
end;
var
obj: TObject;
begin
obj := TObject.Create;
obj.DoThis; // < ERROR: Wrong number of parameters specified for
call to "DoThis"
end.
Regards,
Ryan Joseph
__
for TMyObject
>
> very good!
>
> This feature deserves a bold announcement. Now we are only missing Lazarus
> IDE codetools support for it :)
>
> Again - big thanks.
You’re welcome. I’m looking forward to fixing up some old code myself. :)
Regards,
Ryan Joseph
Any new news on the LLVM code generator? I wanted to test this but the old link
posted seems to be dead. Is there an updated link and instructions to build?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
> On Apr 20, 2019, at 9:56 AM, Ryan Joseph wrote:
>
>> On Apr 16, 2019, at 8:43 PM, Ryan Joseph wrote:
>>
>> I see why that could be a problem but aren’t users reasonable for not doing
>> dangerous things in a language like Pascal with low-level memory a
ice so I think most people know how to be safe.
What this means is that’s it harder for more advanced programmers to do things
like add + and := operator to collection classes like arrays and that’s pretty
unfortunate. At this point it’s already been smuggled in via operator fun
oblem? It just means the
operator needs to mutate the actual class instead of making a copy like for
records, but those are the rules anyways. Given that I still don’t understand
why "class operator” isn’t included in classes.
Regards,
Ryan Joseph
_
left;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
rs who like the compiler syntax,
which is cleaner and probably faster.
So what should I do going forward? Should I abandon the idea or do any of the
other core team members want to me pursue this further?
{$push}
{$dynarrayalign 4096}
type
TInt
> On Mar 30, 2019, at 12:53 PM, Mattias Gaertner via fpc-devel
> wrote:
>
> I guess you mean auto dereferencing.
> {$ModeSwitch AutoDeref}
Yeah I just found this by looking around in the compiler. Mind. Blown. No idea
that existed!
Regards,
n be okay as well
>
> That only works in {$mode delphi}
Oh that’s why! How does this work in Delphi mode without pointers and why
wasn’t it added to ObjFPC mode? That would have saved me some headache in the
past if I knew this.
Regards,
Ryan Joseph
__
recedent for it (i.e. $align).
Can you give some examples of the vector type? I don’t exactly know what you
guys are referring to.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
t crazy to implement in Pascal.
int& getter() {
return i;
}
function getInt: integer; var;
begin
result := i;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
me.
{$push}
{$align 16}
type
TVertex = record
pos: TVec2;
col: TVec2;
end;
{$pop}
Why not use a similar directive for array alignment? That would solve the
problem I discovered with insert/concat.
{$push}
{$align-array 4096}
type
TIntArray = array of integer;
{$pop}
Regards,
thout pointers.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
could be used.
var
{$push}
{$dynamic-array-align 4096}
a: array of integer;
{$pop}
begin
SetLength(a,10); // just use normal SetLength now
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fre
return an
aligned block that had x number of bytes directly before it. No idea if that’s
feasible for memory managers.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
make variants like InsertAligned() and ignore + operators
for aligned arrays
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Now I’m using “cd /rtl; make all FPC=/path/to/compiler” to build the RTL but
this is obviously slow and unnecessary. Is there a quicker way to build just
the unit which contains dynarr.inc and have all the objects files to be put in
the correct location?
Regards,
Ryan Joseph
alignment calls the new one
> with alignment 1.
>
> Note: the compiler can call the new one for both variants, but the old one is
> required for bootstrapping, so you could surround that with {$if not
> defined(ver3_0) and not defined(ver3_2)}.
You mean if the compiler is < 3
> As for extending the array header, maybe introduce a new data type "aligned
> array".
> So normal arrays do not have that field in there header.
The plan was to make a “SetLengthAligned” or add an extra parameter to
“SetLength”, i.e, SetLength(arr,100,true).
array elements
start (which is aligned). It would complicit the code to some extent however
because the current design relies on lots of pointer math.
Is this ok that I add this? Marco said in the comments there was a need so I
assume this is a go but I wanted to ask first.
Regards,
Ryan
es ("+") }
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
kunit/units_bs/x86_64-darwin -Fu../rtl/units/x86_64-darwin
-Fd -n
ld: file not found: /usr/lib/crt1.10.5.o
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
the
types from the parameters.
I have no preference either way but I wanted to ask the list if they had any
better ideas to contribute. If there’s nothing better I’ll just defer to what
Florian wants.
Regards,
Ryan Joseph
___
fpc-devel maillist
> On Mar 21, 2019, at 5:01 PM, Blaise Thorn wrote:
>
> Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph
> :
>> Then maybe he’ll hear this and respond.
>
> I just did.
Oh, you’re the author! I recognize the email now. Yes, please tell me what the
status
.
From what I saw in that repo the captures are stored in an interfaced object
which has reference counting right? Maybe expand on the lifetime management
issues more.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
been just sitting there for 3+
years. Hope we can get this resolved sooner than later.
https://github.com/maciej-izak/freepascal/tree/closures
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
r pure functions so that one’s a
go for sure.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Mar 18, 2019, at 11:23 AM, Ryan Joseph wrote:
>
> type
> generic TUnaryOp = record
>const
> d0 = -I;
> d1 = +I;
> d2 = not I;
> end;
>
> type
> generic TBinaryOp = record
>const
> d0 = I + I;
> d1 =
DoThis(param: integer = I);
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
the "pure" feature are blocked
> until the XML debug node dump feature is approved.
>
That’s too bad. Knowing if a function is “pure” or not seems deceptively simple
but what were the big challenges btw?
Regards,
Ryan Joseph
__
lines is absolutely sorely lacking in FPC currently,
> don't let anyone tell you otherwise.
Sounds exciting progress for FPC. Btw what happened to the development of
“pure” function modifier that would make it possible to use functions in
compile time expressions? I was pretty excited about
e patch for constants in generics and uploaded again
(https://bugs.freepascal.org/view.php?id=35140). Not sure if they added it yet
or they were waiting for my to fix things. Let me know if that patch is in the
correct format so I can fix the other one for multi-helpers.
Regards
thinking about this too much. :)
So anyways look it over and see if this is acceptable. It does at least work
though which is pretty great because it’s a crucial addition for generics imo.
https://github.com/genericptr/freepascal/tree/generic_implicit
Regards,
Ryan Joseph
question) but that is specific to string constants.
For normal function calls this isn’t a problem because the type is always
specified but for implicit specializations the type may need to be declared in
order for the specialization to be possible.
Regards,
Ryan Joseph
reddef(tprocsym(context.sym).procdefList[0]);
end;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Sending this again to see if it gets through (posts getting blocked again).
> On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote:
>
> In my implicit generic specialization code I have one place where I get a
> string const node (stringconstn) which the resultdef is arraydef (not
>
ram actually uses
exceptions or not.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ompile the system unit with
> that switch, since the code for TObject's c
How can I test to verify if this works or not? Martin makes it sound like
there’s some other considerations for subclasses.
Regards,
Ryan Joseph
___
fpc-devel maillist
ure bloat like in other languages). I would suggest we make
this a compilers switch that is on by default but can be disabled.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
and GetCurrent!
>
Here’s this implicit try/finally block on heap allocation thing again. Can
someone please explain this? Some months ago someone complained FPC was doing
this on all TObject.Create calls. Is that true?
Regards,
Ryan Joseph
___
I’ve been hearing about it almost being
done for a few years now and like Ben this is the probably the most needed
feature to make our lives easier.
As an intermediate measure I was able to make nested functions anonymous but
Sven wanted to wait for the real thing.
Rega
C so
shouldn’t this be turned off? I may not understand what you mean by exception
frame though.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Dec 12, 2018, at 7:59 PM, Ryan Joseph wrote:
>
> For example every time you it parses “1 + 1” a large code block is entered
Correction, 1+1 doesn’t enter a large code block unless there’s an overload
present. Once you add overloads however that’s when a caching solution wou
e cached, at least on a per-block level. That’s a
particularly wasteful detail I noticed and there’s probably many more like this.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma
201 - 300 of 328 matches
Mail list logo
