OpenEuphoria

2. Re: More bugs in exw.exe

• Posted by Robert Craig <rds at RapidEuph?ria?com> Jul 16, 2007
• 616 views
• Last edited Jul 17, 2007

CChris wrote:
> 1/ Trying to open C:\VE OPEN\visualeuphoria.exw by double clicking it in
> Windows
> explorer (or its free replacement) causes interpreter to barf:
> Can't open C:\VE.exu

I tested this exact path and filename on my XP system
and it worked fine by double-clicking. I'm not sure
what happened on your system.

I've noticed lately that if it can't open xxx.exw,
it complains about xxx.exu.
This is due to Matt's recent change. The error message
should really be improved somehow.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

4. Re: More bugs in exw.exe

• Posted by Matt Lewis <matthewwalkerlewis at gm??l.com> Jul 17, 2007
• 597 views

CChris wrote:
> 
> Robert Craig wrote:
> > 
> > CChris wrote:
> > > 1/ Trying to open C:\VE OPEN\visualeuphoria.exw by double clicking it in
> > > Windows
> > > explorer (or its free replacement) causes interpreter to barf:
> > > Can't open C:\VE.exu
> > 
> > I tested this exact path and filename on my XP system
> > and it worked fine by double-clicking. I'm not sure
> > what happened on your system.
> > 
> 
> I'm using Wondows XP Home SP2. At the time I was using Windows 2000 on an
> earlier
> computer (when I was working on that VE project), I didn't have this problem.
> 
> Which Matt's mod are you talking about?

It's in main.e, where it tries different extensions.  Basically, it loops
through all standard euphoria executable extensions, rather than the single,
platform specific extension based upon the interpreter.  On Windows, I 
think '.exu' is the last extension tried, and the error just uses whatever
was left.  It should be changed to the platform specific extension.

Matt

6. Re: More bugs in exw.exe

• Posted by Juergen Luethje <j.lue at ??x.de> Jul 17, 2007
• 614 views

Rob wrote:

> CChris wrote:
> 
>> 1/ Trying to open C:\VE OPEN\visualeuphoria.exw by double clicking it in
>> Windows
>> explorer (or its free replacement) causes interpreter to barf:
>> Can't open C:\VE.exu
> 
> I tested this exact path and filename on my XP system
> and it worked fine by double-clicking.

I can confirm this.

> I'm not sure what happened on your system.

I also don't know this, of course. However, I can guess that maybe on
his system in the Windows registry some double quotes are missing at
a particular place.

In the message to which Rob replied, CChris had written:
| This is a bug, since the behaviour is not documented and the above
| is a valid Windows path.

But the bug probably is not in the Euphoria interpreter, since the
_operating system_ controls, what is passed to an application as a
single parameter, and what is passed as separate parameters.

Regards,
   Juergen

8. Re: More bugs in exw.exe

• Posted by Robert Craig <rds at RapidEup?oria.c?m> Jul 17, 2007
• 611 views

CChris wrote:
> While I'm at it:
> The install script blindly adds its thing to existing environment variables,
> without checking whether that's actually needed. So, you can wind up with an
> EUDIR variable containing:
> D:\EUPHORIA\BIN;D:\EUPHORIA\BIN;D:\EUPHORIA\BIN;
> That's how it looks on my system right now.
> While this is not really a bug, as the redundancy hardly matters, this could
> become annoying after the 23rd reinstall of Euphoria for any reason. Perhaps
> an optimisation is in order there.

Yes, I'm aware of that problem.
I remember spending a lot of time a couple of years ago,
looking through the INNO docs and website, 
trying to eliminate that, but I never found a 
good way to do it. Maybe someone has an idea.
It seems like something that many INNO users would run into.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

10. Re: More bugs in exw.exe

• Posted by CChris <christian.cuvier at a?ric?lture.gouv.fr> Jul 17, 2007
• 599 views

Juergen Luethje wrote:
> 
> Rob wrote:
> 
> > CChris wrote:
> > 
> >> 1/ Trying to open C:\VE OPEN\visualeuphoria.exw by double clicking it in
> >> Windows
> >> explorer (or its free replacement) causes interpreter to barf:
> >> Can't open C:\VE.exu
> > 
> > I tested this exact path and filename on my XP system
> > and it worked fine by double-clicking.
> 
> I can confirm this.
> 
> > I'm not sure what happened on your system.
> 
> I also don't know this, of course. However, I can guess that maybe on
> his system in the Windows registry some double quotes are missing at
> a particular place.
> 
> In the message to which Rob replied, CChris had written:
> | This is a bug, since the behaviour is not documented and the above
> | is a valid Windows path.
> 
> But the bug probably is not in the Euphoria interpreter, since the
> _operating system_ controls, what is passed to an application as a
> single parameter, and what is passed as separate parameters.
> 
> Regards,
>    Juergen

