[fpc-devel] Small virtual machine to cross compile FPC

[Paul Breneman]

I've spent a bit of time during the past 7 years trying to figure out 
how to simplify things by avoiding cross-compiling.  This page has many 
of the details:

  http://turbocontrol.com/monitor.htm

I think there is a way to simplify cross-compiling.  Levinux is a small 
(~20 MB) QEMU download for x86 PCs (Windows, OS X, Linux) that provides 
a small Tiny Core Linux VM.  I'd like to see something similar but with 
all the files and tools needed to pull the latest source code and 
cross-compile FPC (also with Debian instead of Tiny Core?).

  http://mikelev.in/ux/

It seems to me that such a small VM should allow a nice standard method 
that will make it easy to test and see things work.


I look forward to your thoughts and comments!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Well... we may differ on this one. I absolutely love attributes, but I guess 
that is just me :-D .
I think attributes are the greatest thing that has happened to Delphi ever, 
I just wish they ware not so limited. Attributes allowed us to cut 3/4 of 
our code base. You can't beat that easily.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Sven Barth

Sent: Monday, October 27, 2014 3:31 PM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 21:01, schrieb Boian Mitov:
But instead of (context sensitive) keywords you have another bunch of
"magic" classes. That's not great either. Also I /hate/ the attribute
syntax that Delphi introduced.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 21:01, schrieb Boian Mitov:

 Hi Sven,

Great work!
I think it will be better if the weak is attribute as done in Delphi.
Attributes eliminate the need for introducing new keywords, to the 
already crowded OP keywords space.
Indeed week is a real attribute of a variable, and it makes more sense 
to be in attribute form. I am sure there will be even more attributes 
needed over time, and we should consider using the attribute form when 
it makes sense as in this case IMHO.
But instead of (context sensitive) keywords you have another bunch of 
"magic" classes. That's not great either. Also I /hate/ the attribute 
syntax that Delphi introduced.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:

Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" 
mailto:drdiettri...@aol.com>>:



 > Something like ShortString and AnsiString?

With the difference that Short- and AnsiString are assignable to 
eachother while Jonas does not want that for reference counted and 
ordinary classes.


Where would this matter? When TObject and TManagedObject are different 
(base) types, a direct assignment of references is impossible.
Take unit Typinfo for example where quite some methods take a TObject 
instance. Or all those classes (TStrings, TObjectList, TComponent, etc.) 
that somewhere take a TObject as parameter.



What do you mean with "virtual counting methods"?


Overriding these methods can enable/disable refcounting for a class, 
and all classes derived from it. The default then can be to do nothing 
(no counting).
But then it's the same reference counting as the COM one, because 
without the COM reference counting those virtual methods would not be 
called.
The main reason I decided not to introduce reference counting for 
every class was that some people feared the performance impact of the 
reference counting. Though Florian said that it shouldn't be that bad 
on today's CPUs...


Did you ever benchmark your model?
Nope. Was glad to have gotten it out to the public with all those 
distractions I have in my free time ;)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 21:06, schrieb Marco van de Voort:



- TObject and all descendants are reference counted (please no size and
performance discussion here)

No they are not. Of course they are not. That would be stupid.
Sorry, I don't get what you're trying to say here. Would you please 
elaborate?



- in code that does not use ARC ("modeswitch arc off" - the default; or
maybe better a local directive) all instance variables are considered "weak"

But Tobject becomes bigger yet again. This is a *ROOT* class, the D2009
additions are already painful enough without voluntarily adding to it.
The D2009 additions are only /per class/ and not per instance. The 
instance size of TObject in trunk is still 4 (or 8 on 64-bit), in my 
branch it's 8 or 12. Also we can not avoid this as sooner or later we'll 
need TMonitor support as well which in Delphi uses a pointer field that 
is part of TObject (though I'm working on an idea to implement this 
without extending TObject).

With this approach there would be no change for legacy code

So now this is the way to go forward by default. Hell no!

And people wonder why I didn't go and simply implemented it in trunk :P

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 20:49, schrieb Hans-Peter Diettrich:

Kostas Michalopoulos schrieb:
On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 
mailto:drdiettri...@aol.com>> wrote:


Then the compiler can safely generate refcounting code for *all*
objects and non-weak references, and the counting methods take care
of required operations


Wouldn't that cause all objects to "pay" (both in terms of 
performance and memory) for something that they don't use?


Right, that's why I suggest to keep both models separate. But the real 
runtime impact has to be benchmarked - it may be as low as with other 
managed types (AnsiString...), where nobody has complaints. Memory 
usage (4 bytes per object) should not matter, Delphi accepts it just 
for mobile devices!
It should be possible to disable ARC completely (define when compiling 
the compiler/RTL) for low memory targets like embedded or i8086-msdos, 
because there every byte may count.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 21:10, schrieb Boian Mitov:
I second this. I would surely love to test drive it. I am also sure we 
will gather valuable experience from testing it.
Then simply use my branch. That's what it's there for. This won't be in 
trunk for quite some time and the less people test it in the branch the 
longer it will take with it becoming part of trunk.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 21:32, schrieb Boian Mitov:
As for 2. this is example where attribute could have helped ;-) . Just 
another argument in favor of attributes vs. new keywords ;-) .
No. It would not. Lazarus doesn't know attributes either. Despite that I 
/hate/ that attribute syntax.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

In general the C/C++ notion of doing as little in the language as possible, 
and as much in library has worked very well for it over the years.
Yes, pluggable languages concept has existed at least since C ;-) . I agree, 
and as I said has worked well.
I think OP can learn a lot from those languages, and prosper from such 
features.
The advantage of doing it this way, is that we can all customize the 
language to our liking, while keeping it all compatible.
It also will allow for blossoming of new programming concepts as developers 
can expand the language themselves without the need to rewrite the compiler. 
Even more so it will make the language very attractive for universities and 
students (so they will not need to use Scheme any more as example ;-) ).
This has the potential of making FPC the premier, and leading language in 
the world of computing, not merely just another language in the crowd ;-) 
IMHO .



With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 2:23 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:

Well... since attributes can be implemented in compiler extending library,


And tell me again why directives couldn't? A switch or whatever trigger 
could

also plug additional directives into the parser. (and then I'm not even
discussing the actual use of plugging).

As said the only *difference* is to skip and ignore unknown attributes since
they are a defined list. But then one must have the actual luxury of
skipping them and the program still working.

And e.g. in the case refcounts skipping that will leave some pretty big
memory leaks :_)


I think library extension of the compiler is a better option that having a
bunch of switch directives.


You made that clear. I just don't understand really why. The extra
interfaces only make the result harder to control. A pluggable program is
much harder to maintain than the same functionality monolithically.


This also allows users easily to customize the compiler for their needs.


That's the only reason to do so. But that is for third party uses, usually
for one application or framework or platform dependent. Not for core
language features that hit both code generation and library.


