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