Hi Alan,
that sounds like a good plan.
An alternative would be to use hexadecimal escape codes
(\u...) instead of
non-ASCII7 characters in the source code, but that has the
drawback that
you can not view the UNICODE character anymore.
I will work on this - earliest commit time will be
tomorro
On 2010-12-30 09:07+0100 Arjen Markus wrote:
> Hello,
>
> I have found an easy way to solve the UTF-8 problem,
> source -econding utf-8 (not cp1252). But it works
> only for Tcl 8.5, as the [source] command was extended
> with that option then.
Hi Arjen:
It appears from what you have said that T
Hello,
I have found an easy way to solve the UTF-8 problem,
source -econding utf-8 (not cp1252). But it works
only for Tcl 8.5, as the [source] command was extended
with that option then.
I will either have to see about an alternative or
make sure this option is not used for Tcl 8.4 and older.
R
Hi Alan,
Tcl has two options to do what you suggest:
- Set the system encoding to cp1252
- Source the file using -encoding cp1252
(A third is to adapt the C side of the Plplot API.)
I will experiment with both.
Regards,
Arjen
On 2010-12-24 22:20, Alan W. Irwin wrote:
> On 2010-12-24 13:05+010
On 2010-12-24 13:05+0100 Arjen Markus wrote:
> Hi Alan,
>
> On 2010-12-21 20:03, Alan W. Irwin wrote:
>
>>
>> I will stop now and not comment more on the Tcl case, because I think
>> it is essential to focus on C for now and one of the cairo or qt
>> devices.
>>
>> Of course, as I have stated be
Hi Alan,
On 2010-12-21 20:03, Alan W. Irwin wrote:
>
> I will stop now and not comment more on the Tcl case, because I think
> it is essential to focus on C for now and one of the cairo or qt
> devices.
>
> Of course, as I have stated before the psc device driver is not useful
> for diagnosis o
Hi Alan,
On 2010-12-21 20:03, Alan W. Irwin wrote:
>
> I agree it is highly confusing and difficult to describe clearly.
>
> When I look at the Peace words in the actual files x24.tcl (and
> x24c.c) with the system tools available to me (the emacs editor in my
> case), it is clear the bytes in
On 2010-12-21 11:21+0100 Arjen Markus wrote:
> Hi Alan,
>
> I think you misunderstand the issue. The problem is that a file
> consists of bytes. In the old days, each byte corresponded to a
> single character, but with the advent of UTF-8 and the like a single
> character may be represented by one
Hello,
here is an update on the FORTRAN 77 issue:
The proposed solution (a compiler directive) does not work with the
current gfortran compiler (issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030).
I can think of several workarounds:
- Expand the argument list of plcon1 with the array tr
Hi Alan,
I think you misunderstand the issue. The problem is that a file
consists of bytes. In the old days, each byte corresponded to a
single character, but with the advent of UTF-8 and the like a single
character may be represented by one, two or more bytes. What a program
will do with these by
On 2010-12-21 09:25+0100 Arjen Markus wrote:
> I solved it, based on a suggestion from a fellow Tcler: we need to
> pass the string to a Tcl_UtfToExternal*() function. The problem on
> Windows is that the system encoding is _not_ UTF-8, but cp1252.
> The strings in the source are therefore transla
Hello all,
On 2010-12-20 14:31, Arjen Markus wrote:
> Hello all,
>
> On 2010-12-20 10:00, Arjen Markus wrote:
>
>> As for my test results with F77 example 9: it turns out that on the
>> DLL side the array "tr" as stored in COMMON block /plplot/ is completely
>> zero. That means the transformed c
Hi Alan,
On 2010-12-20 20:22, Alan W. Irwin wrote:
> Hi Arjen:
>
> On 2010-12-20 10:00+0100 Arjen Markus wrote:
>
>> I think the [example 24] issue has to do with the character encodings.
>> Tcl internally
>> works with UTF-8 and on Windows the system encoding is cp1252 (at least
>> on my machi
Hi Arjen:
On 2010-12-20 10:00+0100 Arjen Markus wrote:
> I think the [example 24] issue has to do with the character encodings. Tcl
> internally
> works with UTF-8 and on Windows the system encoding is cp1252 (at least
> on my machine). I have been experimenting with different encodings but
> no
Hello all,
On 2010-12-20 10:00, Arjen Markus wrote:
>
> As for my test results with F77 example 9: it turns out that on the
> DLL side the array "tr" as stored in COMMON block /plplot/ is completely
> zero. That means the transformed coordinates are (0,0) for all points.
> The question _why_ it
Hi Alan,
On 2010-12-17 08:28, Alan W. Irwin wrote:
> In all cases the drive letter form works, but I didn't want to
> complicate our C code to transform the leading slash form to drive
> letter form for the Windows case. So I have worked around this issue
> (revision 11374) by using a sed script
I should have also said that PLplot users on the Windows platform can
find directions for installing a Windows version of Tcl at
http://www.miscdebris.net/plplot_wiki/index.php?title=Install_Tcl
which is linked from
http://www.miscdebris.net/plplot_wiki/index.php?title=Specifics_for_various_platfor
Hi Alan,
On 2010-12-17 08:28, Alan W. Irwin wrote:
> In all cases the drive letter form works, but I didn't want to
> complicate our C code to transform the leading slash form to drive
> letter form for the Windows case. So I have worked around this issue
> (revision 11374) by using a sed script
Hi Alan,
that is wonderful! My guess as to the subtleties of the two forms of
paths is that bash (or any shell) under MinGW/MSYS recognises the
/z/path/to/file form and _converts_ it to z:\path\to\file (or one with
/'s), to make sure that ordinary programs that assume the DOS form of
absolute pat
19 matches
Mail list logo
