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
2. Re: Multi-purpose include/standalone files - neat trick
- Posted by jbrown105 at speedymail.org Oct 22, 2002
- 384 views
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 My version doesnt require routine_id(), but yours is simpler. Just thought I'd share my variant of your idea as well :) jbrown On 0, petelomax at blueyonder.co.uk wrote: > > 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 Flag=True > 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 > -- probably little or no code to be run if an include > end if > ... > > > 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 > > ==^^=============================================================== > This email was sent to: jbrown105 at speedymail.org > > > -- Linux User:190064 Linux Machine:84163 --
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
4. Re: Multi-purpose include/standalone files - neat trick
- Posted by Mike Nelson <MichaelANelson at WORLDNET.ATT.NET> Oct 23, 2002
- 392 views
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
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
6. Re: Multi-purpose include/standalone files - neat trick
- Posted by petelomax at blueyonder.co.uk Oct 23, 2002
- 379 views
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? > 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... > 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 PS original message snippet follows: > * * HOWEVER * *: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > global procedure isIncludeFile() -- dummy > end procedure >=20 > include fred.ew >=20 > works a treat as fred.ew can simply ask: >=20 > if routine_id("isIncludeFile")=3D-1 then > -- code to be run if standalone > else > -- probably little or no code to be run if an include > 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 --
8. Re: Multi-purpose include/standalone files - neat trick
- Posted by Sabal.Mike at notations.com Oct 24, 2002
- 395 views
I understand exactly what you are doing, and I think it is a wonderful, concise idea. My only issue is stylistic. I like all my includes at the top of a program without any procedures before them confusing things. And when I'm writing a library or multi-use module, I don't want the programmer of the main program to have to do anything special to make it work; especially since I'm usually that programmer and I forget that I need that option defined, etc. If I'm including a module, I want to plug and play with no hassles. The command_line option, while longer and messier in the include program, does allow the include to be plug and play. The best option would be a means of the interpreter telling a file whether or not it is included as part of a larger program. A single, clean, efficient built-in function would remove the need for any of our hoop-jumping be it routine_id, command_line, or nested includes. Mike Sabal petelomax at blueyonder.co.uk wrote: 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
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 )
10. Re: Multi-purpose include/standalone files - neat trick
- Posted by Kat <kat at kogeijin.com> Oct 24, 2002
- 372 views
On 24 Oct 2002, at 23:12, petelomax at blueyonder.co.uk wrote: <snip> > 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 ) Let it be known this was referring to catFISH, not me! Kat