Now I know the concept for compiler being expanded/modified via library is
probably a new one, but .NET already has introduced elements of this years
ago, and seems to work well for them ;-) .


.NET afaik mostly uses it to give hints to the fringes of the system, like 
the ASP.NET

containerized instances of the .NET framework for safety and load balancing
etc, and to interop to communicate to the outside of its walled garden.

There was life in languages before .NET, don't worry ;-) Trying to make
pluggable languages is almost as old as the road to Rome.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Actually Ref. Counting may reduce memory usage, as in reality it will 
require less code. It will eliminate a large number of destructors, and in 
many cases a lot of if statements etc.
I am speaking of personal experience since we introduced [AutoManage] 
attribute in our libraries, and it reduced the code significantly. In our 
case it also creates the objects, so we also eliminate most constructors 
too, but even just the elimination of destructors is a great benefit.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Florian Klämpfl

Sent: Monday, October 27, 2014 2:19 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 um 19:59 schrieb Sven Barth:


No problem with all that, interesting ideas even, but not with the 
current codebase and RTL.
Florian has written me an idea two weeks ago regarding the "backwards 
compatibility" aspect (I won't

argue the performance impact one ;) ):
- TObject and all descendants are reference counted (please no size and 
performance discussion here)


I doubt that the performance impact is measurable if no ref. counting 
references are used because if
the refcount=1 no interlocked operation is needed. And even if interlocked 
operations are needed: On
modern systems they hurt not much. Neither do I believe in significant 
memory increase. I'll test

with the compiler next week.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Boian Mitov said:
> Well... since attributes can be implemented in compiler extending library, 

And tell me again why directives couldn't? A switch or whatever trigger could
also plug additional directives into the parser. (and then I'm not even
discussing the actual use of plugging).

As said the only *difference* is to skip and ignore unknown attributes since
they are a defined list. But then one must have the actual luxury of
skipping them and the program still working.

And e.g. in the case refcounts skipping that will leave some pretty big
memory leaks :_)

> I think library extension of the compiler is a better option that having a 
> bunch of switch directives.

You made that clear. I just don't understand really why. The extra
interfaces only make the result harder to control. A pluggable program is
much harder to maintain than the same functionality monolithically.

> This also allows users easily to customize the compiler for their needs.

That's the only reason to do so. But that is for third party uses, usually
for one application or framework or platform dependent. Not for core
language features that hit both code generation and library.

> Now I know the concept for compiler being expanded/modified via library is 
> probably a new one, but .NET already has introduced elements of this years 
> ago, and seems to work well for them ;-) .

.NET afaik mostly uses it to give hints to the fringes of the system, like the 
ASP.NET 
containerized instances of the .NET framework for safety and load balancing
etc, and to interop to communicate to the outside of its walled garden.

There was life in languages before .NET, don't worry ;-) Trying to make
pluggable languages is almost as old as the road to Rome.
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Florian Klämpfl]

Am 27.10.2014 um 19:59 schrieb Sven Barth:
>>
>> No problem with all that, interesting ideas even, but not with the current 
>> codebase and RTL.
> Florian has written me an idea two weeks ago regarding the "backwards 
> compatibility" aspect (I won't
> argue the performance impact one ;) ):
> - TObject and all descendants are reference counted (please no size and 
> performance discussion here)

I doubt that the performance impact is measurable if no ref. counting 
references are used because if
the refcount=1 no interlocked operation is needed. And even if interlocked 
operations are needed: On
modern systems they hurt not much. Neither do I believe in significant memory 
increase. I'll test
with the compiler next week.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Well... since attributes can be implemented in compiler extending library, 
then attributes can be enabled/disabled just by adding a unit ;-) .

That can't be said for new keywords.
I think library extension of the compiler is a better option that having a 
bunch of switch directives.

This also allows users easily to customize the compiler for their needs.
Now I know the concept for compiler being expanded/modified via library is 
probably a new one, but .NET already has introduced elements of this years 
ago, and seems to work well for them ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 1:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:

Except attributes can't be confused with variables ;-).


The variables can't be confused with attributes.

Attributes are only useful in addition to an established languages, and as
extensions/implementation specific parts (so that the simpler parsers can
afford to ignore them).

As soon as you have two equal implementations like Delphi and FPC adding to
them independently, you are back to square one.


And the other benefit I did not mentioned earlier, a lot of the attributes
(if not all) can actually be implemented as compiler extending libraries 
;-)


The only advantage of attributes is that you can skip unknown ones at the
expense of terser syntax.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:

A semicolon has the problem that you need to distinguish between it 
being a modifier and a normal following identifier as not every keyword 
is a keyword in every context (like for example "read" and "write" for 
properties).


In this discussion I almost miss the elementary distinction between 
keywords (reserved words) and directives. Unlike keywords, directives 
are context sensitive and can be used as identifiers in all other 
places. That's why directives should *follow* identifiers, never precede 
them.


The semicolon usage is not well designed in Delphi, additional 
(intermediate) semicolons are not required and should be banned. Then 
the parser can continue to search for directives until the end of an 
applicable construct (declaration...) is found, which may be a semicolon 
or something else (comma, parenthesis...), depending on the construct 
syntax.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Kostas Michalopoulos schrieb:
On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 
mailto:drdiettri...@aol.com>> wrote:


Then the compiler can safely generate refcounting code for *all*
objects and non-weak references, and the counting methods take care
of required operations


Wouldn't that cause all objects to "pay" (both in terms of performance 
and memory) for something that they don't use?


Right, that's why I suggest to keep both models separate. But the real 
runtime impact has to be benchmarked - it may be as low as with other 
managed types (AnsiString...), where nobody has complaints. Memory usage 
(4 bytes per object) should not matter, Delphi accepts it just for 
mobile devices!


IMO it is better to fully 
disallow subclasses from introducing reference counting than force 
functionality on objects that they don't need to use.


It *looks* better, but has several issues.

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" >:



 > Something like ShortString and AnsiString?

With the difference that Short- and AnsiString are assignable to 
eachother while Jonas does not want that for reference counted and 
ordinary classes.


Where would this matter? When TObject and TManagedObject are different 
(base) types, a direct assignment of references is impossible.




What do you mean with "virtual counting methods"?


Overriding these methods can enable/disable refcounting for a class, and 
all classes derived from it. The default then can be to do nothing (no 
counting).


The main reason I decided not to introduce reference counting for every 
class was that some people feared the performance impact of the 
reference counting. Though Florian said that it shouldn't be that bad on 
today's CPUs...


Did you ever benchmark your model?

That said: if someone wants to test it one could add "refcounted" to 
TObject (my code should(!) handle that correctly) and see what 
happens... (of course there will be problems with circular references then)


Fine :-)

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Boian Mitov said:
> Except attributes can't be confused with variables ;-).

The variables can't be confused with attributes.

