[fpc-devel] compiler/utils/samplecfg, FPCWiki
In the source repository, the current version for trunk/compiler/utils/samplecfg has a line #-Fu~/fpc/packages/base/*/units/$fpctarget;~/fpc/fcll/units/$fpctarget;~/fpc/rtl/units/$fpctarget Since it is commented out, it does not matter much what is on that line; it is just an example. But should /fcll/ not be /fcl/ ? --- By the way, I contributed a page about FCL to the FPCWiki. Could someone add `(FCL)' to the Main_Page after the heading `Free Component Library' under Main components (the page is locked). That way, it will be more in line with FPC and RTL. It would also be good to include `Free Component Library' before FCL on the page FCL (I could not find out how to edit that part); similar for FPC and RTL pages. Just listing the abbreviation as a title is not convenient for those unfamiliar with FreePascal. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Jamie McCracken wrote: Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. True and thats why I suggested ref counting Tobjects only so that no manual memory management is required. I tend to make heavy use of TList, Tstringlist and TFilestream objects so I cant do everything with tcomponents alas. What do you mean with Tobjects? Isn't TObject the ancestor of all classes? If you mean a dedicated root class for reference counted objects, you can use interface instead of class variables (at least in Delphi, not sure about FPC). As was already pointed out, GC doesn't work well without assistance in actual code. There's no big difference between setting a reference to Nil, and calling the destructor or FreeAndNil, for the same purpose. Auto-destroyed local objects, or local interface references, require hidden try-finally blocks; from similar discussions I know that many people don't like such invisible magics, for performance and othX-Mozilla-Status: 0009 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
Hans-Peter Diettrich wrote: You obviously missed that a compiler does not only consist of scanner and parser, but that optimizers and code generators also have to be implemented. For multiple target platforms and CPU's... The new dialect simply makes the syntax less annoying and verbose - it wont alter functionality as such so altering those shouldn't be on the agenda (I hope!). The new dialect simply requires a multi pass parser. It shouldn't be too hard to adapt the existing one for this purpose. Of course the compiler will only use this if the source file tells it to use Rad Pascal dialect so it wont affect or harm compiler performance of other dialects. I can also totally eliminate circular refs in the multi pass phase (it will require three passes if there are circular refs, otherwise one or two passes will be sufficient). The advantage for the developer here is that only one uses clause ever needs to be used. Looking at the tokens.pas file in the compiler, every token in the parser is specified against which dialect implements it (via the mode switch) so it shouldn't be too difficult to remove any redundant syntax where its not needed. (I emphasize removing not adding syntax here!) The safe approach is to write an preprocessor, that can translate your dialect into any implemented language, so that the compiler code must not be touched. Then you'll find out that your dialect needs code completion and other features, that have to be implemented as well, apart from the compiler. These are fine exercises before you start bothering with the compiler code. I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor. For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar. If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here. Thanks jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
El Sábado, 4 de Junio de 2005 11:00, Jamie McCracken escribió: I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor. See the recent thread How to manually control debug information in this list. I asked the very same thing. For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar. If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here. I've been playing with the same concept for years, so I think I do have some advice :-) The preprocessor is the right step to start. I have a working scanner and the next tasks (conditional compilation and expressions) planned in detail. If you're interested, we could share the work. -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug 4004
Can I ask somebody to have another look at this bug - it was flagged
unreproducable on the web system, but I still get it from the current
svn as shown below.
(Note that the orginal report was on ppc but I have the same fault on i386)
Colin
$ fpc ord.pas
Free Pascal Compiler version 2.1.1 [2005/06/04] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling ord.pas
Linking ord
13 Lines compiled, 0.0 sec
$ ./ord
-1
Runtime error 215 at $080480C5
$080480C5
$0804813A
$ more ord.pas
{$R+}{$Q+}
function d(a,b:Char):Integer;
begin
d := Ord(a)-Ord(b);
end;
var
i: Integer;
begin
i := Ord('0')-Ord('1');
WriteLn(i);
WriteLn(d('0','1'));
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Build 2.0.0 documentation in html format
Hi all, before I start re-inventing the wheel I ask it here: If I try to build the documentation using latex2html it complains that ref.htex coudn't be found. If I change the makefile manually so that it uses ref.tex etc I get the following: make[1]: Entering directory `/local/rpmbuild/BUILD/fpc/docs' make[1]: *** No rule to make target `refex.chk', needed by `ref.chk'. Stop. make[1]: Leaving directory `/local/rpmbuild/BUILD/fpc/docs' How can I fix this? And does anyone knows a way to build the .pdf's without changing the memory-buffer in a configuration file? (Maybe some option, somewhere?) And two comments: And not all examples in refex can be build. (still uses memavailable?) The docs-readme says that latex2html is the default, but it isn't. -- Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build 2.0.0 documentation in html format
If I change the makefile manually so that it uses ref.tex etc I get the following: make examples maybe? Do you run make pdf ? Or in a desperate case run make or make pdf in refex/ And does anyone knows a way to build the .pdf's without changing the memory-buffer in a configuration file? (Maybe some option, somewhere?) See FPC wiki, somewhere linked from release engineering. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build 2.0.0 documentation in html format
On Sat, 4 Jun 2005, Joost van der Sluis wrote: Hi all, before I start re-inventing the wheel I ask it here: If I try to build the documentation using latex2html it complains that ref.htex coudn't be found. If I change the makefile manually so that it uses ref.tex etc I get the following: make[1]: Entering directory `/local/rpmbuild/BUILD/fpc/docs' make[1]: *** No rule to make target `refex.chk', needed by `ref.chk'. Stop. make[1]: Leaving directory `/local/rpmbuild/BUILD/fpc/docs' How can I fix this? You can't. And does anyone knows a way to build the .pdf's without changing the memory-buffer in a configuration file? (Maybe some option, somewhere?) You should set an environment variable pool_size, which should be exported. And two comments: And not all examples in refex can be build. (still uses memavailable?) The docs-readme says that latex2html is the default, but it isn't. It isn't and it is no longer supported. You must use tex4ht. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Danny Milosavljevic wrote: you *might* have less overhead using ref count on a tstringlist then making it a component (if you are creating more than one reference to it or passing it as a parameter to a function then yes a component would be more efficient). You also have the problem of what you are going to set the owner to in the case where its only a temp variable. owner nil, and free later yeah and now you are back at manual management. ref cycles are not a big deal - show me one bit of the FCL that has cycles using Tobjects only (IE not with Tcomponents)! I dont know the fcl enough for that. But generally speaking, most (nice) trees have that problem actually. Good point but are trees like that the exception or the rule? I mean Delphi's TTreeview's TTreeNode is not cyclic AFAIK. however they are better implemented using Tcomponent where the parent objects can automatically free the children. In any case we would need weak refs to overcome problems like these in tobjects. so in your code we would have something like: b.Parent := weak (a); where weak() prevents the ref count from incrementing. Or a quick hack would be to manually dec the ref count (assuming we provide a public Tobject method for this) after that assignment. What we shouldn't do is rely on the developer who is using the class to nil it at the end cause that defeats the whole purpose. I admit its not perfect but exceptions like these should hopefully be few and far between. Its obvious that you wont have cycles in things like TstringList, TFileStream objects etc. In fact only in Tlist are you likely to have cycles and in the add method you could check to make sure no self references are added and throw an exception if they are. A knowledgable developer can of course set any object to nil if he knows that there are or likely to be cycles but again this will only happen in a very small minoirty of cases. For gui stuff, it like happens all the time... Absolutely, which is why components will not be ref counted for tree stuff, it like happens all the time ... hmm dunno - its hard to say how common occurances like your example are as all the trees I have recalled using have not been cyclic like that. I would implement ref count on TObjects with a protected boolean variable to turn it off for TComponent descendants as we dont need to ref count components and components by their nature are far more likely to have cycles then plain objects. Its also obvious that pascal by its nature is far better suited to efficient ref counting than others like java because java strings are objects and ref counting a whole load of short term objects can adversely affect performance. (imagine deleting a stringlist where all and pascal strings are ? records or pointers to records. If you use shortstrings then it will be fast cause they are not ref counted. Java strings by comparison are classes so they will always suck in this regard. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
