1. Bug in 1.5a ?
I am using David Cuny's EE editor and Preprocessor.
After fighting for many hours with a program that claimed a routine included
in a .e included file was not declared, I pasted the whole .e into the .ex and
it worked fine. Before you write with all the classic mistakes. It was called
after being declared and I checked the files with EDIT to ensure it was not a
bug in EE or PP. I included print statements before and after the routine
declaration and these worked OK. My suspicion is that I included din\ini.e and
the interpreter was confused by the filename somehow. It ran the included file
fine but did not seem to declare any of its routines. I tried some others and
had the same problem. When pasted into the .ex they all worked fine.
Anybody else had this trouble ?
Daniel
2. Re: Bug in 1.5a ?
Hello Daniel,
>After fighting for many hours with a program that claimed a routine
included
>in a .e included file was not declared, I pasted the whole .e into the
.ex and
>it worked fine. Before you write with all the classic mistakes. It was
called
>after being declared and I checked the files with EDIT to ensure it was
not a
>bug in EE or PP. I included print statements before and after the
routine
>declaration and these worked OK. My suspicion is that I included
din\ini.e and
>the interpreter was confused by the filename somehow. It ran the
included file
>fine but did not seem to declare any of its routines. I tried some
others and
>had the same problem. When pasted into the .ex they all worked fine.
Here is a possible solution.
Check your include file to make sure that all routines called externally
(i.e. from the main .ex program) from the include file are declared as
global. If they are not, you will get an error saying that they are not
declared. If you cut and paste them into a .ex file they will work fine.
Example:
--this is a include file called inc.e
procedure x()
do something here
end procedure
global procedure y()
do something here
end procedure
x() -- this works fine inside the include file
y() -- this also works fine inside the include file
--end include file
--Main program
include inc.e
x() --this will not work, not declared globally
y() --this will work fine
abort(0)
--end main program
This may not be your problem, but it would be the first thing that I
would check for.
Hope this helps,
Greg Harris
HHS
3. Re: Bug in 1.5a ?
On Thu, 5 Feb 1998, Daniel Johnson wrote:
> Anybody else had this trouble ?
When I ran into it, it was fixed when I prefixed the variables with
'global '
--
Ryan Zerby, Senior Programmer ryanz at netrex.com
"to create out of his own imagination the beauty of his wild forebears
--a mythology he cannot inherit." -- Allen Ginsberg 'Wild Orphan'
4. Re: Bug in 1.5a ?
I had include file (declaration) problems with Eu when I used it a few years
ago.. I finally quit trying. I just figured the system was imature. If you ge
t
it figured out, please let me know.
I would hate to tell you how much time I spent on a major development before I
decided to move on to another development environment.
don
Daniel Johnson wrote:
> I am using David Cuny's EE editor and Preprocessor.
>
> After fighting for many hours with a program that claimed a routine included
> in a .e included file was not declared, I pasted the whole .e into the .ex and
> it worked fine. Before you write with all the classic mistakes. It was called
> after being declared and I checked the files with EDIT to ensure it was not a
> bug in EE or PP. I included print statements before and after the routine
> declaration and these worked OK. My suspicion is that I included din\ini.e and
> the interpreter was confused by the filename somehow. It ran the included file
> fine but did not seem to declare any of its routines. I tried some others and
> had the same problem. When pasted into the .ex they all worked fine.
>
> Anybody else had this trouble ?
>
> Daniel
5. Re: Bug in 1.5a ?
OK, I am sorry. Classic mistake no. 5. I am a fool, and you can tell how much
programming I have done so far. Oh well, I live and learn. Global routines
here I come...
Advice for any other newbies : do not stick your head into this list until you
have read the manuals, or you end up looking like a wally. (Like me)
At the same time, I'd like to voice my support for splitting ex.exe into libs,
provided they can be protected. This allows for smaller bound files, custom
routines and makes everything much more professional.
Has anybody written a self-extracting installer of any sort ? If not is there
any demand ?
I am thinking of writing a bind-type program which converts a .ex with lots of
custom .e files into a single .ex with all the routines bar the ones that come
with Euphoria. This allows for better distribution ie to this list and the
files should still be a reasonable size. I was disappointed when I could not
get the fractals to work because I needed load_pic. I only have save pick.
Surely this cannot be a bad thing ?
Daniel
6. Re: Bug in 1.5a ?
Apparently a lot of people have been severely confused
by the "global" keyword in Euphoria. I will improve
the description in REFMAN.DOC. See also
TROUBLE.DOC if you have found that
routines / vars declared in an include file are
reported as "not declared" when you try to
use them in another file.
The situation is this:
If you declare a constant, variable or routine and you do not
put the keyword "global" in front of the declaration,
that variable or routine declaration will become
invisible at the end of its file. It will not be accessible
from any other file. e.g.
-- file x.e
global procedure foo()
end procedure
Without the word "global", foo() would be unknown outside
of x.e. It would only be known inside x.e from the point where
it is declared to the end of x.e. Only code in x.e after the
declaration of foo() would be able to call foo().
With the word "global", foo() will be visible from the point it
is declared right through the rest of the program, in all other
files.
Many people wrongly assume that "global" is the default,
and are puzzled when a declared routine or variable
is said to be "not declared" when called from another
file. I guess that's because BASIC doesn't have this concept,
and in C it's inverted - global is the default situation and
you need the optional keyword "static" to *prevent* a routine or variable
from being known outside of its file. The guy who invented C++
(Stroustrup) has stated that C has it wrong - it should have
been defined the other way (Euphoria's way), i.e. default to
"not global".
Why bother with all this?
Consider that you make a .e include file for other people to use.
Suppose your include file has 20 routines and 30 variables,
but the user of your file should only use 2 of the routines and
none of the variables. Without the global/not-global feature,
you would have to add 20+30 = 50 names to his program,
names that he is not allowed to use. This might cause naming
conflicts for him and he would
have to change some of his names or some of your names.
Furthermore, the global keyword would help to remind him of which
routines/variables he can legitimately use, and which are
internal to your code.
When you later modify your .e file, it will help you to know
that some routine or variable is
not global, therefore you will not break other people's code by
changing/removing it.
If global were the default, people would be lazy and there
would be many internal routines/vars exposed as global
that needn't be. With "not global" as the default, the tendency is
that only the routines/vars that actually need to be global will
be declared that way.
Regards,
Rob Craig
Rapid Deployment Software
