Re: And it was all worth it in the end ;-)
Angus Leeming wrote: > Right. The Qt frontend takes forever to build. Fancy writing an fltk frontend > for LyX? FLTK is designed to be small and modular enough to be statically linked - the "hello" program is only 97k when compiled on an x86 Linux system! I love the use "only" here. 97k to say hello? Everything is relative is guess. Garst > And, of course, FLTK is Fast and Light and runs natively under both *nix and > Windows. I don't know if it supports unicode though. >
Re: And it was all worth it in the end ;-)
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Sep 08, 2003 at 02:53:00PM +0200, Lars Gullik Bj?nnes wrote: > >> | Please let's keep make check for if we ever have a proper testsuite >> >> EY. Do you mean to not use make check now? > | Yeah. > >> This source testing/checking is imho also part of a testsuite, but we > | I would disagree ... testsuites are about correctness not compile time | performance Performance? where did that come into the picture? This is about "source" correctness. (that having the source be "correct" give a boost to compile time performance is nice, but are really just luck.) -- Lgb
Re: And it was all worth it in the end ;-)
On Mon, Sep 08, 2003 at 02:53:00PM +0200, Lars Gullik Bj?nnes wrote: > | Please let's keep make check for if we ever have a proper testsuite > > EY. Do you mean to not use make check now? Yeah. > This source testing/checking is imho also part of a testsuite, but we I would disagree ... testsuites are about correctness not compile time performance john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: And it was all worth it in the end ;-)
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Sep 08, 2003 at 11:35:50AM +0200, Lars Gullik Bj?nnes wrote: > >> (make test or make check... I don't care) > | Please let's keep make check for if we ever have a proper testsuite EY. Do you mean to not use make check now? This source testing/checking is imho also part of a testsuite, but we should not put the time consuming stuff in there. -- Lgb
Re: And it was all worth it in the end ;-)
On Mon, Sep 08, 2003 at 11:35:50AM +0200, Lars Gullik Bj?nnes wrote: > (make test or make check... I don't care) Please let's keep make check for if we ever have a proper testsuite john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote: > | The computer does all the work. All I have to do is type a little: > | $ time make > | [snip...] > | real31m42.847s > | user26m52.940s > | sys 2m16.440s >> > > I thought you seaid you had a fast machine? but that is both xforms > and qt right? Right. The Qt frontend takes forever to build. Fancy writing an fltk frontend for LyX? Yes, that was a joke. Still, we could make really clean code if we did this. The fltk gui builder tool, fluid, allows user-derfined widgets to be added, so we could have things like LyXGlueLengthWidget. It also allows us to #include code snippets for the callback function, so we could use boost::signals. I have fond memories of that trial I did a year or so ago when I wrote some C++ wrappers for the xforms library and made some dialogs from scratch using them. And, of course, FLTK is Fast and Light and runs natively under both *nix and Windows. I don't know if it supports unicode though. > With gcc 3.3.1 I build the xforms verison in ~16 minutes with a > ~2400MHz box I have something comparable. -- Angus
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: > >>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> >> Angus> I suspect that repeated builds (devel) must introduce crap. >> Angus> Can't explain these figues otherwise. >> >> Yes, I also tend to have lots of obsolete generated files in my build dir. >> >> Angus> If you're interested, I could do a 'make maintainer clean; >> Angus> make' run on current cvs. >> >> If you have time, it would be interesting, but don't bother if it is >> too much work... > | The computer does all the work. All I have to do is type a little: | $ time make | [snip...] | real31m42.847s | user26m52.940s | sys 2m16.440s > I thought you seaid you had a fast machine? but that is both xforms and qt right? With gcc 3.3.1 I build the xforms verison in ~16 minutes with a ~2400MHz box -- Lgb
Re: And it was all worth it in the end ;-)
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> I suspect that repeated builds (devel) must introduce crap. > Angus> Can't explain these figues otherwise. > > Yes, I also tend to have lots of obsolete generated files in my build dir. > > Angus> If you're interested, I could do a 'make maintainer clean; > Angus> make' run on current cvs. > > If you have time, it would be interesting, but don't bother if it is > too much work... The computer does all the work. All I have to do is type a little: $ time make [snip...] real31m42.847s user26m52.940s sys 2m16.440s $ du -ks devel/build/src 696676 devel/build/src $ du -ks sep_03/build/src 747104 sep_03/build/src So, it appears that I have saved you all 50MBytes of disk space too. Aren't I nice ;-) -- Angus
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote: >>> | You _really_ don't want to do that. To test for redundant #includes in >>> | the src directory alone took 41 minutes on my 2.7GHz machine here... >>> >>> separate make target then. >> > | Why? > > I like make targets. > (you know, make targets are allowed to run scripts...) Go for it! -- Angus
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: >> >> | Why? But ok: >> >> Not just for this test, but if we have situation where something >> flagged really shouldn't be. >> Sure, I think you have caught all cases. What this "make test" would be for is _new_ changes to CVS, so that we catch "regression" like this early. >>> >> | Sounds a little officious to me ;-) >> >> A lot better to catch it before commit than having to do the stuff you >> have done now .. >> >> | You _really_ don't want to do that. To test for redundant #includes in the >> | src directory alone took 41 minutes on my 2.7GHz machine here... >> >> separate make target then. > | Why? I like make targets. (you know, make targets are allowed to run scripts...) -- Lgb
Re: And it was all worth it in the end ;-)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I suspect that repeated builds (devel) must introduce crap. Angus> Can't explain these figues otherwise. Yes, I also tend to have lots of obsolete generated files in my build dir. Angus> If you're interested, I could do a 'make maintainer clean; Angus> make' run on current cvs. If you have time, it would be interesting, but don't bother if it is too much work... JMarc
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Why? But ok:
>
> Not just for this test, but if we have situation where something
> flagged really shouldn't be.
>
>>> Sure, I think you have caught all cases. What this "make test" would
>>> be for is _new_ changes to CVS, so that we catch "regression" like
>>> this early.
>>
> | Sounds a little officious to me ;-)
>
> A lot better to catch it before commit than having to do the stuff you
> have done now ..
>
> | You _really_ don't want to do that. To test for redundant #includes in the
> | src directory alone took 41 minutes on my 2.7GHz machine here...
>
> separate make target then.
Why?
Why not take the script I posted last night (check_strip.sh),
replace the line
mv -f ${TESTFILE} ${INPUTFILE}
with
echo ${LINE} of ${INPUTFILE} may well be redundant. Please investigate.
and just run it. Preferably overnight.
$ find . -name "*.[Ch]" | xargs check_strip.sh includes > redundant_includes.txt
$ find . -name "*.[Ch]" | xargs check_strip.sh using > redundant_using.txt
All you need to do is add those three scripts to the development
directory somewhere.
--
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | Current CVS: >> | $ ls -l lyx-* >> | -rwxrwxr-x1 angusangus98118911 Sep 8 01:34 lyx-qt >> | -rwxrwxr-x1 angusangus75748955 Sep 8 01:32 lyx-xforms >>> >> | $ size lyx-* >> |textdata bss dec hex filename >> | 3319939 159160 23380 3502479 35718f lyx-qt >> | 3091909 81672 48884 3222465 312bc1 lyx-xforms > >> with gcc 3.2.2 >> >> s -l src/lyx-xforms >> -rwxrwxr-x1 larsbj larsbj 74171850 Sep 8 11:54 src/lyx-xforms >> >> size src/lyx >>textdata bss dec hex filename >> 3005689 81188 48832 3135709 2fd8dd src/lyx > | It appears that here I use gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7) | I guess that the two compilers (yours and mine) are sufficiently similar for | my posts on size to be regarded as meaningful. gcc 3.3.1: ls -l src/lyx-xforms -rwxrwxr-x1 larsbj larsbj 73994128 Sep 8 12:22 src/lyx-xforms size src/lyx textdata bss dec hex filename 3426157 18428 53564 3498149 3560a5 src/lyx -- Lgb
Re: And it was all worth it in the end ;-)
Jean-Marc Lasgouttes wrote: >>> So it is less than 10%, but not bad. An what about 'du -s'? > > Angus> $ du -s devel/build/src/lyx-* 95920 devel/build/src/lyx-qt > Angus> 74056 devel/build/src/lyx-xforms > > Angus> $ du -s sep_03/build/src/lyx-* 102236 sep_03/build/src/lyx-qt > Angus> 78832 sep_03/build/src/lyx-xforms > > Sorry that's not what I meant. I'd like to see the output of du -s on > devel/build and sep_03/build/ to see the effect on the whole build > tree... Hmmm. You're not going to like this... $ du -s devel/build 920824 devel/build $ du -s sep_03/build 757352 sep_03/build I suspect that repeated builds (devel) must introduce crap. Can't explain these figues otherwise. If you're interested, I could do a 'make maintainer clean; make' run on current cvs. -- Angus
Re: And it was all worth it in the end ;-)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> So it is less than 10%, but not bad. An what about 'du -s'? Angus> $ du -s devel/build/src/lyx-* 95920 devel/build/src/lyx-qt Angus> 74056 devel/build/src/lyx-xforms Angus> $ du -s sep_03/build/src/lyx-* 102236 sep_03/build/src/lyx-qt Angus> 78832 sep_03/build/src/lyx-xforms Sorry that's not what I meant. I'd like to see the output of du -s on devel/build and sep_03/build/ to see the effect on the whole build tree... JMarc
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote: > | Current CVS: > | $ ls -l lyx-* > | -rwxrwxr-x1 angusangus98118911 Sep 8 01:34 lyx-qt > | -rwxrwxr-x1 angusangus75748955 Sep 8 01:32 lyx-xforms >> > | $ size lyx-* > |textdata bss dec hex filename > | 3319939 159160 23380 3502479 35718f lyx-qt > | 3091909 81672 48884 3222465 312bc1 lyx-xforms > with gcc 3.2.2 > > s -l src/lyx-xforms > -rwxrwxr-x1 larsbj larsbj 74171850 Sep 8 11:54 src/lyx-xforms > > size src/lyx >textdata bss dec hex filename > 3005689 81188 48832 3135709 2fd8dd src/lyx It appears that here I use gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7) I guess that the two compilers (yours and mine) are sufficiently similar for my posts on size to be regarded as meaningful. -- Angus
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Why? But ok: Not just for this test, but if we have situation where something flagged really shouldn't be. >> Sure, I think you have caught all cases. What this "make test" would >> be for is _new_ changes to CVS, so that we catch "regression" like >> this early. > | Sounds a little officious to me ;-) A lot better to catch it before commit than having to do the stuff you have done now .. | You _really_ don't want to do that. To test for redundant #includes in the src | directory alone took 41 minutes on my 2.7GHz machine here... separate make target then. -- Lgb
Re: And it was all worth it in the end ;-)
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Jean-Marc Lasgouttes wrote: I downloaded a copy of the cvs tree > Angus> from 3 September and ran these scripts on the build dirs of it > Angus> and of current cvs. Total local dependencies reduced from 63 to > Angus> 57 thousand files. > >>> Not bad, 10%. Does it make a difference in terms of debug info >>> size? > > Angus> Current CVS: > Angus> Sep 03 CVS: > > So it is less than 10%, but not bad. An what about 'du -s'? $ du -s devel/build/src/lyx-* 95920 devel/build/src/lyx-qt 74056 devel/build/src/lyx-xforms $ du -s sep_03/build/src/lyx-* 102236 sep_03/build/src/lyx-qt 78832 sep_03/build/src/lyx-xforms -- Angus
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: >> Angus> I downloaded a copy of the cvs tree from 3 September and ran >> Angus> these scripts on the build dirs of it and of current cvs. Total >> Angus> local dependencies reduced from 63 to 57 thousand files. > >> Not bad, 10%. Does it make a difference in terms of debug info size? > | Current CVS: | $ ls -l lyx-* | -rwxrwxr-x1 angusangus98118911 Sep 8 01:34 lyx-qt | -rwxrwxr-x1 angusangus75748955 Sep 8 01:32 lyx-xforms > | $ size lyx-* |textdata bss dec hex filename | 3319939 159160 23380 3502479 35718f lyx-qt | 3091909 81672 48884 3222465 312bc1 lyx-xforms > | Sep 03 CVS: | $ ls -l lyx-* | -rwxrwxr-x1 angusangus104582641 Sep 5 21:20 lyx-qt | -rwxrwxr-x1 angusangus80635602 Sep 5 21:17 lyx-xforms > | $ size lyx-* |textdata bss dec hex filename | 3315295 159140 23464 3497899 355fab sep_03/build/src/lyx-qt | 3087725 81652 48936 3218313 311b89 sep_03/build/src/lyx-xforms with gcc 3.2.2 s -l src/lyx-xforms -rwxrwxr-x1 larsbj larsbj 74171850 Sep 8 11:54 src/lyx-xforms size src/lyx textdata bss dec hex filename 3005689 81188 48832 3135709 2fd8dd src/lyx -- Lgb
Re: And it was all worth it in the end ;-)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: I downloaded a copy of the cvs tree Angus> from 3 September and ran these scripts on the build dirs of it Angus> and of current cvs. Total local dependencies reduced from 63 to Angus> 57 thousand files. >> Not bad, 10%. Does it make a difference in terms of debug info >> size? Angus> Current CVS: Angus> Sep 03 CVS: So it is less than 10%, but not bad. An what about 'du -s'? JMarc
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
>>
>>> Or in compile and link time?
>>
> | Ouch!
>>
>>> What we could do is to make these scripts (in particular if some of
>>> them does not need human intervention to be correct) is to make a
>>> "test" target that tests the source tree:
>>>
>>>- make sure that all .C files includes config.h
>>
> | Trivial:
> | $ find . -name "*.C" | while read file; do grep '^ *# *include
> | *' $file > /dev/null && continue; echo $file 'does not #include
> | !'; done
> | ./graph.C does not #include !
> | ./support/gzstream.C does not #include !
>
> And then we need a list of files where this is ok.
Why? But ok:
find . -name "*.C" | while read file
do
grep '^ *# *include *' $file > /dev/null && {
echo $file '#includes (as it should).'
} || {
echo $file 'does not #include !'
}
done
find . -name "*.h" | while read file
do
grep '^ *# *include *' $file > /dev/null && {
echo $file '#includes (it should not!).'
} || {
echo $file 'does not #include (which is correct)'
}
done
>>>- make sure that all files has the correct header blurb
>>
> | I've done that over the last few weeks and months. I think that all
> | are now up to data. Simple test:
>
> Sure, I think you have caught all cases. What this "make test" would
> be for is _new_ changes to CVS, so that we catch "regression" like
> this early.
Sounds a little officious to me ;-)
>>>- looks for unneeded using statements
>>
> | I wrote and posted a script that automates this to some extent. It's
> | greedy in that it will automatically remove things inside deactivated
> | macro blocks, but it is relatively easy to go through the diff file and
> | put things back. This is exactly what I did last night. For two hours.
>
> For "make test" I don't want anything automatically removed, just
> flagged, and we must have a file telling the scripts that "this
> particular item should not be flagged"
>
>>>- looks for unneeded include statements
>>
> | Ditto. The point to note is that these last two are not painless.
> | Nonetheless, I think that the source is now in a sufficiently clean state
> | that they won;t be needed for some time to come.
>
> That is why "make test" would be ok. To that we don't unknowingly
> regress.
>
> (make test or make check... I don't care)
You _really_ don't want to do that. To test for redundant #includes in the src
directory alone took 41 minutes on my 2.7GHz machine here...
--
Angus
Re: And it was all worth it in the end ;-)
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> Or in compile and link time? > | Ouch! > >> What we could do is to make these scripts (in particular if some of >> them does not need human intervention to be correct) is to make a >> "test" target that tests the source tree: >> >>- make sure that all .C files includes config.h > | Trivial: | $ find . -name "*.C" | while read file; do grep '^ *# *include *' | $file > /dev/null && continue; echo $file 'does not #include !'; | done | ./graph.C does not #include ! | ./support/gzstream.C does not #include ! And then we need a list of files where this is ok. >>- make sure that all files has the correct header blurb > | I've done that over the last few weeks and months. I think that all | are now up to data. Simple test: Sure, I think you have caught all cases. What this "make test" would be for is _new_ changes to CVS, so that we catch "regression" like this early. >>- looks for unneeded using statements > | I wrote and posted a script that automates this to some extent. It's greedy in | that it will automatically remove things inside deactivated macro blocks, but | it is relatively easy to go through the diff file and put things back. This | is exactly what I did last night. For two hours. For "make test" I don't want anything automatically removed, just flagged, and we must have a file telling the scripts that "this particular item should not be flagged" >>- looks for unneeded include statements > | Ditto. The point to note is that these last two are not painless. Nonetheless, | I think that the source is now in a sufficiently clean state that they won;t | be needed for some time to come. That is why "make test" would be ok. To that we don't unknowingly regress. (make test or make check... I don't care) -- Lgb
Re: And it was all worth it in the end ;-)
Lars Gullik Bjønnes wrote: > Or in compile and link time? Ouch! > What we could do is to make these scripts (in particular if some of > them does not need human intervention to be correct) is to make a > "test" target that tests the source tree: > >- make sure that all .C files includes config.h Trivial: $ find . -name "*.C" | while read file; do grep '^ *# *include *' $file > /dev/null && continue; echo $file 'does not #include !'; done ./graph.C does not #include ! ./support/gzstream.C does not #include ! >- make sure that all files has the correct header blurb I've done that over the last few weeks and months. I think that all are now up to data. Simple test: $ find . -name "*.[Ch]" | while read file; do grep 'Full author contact details are available in file CREDITS.' $file > /dev/null && continue; echo $file 'does not have correct header blurb'; done ./frontends/gnome/support.h does not have correct header blurb ./frontends/qt2/qgridview.C does not have correct header blurb ./frontends/qt2/qgridview.h does not have correct header blurb ./frontends/qt2/qttableview.C does not have correct header blurb ./frontends/qt2/qttableview.h does not have correct header blurb ./graphics/GraphicsTypes.C does not have correct header blurb ./support/filetools.C does not have correct header blurb ./support/nt_defines.h does not have correct header blurb ./support/os2_defines.h does not have correct header blurb ./support/os2_errortable.h does not have correct header blurb ./support/snprintf.h does not have correct header blurb ./support/sstream.h does not have correct header blurb ./support/filename.C does not have correct header blurb ./support/gzstream.C does not have correct header blurb ./support/gzstream.h does not have correct header blurb ./support/std_istream.h does not have correct header blurb ./support/std_ostream.h does not have correct header blurb Ok, I'll investigate. >- looks for unneeded using statements I wrote and posted a script that automates this to some extent. It's greedy in that it will automatically remove things inside deactivated macro blocks, but it is relatively easy to go through the diff file and put things back. This is exactly what I did last night. For two hours. >- looks for unneeded include statements Ditto. The point to note is that these last two are not painless. Nonetheless, I think that the source is now in a sufficiently clean state that they won;t be needed for some time to come. -- Angus
Re: And it was all worth it in the end ;-)
Jean-Marc Lasgouttes wrote: > Angus> I downloaded a copy of the cvs tree from 3 September and ran > Angus> these scripts on the build dirs of it and of current cvs. Total > Angus> local dependencies reduced from 63 to 57 thousand files. > Not bad, 10%. Does it make a difference in terms of debug info size? Current CVS: $ ls -l lyx-* -rwxrwxr-x1 angusangus98118911 Sep 8 01:34 lyx-qt -rwxrwxr-x1 angusangus75748955 Sep 8 01:32 lyx-xforms $ size lyx-* textdata bss dec hex filename 3319939 159160 23380 3502479 35718f lyx-qt 3091909 81672 48884 3222465 312bc1 lyx-xforms Sep 03 CVS: $ ls -l lyx-* -rwxrwxr-x1 angusangus104582641 Sep 5 21:20 lyx-qt -rwxrwxr-x1 angusangus80635602 Sep 5 21:17 lyx-xforms $ size lyx-* textdata bss dec hex filename 3315295 159140 23464 3497899 355fab sep_03/build/src/lyx-qt 3087725 81652 48936 3218313 311b89 sep_03/build/src/lyx-xforms -- Angus
Re: And it was all worth it in the end ;-)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > | Angus> I downloaded a copy of the cvs tree from 3 September and ran | Angus> these scripts on the build dirs of it and of current cvs. Total | Angus> local dependencies reduced from 63 to 57 thousand files. > | Not bad, 10%. Does it make a difference in terms of debug info size? Or in compile and link time? What we could do is to make these scripts (in particular if some of them does not need human intervention to be correct) is to make a "test" target that tests the source tree: - make sure that all .C files includes config.h - make sure that all files has the correct header blurb - looks for unneeded using statements - looks for unneeded include statements - etc. And then require a "make check" to pass without regressions before commits to be allowed. -- Lgb
Re: And it was all worth it in the end ;-)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I downloaded a copy of the cvs tree from 3 September and ran Angus> these scripts on the build dirs of it and of current cvs. Total Angus> local dependencies reduced from 63 to 57 thousand files. Not bad, 10%. Does it make a difference in terms of debug info size? JMarc