That fixed the problem.
I changed the parameter for both .exw and .ex files to read "%0" instead of 
%1 (so that the whole command line is passed, just in case), and the file now
properly opens.

Either I somehow messed that up - but I really can't see when - or there are
some double quotes to add in the strings the install script uses to define file
associations. I'll let omeone with more experience with this language to look
into it.

There's still a standing bug when two filenames have the same length and differ
by accented characters. They are considered different even though they may differ
by case only. As I said, same_name() in scanner.e needs some smarts to deal with
this.

RBIL v61 reports that the DOS function AX=#65A2 (ASCIZ country dependent
filename capitalization) is hardly functional, which would require some low level
work using the filename uppercase table directly. Can anyone infirm this? It
would really help making the code more compact (it wouldn't be overly complex
otherwise).

CChris

12. Re: More bugs in exw.exe

• Posted by Jules <jdavy at ?s?.pipex.com> Jul 17, 2007
• 624 views

I can't recommend installing version 3.1 at all, because it
> has known serious bugs.

It does? I'd like to know what they are. Maybe there should be a 'stable'
release and 'bleeding edge' release. At the moment you're stuck with the one
option, buggy or not - unless 2.5 counts as the 'stable' release?

14. Re: More bugs in exw.exe

• Posted by Juergen Luethje <j.lue at ?m?.de> Jul 17, 2007
• 593 views

Jules wrote:

>> I can't recommend installing version 3.1 at all, because it
>> has known serious bugs.
> 
> It does? I'd like to know what they are. 

I wrote the lines above mainly because of
- memory leak on Linux / FreeBSD
- find_from() sometimes crashes the program
(For more detailed information please use the EUforum search function.)
More bugs are listed here:
<http://sourceforge.net/tracker/?group_id=182827&atid=902782>

> Maybe there should be a 'stable' release and 'bleeding edge' release.

Yes, there should be. And hadn't there already been agreement on this
point?

> At the moment you're stuck with the one option,
> buggy or not - unless 2.5 counts as the 'stable' release?

For me, personally, 3.0.2 counts as the latest stable release.

Regards,
   Juergen

16. Re: More bugs in exw.exe

• Posted by Juergen Luethje <j.lue at ?m?.de> Jul 17, 2007
• 609 views
• Last edited Jul 18, 2007

CChris wrote:

> In a DOS Handbuch I happen to have in the depths of mmy archives, the
> following
> is written about functions AX=#65A0-2:
> 
> <quote>
> Die Funktionen sind erst als DOS 4.0 vorhanden und wurden bisher nicht
> dokumentiert.
> Sie wandeln Filenamen in Großbuchstaben um. Es gilt die gleiche
> Aufrufschnittstelle
> wie bei den Funktionen AX=6520H bis 6522H. Der Aufruf funktioniert aber wegen
> eines Bugs in den DOS versionen 4.0 bis 5.0 nicht.
> </quote>

Translation:
| The functions have not been available until DOS 4.0, and have not been
| documented up to now. They convert file names to capital letters. In
| order to call them, use the same interface as for functions AX=6520H to
| 6522H. Because of a bug, the functions do not work in DOS versions 4.0
| to 5.0, though.

> Juergen, or anyone else who speaks german: does this imply that these
> functions
> shouldn't be used? Are they the same as the AX=#6520-6522?

Maybe tomorrow I'll have some time to look into Ralph Brown's interrupt
list, and maybe then I can say something about it. Currently we have
warm tropical nights here, and I want to "finish work" now and drink a
beer. 

Regards,
   Juergen

18. Re: More bugs in exw.exe

• Posted by Gary Shingles <eu at 531?i?co.nz> Jul 18, 2007
• 610 views