Attributes are only useful in addition to an established languages, and as
extensions/implementation specific parts (so that the simpler parsers can
afford to ignore them).

As soon as you have two equal implementations like Delphi and FPC adding to
them independently, you are back to square one.

> And the other benefit I did not mentioned earlier, a lot of the attributes 
> (if not all) can actually be implemented as compiler extending libraries ;-) 

The only advantage of attributes is that you can skip unknown ones at the
expense of terser syntax.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

As for 2. this is example where attribute could have helped ;-) . Just another 
argument in favor of attributes vs. new keywords ;-) .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---

From: hinsta...@yandex.ru 
Sent: Monday, October 27, 2014 6:48 AM
To: FPC developers' list 
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

I tested it a bit; thoughts so far:
1. generic and refcounted do not work well together: no matter how I arrange 
it, a class can't be both generic and refcounted, it causes the compiler to 
produce some internal error 2014092205.
2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled into 
ignoring it with if-defs


27.10.2014, 16:15, "Sven Barth" :

  Am 27.10.2014 11:37 schrieb :

I think we should just roll out this feature to FPC trunk and let people 
test it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments
  Then just checkout the branch I mentioned in my initial mail. It's 
implemented there and is not a thought experiment. I'm not going to commit this 
any time soon to trunk, because 1) there are too many open points and 2) trunk 
is preparing for release branching thus no new big features and especially not 
as critized ones as this.

  Regards,
  Sven
  ,

  ___
  fpc-devel maillist  -  fpc-devel@lists.freepascal.org
   http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> >> scratch, or was it initially based on something like the P6 compiler 
> >> which I believe was on some DEC systems?
> > 
> > The page he referenced lists extensions to both standard and extended
> > pascal. So it seems it is an extended pascal compiler.
> 
> Yes, but extended from /what/?

ISO Pascal 10206:1991, I see schemata in that list. That's a major extended
pascal feature.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

Except attributes can't be confused with variables ;-).
And the other benefit I did not mentioned earlier, a lot of the attributes 
(if not all) can actually be implemented as compiler extending libraries ;-) 
.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 1:17 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:

I think that we should start considering using attributes instead of
introducing new keywords.
This should reduce the compatibility issues due to the new keywords, keep
the language cleaner IMHO.


No, they just move the potential conflicts from modifiers to attributes
namespace IMHO.  Nothing fundamental solved.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Mark Morgan Lloyd]

Marco van de Voort wrote:

In our previous episode, Mark Morgan Lloyd said:
I see from your reference that the compiler extends ANSI/ISO Pascal, but 
there's no indication of whether, when it was written, it was based on 
Jensen & Wirth or the somewhat later ISO standard. Was it written from 
scratch, or was it initially based on something like the P6 compiler 
which I believe was on some DEC systems?


The page he referenced lists extensions to both standard and extended
pascal. So it seems it is an extended pascal compiler.


Yes, but extended from /what/? Not having- as a particular example- P6 
documentation, that list could describe something like the extensions 
that P6 has relative to ISO plus a set of extensions on top of P6.


** Anybody: what's the state of the -Miso mode? I don't see it in the -h 
output.


Getting fairly close for standard pascal, no extended pascal.


In that case somebody ought to check that it appears in -h output.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Boian Mitov said:
> I think that we should start considering using attributes instead of 
> introducing new keywords.
> This should reduce the compatibility issues due to the new keywords, keep 
> the language cleaner IMHO.

No, they just move the potential conflicts from modifiers to attributes
namespace IMHO.  Nothing fundamental solved.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I think that we should start considering using attributes instead of 
introducing new keywords.
This should reduce the compatibility issues due to the new keywords, keep 
the language cleaner IMHO .
There are other benefits of doing it with attributes, but they are subject 
of another discussion ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Marco van de Voort

Sent: Monday, October 27, 2014 3:50 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Kostas Michalopoulos said:

 I think it is a bad idea to
introduce a new keyword placement if there isn't already one since it
breaks consistency (all those other keywords are placed in front of the
type name whereas this special one is placed after).


There are multiple existing ones already see  e.g. 
http://www.freepascal.org/docs-html/ref/refse21.html

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I second this. I would surely love to test drive it. I am also sure we will 
gather valuable experience from testing it.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: hinsta...@yandex.ru

Sent: Monday, October 27, 2014 3:37 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

I think we should just roll out this feature to FPC trunk and let people 
test it; so those who are interested in it would test it and detect 
potential problems in practice rather than in thought experiments


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

I second that. This is definitely a variable not a type modifier. The 
variable is the one that is weak.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, October 27, 2014 1:53 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation



On Mon, 27 Oct 2014, ListMember wrote:



To me, 'weak' is modifying the type rather than the variable itself (much 
like 'packed record').


That is a wrong way of thinking, because the type itself is not modified at 
all.

The behaviour of the variable is modified.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Sven Barth said:
> Florian has written me an idea two weeks ago regarding the "backwards 
> compatibility" aspect (I won't argue the performance impact one ;) ):

Let's not christen this a step forward. So talking about backwards is
premature :-)

> - TObject and all descendants are reference counted (please no size and 
> performance discussion here)

No they are not. Of course they are not. That would be stupid.

> - in code that does not use ARC ("modeswitch arc off" - the default; or 
> maybe better a local directive) all instance variables are considered "weak"

But Tobject becomes bigger yet again. This is a *ROOT* class, the D2009
additions are already painful enough without voluntarily adding to it.

> With this approach there would be no change for legacy code 

So now this is the way to go forward by default. Hell no!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

 Hi Sven,

Great work!
I think it will be better if the weak is attribute as done in Delphi.
Attributes eliminate the need for introducing new keywords, to the already 
crowded OP keywords space.
Indeed week is a real attribute of a variable, and it makes more sense to be 
in attribute form. I am sure there will be even more attributes needed over 
time, and we should consider using the attribute form when it makes sense as 
in this case IMHO.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Sven Barth

Sent: Friday, October 24, 2014 2:23 PM
To: FPC developers' list
Subject: [fpc-devel] Proof of Concept ARC implementation

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:
http://lists.freepascal.org/fpc-devel/2014-September/034263.html

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> I see from your reference that the compiler extends ANSI/ISO Pascal, but 
> there's no indication of whether, when it was written, it was based on 
> Jensen & Wirth or the somewhat later ISO standard. Was it written from 
> scratch, or was it initially based on something like the P6 compiler 
> which I believe was on some DEC systems?

The page he referenced lists extensions to both standard and extended
pascal. So it seems it is an extended pascal compiler.
 
> ** Anybody: what's the state of the -Miso mode? I don't see it in the -h 
> output.

Getting fairly close for standard pascal, no extended pascal.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 19:24, schrieb Michael Van Canneyt:



On Mon, 27 Oct 2014, Sven Barth wrote:



Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" 
:

>
> Jonas Maebe schrieb:
>
>
>> Additionally, as mentioned before, I still believe it's a very bad 
idea to be able to inherited from a regular class and turn it into a 
reference counted class. Reference

