OpenEuphoria

1. Multi-purpose include/standalone files - neat trick

• Posted by petelomax at blueyonder.co.uk Oct 21, 2002
• 403 views

{{{ Trying to write code that could be equally used as part of a package and/or as a standalone function. Not just for being nice sake, but for ease of development.

Long time ago I realised that:

global FlagTrue include fred.ew

would fail as Flag had not been declared, (runing fred s/alone), and:

include fred.ew defines global Flag (False) Flag=True

would be too late as fred would trigger standalone processes...

• * HOWEVER * *:

global procedure isIncludeFile() dummy end procedure

include fred.ew

works a treat as fred.ew can simply ask:

if routine_id("isIncludeFile")=-1 then code to be run if standalone else

Thought I would share that as it just worked out rather well )). You also need only the one dummy routine above as many includes as you have.

Pete

3. Re: Multi-purpose include/standalone files - neat trick

• Posted by Sabal.Mike at notations.com Oct 23, 2002
• 389 views

Both options are good and concise, but rely on variables set outside the
file.  Personally, I like my include files to be self-contained whenever
possible.  The use of command_line() accomplishes that goal.  This
snippet of code from one of my projects handles stand-alone vs. include
checking, syntax checking, and parameter initialization from the command
line.  If the file was included, the parameters would be passed through
the procedure call.

HTH,
Michael J. Sabal

-- The following lines allow the option of this program being
-- run as either a stand-alone program or an included file.

sequence cmd_line

cmd_line = command_line()
if compare(lower(cmd_line[2]),"spidreng.exw")=0 or 
   compare(lower(cmd_line[2]),"spidreng")=0 then
  if length(cmd_line)>3 then
    spider_set_proxy(cmd_line[4])
  end if
  if length(cmd_line)<3 then
    puts(1,"Syntax:\n")
    puts(1,"exw spidreng.exw scriptname proxy_address\n\n")
  else
    spider_run_main(cmd_line[3])
  end if
end if


>>> jbrown105 at speedymail.org 10/22/02 08:19PM >>>

Before routine_id() (BTW I never did figure out this trick on my own),
I
used
this method:

file eubasic.e:

global integer included
included = 0

include/standalone file:

include eubasic.e
if included = 0 then
....
else
...
end if
....

in main file:

include eubasic.e
included = 1
include the includable/standalone file

5. Re: Multi-purpose include/standalone files - neat trick

• Posted by Sabal.Mike at notations.com Oct 23, 2002
• 387 views

True, I hadn't though of the full-path instance.  Your idea is a good
one.  But perhaps using match() instead of compare() by including
wildcard.e would have the same effect.  Although, if the file is
included and the pathname of the main file contains the name of the
included file, match() could give a false positive.

Feature request:
  Since the interpreter already knows whether a file is stand-alone or
included, I don't think it would be hard to provide a built-in boolean
to tell the program its scope.  For example,

if is_include_file()=TRUE then
  do_something()
else
  do_something_else()
end if

Michael J. Sabal

>>> MichaelANelson at WORLDNET.ATT.NET 10/23/02 11:27AM >>>

Mike,

This code doesn't work for me, as command_line returns the full path,
not
just the file name. I have added code to strip the path info below.

-- Mike Nelson

include misc.e

function get_filename(sequence f)
    integer slash,index
    if platform()=LINUX then slash='/' else slash='\\' end if
    index=find(slash,f)
    in index=0 then return f end if
    return get_filename(f[index+1..length(f)])
end function


> -- The following lines allow the option of this program being
> -- run as either a stand-alone program or an included file.
>
> sequence cmd_line
>
> cmd_line = command_line()
    cmd_line[2]=get_filename(cmd_line[2])
> if compare(lower(cmd_line[2]),"spidreng.exw")=0 or
>    compare(lower(cmd_line[2]),"spidreng")=0 then
>   if length(cmd_line)>3 then
>     spider_set_proxy(cmd_line[4])
>   end if
>   if length(cmd_line)<3 then
>     puts(1,"Syntax:\n")
>     puts(1,"exw spidreng.exw scriptname proxy_address\n\n")
>   else
>     spider_run_main(cmd_line[3])
>   end if
> end if

7. Re: Multi-purpose include/standalone files - neat trick

• Posted by jbrown105 at speedymail.org Oct 23, 2002
• 385 views

On  0, petelomax at blueyonder.co.uk wrote:
> 
> On Wed, 23 Oct 2002 09:17:49 -0400, Sabal.Mike at notations.com wrote:
> 
> >Both options are good and concise,
> hmmm. I've just queried jbrown privately re what he meant.
> Main.exw and Include.exw; no other source files, right?

And i've sent a private response.

> 
> > but rely on variables set outside the file.
> Eh? Not me.
> 
> *My* point was simply that routine_id("xxx") figures this out for you
> by returning -1 or a valid routine number (see below). If you wanted
> to communicate with the including app, I guess you could call the
> isIncludeFile() procedure/function (via call_proc/func()) with various
> parameters for each include file, possibly even passing/returning
> routine-id()'s of procs/ funcs defined in include/main source the
> other wishes to call...

No, but you DO rely on a routine set outside the file. I believe this is
what Mike is refering to.

> 
> > Personally, I like my include files to be self-contained whenever
> >possible.  The use of command_line() accomplishes that goal.
> 
> <SNIP some complex stuff>
> OK, I'm listening. Explain to me how using command_line() is better.
> It works, I agree, but better?!?    I don't want to be aggressive
> about this, but I really liked the idea I had & am worried you haven't
> got it yet. (or you see a flaw I don't).
> 
> Pete

Probably means that the main file must be explicitly coded for your
feature (or
mine, for that matter) to work: if someone else took the include file and
used in another program, but was too lazy to use the mechianism to tell
the
include file IT WAS INCLUDED (i.e. dont define the routine before
including
or not setting the global variable) then the include file will assume its
standalone. The command_line() trick works automaticly, however. (I once
used
a similar trick when I was trying to emulate threads.)

Mike's method works best for general libraries which can also be run
stand-alone,
while Pete's method and my own work best for specialized include files
not meant
to be used outside of a particular project.

jbrown


--

9. Re: Multi-purpose include/standalone files - neat trick

• Posted by petelomax at blueyonder.co.uk Oct 24, 2002
• 412 views

On Thu, 24 Oct 2002 00:58:29 UT, jbrown105 at speedymail.org wrote:

>Mike's method works best for general libraries which can also be run
>stand-alone,
>while Pete's method and my own work best for specialized include files
>not meant
>to be used outside of a particular project.

I should confess; I am writing a re-format/re-indent program (didn't
like niceform that much) & find it a pain to write throw-away stubs,
and/or re-work it later. This way I get to write it in the final
format without having to invoke the main app all the time to test
minor changes.

jbrown had a "toplevel" include defining a global which both main &
included file included. That works equally well.

Pete
I never doubted there would be more than one way to skin a cat.
I was just looking for a quieter way to do it )