Re: Modifying the Euphoria interpreter
Robert Craig wrote:
>
> CChris wrote:
> > Definitely, this is a Windows only patch, so I check platform() before
> > calling open_dll() and before using c_func().
> >
> > I tested my mod standalone, and it works. This does not replace full
> > testing, but means I can go ahead with it.
> >
> > The proposed modification is actually a _bug fix_:
> > * Problem: Under Windows NT/2K/XP and later, paths may legitimately contain
> > non-ASCII characters, as long as they belong to the system codepage. If
> > the path in EUDIR, or any path inside EUINC, contains such a character,
> > said path is not processed by path_open(), and include files therein are not
> > found.
> > * Cause of the problem: when getenv() returns a string, that string is
> > encoded using the current Windows codepage. But the strings open() passes
> > are interpreted using the OEM current codepage. Since they have different
> > layouts, some characters are misinterpreted, and path_open() searches a path
> > that very likely doesn't exist.
> > * Current workaround: In the Advanced tab of system properties, change
> > offending characters in paths to the ones with the right codes.
> > Example: if a path ontains a e acute accent, coded #E9 in the Windows code
> > page and #82 in the OEM codepage, replace that e acute by the character with
> > code #82 in the Windows codepage. This happens to be a U acute.
> > This workaround implies tweaking environment variables and rebooting the
> > computer for changes to take effect; it is not satisfactory, but at least it
> > works.
> > * Suggested mod to front end, specifically to path_open():
> > If trying to open a file using a path from EUINC/EUDIR fails, if platform()
> > is Windows and if the path has accented characters, then try again after
> > converting this path using the CharToOemA() WinAPI. It has been in
> > kernel32.dll since Windows 3.0 and probably before.
> > Conversion applies to the path only, not the file name, since it is not
> > stored in the environment variable.
> >
> > At least this is the right API to use, and the modified path_open() now
> > finds
> > files it was missing before.
> > When I have tested with a real life interpreter (built under OW1.5), I'll
> > (try to) submit that mod. Unless someone has a brighter idea.
>
> This sounds reasonable to me.
> Maybe others have an opinion?
>
> I can give you full developer permissions on SourceForge
> so you can check out official source code using SVN
> (e.g. TortoiseSVN) and check it back in again after testing it
> on your system. You just need to sign up for a free SourceForge id
> and let me know what it is.
>
> I realize that 90% of the job will be learning how
> to use SVN, but I want to wean the community off using
> me (or Matt) to make all changes. It will be better if
> we have several people who are able to make changes and
> check them in (and then handle the almost-inevitable bug
> reports and enhancement requests that will flow from that).
>
> I hope to get back to the 3.1 FreeBSD Release Candidate
> later today. I had several distractions over the past few days.
> It might be better to hold off on checking in your changes
> until I do the full 3.1 official release for all platforms,
> this week I hope.
>
> Thanks,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
It's Ok; my SF id is CChris.
I have other things waiting (most urgently fixing text printing using
nonstandard options in win32lib), so that I certainly can wait.
And I was aware too that there would be some learning investment on SVN...
Feel free to email privately oedoc at free dot fr for any relevant
request/info.
CChris
|
Not Categorized, Please Help
|
|