counted and non-reference-counted
>> classes are different language entities with different behaviour 
and different code generation requirements, and hence should be 
completely unrelated.

>
>
> Something like ShortString and AnsiString?

With the difference that Short- and AnsiString are assignable to 
eachother while Jonas does not want that for reference counted and 
ordinary classes.


>> Even if you completely forbid typecasting a reference counted 
class into a non-reference-counted parent class, simply calling an 
inherited method from a
non-reference-counted parent class can easily completely mess up the 
reference counting (e.g. suppose that inherited method inserts "self" 
into a linked list).

>
>
> ACK. The only way out; I can see; is adding the *possibility* of 
refcounting to TObject, meaning Add/ReleaseRef methods and a RefCount 
field. Then the compiler can safely
generate refcounting code for *all* objects and non-weak references, 
and the counting methods take care of required operations. Delphi 
offers two means for specialized
refcounting, the virtual counting methods, and the (COM compatible?) 
refcount value of -1 for unmanaged objects.


What do you mean with "virtual counting methods"?
The main reason I decided not to introduce reference counting for 
every class was that some people feared the performance impact of the 
reference counting.


There *will* be a performance impact, and there *are* circular 
references.


You cannot simply minimize either of these facts away:

Reference counting of all objects is not some nice-to-have "feature". 
It is a complete shift in paradigm at the very root of the language.


You would need to write a different RTL entirely which is aware of 
this paradigm. If you have reference counted objects, you can make 
strings into real objects etc.


No problem with all that, interesting ideas even, but not with the 
current codebase and RTL.
Florian has written me an idea two weeks ago regarding the "backwards 
compatibility" aspect (I won't argue the performance impact one ;) ):
- TObject and all descendants are reference counted (please no size and 
performance discussion here)
- in code that does not use ARC ("modeswitch arc off" - the default; or 
maybe better a local directive) all instance variables are considered "weak"
- constructors of code that does not use ARC return with reference count 
= 1, otherwise reference count is initially 0 (like for interfaces and 
currently in my branch)
- destructors also take care of this additional "pseudo" reference upon 
being called; thus the object is freed after the last ARC reference is 
gone AND (for legacy code) Free/Destroy has been called (thus when the 
reference count really reaches 0)


With this approach there would be no change for legacy code (except for 
the additional refcount field per instance), as reference counting would 
only happen with enabled ARC directive/modeswitch (thus there could 
still be memory leaks for such classes). New code could take ARC into 
account and could be written accordingly with "weak" modifiers, etc.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 16:23, schrieb Sven Barth:


Am 27.10.2014 14:54 schrieb "hinsta...@yandex.ru 
" >:

>
> I tested it a bit; thoughts so far:
> 1. generic and refcounted do not work well together: no matter how I 
arrange it, a class can't be both generic and refcounted, it causes 
the compiler to produce some internal error 2014092205.


Oh, good to know. I'll take a look at that when I find the time :) 
(and that internal error is one I added for that feature, so that's a 
"good" sign as well ;) )



Do you have an example? I tried this and it works:

=== code begin ===

program trefcounted;

{$mode objfpc}

type
  generic TTest = class refcounted
  end;

  TTestLongInt = specialize TTest;

var
  t: TTestLongInt;
begin
  t := TTestLongInt.Create;
end.

=== code end ===

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Sven Barth]

Am 27.10.2014 18:35, schrieb Mark Morgan Lloyd:

Richard Apthorp wrote:

Hi Sven,

Actually found that HP have a documented list:
http://h71000.www7.hp.com/doc/82final/6083/6083pro_032.html#extensions_app 

I'm not sure I feel qualified to change the compiler but as I work on 
this porting project I will be creating a list of the main changes 
which I could then decide if beneficial to create a new compiler mode 
for (with a lot of help I hope!!!)

Thanks again for your advice, Richard.


One useful thing might be to create a test case for each extension as 
you find that FPC (in the default mode ** ) doesn't handle it, and to 
submit it as a bug for discussion. That would enable all the 
"tentative VMS mode" activity to be at least cross-linked.

Yes, that might be a good idea.


I see from your reference that the compiler extends ANSI/ISO Pascal, 
but there's no indication of whether, when it was written, it was 
based on Jensen & Wirth or the somewhat later ISO standard. Was it 
written from scratch, or was it initially based on something like the 
P6 compiler which I believe was on some DEC systems?
Note: As Jonas wrote in an earlier mail you need to add Richard as CC as 
he's not (yet) subscribed to the mailing list.
** Anybody: what's the state of the -Miso mode? I don't see it in the 
-h output.
AFAIK variadic record initialization and peeking input is at least 
missing. Otherwise it should work more or less in trunk (again AFAIK⦆.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Sven Barth wrote:



Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" :
>
> Jonas Maebe schrieb:
>
>
>> Additionally, as mentioned before, I still believe it's a very bad idea to 
be able to inherited from a regular class and turn it into a reference counted class. 
Reference
counted and non-reference-counted
>> classes are different language entities with different behaviour and 
different code generation requirements, and hence should be completely unrelated.
>
>
> Something like ShortString and AnsiString?

With the difference that Short- and AnsiString are assignable to eachother 
while Jonas does not want that for reference counted and ordinary classes.

>> Even if you completely forbid typecasting a reference counted class into a 
non-reference-counted parent class, simply calling an inherited method from a
non-reference-counted parent class can easily completely mess up the reference counting 
(e.g. suppose that inherited method inserts "self" into a linked list).
>
>
> ACK. The only way out; I can see; is adding the *possibility* of refcounting 
to TObject, meaning Add/ReleaseRef methods and a RefCount field. Then the compiler 
can safely
generate refcounting code for *all* objects and non-weak references, and the 
counting methods take care of required operations. Delphi offers two means for 
specialized
refcounting, the virtual counting methods, and the (COM compatible?) refcount 
value of -1 for unmanaged objects.

What do you mean with "virtual counting methods"?
The main reason I decided not to introduce reference counting for every class 
was that some people feared the performance impact of the reference counting.


There *will* be a performance impact, and there *are* circular references.

You cannot simply minimize either of these facts away:

Reference counting of all objects is not some nice-to-have "feature". 
It is a complete shift in paradigm at the very root of the language.


You would need to write a different RTL entirely which is aware of this paradigm. 
If you have reference counted objects, you can make strings into real objects etc.


No problem with all that, interesting ideas even, but not with the current 
codebase and RTL.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Mark Morgan Lloyd]

Richard Apthorp wrote:

Hi Sven,

Actually found that HP have a documented list:
http://h71000.www7.hp.com/doc/82final/6083/6083pro_032.html#extensions_app
I'm not sure I feel qualified to change the compiler but as I work on this 
porting project I will be creating a list of the main changes which I could 
then decide if beneficial to create a new compiler mode for (with a lot of help 
I hope!!!)
Thanks again for your advice, Richard.