Juergen Luethje wrote:
> > <quote>
> > Die Funktionen sind erst als DOS 4.0 vorhanden und wurden bisher nicht
> > dokumentiert.
> > Sie wandeln Filenamen in Großbuchstaben um. Es gilt die gleiche
> > Aufrufschnittstelle
> > wie bei den Funktionen AX=6520H bis 6522H. Der Aufruf funktioniert aber
> > wegen
> > eines Bugs in den DOS versionen 4.0 bis 5.0 nicht.
> > </quote>
> 
> Translation:
> | The functions have not been available until DOS 4.0, and have not been
> | documented up to now. They convert file names to capital letters. In
> | order to call them, use the same interface as for functions AX=6520H to
> | 6522H. Because of a bug, the functions do not work in DOS versions 4.0
> | to 5.0, though.

No... it's:

The functions are only present as DOS 4,0 and were so far not documented. They
convert file names into capital letters. It applies the same call interface as
with the functions AX=6520H to 6522H. The call does not function however because
of a nose in the DOS versions 4,0 to 5,0.

According to Google, that is. 
(Which wasn't doing too badly up until the nose thing)

Gary

20. Re: More bugs in exw.exe

• Posted by CChris <christian.cuvier at agricultur?.g?uv.fr> Jul 18, 2007
• 650 views

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Juergen Luethje wrote:
> > > 
> > > CChris wrote:
> > > 
> > > > In a DOS Handbuch I happen to have in the depths of mmy archives, the
> > > > following
> > > > is written about functions AX=#65A0-2:
> > > > 
> > > > <quote>
> > > > Die Funktionen sind erst als DOS 4.0 vorhanden und wurden bisher nicht
> > > > dokumentiert.
> > > > Sie wandeln Filenamen in Großbuchstaben um. Es gilt die gleiche
> > > > Aufrufschnittstelle
> > > > wie bei den Funktionen AX=6520H bis 6522H. Der Aufruf funktioniert aber
> > > > wegen
> > > > eines Bugs in den DOS versionen 4.0 bis 5.0 nicht.
> > > > </quote>
> > > 
> > > Translation:
> > > | The functions have not been available until DOS 4.0, and have not been
> > > | documented up to now. They convert file names to capital letters. In
> > > | order to call them, use the same interface as for functions AX=6520H to
> > > | 6522H. Because of a bug, the functions do not work in DOS versions 4.0
> > > | to 5.0, though.
> > > 
> > > > Juergen, or anyone else who speaks german: does this imply that these
> > > > functions
> > > > shouldn't be used? Are they the same as the AX=#6520-6522?
> > > 
> > > Maybe tomorrow I'll have some time to look into Ralph Brown's interrupt
> > > list, and maybe then I can say something about it. Currently we have
> > > warm tropical nights here, and I want to "finish work" now and drink a
> > > beer. 
> > > 
> > > Regards,
> > >    Juergen
> > 
> > Good idea.
> > I have a very shallow knowledge of german, so I had almost got it right, but
> > definitely wasn't sure.
> > 
> > RBIL appears to extend this to all versions up to 7.10, with the exception
> > of
> > some Novell (7.0) versions.
> 
> Yes. After having looked into Ralf Brown's interrupt list Release 61,
> I think it's better not to use INT 21, AX=#65A0-A2.
> 

Just what I thought. And indeed they don't work on my system.

> > Looks like I'm going to import the capitalisation
> > table using function AX=#6504 to a sequence and transcode accented chars
> > using
> > that. Unless AX=#6522 is considered a decent, bug-free substitute - the
> > character
> > tables may differ subtly.
> 
> It seems to me that the official DOS functions to capitalize a string are
> INT 21, AX=#6521 and AX=#6522. Here is an example:
> <<a
> href="http://www.uv.tietgen.dk/Staff/Mlha/PC/Prog/asm/int/21/6521.htm">http://www.uv.tietgen.dk/Staff/Mlha/PC/Prog/asm/int/21/6521.htm</a>>
> 

I have played with them last evening, and decided not to use them either.
Capitalisation of accented characters is not done or at least not always done -
for instance, ü and Ü are not recognised as differing in case only.

The only thing that I got working is the one I mentioned, ie working directly
with the filename capitalisation table a pointer to which is returned by function
#6504. I'm currently streamlining the code, since conditional jumps are usually
bad for performance, but basically that fixed the bug.

Under Windows, there's a CharUpperA() API that does the job straight and hardly
ever fails, so using it is certainly the safest way to go.

CChris
> Regards,
>    Juergen

22. Re: More bugs in exw.exe

• Posted by CChris <christian.cuvier at ag?icul?ure.gouv.fr> Jul 18, 2007
• 643 views

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Juergen Luethje wrote:
> > 
> >> CChris wrote:
> 
> [snipped old text]
> 
> >>> Looks like I'm going to import the capitalisation
> >>> table using function AX=#6504 to a sequence and transcode accented chars
> >>> using
> >>> that. Unless AX=#6522 is considered a decent, bug-free substitute - the
> >>> character
> >>> tables may differ subtly.
> >> 
> >> It seems to me that the official DOS functions to capitalize a string are
> >> INT 21, AX=#6521 and AX=#6522. Here is an example:
> >> <<a
> >> href="http://www.uv.tietgen.dk/Staff/Mlha/PC/Prog/asm/int/21/6521.htm">http://www.uv.tietgen.dk/Staff/Mlha/PC/Prog/asm/int/21/6521.htm</a>>
> >> 
> > 
> > I have played with them last evening, and decided not to use them either.
> > Capitalisation
> > of accented characters is not done or at least not always done - for
> > instance,
> > ü and Ü are not recognised as differing in case only.
> 
> It looks as if I've found the reason for this. In my tests,
> INT 21 AX=#6521 properly capitalizes all lowercase German special
> characters in _ASCII_ code. But when I just open an editor on Windows
> and type some text, the text normally is in _ANSI_ code ...
> 
>       |      in       | output of INT 21 AX=#6521 (on Win XP)
> ------+---------------+--------------------------------------
>       |     "äöü"     |
> ASCII | {#84,#94,#81} |  {#8E,#99,#9A} = "ÄÖÜ"  -->  correct
> ANSI  | {#E4,#F6,#FC} |  {#E5,#F6,#FC} = "åöü"  -->  wrong
> 
> And the problem is that a program hardly knows, whether a file that it
> reads is coded in ASCII or in ANSI.
> 

Reminds me of something <smile/>.

> > The only thing that I got working is the one I mentioned, ie working
> > directly
> > with the filename capitalisation table a pointer to which is returned by
> > function
> > #6504. I'm currently streamlining the code, since conditional jumps are
> > usually
> > bad for performance, but basically that fixed the bug.
> 
> If this is reliable, then it's fine. Did you test it with special
> characters in ASCII code and ANSI code?
> 

When processed by a C compiler, the front end sees all strings as ANSI, so the
ASCII framework is not a problem. And my method correctly maps â to Â, ü to Ü, é
to É and so forth, didn't try them all.

As a result, including both fileü.e and fileÜ.e with the same contents no longer
causes "a namespace qualifier is required here".

If you want to run some tests, just run this:

include machine.e

sequence regs,dword
atom strings,addr
strings=allocate_low(5)
-- prepare the DOS serice call
regs=repeat(0,10)
regs[REG_DX]=-1 -- current country
regs[REG_BX]=-1 -- current code page
regs[REG_ES]=floor(strings/16) -- turn 32 bit ptr into 16:16
regs[REG_DI]=and_bits(strings,#0F)
regs[REG_CX]=5 -- buffer size
regs[REG_AX]=#6504 -- function code
-- request *table from DOS for the current code page and country
regs=dos_interrupt(#21,regs)
-- should be an error check here, will fail under DOS <4.0

-- retrieve 16:16 far pointer and turn it into 32-bit near ptr
dword=peek({strings+1,4})
addr=dword[1]+256*dword[2]+16*dword[3]+4096*dword[4]
-- print numerical values in table
?peek({addr+2,128})
-- clean up and wait for keypress
free_low(strings)
?machine_func(26,0)

The printout of numeric character codes will tell you exactly what is mapped to
what. Tconsole display using puts() instead of print() is wrong as expected.

> > Under Windows, there's a CharUpperA() API that does the job straight and
> > hardly
> > ever fails, so using it is certainly the safest way to go.
> 
> I always use CharUpperBuffA(), but I really hope the results are the
> same as with CharUpperA(). 

Exactly the same, and even more so as CharUpperA() transforms the string in
place. This can be a problem with multibyte characters (and then CharUpperBuffA()
is safer to use -.

> 
>       |      in       | output of CharUpperBuffA() (on Win XP)
> ------+---------------+---------------------------------------
>       |     "äöü"     |
> ASCII | {#84,#94,#81} |  {#84,#94,#81} = "äöü"  -->  wrong
> ANSI  | {#E4,#F6,#FC} |  {#C4,#D6,#DC} = "ÄÖÜ"  -->  correct
> 
> So yes, it hardly ever fails -- as long as the special characters are
> coded in ANSI. >:->
> 
> Regards,
>    Juergen
> 
> -- 
> Computers help to solve problems,
> which wouldn't exist without computers.