Re: [fpc-pascal] fpGUI Toolkit source repository migrated to Git
On Tue, 07 Apr 2009 13:06:06 +0200 Vincent Snijders wrote: > Do you generate nightly tarballs for people who don't want the 0.4 version of > tortoisegit? http://fpgui.git.sourceforge.net/git/gitweb.cgi?p=fpgui See "snapshot". ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DBus interface needs an update
On Mon, 18 May 2009 13:38:55 +0200 Matthias Klumpp wrote: > I've spent hours to get the Pascal DBus interface working for me, but even > the example code does not work. I need to use DBus to but I can not make it work. Has anyone made DBus and HAL work with fpc? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTempFileName in Linux
On Wed, 6 Oct 2010 09:41:03 +0200 (CEST) Michael Van Canneyt wrote: > I'm open for some more sophisticated algorithm which does some more checking. > > Michael. Honour one of the temp directory environment variables, I know of TMPDIR, TEMP, TMP. I think it would be best to check them in order and then default to /tmp/. Create a folder in the temp directory naming it after the user name. E.g /tmp/myusername/ Ensure only the owner can read and write in the folder. Create a folder in "/tmp/myusername/" using your program name. Then create your temp file. so you have "/tmp/myusername/programname/tmp01" You should only need to check for symlinks, hardlinks and read/write rights on the "/tmp/myusername" folder. What is the cost? Two more inodes More cpu time What do you get? It hides the file's names Good layout Easier to use Tomoyo and Apparmour. On Wed, 06 Oct 2010 09:40:42 +0200 Sven Barth wrote: >Windows (or at least ReactOS) seems to use GetTickCount to generate a >random filename: Do not you use random file names without a subdirectory because you can not use Tomoyo or Apparmour to lock the program down. I use this trick with Firefox. From my .bashrc file mkdir /tmp/$USER >> /dev/null 2>&1 chmod u=rwx,g=rwx,o-rwx /tmp/$USER >> /dev/null 2>&1 export TMPDIR="/tmp/$USER" >> /dev/null 2>&1 #!/bin/sh mkdir $TMPDIR/firefox/ env TMPDIR=$TMPDIR/firefox /usr/bin/firefox $@ From my Tomoyo profile: allow_read/write /tmp/\*/firefox/\* allow_rename /tmp/\*/firefox/\* /tmp/\*/firefox/\* allow_rename /tmp/\*/firefox/\*.part /home/\*/Downloads/\* allow_truncate /tmp/\*/firefox/\* allow_unlink /tmp/\*/firefox/\* Since there is no way to predict what the file name will be, permissions have to be done on a per folder basis, not per file. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTempFileName in Linux
On Thu, 07 Oct 2010 11:01:44 +0200 Sven Barth wrote: > Btw: What are Tomoyo and Apparmour (I can imagine what the second one > is, but I don't know what functionality they provide)? http://tomoyo.sourceforge.jp/ https://wiki.ubuntu.com/AppArmor ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] class constants
Hello, Does FPC support class constants, and if it doesn't, are there any plans to add this support? Example: type TMyClass = class begin private const MyConst = '123'; end; Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class constants
Marco van de Voort wrote: Does FPC support class constants, and if it doesn't, are there any plans to add this support? Have a look at http://www.freepascal.org/faq.var#extensionselect The question would be "what would make this possible?" Hi Marco, I'm not sure what you mean - do you mean would I be willing to write the support myself? Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class constants
Henry Vermaak wrote: I'm not sure what you mean - do you mean would I be willing to write the support myself? i think he's asking what the use of it is. number 2 under the link he gave. Oh, ok. Well, I'll try to summarize: Class constants add the ability to provide scoped, "namespaced" constants. Although one can handle basic scoping with global constants, by placing them in interface vs implementation, they were not designed to be scope-limited. They also do not provide a way to group several constants under a common name, though one can simulate this functionality using creative constant names. Some of the benefits of class constants are: 1. They provide object-oriented constants, 2. They simplify coding by saving the developer from having to write long constant names to distinguish global constants from each other. 3. They reduce coding errors due to the ability to only make public what is necessary, keeping what is visible to outside units/classes to a mimimum. I'm sure that there are other benefits, I just can't think of them off the top of my head. Personally, the main reason I need them is for compatibility. I have a large Delphi codebase that I'm porting to FPC and it uses class constants all over the code. Here is an example of their use: -- Start of Unit1.pas -- unit Unit1; interface type TTest = class private const PrivateConst = '1'; public const PublicConst = '1'; constructor Create; end; implementation constructor TTest.Create; var Str: String; begin Str := PrivateConst; Str := PublicConst; end; end. -- End of Unit1.pas -- -- Start of Unit2.pas -- unit Unit2; interface type TTest2 = class constructor Create; end; implementation uses Unit1; constructor TTest.Create; var Str: String; begin Str := TTest.PrivateConst; // Will cause compiler error because PrivateConst is not visible to this class. Str := TTest.PublicConst; end; end. -- End of Unit2.pas -- Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class constants
Marco van de Voort: Class constants add the ability to provide scoped, "namespaced" constants. A constant is already in a scope, the unit. The unit scope is a very open scope. Via class constants, one gets private, protected and public scoping for constants, all of which are essential scope levels for OOP. Although one can handle basic scoping with global constants, by placing them in interface vs implementation, they were not designed to be scope-limited. They also do not provide a way to group several constants under a common name, though one can simulate this functionality using creative constant names. Stuff them in one unit. unitname.constant. 1 unit for every unique constant prefix is asking a lot. Some applications have many (>100) different constant prefixes. Some of the benefits of class constants are: 1. They provide object-oriented constants, That's a description, not a benefit. Taste matters are difficult to measure. Constants are not OOP, adding class constants provides OOP constants. 3. They reduce coding errors due to the ability to only make public what is necessary, keeping what is visible to outside units/classes to a mimimum. Units/move them to implementation. The chance that random classes in the same unit clash is negliable. What if the developer wishes to provider the ability to override their class, and allow access to the constants from descendant classes? The constants inside the implementation section are invisible to descendant classes in other units. Class constants provide protected-level scoping Personally, the main reason I need them is for compatibility. I have a large Delphi codebase that I'm porting to FPC and it uses class constants all over the code. IMHO that is the only decent reason. Technically IMHO it doesnt make much sense, it's just a dotnetism, copying blindly from a different world to make nice feature butlletlists. And like the rest of the dotnetims, they are relatively little used, probably mostly out D7- compat reasons. And thus they are waiting for an implementor. I'm not aware of work being done on any of them (though I have a vaguely recollection that the strict private and protected exist, but I'm not sure if in fully compat form). Besides implementing, making a good study of what they _EXACTLY_ do, and a bunch of testcases/unittests could really further the cause also. Thanks for the info. Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] static class methods
Why do static class methods in FPC have a "Self" parameter? In Delphi, static class methods do not have a Self parameter. Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] static class methods
Jonas Maebe wrote: I'm not sure how Delphi could handle this without passing the VMT as invisible parameter (and from a cursory look at the code generated by Kylix, it does appear to pass the VMT). Delphi doesn't allow static class methods to be virtual. Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] static class methods
Micha Nelissen: What are "static" class methods? From RAD Studio 2007's Help file on Methods (ms-help://borland.bds5/devcommon/methods_xml.html): Like class methods, class static methods can be accessed without an object reference. Unlike ordinary class methods, class static methods have no Self parameter at all. They also cannot access any instance members. (They still have access to class fields, class properties, and class methods.) Also unlike class methods, class static methods cannot be declared virtual. Methods are made class static by appending the word static to their declaration. "Plain" class methods are allowed to be virtual, surely. Yes, "plain" class methods can be virtual, and can be overridden. Jon ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
