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

new topic     » goto parent     » topic index » view thread      » older message » newer message

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.
> 
> 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.
That's an interesting method. I don't usually mix old libs and new libs; however
I usually make a new folder under my EUDIR and name it lib and that's where I
dump contributed libraries.

Except for bigger libraries such as wxEuphoria (although that has changed with
0.10.0) and win32lib. They usually get their own directories.

> By the way, has anyone written anything which makes use of the new rules?
Good question. I remember being advocate for it but I haven't used it yet.


> Now, another problem.  Try this:
> 
> }}}
<eucode>
> -- 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
> </eucode>
{{{

> 
> 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

Yeah, this is confirmed. I haven't started on it yet, but I was going to
experiment with an "import" keyword which worked exactly like "include" only
global symbols included other than directly would not propagate to the main
program.

I haven't started on it yet, I've just been thinking. I'm also working with
wxEuphoria stuff (albeit slowly) so I can't promise anything in a timely manner,
if at all.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu