Hi,

I was wondering if anybody could direct me in the right direction (either mail, wiki) with regard to following questions.

What I want to do:
Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and "customattributes" if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo.

For this I'd like to know a few things:
- First off: would this kind of thing even be considered for inclusion?
- How to get it into repository/feedback from core? (through feature request with attachment in mantis?)
- Codestyle conventions for fpc-code? (including licence-header etc)
- Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types?
- Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )?
- I've read somewhere that nothing gets included if no unit-tests are provided. Is this using fpcunit? Any pointers on the testingsystem, do's and don'ts are welcome.

Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess)

Anyhow, the first question is the more crucial one. If anybody is interested in the (public) interfaces of the tobjecttypes, I can provide those. If there needs to be a debate first, fine by me ;-)

kind regards,
Dimitri Smits

Hi,

(just hate it when you send something after re-reading it a few times, and a minute later you know that there is something important you forgot to ask)

Since objectnames and interfaces are cloned from Delphi everywhere in the fpc-rtl, I was wondering if this is legitimate use and not a copyright violation?

ie: the "interface" is the same, the implementation is different (unless trivial).

Is this, or is this not an issue?

kind regards,
Dimitri Smits

Op Sat, 28 Aug 2010, schreef Dimitri Smits:

The EU software directive says a few words about this matter:

"Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive."

In other words: It is okay to copy the interface, but not its expression.

Copyright is about creative decisions. For example the order in which procedures, variables are declared are creative decisions and thus part of the expression of an interface. If you make the same creative decisions as the original program, you violate copyright.

Generally safe is the clean room approach: Someone who doesn't know the Delphi source code implements it from documentation. This is internationally considered best practise and can avoid discussions wether it is a violation or not. If you happen to know the Delphi sources, you have to be carefull what you write.

The EU software directive allows us to develop FPC in a reasonably safe way, but the borders between independent implementation and copyright violation unfortunately is not black and white.

Daniël

I doubt that. It should be possible to compare interfaces easily, for completeness and version compatibility. In languages like C and C++ you can get hell when you change the order of elements, with interleaved #defines and #ifs (what's possible in Pascal as well).

An interface is a contract, and as such every translation *must* follow the original closely.

Documentation is known to not reflect the implementation properly, in all aspects. So another cleanroom were required, that documents the given *implementation*, in a way that allows to implement it in a different way or language.

The EU software directive allows us to develop FPC in a reasonably safe way, but the borders between independent implementation and copyright violation unfortunately is not black and white.

The above formulation is almost a literal translation of the German copyright law (UrhG). The UrhG also allows to observe and even decompile a software, in order to make it interface with some other software ("interoperability"). The only restriction: the results may not be disclosed. It would be interesting to get the full text of the EU directive, in order to find out more.

DoDi

Op Sun, 29 Aug 2010, schreef Hans-Peter Diettrich:

If the order of elements is enforced, it is not a creative decision, thus both programmers can make the same decision without violating each others copyright.

An interface is a contract, and as such every translation *must* follow the original closely.

Be happy an interface by itself is not copyrightable. If you read about the history about the software directive there was a big fight about this, because some companies like IBM wanted copyright to protect them against clones from the far east, while others actually wanted interoperating competing products.

But even though they are not copyrightable, you cannot verbatimly copy interface files. There is copyright on the expression of them.

No surpise here: All copyright laws of member states should be compatible with the directive, though many have skipped the wording about interfaces, but that does not matter a lot. You can the directive here:

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:HTML

Replace the EN in the URL in e.g. DE, NL, ... to read it in another language.

Daniël

In our previous episode, Dani?l Mantione said:

This sidestep thread over the EU directive misses the main point. Legal or not, the question is do we really copy interfaces straight from Borland source? Afaik not. At least I never did, I always looked up header definitions from places as Delphi.about.com

Well, the compiler doesn't support custom attributes.

For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion?

Yes. Any unit to increase Delphi compatibility is worth of inclusion.

- How to get it into repository/feedback from core? (through feature request with attachment in mantis?)

I'll handle that; Just post it on mantis, I'll look into it.

- Codestyle conventions for fpc-code? (including licence-header etc)

Modified LGPL header (see any rtl file).
Code style: follow the Borland style guide.

- Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types?

Not sure I know what you mean by this ?

- Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )?

Nothing. I'll take care of that, you just write the code.

- I've read somewhere that nothing gets included if no unit-tests are - provided. Is this using fpcunit? Any pointers on the testingsystem, - do's and don'ts are welcome.

You can use fpcunit; there are sample tests in the fcl-fpcunit directory.

All other daily test programs use a different mechanism: they must return a zero exit code. Nonzero exit code means that there is an error.

You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus.

Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess)

Let me handle that. Focus on the code.

Michael.

Dimitri Smits wrote

What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and "customattributes" if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo.

At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features:

1. Extended records (methods, class operators)
2. Generics as in delphi
3. Attributes

Once I tried to implement extended records in the compiler but the changes were too big for the time I had and I had left that idea for the better time.

Best regards,
Paul Ishenin.

