OpenEuphoria

Re: Front End? (Was: Re: async problem)

• Posted by "Hayden McKay" <hmck1 at dodo.com.au> Dec 31, 2003
• 429 views

Being able to insert data into a bound program would be cool.
Here is something I tried.


Mainprog.exe -- A bound header file for data.
data.ew          -- data to be operated on.
routines.dat    -- defined routines.

Merge.exe      -- merges Mainprog.exe & data.ew
procedure merge()
integer fn
sequence executable,database,rtines
    executable = read_64("Mainprog.exe")
    database = read_64("database.ew")
    rtines = read_46("routines.dat")
    fn = open("setup.exe")
    puts(fn,write_64(executable) & "\r\n"))
    puts(fn,write_64(database) & "\r\n"))
    puts(fn,write_64(rtines) & "\r\n"))
    flush(fn)
end procedure

the data from 'data.ew' and 'routines.dat' was ingnored by
the new progam setup.exe

Only the data from 'Mainprog.exe' would run in the new program.

(I checked setup.exe with an editor and all the data was there.)

Is it possible to do something like this with another method?


----- Original Message ----- 
From: "Robert Craig" <rds at RapidEuphoria.com>
To: <EUforum at topica.com>
Sent: Wednesday, December 31, 2003 4:34 AM
Subject: Re: Front End? (Was: Re: async problem)


>
>
> C.K. Lester wrote:
>  > What I really want to know is, "What does it mean for the end user?"
>  > Will I notice any difference in how I currently develop programs,
>  > or is all this going to be changes behind the scenes?
>
> Things will stay pretty much the same for the end user.
> My main motivation is to improve the maintainability
> and portability of Euphoria.
>
> There will be a few (minor) positive side effects however:
>     - the interpreter that you bind with will be smaller
>       and use less memory
>     - bound programs will start up without any parsing required
>     - you'll be able to ship a shrouded or bound program and
>       *also* get a clear traceback with original variable names
>       if an error happens
>     - both translated and interpreted code will run a tiny bit faster
>       in some cases (due to some improvements that are now practical
>       in various optimization algorithms)
>
> Of course, if someone buys the Interpreter source, they'll
> see a parser written in pure Euphoria code, which will be easier
> to work with than C, especially if they don't know C very well.
> Perhaps they can use that parser to make other
> Euphoria-related tools.
>
> I think the main advantages to the user will come in
> the long term. I suspect some interesting developments
> could flow from this.
>
> Kat wrote:
> > Specifically, what can we access that we cannot now? The list of
variable
> > names and what they contain? A way to trap when contents of vars change,
> > instead of a type check now?
>
> No, but I might be more inclined to make symbol
> information available, and provide more analysis of the source,
> better "folding" of constant expressions etc.
> Maybe I can (optionally) tell you when a symbol is declared
> as global when it needn't be, when an atom variable could
> be declared as integer etc. etc.
>
> The parser (i.e. front-end) is now free to grow without
> increasing the size of bound programs, or consuming memory
> needed by the Euphoria program at run-time.
>
> There are advanced algorithms I might want to add to
> the Translator. It's 100% C now, but will become 100%
> Euphoria. In Euphoria it will be easier and safer for me to
> add these algorithms.
>
> The run-time system is not changing.
>
> Regards,
>     Rob Craig
>     Rapid Deployment Software
>     http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
> -- 
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.556 / Virus Database: 348 - Release Date: 26/12/03
>


---



--