ANNOUNCE: Tcl Plugin v3.1
Jeff Hobbs
(Firefox, Mozilla, ...)
WHERE: http://www.tcl.tk/software/plugin/
NOTES:
The Tcl web browser plugin has been updated to v3.1. The major updates
are modifications to the install architecture that breaks out the plugin
runtime library to allow users to modify their plugin configuration more
easily at runtime. In addtion, the ActiveX host control was fixed to
allow the plugin to work correctly in multiple simultaneous IE toplevel
windows.
Additional information at:
http://wiki.tcl.tk/12718
Jeff
Earl Greida
"Jeff Hobbs" <je...@activestate.com> wrote in message
news:aIadnZZXR_F6RhPZ...@novus-tele.net...
> WHAT: Tcl/Tk web browser plugin for Internet Explorer and NPAPI browsers
> (Firefox, Mozilla, ...)
>
> WHERE: http://www.tcl.tk/software/plugin/
>
Will this allow Tcl to be embedded in a web-page, like JavaScript, and run
some non-media Tcl program? The documentation talks about media plug-ins,
but I am more interested in form error checking, and other ideas that expand
the functionality of my software test application.
I have designed my product to use the web for configuring and
result/information display. This avoids having to develop a client program
and the hassle of customers needing to load it on any computer they want to
use for accessing my app. Of course, if I go with embedded Tcl in the
web-page then the customers are going to need to install Tcl on any remote
computer. So before I ask/require them to install Tcl I want to make sure
it does what I need, and then more, to make it worth the effort for any
customer.
My main interest at this point is to expand my app by opening a socket
between two computers and pass the real-time output of a debug file on the
app computer to the client. However, thanks to the stateless design of the
web, this is harder than it sounds (at least so far for me). I am thinking
of a Tcl program in the web-page that basically loops and reads the socket,
and then displays the data in the web-page.
Currently, to view the real-time debug file on a client PC requires using a
Telnet (such as Putty) program, or an X-server, and then "tail -f" the debug
file. I want to emulate that functionality on a web-page.
My application runs on Linux, and any client PC on the corporate net
accesses it via the web. If they have a VPN then customers can access it
from home, so that is another PC they would need to install Tcl.
Keith Nash
> The Tcl web browser plugin has been updated to v3.1.
Thank you for this release, which is much appreciated. I shall thoroughly
stress-test in all my browsers (mainly with Tetris).
Are there any release notes (e.g. are there any 2.0 features that had to be
left out for any reason)?
Keith.
Jeff Hobbs
The primary change from 2.0 to 3.0 was a rewrite of the plugin codebase
to support 8.4 and be more flexible in general. It was then all
compressed for distribution into 2 dlls - the NPAPI loaded dll, and a
stardll for all Tcl stuff.
In version 3.1, I move the plugin runtime library out to disk again, to
allow users to modify the plugin configuration (security policies, etc.)
without having to crack the stardll or basekit (on unix).
Jeff
eiji
but the same work on windows explorer 7.0.5346.5 (Beta)
http://www.tcl.tk/software/plugin/applets.html
The same with plugin 3.0!
E.g.: A Bezier (bizarre) Clock
Error message(copy paste not possible):
#####
An error occured ... Tclet:
syntax error in expression "asin(1)/90.0": extra tokens at the end of
expression
....
#####
Always "extra tokens at the end of expression".
On windows XPsp2.
Regards,
Sascha
Ralf Fassel
| An error occured ... Tclet:
| syntax error in expression "asin(1)/90.0": extra tokens at the end of
| expression
| ....
| #####
|
| Always "extra tokens at the end of expression".
| On windows XPsp2.
Do you run a 'german' version of firefox? The error sounds
suspiciously like the 'syntax error in expression' we used to get when
some printer driver messed up the decimal point character from "." to
"," in the german locale.
You could try to change the decimal separator character in the system
settings from ","to ".", then restart firefox and see whether this
makes a difference.
R'
eiji
Ralf Fassel schrieb:
> Do you run a 'german' version of firefox? The error sounds
> suspiciously like the 'syntax error in expression' we used to get when
> some printer driver messed up the decimal point character from "." to
> "," in the german locale.
>
> You could try to change the decimal separator character in the system
> settings from ","to ".", then restart firefox and see whether this
> makes a difference.
>
Nice idea!
But I can't find the place to change this "system setting". Do you know
where?
And you think die win-explorer handles this sensitive, while firefox
did not?
Thanks,
Sascha
Ralf Fassel
| > You could try to change the decimal separator character in the
| > system settings from ","to ".", then restart firefox and see
| > whether this makes a difference.
|
| Nice idea! But I can't find the place to change this "system
| setting". Do you know where?
I only have the german version of XP, there it is:
Start -> Systemsteuerung -> Regions- und Sprachoptionen -> Regionale
Einstellungen -> Anpassen... -> Dezimaltrennzeichen. Default in
german is ",", change that to "." Keep in mind that this may
influence other programs like spreadsheets.
| And you think die win-explorer handles this sensitive, while firefox
| did not?
This topic is a known problem when numeric input from different
sources is to be handled, so I try not to judge whether one program
handles it 'correctly' and the other not. If all of your input/output
comes from only one source (as might well be the case in windows
explorer), the problem is less significant. But if you read numbers
from 'english' texts (1000.0) and from 'german' texts (1000,0) in the
same program, there is no single locale which can handle this
simultaneously.
R'
eiji
Changing "," to"." resolves this issue.
On Windows Explorer this is no problem, but on firefox!
Now I celebrate this success playing some tetris :-), thanks Ralf.
Regards,
Sascha
MartinLemburg@UGS
Hello Ralf,
we had the same problem in our application (C++/tcl), after a file
selection box, where the user caused MS NFS drivered to be loaded,
which changed our locale from 'C' to 'German'.
Changing the systems locale settings is not really the trick of the
game! Just because all other applications, may be previously working
"jobs", may fail now.
Such a system wide change is IMHO not the right way to prevent such
mess, because there are a lot of other country settings in other
countries, that now may need to change their locale settings, just to
let tcl calculate the right way!
In tcl 8.5 using the new library for bignums (or something similar),
this problem vanished away, but in tcl 8.4 in non-english environments
perhabs other "fixes" have to be introduced, like a strtod-clone,
ignoring the locale settings, inside the tcl DLL!
I know, that tcl brings platform dependent Standard C replacement
functions with it, so why not as a kind of bug fix, the same for
strtod, strol, etc.?
And in my eyes this would be clearly a bug fix, because changing the
locale inside the tcl interpreters scope must not let the expression
parser suddenly fail, because of expecting "8,4" instead of "8.4"!
Best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
P.S.: during our problem with tcl and locale settings, some voices got
louder asking if tcl is the right programming language if it is so
vulnerable and it was not that easy to convince from the opposite!
Michael Schlenker
there without the standard libs strtod functions.
Michael
MartinLemburg@UGS
Is there a chance to call the tcl 8.4 behaviour as bug and to introduce
such a bugfix, with a locale-independent set of strto... functions?
I ask this because the time that many people or companies will need to
step to 8.5 will be more or less long, so that for many users and
applications this problem will stay for a longer time.
In our application we solved this problem, by asking for the locale
after the user used a file selection dialog and to reset it to 'C' if
it was changed by some external MS Windows used DLL. But this is no
real solution for this problem!
MartinLemburg@UGS
Hi Ralf,
I use an English version of FireFox (everything in English), like I use
an English MS Windows XP (the explorer, system control, Internet
Explorer, etc. all in English), but my default language setting is
changed to German, switching sometimes to English or to Spanish, and I
work with a localized US-American MS Office version (English UI, but
enabled to work with German)!
So it is not that trivial to tweak the regional settings, isn't it?
Donal K. Fellows
> Is there a chance to call the tcl 8.4 behaviour as bug and to introduce
> such a bugfix, with a locale-independent set of strto... functions?
A backport? Not really. The problem is purely that the number parsing
functions took a lot of code to implement (including the addition of a
new library), are quite tied in with the bignum handling (there are
things you do differently if you're potentially handling bignums), and
required a lot of changes which would have to be re-stabilized in any
backport. So the real answer is "yes we could, but it's a huge amount of
work". It might be easier to figure out how to do a workaround so that
you're not trying to parse floating-point numbers... :-\
Donal (not meaning to be down, but the number changes are the largest
new feature of 8.5 by lines of code and numbers of files by far.)
Ralf Fassel
| So it is not that trivial to tweak the regional settings, isn't it?
No, it is not. My suggestion to change the locale settings was meant
to check whether this indeed is the cause of the OPs error.
We have decided to introduce a similar workaround for the
locale-switching as you described in your other posting (remember the
locale and reset after dialog).
| P.S.: during our problem with tcl and locale settings, some voices
| got louder asking if tcl is the right programming language if it is
| so vulnerable and it was not that easy to convince from the opposite!
Well, in fact *any* program which uses the strto* family of functions
is affected. Either the other programs don't use the standard strto*
functions, or they do not check the return value and silently truncate
to the integer value of the floating point value in the string.
Should be easy to construct a test case for the latter (switch to
english locale, export data to ASCII, read back in german locale).
| I know, that tcl brings platform dependent Standard C replacement
| functions with it, so why not as a kind of bug fix, the same for
| strtod, strol, etc.?
I already see them in the compat/ subdirectory
-rw-r--r-- 1 ralf abg 5931 Feb 25 2002 strtod.c
-rw-r--r-- 1 ralf abg 2037 Feb 25 2002 strtol.c
-rw-r--r-- 1 ralf abg 2644 Feb 24 2002 strtoll.c
-rw-r--r-- 1 ralf abg 5090 Feb 25 2002 strtoul.c
-rw-r--r-- 1 ralf abg 5485 Feb 24 2002 strtoull.c
so it seems a matter of triggering the use of those. Using BFI, I'd
just run 'configure' and then replace the relevant macro (COMPAT_OBJS)
in the generated Makefile.
R'
Andreas Leitgeb
> MartinLemburg@UGS wrote:
>> Is there a chance to call the tcl 8.4 behaviour as bug and to introduce
>> such a bugfix, with a locale-independent set of strto... functions?
> A backport? Not really. ...
> Donal (not meaning to be down, but the number changes are the largest
> new feature of 8.5 by lines of code and numbers of files by far.)
Is it possible, you got him wrong?
I don't think Martin wanted the whole bignum changes ported to
8.4, but only one strtod() function, that does not depend
on locale-settings.
Such a thing might even be hacked by determining at runtime
what decimal character is "wanted" by strtod, and substing
all "." for that particular char, then calling system's strtod.
Admitted, a selfmade strtod is not really trivial, but should still
be workable without adding a dependency on third party libraries.
Jeff Hobbs
If all that is required is to use compat/strod.c, then that is something
that can be hacked in easily. However, is this something that just
Windows is more susceptible to, or should this be done on other
platforms? I don't see a large issue in using compat/strod.c, except
that it will be slightly slower than a native version (which likely is
coded in assembly).
I'm willing to give anyone a test version of 8.4 with compat/strod.c
used. We could even make it a compile option for 8.4.14.
Jeff
MartinLemburg@UGS
Wonderful to hear this!!!
The first time I started a thread about "our" floating point problem in
the expressions parser, the "community" wasn't that helpful.
The only thing is ... currently we use on MS Windows only the standard
distribution!
Only on the supported UNIX platforms we built tcl on our own (older or
64bit platforms).
The reason why I called the behaviour of the expression parser a bug
and asked for an introduction of a more "independent" strtod version
(compat/strod.c), is that whole applications may break, only because of
an external influence, so that it seems, that such a central part of
tcl like "expr" is not encapsulated enough to guarantee a constant and
syntactical right behaviour.
To introduce the slower, but always correct working compat/strod.c
version is (perhabs only for us) the best, that could happen, even if
it is a bit slower, because we try to move most of the often used
calculations to C++.
So - what's about controlling the "expr" behaviour by replacing the
systems strtod in the future tcl 8.4 versions by default?
Eckhard Lehmann
eiji wrote:
> Error message(copy paste not possible):
> #####
> An error occured ... Tclet:
> syntax error in expression "asin(1)/90.0": extra tokens at the end of
> expression
> ....
> #####
>
> Always "extra tokens at the end of expression".
> On windows XPsp2.
It's a localization problem, probably [,.]. I had it as well and it
went away when I set the locale to english in the control panel
("Regional and language options").
Here is a thread on this in c.l.t:
139841883.9...@g47g2000cwa.googlegroups.com
Eckhard
Eckhard Lehmann
Eckhard Lehmann wrote:
Hmm, I've seen you solved it already... anyway, the message ID of the
thread that I referred to was wrong - here is the correct one:
1139841883....@g47g2000cwa.googlegroups.com
Eckhard
Andreas Leitgeb
>> I'm willing to give anyone a test version of 8.4 with compat/strod.c
>> used. We could even make it a compile option for 8.4.14.
>
> distribution!
It seems that mostly windows' strtod is problematic.
Linux's is either unproblematic, or the compat/strtod is
already used, ditto for solaris.
So, to make an "almost latest-activestate-identical" build for
windows except for the strtod, and offer the binaries
(dll and exe) as drop'in-replacements would probably be
most helpful for evaluation.
Based on feedback, future versions of tclsh/libtcl* can
be (platform-specifically) adapted(corrected).
just $0.02 from an unconcerned observer.
Donal K. Fellows
> It seems that mostly windows' strtod is problematic.
> Linux's is either unproblematic, or the compat/strtod is
> already used, ditto for solaris.
As I understand it, the problem is a combination of the way Windows does
certain functionality (by loading DLLs instead of talking to services)
and the fact that some DLLs like to diddle with reinitialising the
locale (a big no-no). Unix overall tends to not do that (for whatever
reason) and so these problems, which still theoretically exist, don't
bite for real.
Donal.
Jeff Hobbs
In addition, the browser plugin and similar applications are the most
susceptible because they operate as sub-libraries and not the primary
application at all times.
Hmmm, in fact, this may be more the location of the problem. For unix,
we do the setlocale in tclUnixInit.c:TclpSetInitialEncodings. On
Windows, it instead occurs in tclAppInit.c:main. That means only tclsh
does the setlocale on Windows, whereas any library usage should call it
on unix. Has anyone noticed if this problem crops up on unix systems as
well?
Jeff
MartinLemburg@UGS
Hi Jeff,
the problem is not located during the l10n startup, not on MS Windows!
We had this problem while our Application was running, because a user
used a file selection box to walk through the complete system causing
MS Services for Unix (NFS) DLLs to be loaded, which changed the locale
of our applicaton (yes ...a no-no, but they did!).
To guarantee a non-problematic l10n startup even in libraries would be
a nice, but a locale independent number parser using compat/strtod.c
would be much finer.
Don Porter
> Hmmm, in fact, this may be more the location of the problem. For unix,
> we do the setlocale in tclUnixInit.c:TclpSetInitialEncodings. On
> Windows, it instead occurs in tclAppInit.c:main. That means only tclsh
> does the setlocale on Windows, whereas any library usage should call it
> on unix.
To try to say that a different way, Tcl's call to
setlocale(LC_NUMERIC, "C");
on unix is in TclpSetInitialEncodings, which gets called (eventually)
by Tcl public routine Tcl_FindExecutable(). Any program that embeds
Tcl and calls Tcl_FindExecutable() (all embedding programs should!)
gives Tcl a chance to establish its locale needs on Unix.
By contrast, on Windows, Tcl's call to
setlocale(LC_ALL, "C");
is found only in the main() routine of tclsh, so other programs
that embed Tcl never actually call it on Windows, unless they arrange
for their own call to setlocale(), which is what wish does.
Looking at the plugin sources, I see that they do call Tcl_FindExecutable,
but they do not include a direct call to setlocale().
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Ralf Fassel
| Looking at the plugin sources, I see that they do call
| Tcl_FindExecutable, but they do not include a direct call to
| setlocale().
Even if they did call setlocale() at their startup it would not
matter, since that would only fix things until the next DLL is loaded
which changes the locale again.
R'