On 10.10.2015 19:49, Schneider wrote:
Sven:
https://alum.mit.edu/www/toms/software.html
I can't access neither that link nor the other. I get redirected to
https://schneider.ncifcrf.gov/software.html
The redirection is intentional. They keep changing the location of my
website so I set up
2015-10-10 21:12 GMT+02:00 Sven Barth :
> It's not an easy topic and I'd really welcome the input of other core
> developers...
>
> Regards,
> Sven
That would be great. Especially interesting for me is opinion about
"default" for field (IMO better than introducing many new operators). Maybe
it i
On 10.10.2015 19:09, Maciej Izak wrote:
2015-10-10 18:40 GMT+02:00 Sven Barth mailto:pascaldra...@googlemail.com>>:
While I see and understand your reasoning behind it I don't really
like it... There needs to be some better way for this... hmm... :/
I am only sure about MANAGEMENTOPERATO
On 05/28/2015 08:45 AM, Paul Breneman wrote:
Wow, yesterday I started this new message:
http://forum.lazarus.freepascal.org/index.php/topic,28561.0.html
And today Laksen says it's committed to SVN trunk. That was fast!
Thanks to all the FPC developers!
And today I finally made my first relea
Sven:
> > https://alum.mit.edu/www/toms/software.html
>
> I can't access neither that link nor the other. I get redirected to
> https://schneider.ncifcrf.gov/software.html
The redirection is intentional. They keep changing the location of my
website so I set up a permanent link through MIT. It
2015-10-10 13:32 GMT+02:00 Michael Van Canneyt :
>
> All clear, and I hope to see an ARC implementation based on this "really
> soon" :-)
>
Maybe FPC 4.0? ;)
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
2015-10-10 18:40 GMT+02:00 Sven Barth :
> Am 10.10.2015 18:19 schrieb "Maciej Izak" :
> > class operator TSmartPtr.Copy(constref aSource: TSmartPtr; var
> aDest: TSmartPtr);
> > begin
> > if aDest.RefCount <> nil then
> > Finalize(aDest);
> > if aSource.RefCount <> nil then
> > InterLo
Am 10.10.2015 18:19 schrieb "Maciej Izak" :
> class operator TSmartPtr.Copy(constref aSource: TSmartPtr; var
aDest: TSmartPtr);
> begin
> if aDest.RefCount <> nil then
> Finalize(aDest);
> if aSource.RefCount <> nil then
> InterLockedIncrement(aSource.RefCount^);
> aDest.RefCount := a
Am 10.10.2015 17:57 schrieb "Schneider" :
>
> Sven:
>
> > > > In addition you might be the biggest ISO user
> > > > of FPC yet :) (which will hopefully help to find more bugs in that
mode
> > > > ;) )
> > >
> > > Well, assuming that it gets off the ground and I can compile my
> > > programs ...
> >
First of all there was small bug in my previous code: wrong usage of
Finalize, lack of SmartFinalize and bad parameter for Implicit (keep in
mind that this structure will be complemented for TWeakPtr). Correct
version:
==begin code==
type
TSmartPtr = record
// similar as overloading
Sven:
> > > In addition you might be the biggest ISO user
> > > of FPC yet :) (which will hopefully help to find more bugs in that mode
> > > ;) )
> >
> > Well, assuming that it gets off the ground and I can compile my
> > programs ...
>
> I hope so. And we do after all want FPC to become fully I
Sven:
> > That worked. Not clear whether -Tdarwin should stay ...
>
> Since you're compiling on Mac OS X you don't need that. It's only if
> you compile for a different target than the one you're on (that's the
> simple version, but that should be sufficient for now ;) ).
Ok, good, I removed th
On 10.10.2015 16:58, Michael Van Canneyt wrote:
The class does not need to have a default property to begin with, so
it is somewhere logical.
Yes, in that case a default enumerator would not be allowed, which
sounds (in contrary) logical to me: no default array property => no
enumerator. But th
On Sat, 10 Oct 2015, Ondrej Pokorny wrote:
Oh, it would be so nice if default enumerator wasn't defined with the
"GetEnumerator" function but with the default property:
TTest = class
// ...
function GetObjectEnumerator: TTestObjectEnumerator;
property Objects[Index: Integer]: TObje
Oh, it would be so nice if default enumerator wasn't defined with the
"GetEnumerator" function but with the default property:
TTest = class
// ...
function GetObjectEnumerator: TTestObjectEnumerator;
property Objects[Index: Integer]: TObject read GetObject enumerator
GetObjectEnum
On 10/10/2015 07:12 AM, Mark Morgan Lloyd wrote:
One thing that bothers me about these approaches is that sooner or later some
awkward cuss (such as myself) will start whining about how much better Pascal
would be if there were a decent macro preprocessor so that CaseOf() could be
specialised int
On 10.10.2015 12:41, Michael Van Canneyt wrote:
100% agreed :)
Great!
I wrote a feature request in mantis for it so that we don't forget about
it and can follow it there: http://bugs.freepascal.org/view.php?id=28820
Ondre
___
fpc-devel maillist -
On Sat, 10 Oct 2015, Sven Barth wrote:
Am 10.10.2015 12:15 schrieb "Michael Van Canneyt" :
Just allow those three
operator overloads for normal records and have them be present in the
Init
RTTI of the record so that fpc_initialize(), fpc_finalize() and
fpc_copy()
can pick them up. This wi
Am 10.10.2015 12:15 schrieb "Michael Van Canneyt" :
>> Just allow those three
>> operator overloads for normal records and have them be present in the
Init
>> RTTI of the record so that fpc_initialize(), fpc_finalize() and
fpc_copy()
>> can pick them up. This will be needed anyway should such recor
Michael Van Canneyt wrote:
On Sat, 10 Oct 2015, Sven Barth wrote:
Am 10.10.2015 10:51 schrieb "Mark Morgan Lloyd" <
markmll.fpc-de...@telemetry.co.uk>:
Michael Van Canneyt wrote:
On Fri, 9 Oct 2015, Sven Barth wrote:
I'm not sure this kind of semantics is possible with a compiler
intr
On Sat, 10 Oct 2015, Ondrej Pokorny wrote:
On 10.10.2015 12:30, Michael Van Canneyt wrote:
After a
sed s/iterator/enumerator/g
I'm all for it.
+ Yes, the "in Self" is supported. But this is not the problem here. The
example still doesn't compile. A class can have more array properties. A
On 10.10.2015 12:30, Michael Van Canneyt wrote:
After a
sed s/iterator/enumerator/g
I'm all for it.
I've been looking how to implement names/objects/values enumerators in
TStrings. This would be the almost perfect solution.
But your example is not well-chosen, since the enumerator for
TCom
On Sat, 10 Oct 2015, Ondrej Pokorny wrote:
When we are already discussing new language features, what about supporting
iterators for array properties:
TTest = class
// ...
property Objects[Index: Integer]: TObject read GetObject *iterator
GetObjectIterator*;
property ObjectCount:
When we are already discussing new language features, what about
supporting iterators for array properties:
TTest = class
// ...
property Objects[Index: Integer]: TObject read GetObject *iterator
GetObjectIterator*;
property ObjectCount: Integer read GetObjectCount;
end;
This
On Sat, 10 Oct 2015, Sven Barth wrote:
Am 10.10.2015 11:12 schrieb "Michael Van Canneyt" :
On Sat, 10 Oct 2015, Maciej Izak wrote:
I am working on smart pointers for FPC (something more than pure ARC for
classes).
This solution is full compatible with existing code base.
I would like t
On Sat, 10 Oct 2015, Sven Barth wrote:
Am 10.10.2015 10:51 schrieb "Mark Morgan Lloyd" <
markmll.fpc-de...@telemetry.co.uk>:
Michael Van Canneyt wrote:
On Fri, 9 Oct 2015, Sven Barth wrote:
I'm not sure this kind of semantics is possible with a compiler
intrinsic...
But if it is: I
Am 10.10.2015 11:12 schrieb "Michael Van Canneyt" :
>
>
>
> On Sat, 10 Oct 2015, Maciej Izak wrote:
>
>> I am working on smart pointers for FPC (something more than pure ARC for
>> classes).
>>
>> This solution is full compatible with existing code base.
>>
>> I would like to know what do you think
Am 10.10.2015 10:51 schrieb "Mark Morgan Lloyd" <
markmll.fpc-de...@telemetry.co.uk>:
>
> Michael Van Canneyt wrote:
>>
>> On Fri, 9 Oct 2015, Sven Barth wrote:
>>
>>
I'm not sure this kind of semantics is possible with a compiler
>>>
>>> intrinsic...
But if it is: In that case
On Sat, 10 Oct 2015, Maciej Izak wrote:
I am working on smart pointers for FPC (something more than pure ARC for
classes).
This solution is full compatible with existing code base.
I would like to know what do you think about my conception and work.
First step is almost done -> new record o
Michael Van Canneyt wrote:
On Fri, 9 Oct 2015, Sven Barth wrote:
I'm not sure this kind of semantics is possible with a compiler
intrinsic...
But if it is: In that case the IfThen or IIF() or somesuch has my
absolute top preference, followed by ternary. (and the If .. then
expression shoul
Am 10.10.2015 02:41 schrieb "Maciej Izak" :
> First step is almost done -> new record operators:
>
> === begin code ===
> {$MODESWITCH MANAGEMENTOPERATORS}
> type // Record with automatic constructor and destructor
> TValue = record
> class operator Initialize(var aRec: TValue);
> class o
Am 09.10.2015 23:39 schrieb "Schneider" :
> > In addition you might be the biggest ISO user
> > of FPC yet :) (which will hopefully help to find more bugs in that mode
> > ;) )
>
> Well, assuming that it gets off the ground and I can compile my
> programs ...
I hope so. And we do after all want FP
Am 09.10.2015 23:31 schrieb "Schneider" :
>
> Sven:
>
> > > fpc -Miso -Tdarwin -Mmacpas getput.p
> >
> > You should only pass one of the major modes (which are "fpc", "tp",
> > "iso", "objfpc", "macpas", "delphi" and "delphiunicode") while you can
> > use multiple of the minor modeswitches (I don
Am 09.10.2015 23:11 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Oct 9, 2015 at 5:04 PM, Sven Barth
wrote:
>>
>> Yes a compiler intrinsic could handle that. In the end all three
syntaxes are the same code representation anyway: namely an if-node.
>> The IfThen() intrinsic would be fine with me as we
34 matches
Mail list logo
