Author | Topic: Great job by Alaska! | |
---|---|---|
Simon Burford, Uluru Support | Great job by Alaska! on Wed, 07 Jan 2004 12:02:54 +0000 Hi all at Alaska! Well done for a fantastic piece of software. My thinking until now: I am not usually a fan of IDEs as I am a "traditional" programmer and like to feel like I'm doing everything myself - unless something saves a "significent" amount of time I can't be bothered with software which does everything behind the scenes and I don't know what it's doing. My way of thinking is that, if I became unable to use the IDE for some reason (goes off the market and my copy is destroyed somehow!) then I would have no knowledge of how to actually build my software. It's like buying a car to go to work and then getting somebody else to drive you there in it instead of learning to drive yourself!!! I've always produced my applications by using a simple DOS batch file which says, essentially: arc myresources.arc xpp file 1 xpp file 2 xpp file 3 alink file 1 file 2 file 3 myresources.arc I know some people complain that this is recompiling everything everytime whereas a project file would only compile what has changed, but hey, if this is the only reason to use a project file (which is harder to set up) then that's a silly reason I have a 3Ghtz PC and even my batch file compiles my biggest project (100,000+ lines of code) in 10 seconds, which is quite quick enough for me, thanks! Besides, this assumption assumes that most people create projects made up of many, many different .prg files. Why would anyone do this - it's a step backwards. In the 80's under DBase III+, every function was contained in a seperate .prg file and edited with MODIFY COMMAND. When Clipper came along and allowed one .prg containing the whole application, everyone sighed with relief and said "thank god, no more searching for the right .prg all the time - now I just do search/replace for any code I want in my single .prg file. Now, suddenly, there seems to be this "step backwards" idea of splitting everything up again. If this is to allow a project file to compile just what has changed, then fair enough - but a batch file can compile the whole app in no time anyway so are people really worried about shaving 5 seconds off of each compile time? Just how often do you recompile anyway?!? HOWEVER!!!: This IDE is fantastic. It has everything I need, and doesn't store everything in binary repositaries so I don't know what's going on. I can examine the project file and see what it has done. I no longer need a seperate editor, or a DOS box open so that I can compile from the DOS prompt and see the results (which whiz by without being able to see any errors when clicked in windows explorer) - the results window shows me everything. A fantastic job. I'm converted Simon | |
Andreas Herdt | Re: Great job by Alaska! on Wed, 07 Jan 2004 13:15:32 +0100 Well, We can discuss the subject of how to setup a project to the last extend and I am shure that this will become a veeeeery long thread However, it was a bunch of work to make the VX as transparent as possible. Thus a very big THANK YOU for your kind words. Regards Andreas Herdt Till Warweg Steffen Pirsig [Alaska Research & Development] Simon Burford, Uluru Support wrote: > Hi all at Alaska! > > Well done for a fantastic piece of software. > > My thinking until now: > I am not usually a fan of IDEs as I am a "traditional" programmer and like > to feel like I'm doing everything myself - unless something saves a > "significent" amount of time I can't be bothered with software which does > everything behind the scenes and I don't know what it's doing. My way of > thinking is that, if I became unable to use the IDE for some reason (goes > off the market and my copy is destroyed somehow!) then I would have no > knowledge of how to actually build my software. It's like buying a car to go > to work and then getting somebody else to drive you there in it instead of > learning to drive yourself!!! > > I've always produced my applications by using a simple DOS batch file which > says, essentially: > > arc myresources.arc > xpp file 1 > xpp file 2 > xpp file 3 > alink file 1 file 2 file 3 myresources.arc > > I know some people complain that this is recompiling everything everytime > whereas a project file would only compile what has changed, but hey, if this > is the only reason to use a project file (which is harder to set up) then > that's a silly reason I have a 3Ghtz PC and even my batch file compiles > my biggest project (100,000+ lines of code) in 10 seconds, which is quite > quick enough for me, thanks! > Besides, this assumption assumes that most people create projects made up of > many, many different .prg files. Why would anyone do this - it's a step > backwards. In the 80's under DBase III+, every function was contained in a > seperate .prg file and edited with MODIFY COMMAND. When Clipper came along > and allowed one .prg containing the whole application, everyone sighed with > relief and said "thank god, no more searching for the right .prg all the > time - now I just do search/replace for any code I want in my single .prg > file. Now, suddenly, there seems to be this "step backwards" idea of > splitting everything up again. If this is to allow a project file to compile > just what has changed, then fair enough - but a batch file can compile the > whole app in no time anyway so are people really worried about shaving 5 > seconds off of each compile time? Just how often do you recompile anyway?!? > > HOWEVER!!!: > > This IDE is fantastic. It has everything I need, and doesn't store > everything in binary repositaries so I don't know what's going on. I can > examine the project file and see what it has done. I no longer need a > seperate editor, or a DOS box open so that I can compile from the DOS prompt > and see the results (which whiz by without being able to see any errors when > clicked in windows explorer) - the results window shows me everything. > > A fantastic job. I'm converted > > Simon > > | |
Phil Ide | Re: Great job by Alaska! on Wed, 07 Jan 2004 13:39:40 +0000 Simon, > Besides, this assumption assumes that most people create projects made up of > many, many different .prg files. Why would anyone do this - it's a step > backwards. In the 80's under DBase III+, every function was contained in a > seperate .prg file and edited with MODIFY COMMAND. When Clipper came along > and allowed one .prg containing the whole application, everyone sighed with > relief and said "thank god, no more searching for the right .prg all the > time - now I just do search/replace for any code I want in my single .prg > file. Now, suddenly, there seems to be this "step backwards" idea of > splitting everything up again. If this is to allow a project file to compile > just what has changed, then fair enough - but a batch file can compile the > whole app in no time anyway so are people really worried about shaving 5 > seconds off of each compile time? Just how often do you recompile anyway?!? As Andreas said, building a project file could start a very long thread I split a project into multiple files for simplicity: Logon and security routines in one file Table/Index opening/reindexing and affilate routines in another. The application itself is comprised of a vast number of discrete proedures (in the general meaning, not PROCEDURE). For example, viewing/editing a clients policy options is one. Another is maintenance of the broker file, and another queries loss ratio's (premium against claims). By keeping related code together, it makes things easier to find. By seperating disparate routines, it makes things easier to find. It also helps to create libraries and stock routines. Take a look at my site and you'll see more than 50 downloads on the Xbase++ page. Most of those (that I wrote myself) are the result of single project. If someone points out a bug or a possible enhancement, I edit the code and put it back on my site - then copy the source to my application's project directory and relink and my application gains from the changes. I have two main applications that I work on (plus some auxhilary apps such as SOAP servers and utils). Most of the code on my site (from me) was actually spawned from just one of these apps. The two projects contain over 50,000 lines of code - and they share a lot of code between them!. The code sharing would not be possible if the source was lumped into just a few source files, and I wouldn't be able to put any source on my web. Further, I wouldn't benefit from the feedback I gain by placing such code on my web. When starting a new project, I typically create the first source file and just link on the command line using: xpp file1 /m /n /w /a /b /link"/de /pm:pm" When I get to two source files, I create a project: dir *.prg /b>project.txt pbuild @project.txt I then edit the project file to turn GUI on (if req) and change the name of the target .exe, then: pbuild /g The project is then ready. What's difficult about that? It's no harder (and probably quicker) than your batch file. Regards, Phil Ide *************************************** * Xbase++ FAQ, Libraries and Sources: * * goto: http://www.idep.org.uk/xbase * *************************************** Bored at 3:00 a.m.? PSSSTTT - got a modem? |