Hi Paul,
thanks for the input.

4. scopeable RTTI ($RTTI directive)

incremental changes. First try the basic types, then classes/objects/records. And leave out those types for now that cannot be ported. In a next phase, then include what is needed either in compiler or fpc-specific rtti objects (in same style/spirit).

As for that (4) above. The last few months I've seen this requested a few times (either direct or indirect) on mailinglists.

kind regards,
Dimitri Smits

If the order of elements is enforced, it is not a creative decision, thus both programmers can make the same decision without violating each others copyright.

How can one be sure that the arrangement is not required, somehow? ;-)

Competing products seem to have won, else FPC and Lazarus were illegal.

But even though they are not copyrightable, you cannot verbatimly copy interface files. There is copyright on the expression of them.

ACK.

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:HTML

Thanks :-)

I didn't know that the Directive is so old, and has become part of the German law almost literally.

DoDi

In our previous episode, Hans-Peter Diettrich said:

I didn't claimed to. That goes for anything on the web btw, which is why I generally try Microsoft sources first, and see if I can derive it from that in combination with testing with applications. This doesn't go for everything but goes a long way.

I also avoid using materials that I received under my Delphi eula, but try to use websources. That includes Embarcaderos, since I consider those published.

I haven't researched every legal aspect of that policy, but I considered that an easier defendable position then trying to defy an agreed EULA first.

Another murky subject is the docs (in CHM format and others) that have been (are?) available from Embarcadero FTP server. I never used those either, but partially that is also because Borland started posting docs online before it became necessary for me.

In our previous episode, Hans-Peter Diettrich said:

Since this feature is not fully connected to unicode I don't see the need for that restriction. Even if we only allow it in a possible future D2009+ mode, changing mode assignments is probably much less work than implementing it.

There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first.

Michael.

In our previous episode, Michael Van Canneyt said:

Delphi Xe is not the multiplatform version anyways.

That sounds like a compiler problem, not a makefile problem. That is beyond my capabilities.

The makefiles have worked for 16 years. Unless you changed them, I see nothing that could cause it to break except a broken compiler.

Michael.

This sidestep thread over the EU directive misses the main point. Legal or not, the question is do we really copy interfaces straight from Borland source? Afaik not. At least I never did, I always looked up header definitions from places as Delphi.about.com

How can you be sure that this information has been acquired and published in accordance to the law?

But you are right, this is not the right place for a detailed discussion. Let's do our best, *not* to violate the rights of others...

DoDi

> For this I'd like to know a few things: > - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion.

IMO compatibility with the Delphi Unicode version were a different project, requiring some manpower. There exist some more questionable features, resulting from the (attempted and dropped) .NET version, like dotted unit names.

IMO we should wait for Delphi "X", and then update FPC/Lazarus according to that platform independent version.

DoDi

Michael.

Can you help out with my makefile problem, arising during recompilation of the compiler (NoGlobals branch)?

The build fails when the (relative) searchpaths are prefixed with "..\" in a later stage of the make cycle, as already reported.

DoDi

In our previous episode, Michael Van Canneyt said:

Professionally I'm not terribly interested in either atm. I am mildly interested in Windows 64-bit, but in my current job it has no real big priority either. On the other hand, when most camera manufacturers start moving focus from 32-bit to 64-bit, it needs to be there instantly.

The 64-bit version is where the focus is.
Since that requires them to rework the compiler and then the complete VCL, they're in for some work.

Michael.

I mean that for implementing RTTI unit compatible by interface with delphi you need that 3 features I wrote about. Or how you will port for example TValue record:

   TValue = record
   private
     function GetIsEmpty: Boolean;
     ...
     procedure Get<T>(out Result: T);
   public
     // Easy in
     class operator Implicit(const Value: string): TValue;
    ...

1. GetIsEmpty - a method in a record.
2. Get<T>(out Result: T) - generics as in delphi
3. class operator Implicit(const Value: string): TValue - delphi class operators

I was wrong about Attributes - seems they are not used in the rtti unit interface.

Best regards,
Paul Ishenin.

Op Sun, 29 Aug 2010, schreef Paul Ishenin:

You can come a long way by using FPC alternatives: Use objects, and
overload the := operator.

Daniël

I have browsed through the system.pas file of 2010 on one occasion (when I had the chance). Was full of MACOS and Linux IFDEF's already!

kind regards,
Dimitri Smits

I see no chance how the compiler can influence the command arguments, generated by Make.

The makefiles have worked for 16 years. Unless you changed them, I see nothing that could cause it to break except a broken compiler.

It may be a configuration problem. Can you build the new NoGlobals compiler(s)?

DoDi

The linux ifdefs are there since 2002.

Michael.

If the same command works with trunk, then the cause is in the compiler, since that is the only thing that differs ?

The compiler is built. ppudump is not.
But the same makefile works for trunk, so the cause is in the compiler.

Michael.

Right, because the search paths are modified by make, after the compiler has been built and moved.

The compiler cannot work with wrong search paths, obviously. So the question is still not answered: what causes make to provide wrong -Fi arguments to the compiler?

DoDi