> I have a question related to the clearing of any old temp files - does > the Qooxdoo build system update the time-date stamp of the cache files > on each run?
No, that would defeat comparing the last modified time of the cache file to the last modified time of the application file it correlates to. A cache file is only updated when the corresponding application file is newer. At least that's the plan :-). > If so, frequent build runs would prevent any automatic > cache cleanup that only removes old files from removing the Qooxdoo > cache files. If not, maybe that would be a smart thing to change in the > Qooxdoo build system. I'm not sure I understand you here. But I can assure you that frequent build runs do not interfer with cache updates. T. > > Gene > > On Sun, 2009-05-31 at 23:24 +0200, Fritz Zaucker wrote: > >> Hi Thomas >> >> On Sat, 30 May 2009, thron7 wrote: >> >> >> Most Linux distributions either clear out /tmp each time the computer >> >> boots, or mount /tmp on a virtual file system (e.g. tmpfs) that is >> >> recreated on each boot. I believe this means that on a laptop that is >> >> rebooted a few times each day, an application in development would >> >> require a complete rebuild following each boot -- a very long >> process, of >> >> course, with any substantial application. >> > >> > Mh, I was not aware of that. I have been working with Linux the past >> 10 >> > years and never had my /tmp been cleared automatically. >> >> In general, the /tmp directory on most Unix systems (including Linux) >> should >> be cleared at reboot. I am surprised to hear that there are systems that >> don't do that. >> >> Of course, this isn't something that is done magically. Usually there is >> a >> script in /etc/init.d/ doing that. On Ubunty Jaunty (which happens to >> run on >> my laptop) it is the script mountall-bootclean.sh >> >> > But then, I'm not using one of those modern desktop versions of Linux. >> And >> > actually, since 2 years I hardly reboot, I only hibernate. - But of >> > course, I'm interested in other people's experiences. >> >> Even if a reboot does occur only rarely (Unix servers often aren't >> rebooted >> for months if not years, as a reboot is required only rarely compared to >> other OSes), the cache data might still be wanted to survive (and I >> don't >> really see a reason why they shouldn't). >> >> In some sense I even think it is a mistake to not clean the tmpdir ... >> and a >> well maintained system might actually clean the /tmp regularly once it >> starts filling up (although a well designed algorithm will only delete >> old >> files and not the recently modified Qooxdoo cache). >> >> >> I would suggest using a different environment variable variable name, >> >> e.g. QOOXDOO_CACHE_DIR, with a fallback to TMPDIR. >> > >> > I'm not sure I completely understand you here. For one thing, we are >> not >> > evaluating environment variables. Technically, we use the gettempdir() >> > function of one of Python's standard modules, tempfile. This in turn >> does >> > evaluate environment variables, but also applies a lot of platform >> logic, >> > so we don't have to worry about it. Since we are running >> >> This seems reasonable for getting the "local" location for temporary >> files. >> And according to the documentation the first place gettempdir() tries IS >> the >> TMPDIR environment variable. >> >> On the other hand, as Derrell points out, it might not be the ideal >> location >> IF the data in this directory is supposed to survive a reboot. >> >> > But more importantly, the TMPDIR *is* the fallback already. Just set >> your >> > CACHE macro to some other path and you're set. If you don't like the >> > TMPDIR location, just override it. Config macros are our way of >> tailoring >> > the system, and I wouldn't want to add another mechanism, like >> environment >> > variables, without compelling need. - If you are running multiple >> > applications on your machine, and want to maintain a central setting, >> just >> > create some "site.json" and include it in the individual >> config.json's. >> >> It seems to make sense to me to configure the cache location in the >> config.json file on a per application basis. This way each developer can >> decide what he wants to do. >> >> Personally, I think it would make sense to have the cache directory >> default >> to a directory inside the application tree. >> >> > But sure enough, while this should help you individually, the fallback >> > setting should be sensible for most people, so if a lot of people have >> the >> > issues you describe we should re-consider the default. >> >> Perhaps /var/tmp/ would be more reasonable, although I am not sure if >> there >> aren't distributions that clear this as well (Ubuntu Jaunty doesn't). >> > >> >> If QOOXDOO_CACHE_DIR is not found in the environment, a warning >> should be >> >> issued (but not in -q "quiet" mode) because falling back to TMPDIR >> will >> >> cause the problem described above on each boot, causing a poor user >> >> experience of long build times. Maybe a suggestion of how to add it >> to >> >> .profile could be provided. >> > >> > As I said, the solution is as close as your config.json. As for the >> poor >> > user experience due to automatically erased /tmp directories, I would >> be >> > interested to learn who else has this issue?! >> >> Just tried my current application with >> >> ./generate source >> >> With cache: 1.592u 0.112s 0:01.76 96.5% 0+0k 1944+0io 0pf+0w >> Without cache: 56.003u 0.956s 1:08.43 83.2% 0+0k 48432+0io 0pf+0w >> >> So this WILL hurt, if the cache is deleted unintentionally. >> >> Cheers, >> Fritz >> > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
