Re: [fpc-devel] Friend classes?
Marco van de Voort wrote: The definitions of templates, inline procedures or macros do not immediately contribute to the size of a compiled module, only when they are *used* in code modules. That goes for all routines. I'm not sure what you mean. A global procedure, exported in the interface section of a unit, always must be be compiled. Only the linker can determine which procedures really are used in a project, and which ones can be omitted. A specific procedure can be used in one project, but can be unused in another project. Think of the standard units like System... In comparison with C/C++, uses summarizes the #include of header files and the dependency checks of Make. The important difference (in TP/Delphi/FPC) is that preprocessor state doesn't follow USES statements. Do you mean that only one level of dependencies must be checked with uses, whereas even the indirectly #included files must be checked for changes? That allows the compiler to auto-find the compilation order.. What's the importance of a compilation order? Many properties make Pascal compilers faster than C/C++ compilers. The effect of uses is equivalent to C/C++ precompiled header files. The effect of units is that it is a lot safer (more guaranteed) and easier to implement that precompiled header files, and auto-building is also a lot easier (not requiring explicit manual compile order enforced) Again I don't understand what you mean (compile order???) :-( A C project doesn't require any compilation order, every module can be compiled independently from other modules. The problem is not the order, instead it's the condition, *when* a module has to be recompiled. The only *disadvantage* of units are the current Pascal compilers, which cannot handle circular unit references :-( It could in theory deal with some forms of circular records. Specially in the case of e.g. classes. I can imagine some kind of extended forward declarations, extending into other units. In most cases it's suffient, for compilation, that the general kind of a named type is known, in detail with pointers and references. Then it's possible to layout records, classes or other structured data types, including parameter lists of subroutines, without the exact knowledge of the referenced types. Knowledge about the exact types usually is required only when members of some referenced complex type come into the play, what does not normally happen in declarations (interface part of units). Perhaps I should give some examples: type A = record a1: B; end; B = record b1: A; end; Such a construct of course is illegal, because of infinite recursion. The same construct would be perfectly accepatble with pointers: type A = record a1: ^B; end; B = record b1: ^A; end; My idea for extended external declarations: type C = class in OtherUnit; or OtherUnit.C = class; Now the compiler can insert a reference to OtherUnit.C for every occurence of C in the remainder of the interface section. The OtherUnit now can be moved from the uses list of the interface section into the uses list of the implementation section; or it's imported implicitly, in the most comfortable case. Just recompile till CRCs don't change anymore. This allows units that circularly import eachother, but have no real circular dependancy of types to compile. Or even if the circular reference only involves types of which the sizes are known (like class etc types that are only 4 bytes). I would be happy with the latter case and no recompilation at all. However it is of course questionable if it is worth the trouble to implement this, and make it bullet proof. Maybe somebody who does graph theory as a hobby? I don't qualify as graph theory guru, even if I have already implemented the analysis of control flow graphs in my decompilers. In the case of circular unit references I'd ignore the unit dependencies for themselves, and instead concentrate on the type definitions themselves. There I'd use a list of type names, with some fixed attributes (unit, size, immediate type...), and a reference to the detailed definition of the base type, in case of more complex types. Then the existence of a (illegal) loop can be determined from a Nil reference, whenever access to the detailed definition is actually required. The unit attribute in the fixed part of a type definition is required to distinguish definitions of the same name in different units, and it also can be used to complete forward (or external) type references when the defining unit is imported later. IIRC TP could handle mild circular references and so can FPC. I don't know if this is still the case. Sounds interesting, do you have more information? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] First benchmark of Abbrevia 4.0
A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. I hope to get the original .tgz archive soon, in order to test it with GNU gzip and tar as well. The time may decrease again when the log is redirected into an file... Currently I'm implementing a ZIP module, as the last proof-of-concept for the extractors. This is a very hard job, because half of all Abbrevia modules are involved and have to be updated. Then comes the final step, the creation of new archives. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] First benchmark of Abbrevia 4.0
On Sun, 27 Mar 2005, DrDiettrich wrote: A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. Huh ? Who creates archives with million of files ? Who creates a million of files in the first place ?! I hope to get the original .tgz archive soon, in order to test it with GNU gzip and tar as well. The time may decrease again when the log is redirected into an file... It should, definitely if the test was run on Windows; Currently I'm implementing a ZIP module, as the last proof-of-concept for the extractors. This is a very hard job, because half of all Abbrevia modules are involved and have to be updated. Then comes the final step, the creation of new archives. If you need testers, I'm always prepared to help. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Hi all, In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file. My suggestion would be the same dir as the fpc source tar ball, i.e. ftp://ftp.freepascal.org/mirrors/fpc/beta/source-1.9.8/ Comments? Questions? Best wishes - Daniel Herzog (Shamelessly snaffled, defaced, abandond from here: http://www.nl.freepascal.org/lists/fpc-devel/2005-March/004784.html) :-) Sources shouldn't contain binaries. Bootstrapping compilers is always a chicken-and-egg story. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] First benchmark of Abbrevia 4.0
On Tue, 2005-03-29 at 12:29 +0200, Michael Van Canneyt wrote: On Sun, 27 Mar 2005, DrDiettrich wrote: A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. Huh ? Who creates archives with million of files ? Who creates a million of files in the first place ?! Any microsoft app seems to... I mean, OOo is what, a few hundred MB while equivalent MS is gigs+ If we are to be truly cross-platform we must be prepared for cross-platform bloat as well. ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Tue, 29 Mar 2005, Daniel Herzog wrote: Hi all, In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file. 640 K ? Is that a joke ? The compiler sources alone are more than 2Mb ? It makes no sense to do this for a distribution. You can simply use the .tar.gz file and extract that to the needed places. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Tue, 29 Mar 2005, Daniel Herzog wrote: Hi all, In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file. 640 K ? Is that a joke ? The compiler sources alone are more than 2Mb ? I think he means only the cmdline compiler. A fpc.cfg doesn't matter for bootstrap purposes. (and would be location dependant, and thus useless anyway) This because the main src archive is not OS-ARCH specific. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On 29 mrt 2005, at 15:52, Michael Van Canneyt wrote: In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file. 640 K ? Is that a joke ? The compiler sources alone are more than 2Mb ? He's talking about just a compiler binary (which, in combination with the sources, can be used to bootstrap). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Tue, 29 Mar 2005, Marco van de Voort wrote: On Tue, 29 Mar 2005, Daniel Herzog wrote: Hi all, In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file. 640 K ? Is that a joke ? The compiler sources alone are more than 2Mb ? I think he means only the cmdline compiler. A fpc.cfg doesn't matter for bootstrap purposes. (and would be location dependant, and thus useless anyway) This because the main src archive is not OS-ARCH specific. Ah, this makes more sense... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Okay. I'll totally rephrase this now: Gentoo builds (almost) everything from source. This is done via ebuilds. There is grap this file: ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/fpc-1.9.8.source.tar.gz And compile and install it. Don't expect this directory to exists very long. When the release is made this directory is moved to an other place. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Okay. I'll totally rephrase this now: Gentoo builds (almost) everything from source. This is done via ebuilds. There is grap this file: ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/fpc-1.9.8.source.tar.gz And compile and install it. Don't expect this directory to exists very long. When the release is made this directory is moved to an other place. When this directory doesnt exist anymore a new version of the ebuild is released and that's it. Every project from time to time changes it's files... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Tue, 29 Mar 2005, Daniel Herzog wrote:
Okay. I'll totally rephrase this now:
Gentoo builds (almost) everything from source.
This is done via ebuilds.
There is grap this file:
ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/fpc-1.9.8.source.tar.gz
And compile and install it.
To do this, i need a starting compiler, nothing more.
It would be nice to have a starting compiler like here:
ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/ppcARCH
And it would also be nice if you only need the version of your source -
like 1.9.8 - and can script the location of the starting compiler from
that. Like, in my case:
ftp://ftp.freepascal.org/pub/fpc/beta/source-${MY_P}/ppcARCH
Which means, the location of the starting compiler should please not
change randomly, but change with the versions...like the source tarballs
also do.
Another thing needed is, surprise!, that the corresponding starting
compiler works, e.g. always is the binary taken from here:
ftp://ftp.freepascal.org/pub/fpc/dist/Linux/ARCH/separate/binary.tar
But without all the unit's and stuff, which isnt needed to bootstrap...
I hope this clarified things a bit...
This was clear from the beginning :)
But thank you for taking the trouble yo elaborate.
We're discussing on the core list how we can accomodate for things like this.
We'll send a mail with the outcome.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Thanks. I'll, for now, work around it using the binary.tar. In practise, the only problem is the bigger download, and getting the ppc386 out of it... This was clear from the beginning :) But thank you for taking the trouble yo elaborate. We're discussing on the core list how we can accomodate for things like this. We'll send a mail with the outcome. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Tue, 29 Mar 2005, Daniel Herzog wrote: Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? ISP and consequently DNS has changed. Check the IP address. It should be 62.166.198.202 But you're the only one to report problems, which suggests the problem is somewhere on your side. Maybe a proxy ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Even better:
One single archive containing all ppc* starting compilers - this way i
could also package it quite easily for all arches, and it would easy to
script it using ppc${ARCH} everywhere...you see?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Tue, 2005-03-29 at 21:56 +0400, Alexey Barkovoy wrote: But you're the only one to report problems, which suggests the problem is somewhere on your side. Maybe a proxy ? Well I'm having problems with www.freepascal.org for around a month now (maybe even more). Sometimes it's just reappears - last time it's happened in sunday - I've succesfully filed bug report and downloaded sources from CVS. But next day it again disappeared. And now not reachable either throw www.freepascal.org or 62.166.198.202. I hate being a me to or not me, but it works fine from here (WV, USA). Web responds quickly, however last week I did notice some slowdowns. Here's a traceroute: traceroute to www.freepascal.org (62.166.198.202), 30 hops max, 38 byte packets 1 192.168.1.1 (192.168.1.1) 0.726 ms 0.674 ms 0.698 ms 2 L200.DSL-RTR1.CHAR.verizon-gni.net (151.205.95.1) 27.748 ms 27.505 ms 27.541 ms 3 130.81.12.89 (130.81.12.89) 27.846 ms 27.932 ms 27.801 ms 4 so-2-2-1-0.BB-RTR1.PHIL.verizon-gni.net (130.81.18.30) 45.182 ms 45.109 ms 44.786 ms 5 so-1-0-0-0.PEER-RTR1.PHIL.verizon-gni.net (130.81.7.226) 43.275 ms 43.577 ms 43.098 ms 6 dca-edge-03.inet.qwest.net (65.118.218.45) 46.026 ms 46.443 ms 47.013 ms 7 dca-core-02.inet.qwest.net (205.171.9.61) 46.072 ms 46.209 ms 46.054 ms 8 dca-brdr-01.inet.qwest.net (205.171.9.54) 46.780 ms 45.944 ms 46.029 ms 9 so0-1-0-622M.ar3.wdc2.gblx.net (208.51.74.9) 46.059 ms 46.696 ms 46.026 ms 10 so0-0-0-2488M.ar3.AMS2.gblx.net (67.17.73.86) 129.326 ms 128.660 ms 128.834 ms 11 Versatel-Nederland.so-3-0-0.ar3.AMS2.gblx.net (64.211.166.182) 131.008 ms Versatel-Nederland.so-2-0-0.ar3.AMS2.gblx.net (64.212.109.2) 130.687 ms Versatel-Nederland.so-3-0-0.ar3.AMS2.gblx.net (64.211.166.182) 130.895 ms 12 62.58.126.196 (62.58.126.196) 134.834 ms 134.170 ms 133.728 ms 13 unlabelled.versatel.net (62.58.126.46) 134.015 ms 135.156 ms 133.503 ms 14 cust198-193.dsl.versadsl.be (62.166.198.193) 138.201 ms 138.953 ms 138.834 ms 15 cust198-202.dsl.versadsl.be (62.166.198.202) 138.213 ms 139.142 ms 138.955 ms ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OT: pmtu/tcp window clamping
No matter what i change all those mtu's to - 1460 byte will be the bigges package that works. Are you clamping the tcp window size correctly on 0.1? If you can't do it there maybe try on 0.2. johannes Explain please. (All but 0.1 are Linux, 0.1 is a D-Link device) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
ISP and consequently DNS has changed. Check the IP address. It should be 62.166.198.202 But you're the only one to report problems, which suggests the problem is somewhere on your side. Maybe a proxy ? Well I'm having problems with www.freepascal.org for around a month now (maybe even more). Sometimes it's just reappears - last time it's happened in sunday - I've succesfully filed bug report and downloaded sources from CVS. But next day it again disappeared. And now not reachable either throw www.freepascal.org or 62.166.198.202. PS. Actually another successful connection were just after 1.9.8 release. Try www.jp.freepascal.org as a workaround (works nice here), or the google cache. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Try www.jp.freepascal.org as a workaround (works nice here), or the google cache. But I still will not be able to fill / browse bug reports! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Marco van de Voort wrote: immediately contribute to the size of a compiled module, only when they are *used* in code modules. That goes for all routines. I'm not sure what you mean. A global procedure, exported in the interface section of a unit, always must be be compiled. Only the linker can determine which procedures really are used in a project, and which ones can be omitted. A specific procedure can be used in one project, but can be unused in another project. Think of the standard units like System... Yeah, but smartlinking/deadcodeelimination is a pretty standard feature. In comparison with C/C++, uses summarizes the #include of header files and the dependency checks of Make. The important difference (in TP/Delphi/FPC) is that preprocessor state doesn't follow USES statements. Do you mean that only one level of dependencies must be checked with uses, whereas even the indirectly #included files must be checked for changes? You always have to do the #include. Always. Pre-compiled headers are possible, not trivial, since it requires a comparison of the entire preprocessor state to see if a header needs recompilation. That allows the compiler to auto-find the compilation order.. What's the importance of a compilation order? It is something that doesn't come cheap. The effect of units is that it is a lot safer (more guaranteed) and easier to implement that precompiled header files, and auto-building is also a lot easier (not requiring explicit manual compile order enforced) Again I don't understand what you mean (compile order???) :-( Not recompiling the headers each time saves a lot of time. A C project doesn't require any compilation order, every module can be compiled independently from other modules. Implementation: yes. Header: no. [snip] Such a construct of course is illegal, because of infinite recursion. The same construct would be perfectly accepatble with pointers: type A = record a1: ^B; end; B = record b1: ^A; end; Yes. But it doesn't even have to so complex. Simply two files having dependancies on eachother, without having cycles in types are most typical. My idea for extended external declarations: IMHO it is not a problem that needs solving, specially not with extra syntax. IIRC TP could handle mild circular references and so can FPC. I don't know if this is still the case. Sounds interesting, do you have more information? No. It could also be that one of the other devels remember how it exactly went. I quickly tested, and it doesn't work now: -bash-2.05b$ fpc unit1 Free Pascal Compiler version 1.9.9 [2005/03/29] for i386 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: FreeBSD/ELF for i386 Compiling unit1.pas Compiling unit2.pas unit2.pas(5,11) Fatal: Circular unit reference between unit2 and unit1 Error: /home/marcov/bin/ppc386 returned an error exitcode (normal if you did not specifiy a source file to be compiled) So if it worked at a certain point it was removed later. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
A sample configuration, or the great (i really like it) samplecfg tool, are needed, to avoid possibly broken/outdated/... /etc/fpc.cfg files please add this somehow too. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
A sample configuration, or the great (i really like it) samplecfg tool, are needed, to avoid possibly broken/outdated/... /etc/fpc.cfg files please add this somehow too. I'm sorry. Forget about it - OPT=-n solves it... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? The webserver (apache2) uses the defaults from Suse 9.2. Nothing special is configured. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
