OpenEuphoria

1. Include decision

• Posted by ZNorQ <znorq at holhaug.com> Nov 06, 2006
• 639 views

I'm using a third party include file - TCP4U - but I want to be able to
turn it off using a global constant ACTIVATE_TCP = FALSE. (This is if
I'm gonna distribute a version of my program without the TCP4U module
included. Don't worry, any recognitions are made to the appropriate
owners.)

The way it works is that the DLL is 'sequenced' into my application,
and if the ACTIVATE_TCP = TRUE, it will save the DLL to file - and then
execute the TCP4U module.

The challenge (or - problem) is that when I deactivate the TCP4U
(ACTIVATE_TCP = FALSE) the program shall NOT save the DLL to disk, and
NOT run the TCP4U wrapper. Only problem is that as soon as I include the
wrapper - certain initialization routines are already executed, and since
it wont find the DLL file - errors will emerge.

What I've done up till now, is modify the wrapper itself with an
'IF ACTIVATE_TCP = TRUE...' etc, but I don't want to have to edit third
party snippets..

Anyone know what walkaround I can use? 

PS! The point is that I'm only supposed to change the ACTIVATE_TCP
variable - I don't want to remove the includes.

Hope my poor attempt of explaining my problem was good enough... :)

ZNorQ

3. Re: Include decision

• Posted by ZNorQ <znorq at holhaug.com> Nov 06, 2006
• 595 views
• Last edited Nov 07, 2006

> 
> As far as I understand, it looks as if using a pre-processor is what
> you might want to do. See
> <<a
> href="http://rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=preprocessor">http://rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=preprocessor</a>>
> 
> Regards,
>    Juergen

Ah, so there is no other way to do this, than using a pre-processor.. From
the list you sent me, most of those apps dates back to the 1990s/early 2000,
which makes me wonder if I really can trust these apps? Some files wheren't
even available anymore.

Have you tested any of these that I could use for sure?

ZNorQ

5. Re: Include decision

• Posted by ZNorQ <znorq at holhaug.com> Nov 07, 2006
• 586 views

