Re: [fpc-devel] Create installer for MacOSX
On 15 mrt 2005, at 05:58, Adriaan van Os wrote: PackageMaker is basically a GUI interface to pax, so it might be possible to create a Mac OS X installer package with command line tools. You would have to look at the file layout of a package by using PackageMaker first or by looking at an existing package. I didn't try this, it is just an idea. Another important remark about making a package: always make sure all files you add to a package are owned by root/wheel (or root/admin). You don't want a random user on the target system, who happens to have the same UID as you do, to be able to overwrite those files. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] crt unit fix
On 15 mrt 2005, at 08:51, Dr. Karl-Michael Schindler wrote: There is a endian related bug in the crt unit, which breaks the examples ex10 and ex11 of the crt docs. The following fixes the bug and makes the code more obvious. I suggest to replace the following two routines. Tested on Mac OS X. It fixes web bug 3788 (I submitted that one) and 3391 as good as possible (submitted by coraxyn). Some small editing corrections as well. There's still a problem somewhere though: at the end of ex10, the output on the screen is Line 1 Line 2 Line 3 Oops, forgot Line 2, let's insert at the cursor postion Under Linux, there is no space before Line 2, and from looking at the source, there shouldn't be any. Nevertheless, your patch already solves some other problems, so I've committed it. Thanks. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
Michael Van Canneyt wrote: 1. What happens if f would use a variable from somefun, and f is called when somefun is no longer executed ? This can not happen when the function parameter cannot be stored anywhere. 2. I see no difference whatsoever between typ_fun and iso_fun, except the use of an extra type, which, in my opinion, does not change anything to the usage or code of these functions. If one is allowed, the other should be allowed as well. As I understand the ISO convention, it just shall disallow to create variables of the procedural type, which were required to store such a reference. In Pascal two type declarations are different, even if they look the same. Let me add some more thoughts about procedural types: - I like the ability to declare procedural types, the ISO convention looks like one of the many incredible C hacks to me :-( - For the restricted use of local subroutines as procedural parameters I could imagine a const prefix in the accepting procedure declaration: procedure my_fun(const pf: tfun); The const prefix here means that the procedure pf only can be called, but cannot be stored in a variable. The compiler then can assure that local subroutines are passed only as const arguments. This syntax requires no changes to the parser. The compiler message for a missing const could be a warning instead of an error, to prevent compatibility/portability problems. Other compilers should ignore the const, so that accordingly modified source code still should be portable? Hmm, the hidden frame parameter still will make a difference with local subroutines. At least in Pascal calling convention, where the arguments are popped by the called subroutine, not by the caller... - I'd appreciate to define procedures based on procedural types as well. Currently a change to the procedural type requires updates of all derived procedure declarations. Something like: myproc: tfun = begin blabla end; IMO such a definition would better implement the strict Pascal typing, instead of only a type equivalence determined by the procedure signature. Unfortunately(?) this syntax is incompatible with procedural variables, so that it would disallow to create such variables. A procedure prefix would make the definition look like a function returning an TProcType. But perhaps somebody has a better idea? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Friend classes?
I just came about code that uses protected members of other classes, defined in other units. In Delphi this possible by a declaration like: type TFriendClass = class(TNotMyClass); After this declaration the protected (and private?) members of TNotMyClass are accessible, using TFriendClass as an type alias. Now my questions: 1) Is such behaviour also available with FPC? In non-Delphi modes? 2) How portable are such friend classes? Does there exist some (other) standard for this purpose? 3) What alternatives could be used, so that not all class members must be made public, when they shall be used only in specific related units? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
On Tue, 15 Mar 2005, DrDiettrich wrote: I just came about code that uses protected members of other classes, defined in other units. In Delphi this possible by a declaration like: type TFriendClass = class(TNotMyClass); This is a simple descendent. After this declaration the protected (and private?) members of TNotMyClass are accessible, using TFriendClass as an type alias. Now my questions: 1) Is such behaviour also available with FPC? In non-Delphi modes? Yes. Only protected. 2) How portable are such friend classes? Does there exist some (other) standard for this purpose? The above is a simple descendent, so I'm not sure about this 'friend' ? 3) What alternatives could be used, so that not all class members must be made public, when they shall be used only in specific related units? ? Please explain. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
