[Color Computer] Re: [Coco] C-Cubed

[Roger Taylor]

I was thinking about adding internet file transfer capabilities to Portal-9 
but am not sure what people would like to use it for the most.  The 
transfers would be done automatically via FTP to one or more of my servers.

Another idea I had was making CCASM (6809/6309 cross assembler) work online 
via CGI.  The assembler would take its source file as an HTTP post or by 
form input (text box) then return the output in HTML or binary like a 
download.  S-record files could be returned using HTML, for example.

CCASM currently has a slight problem keeping it from compiling completely 
for Linux.  The problem was/is in the parent language HLA but I have not 
tried to recompile in a while so I am due for a new test session.  Because 
my web servers use Linux, and I am into CGI programs, this opens up a lot 
of online possibilities for CCASM and Portal-9.






At 04:36 PM 7/23/2005, you wrote:
>I think this could work, but it won't be as simple as posting a file and
>retrieving the binary (e.g. the HTTP POST/GET model). In order for make
>files to work, the server should accept the make file as input followed by
>requests of each source and library file required to build the project.
>
>Perhaps a more intuitive approach would be to implement the client/server
>logic in make itself. In this model, the HTTP POST/GET methodology still
>works but make submits a request to compile each source file to an object
>file followed by requests to link the files into a library or executable
>module. There would be more traffic during the initial build, but subsequent
>builds would (at least theoretically) be smaller incremental builds.
>
>Putting the client/server logic in make rather than in the compiler
>simplifies the compiler code and allows pieces of the compiler to be farmed
>out to the server as required. The question then becomes which portions of
>the compiler run on the server. If rlink were kept on the client, for
>example, we wouldn't need to send potentially large libraries over an IP
>connection and allows the server to become a relocatable object generator.
>If rma were kept on the client, the server becomes a C to assembly
>translator.
>
>The advantage is that a configuration file could be used to specify which
>compiler components are located on the server to allow the potential for
>future "open source" compiler components that can be distributed. The
>disadvantage, of course, is that all projects require a make file. How much
>of a disadvantage this poses depends entirely on whether the developer
>normally creates make files or uses the cc executive.
>
> > -----Original Message-----
> > From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
> > On Behalf Of James Diffendaffer
> > Sent: Thursday, July 21, 2005 8:49 AM
> > To: ColorComputer at yahoogroups.com
> > Subject: [Color Computer] Re: [Coco] C-Cubed
> >
> > A remote hosted compiler is an interesting idea as an alternative to
> > having to set up something like Cygwin (definately not for the
> > beginner) or worry about copyright issues.
> >
> > However... I'm not sure how well it will work.
> > You must be able to 'make' a project with multiple source files,
> > include files and your own libs.
> >
> >
> > I see only a few ways this can work:
> >
> > If you use standard include files and are compiling one source file.
> > I guess it would work for a beginner but it would be of no use to a
> > real developer.  No make capability.
> >
> > Set up something like a unix account for them... not very practical.
> >
> > Or they archive their entire environment with their own libs, includes
> > and everything.  If anything were wrong with the directory structure
> > in the archive it would fail but it's possible.
> >
> >
> > I don't think anything for the CoCo will be big enough to cause a huge
> > delay accessing such a system... but you would need to be online to
> > use it.
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco


-- 
Roger Taylor