Alaska Software Inc. - Great job by Alaska!
Username: Password:
AuthorTopic: Great job by Alaska!
Simon Burford, Uluru SupportGreat 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?