One useful thing might be to create a test case for each extension as 
you find that FPC (in the default mode ** ) doesn't handle it, and to 
submit it as a bug for discussion. That would enable all the "tentative 
VMS mode" activity to be at least cross-linked.


I see from your reference that the compiler extends ANSI/ISO Pascal, but 
there's no indication of whether, when it was written, it was based on 
Jensen & Wirth or the somewhat later ISO standard. Was it written from 
scratch, or was it initially based on something like the P6 compiler 
which I believe was on some DEC systems?


** Anybody: what's the state of the -Miso mode? I don't see it in the -h 
output.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" :
>
> Jonas Maebe schrieb:
>
>
>> Additionally, as mentioned before, I still believe it's a very bad idea
to be able to inherited from a regular class and turn it into a reference
counted class. Reference counted and non-reference-counted
>> classes are different language entities with different behaviour and
different code generation requirements, and hence should be completely
unrelated.
>
>
> Something like ShortString and AnsiString?

With the difference that Short- and AnsiString are assignable to eachother
while Jonas does not want that for reference counted and ordinary classes.

>> Even if you completely forbid typecasting a reference counted class into
a non-reference-counted parent class, simply calling an inherited method
from a non-reference-counted parent class can easily completely mess up the
reference counting (e.g. suppose that inherited method inserts "self" into
a linked list).
>
>
> ACK. The only way out; I can see; is adding the *possibility* of
refcounting to TObject, meaning Add/ReleaseRef methods and a RefCount
field. Then the compiler can safely generate refcounting code for *all*
objects and non-weak references, and the counting methods take care of
required operations. Delphi offers two means for specialized refcounting,
the virtual counting methods, and the (COM compatible?) refcount value of
-1 for unmanaged objects.

What do you mean with "virtual counting methods"?
The main reason I decided not to introduce reference counting for every
class was that some people feared the performance impact of the reference
counting. Though Florian said that it shouldn't be that bad on today's
CPUs...
That said: if someone wants to test it one could add "refcounted" to
TObject (my code should(!) handle that correctly) and see what happens...
(of course there will be problems with circular references then)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 17:19 schrieb "Kostas Michalopoulos" :
>
> On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort 
wrote:
>>
>> There are multiple existing ones already see  e.g.
http://www.freepascal.org/docs-html/ref/refse21.html
>
>
> But all of those (and "absolute" that Sven mentioned) are not used in
function parameters (something that i already mentioned). However if this
isn't needed for function parameters, then IMO it is fine. However i'd
rather have it with a semicolon like in cdecl, external, etc. IMO it
inconsistent when some use a semicolon and others do not.

A semicolon has the problem that you need to distinguish between it being a
modifier and a normal following identifier as not every keyword is a
keyword in every context (like for example "read" and "write" for
properties).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 
wrote:

> Then the compiler can safely generate refcounting code for *all* objects
> and non-weak references, and the counting methods take care of required
> operations
>

Wouldn't that cause all objects to "pay" (both in terms of performance and
memory) for something that they don't use? IMO it is better to fully
disallow subclasses from introducing reference counting than force
functionality on objects that they don't need to use.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Jonas Maebe schrieb:

Additionally, as mentioned before, I still believe it's a very bad idea 
to be able to inherited from a regular class and turn it into a 
reference counted class. Reference counted and non-reference-counted
classes are different language entities with different behaviour and 
different code generation requirements, and hence should be completely 
unrelated.


Something like ShortString and AnsiString?

I agree that a *compiler-based* implementation, of a single TObject base 
class, would require two sets of libraries, starting with the RTL, else 
a mix of units with different object types cannot be avoided in an 
executable. And it would almost disallow to use DLLs, of a possibly 
different model.


Even if you completely forbid typecasting a reference counted class into 
a non-reference-counted parent class, simply calling an inherited method 
from a non-reference-counted parent class can easily completely mess up 
the reference counting (e.g. suppose that inherited method inserts 
"self" into a linked list).


ACK. The only way out; I can see; is adding the *possibility* of 
refcounting to TObject, meaning Add/ReleaseRef methods and a RefCount 
field. Then the compiler can safely generate refcounting code for *all* 
objects and non-weak references, and the counting methods take care of 
required operations. Delphi offers two means for specialized 
refcounting, the virtual counting methods, and the (COM compatible?) 
refcount value of -1 for unmanaged objects.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort 
wrote:

> There are multiple existing ones already see  e.g.
> http://www.freepascal.org/docs-html/ref/refse21.html
>

But all of those (and "absolute" that Sven mentioned) are not used in
function parameters (something that i already mentioned). However if this
isn't needed for function parameters, then IMO it is fine. However i'd
rather have it with a semicolon like in cdecl, external, etc. IMO it
inconsistent when some use a semicolon and others do not.

In any case, as i said, this isn't really an important aspect.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 14:54 schrieb "hinsta...@yandex.ru" :
>
> I tested it a bit; thoughts so far:
> 1. generic and refcounted do not work well together: no matter how I
arrange it, a class can't be both generic and refcounted, it causes the
compiler to produce some internal error 2014092205.

Oh, good to know. I'll take a look at that when I find the time :) (and
that internal error is one I added for that feature, so that's a "good"
sign as well ;) )

> 2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled
into ignoring it with if-defs

That's expected. It's a new (and experimental) feature after all ;)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Richard Apthorp]

Hi Sven,

Actually found that HP have a documented list:
http://h71000.www7.hp.com/doc/82final/6083/6083pro_032.html#extensions_app
I'm not sure I feel qualified to change the compiler but as I work on this 
porting project I will be creating a list of the main changes which I could 
then decide if beneficial to create a new compiler mode for (with a lot of help 
I hope!!!)
Thanks again for your advice, Richard.


-Original Message-
From: Sven Barth [mailto:pascaldra...@googlemail.com] 
Sent: 27 October 2014 11:38
To: FPC developers' list
Cc: Richard Apthorp
Subject: Re: [fpc-devel] VMS Pascal Compiler mode

On 27.10.2014 11:51, Richard Apthorp wrote:
> Hi Sven,
>
> Thanks for the reply. Yes some of it could be handled by a unit for 
> special types etc but not  sure what adding a new mode means or how to do it, 
> could this handle differences such as - Type conversions:
> Var::integer  instead of integer(var)
> Passing in characters arrays:
> Procedure Proc(str : array [A..B] of char); Defaulting parameters 
> Procedure Proc(p1 : integer := 1; p2,p3:integer); And calling it in 
> different ways:
> Proc(,2,3);
> Proc(1,p3 := 3, p2:= 2);

Maybe you should indeed first try to list all differences then we could help 
you with judging how hard they are to be implemented. E.g. calling arguments by 
name is already implemented for some special cases (AFAIK for IDispatchable 
interfaces or something like that) so that would already be there. And then we 
could guide you for implementing them starting from the easy ones to the hard 
ones so that you could get familiar with the compiler.

