>> (Time is not my friend at the moment). I know what you mean. I've been trying to put aside time to work on project ideas. I get little pieces here and there but not enough to really call it progress. >> Are you saying I should build it in myself? OK... I'll give it a go... Yes and no. I wasn't speaking directly to you but everyone, including myself. In the last few weeks I've seen a barrage of request for things that I know are done on a volunteer basis. I'm just trying to keep it all in perspective. >> Probably not necessary for the intermediate c files... What I'm most concerned about are the source files. If I put a project on the ram-disk, I will be concerned with the source that is used to generate the C files. I put the project on the ram disk, the temporary folder and all build files get created there. If the changes I make to the source get lost, I'm pretty upset. The intermediate files are a product of the original source translation. The rebuild time for the intermediate files becomes greatly reduced on the ram disk, even if I repeatedly delete the temp directory. Maybe that wasn't the way intended to do it. Maybe you only wanted the build files to show up on the ram disk which is a good idea but (I imagine) would require a different design for FBtoC. I'm ignorant of its design but hopefully I wont be that way for long. W. -----Original Message----- From: andy@... [mailto:andy@...] Sent: Monday, July 20, 2009 4:00 PM To: futurebasic@... Subject: RE: [FB] RAM disk > >>> > However and as Andy suggested, I should also prefer an integration to > the FB-IDE; but I'm not at all convinced whether it suffices to saved > the intermediate C-code to the RAM-Disk in order to achieve the > reported acceleration (factor 7!) of the entire compilation. > << > > I haven't looked at the source for FBtoC but looking at the behavior > of the program indicates integrating a ram-disk might not happen. Built into FBtoC? Well that may be the case. But is happening now as far as I'm concerned. I've developed a routine to copy to/from RAM disk and compile within the RAM disk and it is working well. I just close the lid of my MacBook and everything is held in memory until I am able to snatch another few minutes on my program. (Time is not my friend at the moment). I do need to get more RAM for my machine though! > When > GCC goes through the build process, the temporary folder is created in > the project folder. The build and paths would be relative to the build > folder. In order for integration to take place, all builds would take > place in the ram-disk, each build folder would need to be given a unique > name and all paths would be relative to the ram-disk. For those who are > are getting compilation cramps waiting on there builds to complete it > might be a great benefit but I'm *guessing* for the majority, it would be > a nice to have at a cost that I wonder if anyone is willing to pay, > outside > of the FBtoC team. Its great to want something but are we willing to > contribute to make it happen. Are you saying I should build it in myself? OK... I'll give it a go... > I drive what probably be considered a > hoopty.... (snip).... > Sorry, I got side tracked. > Using a ram-disk is a great idea but it should be coupled with a safety > feature > such as automatic save to disk, using built in utilities such as hdiutil > to create > a backup the ram drive contents to physical disk. > > http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/hdiutil.1.html Probably not necessary for the intermediate c files... I've worked out where some of my huge time saving comes from... my program has a very large resources folder which is copied into the program bundle. This is slow as a disk to disk copy but virtually no time as a RAM to RAM disk copy. Andy -- To unsubscribe, send ANY message to: futurebasic-unsubscribe@...