Pete Lomax wrote:
> 
> On Mon, 06 Nov 2006 13:48:40 -0800, ZNorQ <guest at RapidEuphoria.com>
> wrote:
> 
> >I'm using a third party include file - TCP4U - but I want to be able to
> >turn it off using a global constant ACTIVATE_TCP = FALSE. (This is if
> >I'm gonna distribute a version of my program without the TCP4U module
> >included. Don't worry, any recognitions are made to the appropriate
> >owners.)
> I don't and never have had tcp4u loaded, btw
> >
> >The way it works is that the DLL is 'sequenced' into my application,
> >and if the ACTIVATE_TCP = TRUE, it will save the DLL to file - and then
> >execute the TCP4U module.
> Are you really saying:
> }}}
<eucode>
> constant gunk={blah}
> if ACTIVATE_TCP then
>   fn = open("zz.dll","w")
>   puts(fn,decipher(gunk))
>   close(fn)
> end if
> </eucode>
{{{

> >

Well, if {blah} = the DLL code in a byte structure - yes - this is how I
do it. I used a program that is called "Sequencer" by Andrea Cini to create
a sequenced version of the DLL that is incorporated into my program. This
way the user of the program don't have to worry about having the DLL laying
around. So, if ACTIVATE_TCP = true, the above program you describe exports
the DLL. (Not sure what that 'decipher' function you're referring to is 
supposed to be..)

The problem however, is that I don't want it to start the wrappers 
initialization process of it if ACTIVATE_TCP = false, like the DLL loading
which is taken care of by the wrapper itself.

What I had to do for now, is to include an 'if ACTIAVE_TCP = FALSE then
<skip all TCP4U initializations>' in the TCP4U wrapper itself. I really don't
want to make changes in other peoples applications. Ofcourse, without the
change, I'll end up with a bunch of errors since the wrapper cannot find the
DLL file.

Then you might ask, why not just remove the include file? Well, I use a
system where I have alot of 'switches' (constants) that I turn on / off. By 
using these I can 'fine tune' the application according to the users need.
Think of them as some backward attempt of compiler directives...

Example;
  ACTIVATE_TCP = FALSE
  AUTHENTIFICATION = TRUE
  EXPIRY_DATE = "11.07.2006"
  ...

My problem would have been solved if there was a way to include the wrapper
only if the ACTIVATE_TCP = true, and if it isn't - skip the include.

So in short - since the wrapper takes care of all initializations, and I don't
want that to start if ACTIVATE_TCP = true, and I don't want to make changes
in the wrapper itself... What then?

It's been proposed to use some sort of pre-processor, so I'll have a look into
that. Not very driven in the world of pre-processors, though, so it might take
some time :) And it seems to me that either the pre-processor is too old - 
dating back to 97/98, or it doesn't exist - OR it doesn't contain what I 
need.. Doh...

> >The challenge (or - problem) is that when I deactivate the TCP4U
> >(ACTIVATE_TCP = FALSE) the program shall NOT save the DLL to disk, and
> >NOT run the TCP4U wrapper. Only problem is that as soon as I include the
> >wrapper - certain initialization routines are already executed, and since
> >it wont find the DLL file - errors will emerge.
> then eg:
> }}}
<eucode>
> constant zz=open_dll("zz.dll")
> if zz=-1 then ?9/0 end if -- or other use of zz
> </eucode>
{{{

> IE: the second half (in tcp4u) does NOT test ACTIVATE_TCP?
> 
> Well (assuming the above assumption is correct) the only thing I can
> suggest is that you repackage [SEE BELOW!], eg replace:
> 
> }}}
<eucode>
> constant zz=open_dll("zz.dll")
> ..etc
> </eucode>
{{{

> with
> integer zinit zinit=0
> atom zz, ..
> 
> procedure initZ()
>   zz=open_dll("zz.dll")
>   ..
>   zinit=1
> end procedure
> 
> global routine a(...)
>   if not zinit then initZ() end if
> end routine
> 
> global routine b(...)
>   if not zinit then initZ() end if
> end routine
> </eucode>
{{{

> 

> And... Re-Submit This Code to the Archives
> (that was the [SEE BELOW!] point above, btw.)
> You may feel reluctant, but it is prolly the right thing to do...
> >
> >What I've done up till now, is modify the wrapper itself with an
> >'IF ACTIVATE_TCP = TRUE...' etc, but I don't want to have to edit third
> >party snippets..
> >
> The problem with a [new] constant ACTIVATE_TCP is that it cannot be
> defined inside the wrapper, and it will break all legacy use, which
> the above ought not to - and if /your/ (ACTIVATE_TCP-wrapped) code
> does not call routine a/b/etc, no prob with missing zz.dll, yes?
> 
> >Anyone know what walkaround I can use? 
> HTH,
> Regards,
> Pete
> 
>

7. Re: Include decision

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 07, 2006
• 595 views

On Mon, 06 Nov 2006 13:48:40 -0800, ZNorQ <guest at RapidEuphoria.com>
wrote:

Oops, minor correction (missing eucode statement):

>I'm using a third party include file - TCP4U - but I want to be able to
>turn it off using a global constant ACTIVATE_TCP = FALSE. (This is if
>I'm gonna distribute a version of my program without the TCP4U module
>included. Don't worry, any recognitions are made to the appropriate
>owners.)
I don't and never have had tcp4u loaded, btw
>
>The way it works is that the DLL is 'sequenced' into my application,
>and if the ACTIVATE_TCP = TRUE, it will save the DLL to file - and then
>execute the TCP4U module.
Are you really saying:

constant gunk={blah}
if ACTIVATE_TCP then
  fn = open("zz.dll","w")
  puts(fn,decipher(gunk))
  close(fn)
end if

>
>The challenge (or - problem) is that when I deactivate the TCP4U
>(ACTIVATE_TCP = FALSE) the program shall NOT save the DLL to disk, and
>NOT run the TCP4U wrapper. Only problem is that as soon as I include the
>wrapper - certain initialization routines are already executed, and since
>it wont find the DLL file - errors will emerge.
then eg:

constant zz=open_dll("zz.dll")
if zz=-1 then ?9/0 end if -- or other use of zz

IE: the second half (in tcp4u) does NOT test ACTIVATE_TCP?

Well (assuming the above assumption is correct) the only thing I can
suggest is that you repackage [SEE BELOW!], eg replace:

constant zz=open_dll("zz.dll")
..etc

with

integer zinit zinit=0
atom zz, ..

procedure initZ()
  zz=open_dll("zz.dll")
  ..
  zinit=1
end procedure

global routine a(...)
  if not zinit then initZ() end if
end routine

global routine b(...)
  if not zinit then initZ() end if
end routine

And... Re-Submit This Code to the Archives
(that was the [SEE BELOW!] point above, btw.)
You may feel reluctant, but it is prolly the right thing to do...
>
>What I've done up till now, is modify the wrapper itself with an
>'IF ACTIVATE_TCP = TRUE...' etc, but I don't want to have to edit third
>party snippets..
>
The problem with a [new] constant ACTIVATE_TCP is that it cannot be
defined inside the wrapper, and it will break all legacy use, which
the above ought not to - and if /your/ (ACTIVATE_TCP-wrapped) code
does not call routine a/b/etc, no prob with missing zz.dll, yes?

>Anyone know what walkaround I can use? 
HTH,
Regards,
Pete

9. Re: Include decision

• Posted by ZNorQ <znorq at holhaug.com> Nov 08, 2006
• 661 views

Pete Lomax wrote:
> 
> On Mon, 06 Nov 2006 23:44:06 -0800, ZNorQ <guest at RapidEuphoria.com>
> wrote:
> 
> >I used a program that is called "Sequencer" by Andrea Cini
> >(Not sure what that 'decipher' function you're referring to is supposed to
> >be..)
> (That one you mentioned, or something/anything like it.)

??? Must be me, my memory isn't exactly perfect.. Just forget I asked. :P

> 
> >I can 'fine tune' the application according to the users need.
> I must admit I am a bit confused as to what optimisation you think you
> are achieving here, especially if the exe contains a 'sequenced' dll:
> ACTIVATE_TCP = FALSE:
>   exe loads that 25K (plus code from tcp4u.ew) every time.
> ACTIVATE_TCP = TRUE:
>   as above, plus (re-) creating tcp4w32.dll, plus loading the dll, and
>   therefore effectively having two copies in memory at once.
> 
> In both cases this is clearly sub-optimal. In the first case above, 
> you seem to be especially concerned that it does not execute some 22 
> statements and completely ignore an overhead several times that.

I never mentioned memory (ie. overhead?) being an issue, because it's not!
The topic which is 'do I want to include a file or not' - based on a ruling
factor which in this case is a constant beeing true or false.

This constant is part of a set of constants that enables me to EASILY 
give/remove access to different parts of my program. The program is a set
of useful functions that is very much needed - but the need for the different
types of functions is variable from project to project. Now, I want to create 
specific compiled releases of my program to each project in order not to
confuse the users with options they don't need or should not at all have
access to. TCP4U is just one part of that.

Back to the issue at hand;

A hopefully readable example of how the program handles the tcp part;
  --
  constant ACTIVATE_TCP = TRUE or FALSE
  sequence TCPDLL
  TCPDLL = {#00, ... <THE WHOLE DLL CODE IN HERE>...}
  --
  if ACTIVATE_TCP = TRUE then 
	save TCPDLL as "tcp4w32.dll" to disk
	activate tcpwrapper
	TCPDLL ={}		-->> Clear the sequence to free 25k of mem
  else TCPDLL = {}		-->> Just clear sequence and ..
	skip the tcplibrary	-->> .. skip the tcp wrapper initializations.
  end if

Instead of going into each part of the code removing everything that
has to do with the TCP library for each COMPILED release of the program
I distribute out to my user base, I just 'flip the switch' by adjusting
the constant to true or false instead.

I do this so that I don't need to 'remember' to include the tcp dll each
time - its baked into my program and saved to disk if necessary. You could
look at my program as one install file that extracts files needed.

Now, I wasn't really discussing wether this is good practise, or not - but
if it's possible - somehow - to include a file based on a set of rules,
ie. ACTIVATE_TCP being true or false.

> A better 'fine tuning' would be (obviously) to distribute either:
>  a) dll + exe incorporating tcp4u.ew, or
>  b) exe w/o any tcp code/capability at all.

Why is this obvious? Lets say that the tcp code is so incorporated into the
program, wouldn't it be better leave all tcp code - even the DLL - as is,
and just use a constant to flip it on or off? I'm talking about a compiled
distribution - an executable with the DLL incorporated. If I don't want the
user to have access to this part, the DLL in memory is just deleted, and never
saved to disk. The total size of the compiled program is a meg - there is
no problem concerning file-/memory size.

> 
> Now I know you're going to say you don't want to do that, but unless 
> you do, the whole 'fine tune' justification is meaningless - and it is
> precisely the meaningnessless of the justification that confuses me.
> 

I'm sorry, but it's not very easy for me to explain, but I also think that
all this is just a tad offopic as the question was really how do I dynamically
include files.. What I understand is that in native Euphoria, this isn't
possible. One have to look at pre-prosessors, etc - and that is what I'm 
looking into now.

> Of course you can create/load the dll every time, just not use it, and
> simply stop fretting about such an insignificant overhead?

It's not about overhead. And yes, I could just create the DLL and just
let the wrapper do the initialization and just don't use it. This is not
the issue.

If I do something backward, let me - I'm in a learning stage here. 
The programming jargons aren't that familiar to me.. Hopefully some of 
these jargons penetrates that brick wall in my brain.

> 
> Regards,
> Pete
> PS An alternative to a pre-processor in this case could be:
> withTCP.exw:
> }}}
<eucode>
> --global procedure create_dll(sequence name) [see below]
> include tcp4u.ew
> global constant ACTIVATE_TCP = TRUE
> include myapp.exw
> </eucode>
{{{

> and woutTCP.exw:
> }}}
<eucode>
> ACTIVATE_TCP = FALSE
> include myapp.exw
> </eucode>
{{{


Yes, this is probably a good way to do it, but then remember that what I'm
looking for is constant declaration part in the beginning of the code - which is
a good clean overview of what access I want to give to the user. This was what
I was hoping for anyway.

> 
> This means it depends on which program you run/install, which is
> better than relying on editing the source, as that can become quite a
> drag at ten times a day.
> 
> PPS A better method of creating the dll would be to catch the open
> error, rather than doing it every time, eg:
> }}}
<eucode>
> global function link_dll(sequence name)
> atom handle
> integer r
>     handle = open_dll( name )
> 
>     if handle = NULL then
>         r = routine_id("create_dll")
>         if r!=-1 then
>             call_proc(r,{name})
>             handle = open_dll( name)
>         end if
>         if handle = NULL then
>             wait_abort("Couldn't find DLL " & name)
>         end if
>     end if
>     return handle
> 
> end function
> </eucode>
{{{

> 

As far as I can see, this would have to be done in the 3rd party wrapper then?
Remember, I just utilize the TCP4U's functions, I don't do anything with the
wrapper itself - I want to leave that be.

When it comes to opening DLL's etc., I'm drawing a blank. Haven't wandered into
that turf yet.. But I understand what you're getting at in the above example.

Thanks for the feedback, Pete.

Ken / ZNorQ