Regards,
Sven

PS: Please keep the fpc-devel list as recipent as well (either as main To or as 
CC) so that others interested in this topic can read your messages as well. 
Maybe it would be better if you'd subscribe to the list, because then others 
don't need to CC you if they answer.

>
> -Original Message-
> From: Sven Barth [mailto:pascaldra...@googlemail.com]
> Sent: 25 October 2014 13:10
> To: FPC developers' list; Richard Apthorp
> Subject: Re: [fpc-devel] VMS Pascal Compiler mode
>
> On 24.10.2014 13:22, Richard Apthorp wrote:
>> Porting a large project running on the VMS operating system written 
>> in Pascal to Linux and Free Pascal.
>> However there is no compiler switch for HP VMS Pascal. Would be 
>> really useful if just the main syntax differences could be catered for eg:
>> Specifying parameter names in procedure calls (instead of overload) - 
>> I could provide a list.
>> Noticed GNU Pascal has such a compiler switch.
>> Anyway in the middle of writing a pre-processor to make the syntax 
>> changes but wondering if anybody has done something similar?
>> HP having just announced VMS retirement after 35 years there must be 
>> a lot of HP Pascal around some of which will need to be ported!
>
> I'm not aware of anyone developing a compiler mode for HP VMS Pascal (or 
> Compaq Pascal as it seems to be called). So feel free to implement it 
> yourself (you could start small by only adding the new mode first and maybe a 
> compatibility unit for special type declarations that will be automatically 
> loaded like the ObjPas unit for modes Delphi and ObjFPC or the MacPas unit 
> for the Mac Pascal mode).
>
> Regards,
> Sven
>

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinsta...@yandex.ru]

I tested it a bit; thoughts so far:1. generic and refcounted do not work well together: no matter how I arrange it, a class can't be both generic and refcounted, it causes the compiler to produce some internal error 2014092205.2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled into ignoring it with if-defs27.10.2014, 16:15, "Sven Barth" : Am 27.10.2014 11:37 schrieb : I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested in it would test it and detect potential problems in practice rather than in thought experiments Then just checkout the branch I mentioned in my initial mail. It's implemented there and is not a thought experiment. I'm not going to commit this any time soon to trunk, because 1) there are too many open points and 2) trunk is preparing for release branching thus no new big features and especially not as critized ones as this. Regards, Sven , ___ fpc-devel maillist  -  fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 11:47 schrieb "Kostas Michalopoulos" :
> Is there any other such use of a keyword? I think it is a bad idea to
introduce a new keyword placement if there isn't already one since it
breaks consistency (all those other keywords are placed in front of the
type name whereas this special one is placed after).

I know of two: "absolute" and "location" (the later only on Amiga/Morphos
on m68k and PPC) and those are what I based it on.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 11:26 schrieb "Jonas Maebe" :
>
>
> On 27 Oct 2014, at 11:10, Sven Barth wrote:
>
>> A third possiblity would be to implement a cycle detector in the
decrement helper, but I haven't come around that for now as I wanted to get
a first rough implementation out to you all ;)
>
>
> I think that a cycle detector should be an independent component, just
like heaptrc is an independent add-on to detect memory problems in regular
programs.

My plan was to add this as a callback. Thus way one could use a collector
in a different thread or a synchronous one :)

>
> Additionally, as mentioned before, I still believe it's a very bad idea
to be able to inherited from a regular class and turn it into a reference
counted class. Reference counted and non-reference-counted classes are
different language entities with different behaviour and different code
generation requirements, and hence should be completely unrelated.
>
> Even if you completely forbid typecasting a reference counted class into
a non-reference-counted parent class, simply calling an inherited method
from a non-reference-counted parent class can easily completely mess up the
reference counting (e.g. suppose that inherited method inserts "self" into
a linked list).

That's why I implemented it like this for now so we could check on real
code whether there would be any problems instead of theorizing about it. :)
Afterall I said it's experimental and nowhere near final.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

Am 27.10.2014 11:37 schrieb :
>
> I think we should just roll out this feature to FPC trunk and let people
test it; so those who are interested in it would test it and detect
potential problems in practice rather than in thought experiments

Then just checkout the branch I mentioned in my initial mail. It's
implemented there and is not a thought experiment. I'm not going to commit
this any time soon to trunk, because 1) there are too many open points and
2) trunk is preparing for release branching thus no new big features and
especially not as critized ones as this.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:37 AM, hinsta...@yandex.ru wrote:

I think we should just roll out this feature to FPC trunk and let people test 
it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments


Hmm.

The potential TList problem to me seems a little bit similar to what 
Embarcadero (IMHO frivolously) did with the new Strings.


The "List" Classes (TStrings siblings) force a certain encoding. You can 
use them to store differently encoded strings but this will force very 
expensive conversions.  You of course could use (i.e. do)  TStrings work 
alikes for  different encoding, (separately for all might need), but the 
multiple brands of the String type introduce a huge PITA.


And fpc seems to be forced to blindly follow.

Here we might get two incompatible brands of the "TObject" class.

This might ask for some thinking about the consequences.

-Michael




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Flávio Etrusco]

On Mon, Oct 27, 2014 at 8:37 AM, Sven Barth  wrote:
> On 27.10.2014 11:51, Richard Apthorp wrote:
>>
>> Hi Sven,
>>
>> Thanks for the reply. Yes some of it could be handled by a unit for
>> special types etc but not  sure what adding a new mode means or how to do
>> it, could this handle differences such as -
>> Type conversions:
>> Var::integer  instead of integer(var)
>> Passing in characters arrays:
>> Procedure Proc(str : array [A..B] of char);
>> Defaulting parameters
>> Procedure Proc(p1 : integer := 1; p2,p3:integer);
>> And calling it in different ways:
>> Proc(,2,3);
>> Proc(1,p3 := 3, p2:= 2);
>
>
> Maybe you should indeed first try to list all differences then we could help
> you with judging how hard they are to be implemented. E.g. calling arguments
> by name is already implemented for some special cases (AFAIK for
> IDispatchable interfaces or something like that) so that would already be
> there. And then we could guide you for implementing them starting from the
> easy ones to the hard ones so that you could get familiar with the compiler.
>
> Regards,
> Sven

It would be really nice if one could enable calling arguments by name
using modeswitch ;-)
http://www.freepascal.org/docs-html/prog/progsu106.html

