On Mon, 2009-06-01 at 17:00 +0200, thron7 wrote: > > 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.
It was just a thought related to one particular comment in the thread, I think from Derrell. I guess I was thinking about the comment on automatic temp directory activity that only removes older content and leaves newer content. If the Qooxdoo cache in the temp directory is new enough, it would not get removed during automatic clearing of old content. If it never changes after the initial creation, then it would be ripe for cleanout of old files, causing the long compile time while the cache is getting rebuilt. Since my knowledge of the internal workings of the Qooxdoo build system and cache usage is limited, I can't really give a complete opinion, but that thought came to mind while reading that particular thread post. In reality, I don't have enough experience to say whether the changes you've described will cause me any problems or not. BTW, I can appreciate the comment that Linux systems will likely not see frequent reboots - one of the reasons I switched my primary desktop to Linux years ago! My desktop's current uptime is 31 days. Carry on with all of the fine work... Gene > > 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
------------------------------------------------------------------------------ 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
