Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
On 28 Aug 2010, at 01:07, Martin wrote: > But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time > only, e.g. just open+lock, read, close), then there is the slim chance of a > conflict, and this error could be explained. FPC opens it as a regular text file using a regular assign/reset. I don't think that will result in exclusive access. It also checks for its existence using sysutils.fileexists, but I doubt that one asks for exclusive access either. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
On 28/08/2010 10:59, Jonas Maebe wrote: On 28 Aug 2010, at 01:07, Martin wrote: But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time only, e.g. just open+lock, read, close), then there is the slim chance of a conflict, and this error could be explained. FPC opens it as a regular text file using a regular assign/reset. I don't think that will result in exclusive access. It also checks for its existence using sysutils.fileexists, but I doubt that one asks for exclusive access either. Afaik uing assign/reset using exclusive lock on windows. Lazarus did use them for logfiles, and you couldn't open the lockfile (fro tailing) because of that. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
In our previous episode, Jonas Maebe said: > > But *if* fpc does lock the fpc.cfg file exclusively ( for a very short > > time only, e.g. just open+lock, read, close), then there is the slim > > chance of a conflict, and this error could be explained. > > FPC opens it as a regular text file using a regular assign/reset. I don't > think that will result in exclusive access. It also checks for its > existence using sysutils.fileexists, but I doubt that one asks for > exclusive access either. Doesn't that depend on filemode? I see a lot of places in the compiler where it is read/changed/preserved: comprsrc.pas: oldfmode:=Filemode; comprsrc.pas: Filemode:=0; comprsrc.pas: Filemode:=oldfmode; cstreams.pas: oldfilemode : byte; cstreams.pas: oldfilemode:=filemode; cstreams.pas: filemode:=$40 or Mode; cstreams.pas: filemode:=oldfilemode; finput.pas:ofm:=filemode; finput.pas:filemode:=0; finput.pas:filemode:=ofm; impdef.pas: OldFileMode:longint; impdef.pas: OldFileMode:=filemode; impdef.pas: filemode:=0; impdef.pas: filemode:=OldFileMode; ppu.pas: ofmode:=filemode; ppu.pas: filemode:=$0; ppu.pas: filemode:=ofmode; ppu.pas:ofm:=filemode; ppu.pas:filemode:=0; ppu.pas:filemode:=ofm; None of them in options. So there could be something to it, specially since it is so early in the startup. Hmm, I did a quick writeln(filemode) just before the config file was opened, and it printed 2, read/write (the default. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
On 28 Aug 2010, at 12:15, Martin wrote: > On 28/08/2010 10:59, Jonas Maebe wrote: >> On 28 Aug 2010, at 01:07, Martin wrote: >>> But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time >>> only, e.g. just open+lock, read, close), then there is the slim chance of a >>> conflict, and this error could be explained. >> FPC opens it as a regular text file using a regular assign/reset. I don't >> think that will result in exclusive access. It also checks for its existence >> using sysutils.fileexists, but I doubt that one asks for exclusive access >> either. > > Afaik uing assign/reset using exclusive lock on windows. I thought that was only for regular files, not for text files (since if you open a regular file using reset, you can still write to it, while that's not the case for text files). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On 2010-08-28 01:38, Graeme Geldenhuys wrote: Yes, I placed in on GitHub. You can clone the repository as follows: via git protocol (faster): git clone git://github.com/graemeg/fpprofiler.git via http protocol: git clone http://github.com/graemeg/fpprofiler.git Alternatively (though not tested) - you should be able to download a zip archive of the latest code via this URL: http://github.com/graemeg/fpprofiler/zipball/HEAD NOTE: Make sure the code you want to profile is backed up, or in some repository. I have found cases where the profiler (fpp) failed to modify all units due to parsing errors, then failed again restoring all units to what they were. I think I fixed this bug, but I thought I better let you know Thank you - I will try it today or tomorrow. I will write if I'll find some bugs. Regards Žilvinas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
Marco van de Voort schrieb: Doesn't that depend on filemode? I see a lot of places in the compiler where it is read/changed/preserved: [...] None of them in options. So there could be something to it, specially since it is so early in the startup. IMO we should add an (optional?) filemode parameter to the old style file procedures, so that every file can be opened with the appropriate settings and without affecting other files. Just like in TFileStream... The default mode should not lock any file, at least for read(only) access. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Type redefinitions
Several type redefinitions are reported in compiling the compiler, can these be removed? Most types (PByte...) are declared in systemh.inc and objpash.inc. I'm not sure, but can't these redefinitions be excluded conditionally, for e.g. mode OBJPAS (as set for the compiler)? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
In our previous episode, Hans-Peter Diettrich said: > > Doesn't that depend on filemode? I see a lot of places in the compiler where > > it is read/changed/preserved: > [...] > > None of them in options. So there could be something to it, specially since > > it is so early in the startup. > > IMO we should add an (optional?) filemode parameter to the old style > file procedures, so that every file can be opened with the appropriate > settings and without affecting other files. We still have to support the filemode var out of compatibility. So I'm not exactly sure what you are proposing. Do you mean you want a kind file I/O wrappers somewhere to avoid this in new code? Then there is no reason to use mutate the existing routines, just write a new unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
Hi all, The safecall calling convention is now implemented for i386/linux in fpc-trunk. The next step to get XPCom working now is to update the QueryInterface (and AddRef and ReleaseRef) definitions in IInterface. Problem is that they are defined as 'stdcall' but to make them work on Linux/i386 that should be 'cdecl'. So that will change in the near future. (using an ifdef, so it's stdcall on windows, cdecl on all others) This will break backwards compatibility on non-windows systems for users who implement their own QueryInterface, AddRef and ReleaseRef methods! But it's easy fixable and the compiler will complain. The problem that then still remains is that the IID parameter of QueryInterface has to be passed by reference. Now it's defined as 'const' so it won't be passed by reference in Linux (cdecl). Now I see three options: pass all records with a size bigger then the register-size by reference for all cdecl-params which are defined as 'const'. The same happens for stdcall parameters on Windows and this is suggested before by some people. This should not lead to any backwards compatibility problems, because when 'const' is used right, it leaves the decision to pass by reference or not to the compiler. So when this changes, there shoudn't be any problem. But this is also the weak part of this solution: with this change the developer will use 'const' to make the compiler pass the variable by reference, which should be free for the compiler to decide. (In other words: it will make the usage of 'const' parameters for connecting with external (c) programs very difficult, because the meaning of const will be difference than how c-compilers will handle it) Second option is to change the 'iid' parameter of QueryInterface from 'const' to 'var'. This is not a really option, though, because then you can not pass constant values to QueryInterface anymore. Which means that you also can not pass an IInterface (and thus it's GUID) to it directly. This leads to the third option: introduce a new parameter-type which will always pass the variable by reference, and will be handled as being constant by the compiler. We could name it 'in', for example. First and third option are possible. I would choose for the third option because this will also settle these kind of problems for the future. (This idea is also mentioned on this list before by others) Or are there any considerations/arguments that I missed? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
In our previous episode, Joost van der Sluis said: > > Now I see three options: pass all records with a size bigger then the > register-size by reference for all cdecl-params which are defined as > 'const'. The same happens for stdcall parameters on Windows and this is > suggested before by some people. This should not lead to any backwards > compatibility problems, because when 'const' is used right, it leaves > the decision to pass by reference or not to the compiler. So when this > changes, there shoudn't be any problem. > But this is also the weak part of this solution: with this change the > developer will use 'const' to make the compiler pass the variable by > reference, which should be free for the compiler to decide. The weak part of this kind of reasoning is that first the application crashes, and only a week the developer finds the reason. If he is skilled enough. Nearly all problems I had when porting big Delphi packages to FPC turned to be hidden assumptions like this, or string conversion assumptions. Of course, most of those are solved now, but this could produce similar problems on systems with multiple compilers that adhere to cdecl semantics. > (In other words: it will make the usage of 'const' parameters for > connecting with external (c) programs very difficult, because the > meaning of const will be difference than how c-compilers will handle it) The problem is that currently we use the calling convention to decide all aspects of the ABI, not just calling convention. This is specially a problem on systems where the ABI is not rigidly followed by everybody like on Windows. The only solution is to fully parameterise the calling process (which registers to use, how and what const means const, how to use the stack, what to do with floating point (skip int regs for them or not) etc. This might also allow to kill som assembler from the RTL, since you can do much more that defies the standard procedural regime in Pascal. I've seen this in compilers before, but they didn't have the mass of parameters that FPC has. I don't know if it is doable. (and even if, it is probably a _major_ rewrite) > Second option is to change the 'iid' parameter of QueryInterface from > 'const' to 'var'. This is not a really option, though, because then you > can not pass constant values to QueryInterface anymore. Which means that > you also can not pass an IInterface (and thus it's GUID) to it directly. Getting back to the practical, if you really need to force byref, we need a way to force byref, period. Delphi compatible or not. A way to keep it delphi compat might be using a directive. (e.g. to specify the minimal size of byref passing) Because now cdecl is tuned to this application, but potentially hampering or breaking compatibility with others. And tomorrow a bugreport will be filed for another. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
On Sat, 2010-08-28 at 14:14 +0200, Marco van de Voort wrote: > In our previous episode, Joost van der Sluis said: > > > > Now I see three options: pass all records with a size bigger then the > > register-size by reference for all cdecl-params which are defined as > > 'const'. The same happens for stdcall parameters on Windows and this is > > suggested before by some people. This should not lead to any backwards > > compatibility problems, because when 'const' is used right, it leaves > > the decision to pass by reference or not to the compiler. So when this > > changes, there shoudn't be any problem. > > But this is also the weak part of this solution: with this change the > > developer will use 'const' to make the compiler pass the variable by > > reference, which should be free for the compiler to decide. > > The weak part of this kind of reasoning is that first the application > crashes, and only a week the developer finds the reason. If he is skilled > enough. Nearly all problems I had when porting big Delphi packages to FPC > turned to be hidden assumptions like this, or string conversion assumptions. Yes, you are completely right. That's why changing the queryinterface definition from stdcall to cdecl isn't really a problem, because the compiler will complain. This change will lead to hidden results. > Of course, most of those are solved now, but this could produce similar > problems on systems with multiple compilers that adhere to cdecl semantics. > > > (In other words: it will make the usage of 'const' parameters for > > connecting with external (c) programs very difficult, because the > > meaning of const will be difference than how c-compilers will handle it) > > The problem is that currently we use the calling convention to decide all > aspects of the ABI, not just calling convention. This is specially a > problem on systems where the ABI is not rigidly followed by everybody like > on Windows. > > The only solution is to fully parameterise the calling process (which > registers to use, how and what const means const, how to use the stack, what > to do with floating point (skip int regs for them or not) etc. This might > also allow to kill som assembler from the RTL, since you can do much more > that defies the standard procedural regime in Pascal. > > I've seen this in compilers before, but they didn't have the mass of > parameters that FPC has. I don't know if it is doable. (and even if, it is > probably a _major_ rewrite) And only usable for professionals who know what they are doing. And aren't you exaggerate it a bit? (schieten met een kanon op een mug) I only need a forced pass-by-reference. > > Second option is to change the 'iid' parameter of QueryInterface from > > 'const' to 'var'. This is not a really option, though, because then you > > can not pass constant values to QueryInterface anymore. Which means that > > you also can not pass an IInterface (and thus it's GUID) to it directly. > > Getting back to the practical, if you really need to force byref, we need a > way to force byref, period. Delphi compatible or not. A way to keep it > delphi compat might be using a directive. (e.g. to specify the minimal > size of byref passing) Hmm... could be an idea. But then you can't manually decide which paremeter should be passed by reference and which one not. And isn't the suggested 'in' parameter type much cleaner in it's use? > Because now cdecl is tuned to this application, but potentially hampering or > breaking compatibility with others. And tomorrow a bugreport will be filed > for another. For example? I don't see where adding 'in' will lead to problems, except that the code won't compile on Delphi anymore? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
On 28 Aug 2010, at 13:59, Joost van der Sluis wrote: > Now I see three options: pass all records with a size bigger then the > register-size by reference for all cdecl-params which are defined as > 'const'. The same happens for stdcall parameters on Windows and this is > suggested before by some people. This should not lead to any backwards > compatibility problems, because when 'const' is used right, it leaves > the decision to pass by reference or not to the compiler. So when this > changes, there shoudn't be any problem. That's not true for cdecl. For cdecl, "const" means "pass the same way as if it was declared as 'const' in C". > This leads to the third option: introduce a new parameter-type which > will always pass the variable by reference, and will be handled as being > constant by the compiler. We could name it 'in', for example. "in" is not a good name, it does not convey any information to the reader about how the parameter is passed (and since the whole point of introducing such a modifier is changing the way the parameter is passed...). Past suggestions have included "const var" (http://bugs.freepascal.org/view.php?id=7612), "constvar" and "constref". > First and third option are possible. I would choose for the third option > because this will also settle these kind of problems for the future. > (This idea is also mentioned on this list before by others) > > Or are there any considerations/arguments that I missed? Another option is to declare it as "mwpascal" instead of "cdecl". The mwpascal calling convention is identical to cdecl, except that all structured const parameters are passed by reference (for compatibility with the MetroWerks Pascal compiler). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
On Sat, 2010-08-28 at 14:39 +0200, Jonas Maebe wrote: > On 28 Aug 2010, at 13:59, Joost van der Sluis wrote: > > > Now I see three options: pass all records with a size bigger then the > > register-size by reference for all cdecl-params which are defined as > > 'const'. The same happens for stdcall parameters on Windows and this is > > suggested before by some people. This should not lead to any backwards > > compatibility problems, because when 'const' is used right, it leaves > > the decision to pass by reference or not to the compiler. So when this > > changes, there shoudn't be any problem. > > That's not true for cdecl. For cdecl, "const" means "pass the same way as if > it was declared as 'const' in C". > > > This leads to the third option: introduce a new parameter-type which > > will always pass the variable by reference, and will be handled as being > > constant by the compiler. We could name it 'in', for example. > > "in" is not a good name, it does not convey any information to the reader > about how the parameter is passed (and since the whole point of introducing > such a modifier is changing the way the parameter is passed...). Past > suggestions have included "const var" > (http://bugs.freepascal.org/view.php?id=7612), "constvar" and "constref". I would say 'constref'. But what do you thing of the idea from Marco to use a directive? It will avoid problems with Delphi-compatibility. http://www.hu.freepascal.org/fpcircbot/cgifpcbot?channel=fpc&fromdate=2010-08-28&todate=2010-08-28&linecount=50&fromtime=14%3A20&totime=15%3A00&sender=&msg= > > First and third option are possible. I would choose for the third option > > because this will also settle these kind of problems for the future. > > (This idea is also mentioned on this list before by others) > > > > Or are there any considerations/arguments that I missed? > > Another option is to declare it as "mwpascal" instead of "cdecl". The > mwpascal calling convention is identical to cdecl, except that all structured > const parameters are passed by reference (for compatibility with the > MetroWerks Pascal compiler). Hey, that's the easiest for me, now. No need to change the compiler. But i'm not sure that this is the best solution for the long run. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
On 28 Aug 2010, at 14:54, Joost van der Sluis wrote: > I would say 'constref'. But what do you thing of the idea from Marco to > use a directive? It will avoid problems with Delphi-compatibility. > > http://www.hu.freepascal.org/fpcircbot/cgifpcbot?channel=fpc&fromdate=2010-08-28&todate=2010-08-28&linecount=50&fromtime=14%3A20&totime=15%3A00&sender=&msg= Probably being predictable again: I don't like the ability to change the meaning of keywords using switches like that. It makes code harder to read, because you have to know which switches are active before you know what the code actually means. In case of mwpascal, the modifier that influences the behaviour is right next to the declaration, so the context is clear (unless you use macros, but it's possible to obfuscate everything using that feature). >> Another option is to declare it as "mwpascal" instead of "cdecl". The >> mwpascal calling convention is identical to cdecl, except that all >> structured const parameters are passed by reference (for compatibility with >> the MetroWerks Pascal compiler). > > Hey, that's the easiest for me, now. No need to change the compiler. But > i'm not sure that this is the best solution for the long run. My second preference would be something like constref. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?
In our previous episode, Jonas Maebe said: > > > http://www.hu.freepascal.org/fpcircbot/cgifpcbot?channel=fpc&fromdate=2010-08-28&todate=2010-08-28&linecount=50&fromtime=14%3A20&totime=15%3A00&sender=&msg= > > Probably being predictable again: Don't read too much into that. > I don't like the ability to change the meaning of keywords using switches > like that. It makes code harder to read, because you have to know which > switches are active before you know what the code actually means. It is meant to avoid a heavy ifdefed solution which is IMHO even worse. It is also meant to avoid the combinatorial aspect. For calling conventions you need a separate one for each detail deviation. Or you need to introduce separate modifiers for separate aspects of the calling convention. This includes an ability to keep code depending on current cdecl semantics running. > >> Another option is to declare it as "mwpascal" instead of "cdecl". The > >> mwpascal calling convention is identical to cdecl, except that all > >> structured const parameters are passed by reference (for compatibility > >> with the MetroWerks Pascal compiler). > > > > Hey, that's the easiest for me, now. No need to change the compiler. But > > i'm not sure that this is the best solution for the long run. > > My second preference would be something like constref. Needs ifdef in every prototype that needs to remain Delphi compat, and that IMHO makes it an hard sell. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RTTI unit
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On 2010-08-28 01:38, Graeme Geldenhuys wrote: Alternatively (though not tested) - you should be able to download a zip archive of the latest code via this URL: http://github.com/graemeg/fpprofiler/zipball/HEAD Tried sample project today. Some a comment and a question: 1) I have a strange error when the same file is modified twice (and afterwards restored twice). One is: insert: E:\lazarus\components\fpprofiler\demo\test001\test001.pp .. OK and another is: insert: .\test001.pp - After these two modifications modified units have compilation errors (duplicate uses units). - When modifications are removed - duplicate files are deleted totally. - (BTW, when -r is used for fpp it is passed to fpc and fpc is not happy.) - I am attaching console output if it helps at all. - I used a workaround: In procedure InsertProfilingCode(FileList: TStrings; ModTokenProc: TModTokenProc); - //make a copy of the original files and process them for i := 0 to FileList.Count - 1 do begin if FileExists(FileList[i] + FPPROF_EXT) then begin // <-- if the file is processed (backup exists) - do not process it again writer.AddIgnoredFile(FileList[i]); // <-- (don't know if this is required?) Continue; // <-- end; // <-- - In procedure RemoveProfilingCodeFromFile(const FileName: string); - begin if FileExists(FileName) then begin // <-- if there is no backup file - do not delete original file - 2) Where should I write comments/bug reports for fpprofiler? Regards Žilvinas E:\lazarus\components\fpprofiler\demo\test001>fpp -r test001.pp -MObjFPC -Scghi -O1 -gl -vewnhi -l -FuE:\lazarus\components\fpprofiler\fpprof\ -Fu. -FUlib\i386 -win32\ -oproject1.exe GNU FreePascal profiler 0.2 Copyright 2007 Darius Blaszyk. Contributions by Graeme Geldenhuys 2010. FPP is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for FPP. insert: E:\lazarus\components\fpprofiler\demo\test001\test001.pp .. OK insert: E:\lazarus\components\fpprofiler\demo\test001\test_001.pas .. OK insert: E:\lazarus\components\fpprofiler\fpprof\fpmake.inc .. OK insert: E:\lazarus\components\fpprofiler\fpprof\fpmake.pp .. OK insert: E:\lazarus\components\fpprofiler\fpprof\fpprof.pp .. OK insert: E:\lazarus\components\fpprofiler\fpprof\fpputils.pas .. OK insert: E:\lazarus\components\fpprofiler\fpprof\fppwriter.pas .. OK insert: E:\lazarus\components\fpprofiler\fpprof\systemtime.inc .. OK insert: E:\lazarus\components\fpprofiler\fpprof\win32systemtime.inc .. O K insert: .\test001.ppinsert: .\test_001.pasexecuting: fpc -gl -FuE:\lazarus\compo nents\fpprofiler\fpprof -r test001.pp -MObjFPC -Scghi -O1 -gl -vewnhi -l -FuE:\l azarus\components\fpprofiler\fpprof\ -Fu. -FUlib\i386-win32\ -oproject1.exe Hint: Start of reading config file E:\lazarus\fpc\fpc_my\bin\i386-win32\fpc.cfg Hint: End of reading config file E:\lazarus\fpc\fpc_my\bin\i386-win32\fpc.cfg Error: Illegal parameter: -r Hint: -? writes help pages Error: E:\lazarus\fpc\fpc_my\bin\i386-win32\ppc386.exe returned an error exitcod e (normal if you did not specify a source file to be compiled)___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] regarding RTTI unit mail
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
P. S. I know I didn't have to include -FuE:\lazarus\components\fpprofiler\fpprof\ This log is from an experiment... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] regarding RTTI unit mail
Op Sat, 28 Aug 2010, schreef 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? 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] regarding RTTI unit mail
Daniël Mantione schrieb:
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.
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.
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