> PS: Please keep the fpc-devel list as recipent as well (either as main To or
> as CC) so that others interested in this topic can read your messages as
> well. Maybe it would be better if you'd subscribe to the list, because then
> others don't need to CC you if they answer.
>
>
>>
>> -Original Message-
>> From: Sven Barth [mailto:pascaldra...@googlemail.com]
>> Sent: 25 October 2014 13:10
>> To: FPC developers' list; Richard Apthorp
>> Subject: Re: [fpc-devel] VMS Pascal Compiler mode
>>
>> On 24.10.2014 13:22, Richard Apthorp wrote:
>>>
>>> Porting a large project running on the VMS operating system written in
>>> Pascal to Linux and Free Pascal.
>>> However there is no compiler switch for HP VMS Pascal. Would be really
>>> useful if just the main syntax differences could be catered for eg:
>>> Specifying parameter names in procedure calls (instead of overload) -
>>> I could provide a list.
>>> Noticed GNU Pascal has such a compiler switch.
>>> Anyway in the middle of writing a pre-processor to make the syntax
>>> changes but wondering if anybody has done something similar?
>>> HP having just announced VMS retirement after 35 years there must be a
>>> lot of HP Pascal around some of which will need to be ported!
>>
>>
>> I'm not aware of anyone developing a compiler mode for HP VMS Pascal (or
>> Compaq Pascal as it seems to be called). So feel free to implement it
>> yourself (you could start small by only adding the new mode first and maybe
>> a compatibility unit for special type declarations that will be
>> automatically loaded like the ObjPas unit for modes Delphi and ObjFPC or the
>> MacPas unit for the Mac Pascal mode).
>>
>> Regards,
>> Sven

Regards,
Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] VMS Pascal Compiler mode

[Sven Barth]

On 27.10.2014 11:51, Richard Apthorp wrote:

Hi Sven,

Thanks for the reply. Yes some of it could be handled by a unit for special 
types etc but not  sure what adding a new mode means or how to do it, could 
this handle differences such as -
Type conversions:
Var::integer  instead of integer(var)
Passing in characters arrays:
Procedure Proc(str : array [A..B] of char);
Defaulting parameters
Procedure Proc(p1 : integer := 1; p2,p3:integer);
And calling it in different ways:
Proc(,2,3);
Proc(1,p3 := 3, p2:= 2);


Maybe you should indeed first try to list all differences then we could 
help you with judging how hard they are to be implemented. E.g. calling 
arguments by name is already implemented for some special cases (AFAIK 
for IDispatchable interfaces or something like that) so that would 
already be there. And then we could guide you for implementing them 
starting from the easy ones to the hard ones so that you could get 
familiar with the compiler.


Regards,
Sven

PS: Please keep the fpc-devel list as recipent as well (either as main 
To or as CC) so that others interested in this topic can read your 
messages as well. Maybe it would be better if you'd subscribe to the 
list, because then others don't need to CC you if they answer.




-Original Message-
From: Sven Barth [mailto:pascaldra...@googlemail.com]
Sent: 25 October 2014 13:10
To: FPC developers' list; Richard Apthorp
Subject: Re: [fpc-devel] VMS Pascal Compiler mode

On 24.10.2014 13:22, Richard Apthorp wrote:

Porting a large project running on the VMS operating system written in
Pascal to Linux and Free Pascal.
However there is no compiler switch for HP VMS Pascal. Would be really
useful if just the main syntax differences could be catered for eg:
Specifying parameter names in procedure calls (instead of overload) -
I could provide a list.
Noticed GNU Pascal has such a compiler switch.
Anyway in the middle of writing a pre-processor to make the syntax
changes but wondering if anybody has done something similar?
HP having just announced VMS retirement after 35 years there must be a
lot of HP Pascal around some of which will need to be ported!


I'm not aware of anyone developing a compiler mode for HP VMS Pascal (or Compaq 
Pascal as it seems to be called). So feel free to implement it yourself (you 
could start small by only adding the new mode first and maybe a compatibility 
unit for special type declarations that will be automatically loaded like the 
ObjPas unit for modes Delphi and ObjFPC or the MacPas unit for the Mac Pascal 
mode).

Regards,
Sven



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Michael Van Canneyt wrote:




On Mon, 27 Oct 2014, Kostas Michalopoulos wrote:



On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell  
wrote:


  So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?



IMO if a program takes care to avoid cyclic references (with a heaptrc-like 
unit to find such cases), it shouldn't pay for the overhead that a detector 
would have. Of course i'd
make that a compiler directive (or some global flag) since others may not 
care.


@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird 
to me compared to other keyword usage in Free Pascal. If at least there was 
a semicolon after the type
it may look more consistent (after all, cdecl, extern, etc are placed after 
a semicolon). F.e.


Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there 
aren't "cdecl", "extern", "static", etc function arguments.


Is there any other such use of a keyword? I think it is a bad idea to 
introduce a new keyword placement if there isn't already one since it 
breaks consistency (all those other
keywords are placed in front of the type name whereas this special one is 
placed after).


as far as I can see, the proposal of Sven is perfectly in line with existing 
constructs and does not break consistency.


var
 a : something deprecated ; cdecl; external 'x';

Fields in classes:

 aa : integer implementation; static;


That should have been
  aa : integer unimplemented; static;

Anyway, see e.g.
http://www.freepascal.org/docs-html/ref/refse5.html#x17-160001.5

So Sven is not deviating from existing practices.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, Kostas Michalopoulos wrote:



On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell  wrote:

  So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?


IMO if a program takes care to avoid cyclic references (with a heaptrc-like 
unit to find such cases), it shouldn't pay for the overhead that a detector 
would have. Of course i'd
make that a compiler directive (or some global flag) since others may not care.

@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird to 
me compared to other keyword usage in Free Pascal. If at least there was a 
semicolon after the type
it may look more consistent (after all, cdecl, extern, etc are placed after a 
semicolon). F.e.

Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there aren't "cdecl", 
"extern", "static", etc function arguments.

Is there any other such use of a keyword? I think it is a bad idea to introduce 
a new keyword placement if there isn't already one since it breaks consistency 
(all those other
keywords are placed in front of the type name whereas this special one is 
placed after).


as far as I can see, the proposal of Sven is perfectly in line with existing 
constructs and does not break consistency.

var
  a : something deprecated ; cdecl; external 'x';

Fields in classes:

  aa : integer implementation; static;

etc. Modifiers are always placed after the thing they modify.

Reference counting behaviour for function arguments is already controlled through const, var and out, 
so I don't think a new keyword needs to be used for them.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Marco van de Voort]

In our previous episode, Kostas Michalopoulos said:
>  I think it is a bad idea to
> introduce a new keyword placement if there isn't already one since it
> breaks consistency (all those other keywords are placed in front of the
> type name whereas this special one is placed after).

There are multiple existing ones already see  e.g. 
http://www.freepascal.org/docs-html/ref/refse21.html
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Kostas Michalopoulos]

On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell 
wrote:

>
> So you suggest cyclic references should be forbidden (erroneous
> programming technique). Are they ?
>

IMO if a program takes care to avoid cyclic references (with a heaptrc-like
unit to find such cases), it shouldn't pay for the overhead that a detector
would have. Of course i'd make that a compiler directive (or some global
flag) since others may not care.

