OpenEuphoria

1. include path problem [WAS: STANDARD EUPHORIA LIBRARYS]

• Posted by Bob Elia <bobelia200 at netzero?n?t> Aug 05, 2007
• 572 views

C.K. Lester wrote:
>Bob Elia wrote:
>> 
>> I am currently using version 3.0.2 because the include path changes break
>> several of my programs; apparently, I'm the only person on earth with this
>> problem since it's never been mentioned.
>
>Just FMI, could you give an example where that change broke some code? I can't
>imagine a case where looking one more spot for include files would break code.

Hi CK,

Sorry for the delay.  The problems I am having are namespace conflict errors,
so it's only in that sense that they break my code.  The problem is that
I'm using a rather unorthodox, though legal under the old rules, EUINC.
I am aware that this is NOT recommended practice.

I had been in the habit of installing each new version of euphoria in a
different directory and then prepending it's include directory to EUINC.
So, the latest %EUDIR%\INCLUDE would always be at the beginning of EUINC
so a program would always find the current standard includes first.
New libraries would be installed in the current installation's ...\INCLUDE.
If I wanted to compare versions I could run a batch file which would change
the current installation by changing EUDIR and EUINC.

What happens under the new rules is that a library residing in an old
...\INCLUDE path which includes a standard file gets it from that old
directory.  Then, later on, another file includes the same filename but
gets it from the current installation's ...\INCLUDE thus causing a
namespace error.

Some time ago I created a single directory, separate from any installation,
called \EULIBS\ for new libraries.  I've managed to fix the errors I was getting
as they occur by moving old libraries out of the old .../INCLUDE/ directories
into EULIBS.

This looks simple at first glance but there are (or perhaps were) user
contributions which contained mods of files that were not renamed.


By the way, has anyone written anything which makes use of the new rules?


Now, another problem.  Try this:

-- O:\TESTSAFE\TESTSAFE.EX

include machine.e  -- copied from %EUDIR%\INCLUDE\safe.e as MACHINE.E
                   -- into this program's directory as per REFMAN.DOC

include database.e    -- includes machine.e

atom a

a = allocate(1024)

? a

while get_key() = -1 do end while
-- end of file

This results in:

L:\progra~1\EUPHORIA\INCLUDE\database.e:127
A namespace qualifier is needed to resolve allocate.
allocate is defined as a global symbol in:
    .\machine.e
    L:\progra~1\EUPHORIA\INCLUDE\machine.e

mem0 = allocate(4)
              ^

Can anyone reproduce this error?

This used to work because of the "include once" behavior.  What now?
If this is not due to my error, then perhaps the docs will have to
be changed to recommending renaming safe.e to machine.e in %EUDIR%\INCLUDE\.
This could be done with a batch file.

Bob

3. Re: include path problem [WAS: STANDARD EUPHORIA LIBRARYS]

• Posted by c.k.lester <euphoric at cklest?r.co?> Aug 06, 2007
• 556 views

Bob Elia wrote:
> C.K. Lester wrote:
> >Bob Elia wrote:
> >> I am currently using version 3.0.2 because the include path changes break
> >> several of my programs; apparently, I'm the only person on earth with this
> >> problem since it's never been mentioned.
> >Just FMI, could you give an example where that change broke some code? I
> >can't
> >imagine a case where looking one more spot for include files would break
> >code.
> By the way, has anyone written anything which makes use of the new rules?

My BBCMF is the reason why I needed it.

   http://www.cklester.com/euphoria/bbcmf/

I wanted this change primarily because CGI is so different from standard
program interfaces. I've been able to create a significant plugin system
for BBCMF that was not possible with the old include method.  Even now I
wish open() worked the same way; it would make for pure modularity.

5. Re: include path problem [WAS: STANDARD EUPHORIA LIBRARYS]

• Posted by c.k.lester <euphoric at c?lester.c?m> Aug 06, 2007
• 554 views
• Last edited Aug 07, 2007

CChris wrote:
> c.k.lester wrote:
> > I wanted this change primarily because CGI is so different from standard
> > program interfaces. I've been able to create a significant plugin system
> > for BBCMF that was not possible with the old include method.  Even now I
> > wish open() worked the same way; it would make for pure modularity.
> What about an open_path(filename,mode) which would use exactly the same
> mechanism that }}}
<eucode>include</eucode>
{{{

> uses?</font>

Yes, please. :)

Here were Rob's comments to me about modifying open():

"I really don't think you should mess with open().
It should remain a basic, efficient, primitive mechanism
for opening a file according to the rules of
the host operating system.

You should instead make your own search_open(), or
some such thing, that will take a list of directories,
from an environment variable, or whatever,
and search them according to whatever rules you like.
Don't force the rest of us to have to worry about your path
rules, and accidentally open a file that shouldn't be opened.

Lots of languages have a search path for opening include files.
I don't know of any that have a search path for their
basic, general, "open a file" operation."

So, I guess he said what you're saying, but I was too dense to get it. :/