@Sven:
TBH i don't feel that strongly (heh) about the syntax. It just looks weird
to me compared to other keyword usage in Free Pascal. If at least there was
a semicolon after the type it may look more consistent (after all, cdecl,
extern, etc are placed after a semicolon). F.e.

Foo: TFoo; weak;

But that probably wont work well with function arguments. After all there
aren't "cdecl", "extern", "static", etc function arguments.

Is there any other such use of a keyword? I think it is a bad idea to
introduce a new keyword placement if there isn't already one since it
breaks consistency (all those other keywords are placed in front of the
type name whereas this special one is placed after).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

I think we should just roll out this feature to FPC trunk and let people test 
it; so those who are interested in it would test it and detect potential 
problems in practice rather than in thought experiments

27.10.2014, 13:35, "Michael Schnell" :
> On 10/27/2014 11:26 AM, Jonas Maebe wrote:
>>   (e.g. suppose that inherited method inserts "self" into a linked list).
>
> Or using TList with it ?
>
> Would we need an alternate TList for ref-counted objects ?
>
> -Michael
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:26 AM, Jonas Maebe wrote:

 (e.g. suppose that inherited method inserts "self" into a linked list).

Or using TList with it ?

Would we need an alternate TList for ref-counted objects ?

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Schnell]

On 10/27/2014 11:26 AM, Jonas Maebe wrote:



I think that a cycle detector should be an independent component, just 
like heaptrc is an independent add-on to detect memory problems in 
regular programs.


So you suggest cyclic references should be forbidden (erroneous 
programming technique). Are they ?




Additionally, as mentioned before, I still believe it's a very bad 
idea to be able to inherited from a regular class and turn it into a 
reference counted class. Reference counted and non-reference-counted 
classes are different language entities with different behaviour and 
different code generation requirements, and hence should be completely 
unrelated.


So there simply would be a ref-counted variant of TObject you can 
inherit from use as an option ?


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

On 27 Oct 2014, at 11:10, Sven Barth wrote:

A third possiblity would be to implement a cycle detector in the  
decrement helper, but I haven't come around that for now as I wanted  
to get a first rough implementation out to you all ;)


I think that a cycle detector should be an independent component, just  
like heaptrc is an independent add-on to detect memory problems in  
regular programs.


Additionally, as mentioned before, I still believe it's a very bad  
idea to be able to inherited from a regular class and turn it into a  
reference counted class. Reference counted and non-reference-counted  
classes are different language entities with different behaviour and  
different code generation requirements, and hence should be completely  
unrelated.


Even if you completely forbid typecasting a reference counted class  
into a non-reference-counted parent class, simply calling an inherited  
method from a non-reference-counted parent class can easily completely  
mess up the reference counting (e.g. suppose that inherited method  
inserts "self" into a linked list).



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[hinstance]

In my opinion, such thing as cycle detector would be an unnecessary 
complication; however I have not studied the subject in depth therefore not sure

27.10.2014, 13:10, "Sven Barth" :
> On 27.10.2014 11:12, Nikolai Zhubr wrote:
>>  Hello Sven!
>>
>>  25.10.2014 0:23, Sven Barth:
>>>  Hello together!
>>>
>>>  I've now finished my Proof of Concept ARC implementation which is based
>>>  on the RFC I published a few weeks back:
>>  [...]
>>
>>  Could you please elaborate a bit on what will happen to cyclic
>>  references? Is there autodetection in place already? And then, will it
>>  be usable for managing of e.g. 100M-long 2-way linked list?
>
> Cycles need to be manually handled currently by declaring some
> participants of the cycle as "weak".
> Another possiblity would be DoDi's suggestion to implement a "finalizer"
> (e.g. Delphi's DisposeOf) which would force the instance to destroy
> itself, though that would come with its own set of problems...
> A third possiblity would be to implement a cycle detector in the
> decrement helper, but I haven't come around that for now as I wanted to
> get a first rough implementation out to you all ;)
>
> Yours,
> Sven
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 27.10.2014 11:12, Nikolai Zhubr wrote:

Hello Sven!

25.10.2014 0:23, Sven Barth:

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:

[...]

Could you please elaborate a bit on what will happen to cyclic
references? Is there autodetection in place already? And then, will it
be usable for managing of e.g. 100M-long 2-way linked list?


Cycles need to be manually handled currently by declaring some 
participants of the cycle as "weak".
Another possiblity would be DoDi's suggestion to implement a "finalizer" 
(e.g. Delphi's DisposeOf) which would force the instance to destroy 
itself, though that would come with its own set of problems...
A third possiblity would be to implement a cycle detector in the 
decrement helper, but I haven't come around that for now as I wanted to 
get a first rough implementation out to you all ;)


Yours,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Nikolai Zhubr]

Hello Sven!

25.10.2014 0:23, Sven Barth:

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:

[...]

Could you please elaborate a bit on what will happen to cyclic 
references? Is there autodetection in place already? And then, will it 
be usable for managing of e.g. 100M-long 2-way linked list?


Thanks.
Nikolai
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 09:39, Michael Van Canneyt wrote:



On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 

> wrote:

Definitely not. We are in Pascal and there such directives 
are

placed afterwards.

how about these:

1) 'record' ---> 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.


To me, 'weak' is modifying the type rather than the variable itself (much 
like 'packed record').


That is a wrong way of thinking, because the type itself is not modified at all.
The behaviour of the variable is modified.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[ListMember]

On 2014-10-27 09:39, Michael Van Canneyt wrote:



On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 

> wrote:

Definitely not. We are in Pascal and there such 
directives are

placed afterwards.

how about these:

1) 'record' ---> 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.


To me, 'weak' is modifying the type rather than the variable itself 
(much like 'packed record').


So, it would make more sense to me if we wrote it like

FVariable: weak TSometype;


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[Michael Van Canneyt]

On Mon, 27 Oct 2014, ListMember wrote:


On 2014-10-27 00:00, Sven Barth wrote:
  On 26.10.2014 12:17, Kostas Michalopoulos wrote:
On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth 
mailto:pascaldra...@googlemail.com>> wrote:

    Definitely not. We are in Pascal and there such directives are
    placed afterwards.

how about these:

1) 'record' ---> 'packed record'
2) AVariable: Integer absolute AnotherVariable.


Weak is a modifier, just as static, cdecl, external etc.

In Pascal, modifiers are placed after the thing they modify.

'absolute' modifies AVariable. That just confirms the above rule.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[ListMember]

On 2014-10-27 00:00, Sven Barth wrote:

On 26.10.2014 12:17, Kostas Michalopoulos wrote:

On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth mailto:pascaldra...@googlemail.com>> wrote:

Definitely not. We are in Pascal and there such directives are
placed afterwards.

how about these:

1) 'record' ---> '*packed* *record*'
2) AVariable: Integer *absolute**AnotherVariable*.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel