f



windows tcl/tk bug does not appear under Wine

I posted about this four days ago without a response so I'm reposting
in the hope that somebody understands what is going on.

I sent a friend a Starpack so that he could test a program under MS
Windows. When he ran it, he encountered the old bug in which assigning
a hexadecimal number like 0xFF to a scale variable (not "scalar", but
the variable named in the -variable option of a scale widget) fails
because 0xFF is interpreted as non- numeric. I've encountered this
before and fixed it (by using decimal), but evidently hadn't changed
it here. The MS Windows runtime I used turned out to be tcl 8.4.9, so
it makes sense that the bug would turn up when running the Starpack
but not on my Linux systems since they have 8.4.14 or later. The weird
thing is that when I run the same
Starpack under Linux using Wine I get no such error. I don't see how
that is possible. The Tcl that is running under Wine is 8.4.9, not the
later Linux version, so the bug should appear when running under Wine
just as it does on a real Windows system.

Does anyone understand how this could happen?

0
billposer (379)
6/18/2007 9:36:24 PM
comp.lang.tcl 23429 articles. 2 followers. Post Follow

13 Replies
890 Views

Similar Articles

[PageSpeed] 49

billposer@alum.mit.edu wrote:
> I sent a friend a Starpack so that he could test a program under MS
> Windows. When he ran it, he encountered the old bug in which assigning
> a hexadecimal number like 0xFF to a scale variable (not "scalar", but
> the variable named in the -variable option of a scale widget) fails
> because 0xFF is interpreted as non- numeric. I've encountered this
> before and fixed it (by using decimal), but evidently hadn't changed
> it here. The MS Windows runtime I used turned out to be tcl 8.4.9, so
> it makes sense that the bug would turn up when running the Starpack
> but not on my Linux systems since they have 8.4.14 or later. The weird
> thing is that when I run the same
> Starpack under Linux using Wine I get no such error. I don't see how
> that is possible. The Tcl that is running under Wine is 8.4.9, not the
> later Linux version, so the bug should appear when running under Wine
> just as it does on a real Windows system.
> 
> Does anyone understand how this could happen?

My guess is that when running in the Wine environment, the program calls
a different strtod() routine that leads to the divergent behavior.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
dgp2341 (685)
6/18/2007 9:49:11 PM
On Jun 18, 2:49 pm, Don Porter <d...@nist.gov> wrote:
> billpo...@alum.mit.edu wrote:
> > I sent a friend a Starpack so that he could test a program under MS
> > Windows. When he ran it, he encountered the old bug in which assigning
> > a hexadecimal number like 0xFF to a scale variable (not "scalar", but
> > the variable named in the -variable option of a scale widget) fails
> > because 0xFF is interpreted as non- numeric. I've encountered this
> > before and fixed it (by using decimal), but evidently hadn't changed
> > it here. The MS Windows runtime I used turned out to be tcl 8.4.9, so
> > it makes sense that the bug would turn up when running the Starpack
> > but not on my Linux systems since they have 8.4.14 or later. The weird
> > thing is that when I run the same
> > Starpack under Linux using Wine I get no such error. I don't see how
> > that is possible. The Tcl that is running under Wine is 8.4.9, not the
> > later Linux version, so the bug should appear when running under Wine
> > just as it does on a real Windows system.
>
> > Does anyone understand how this could happen?
>
> My guess is that when running in the Wine environment, the program calls
> a different strtod() routine that leads to the divergent behavior.
>
> --
> | Don Porter          Mathematical and Computational Sciences Division |
> | donald.por...@nist.gov             Information Technology Laboratory |
> |http://math.nist.gov/~DPorter/                                 NIST |
> |______________________________________________________________________|

Ah,thanks. I am an idiot. That must be it. As I recall this bug even
in earlier versions of Tcl occurred only under MS Windows, which would
be accounted for by use of different library functions on different
systems as it seems unlikely that the Tcl implementation on different
systems would differ in this way.

0
billposer (379)
6/18/2007 9:59:13 PM
Don Porter wrote:
> billposer@alum.mit.edu wrote:
>> I sent a friend a Starpack so that he could test a program under MS
>> Windows. When he ran it, he encountered the old bug in which assigning
>> a hexadecimal number like 0xFF to a scale variable (not "scalar", but
>> the variable named in the -variable option of a scale widget) fails
>> because 0xFF is interpreted as non- numeric. I've encountered this
>> before and fixed it (by using decimal), but evidently hadn't changed
>> it here. The MS Windows runtime I used turned out to be tcl 8.4.9, so
>> it makes sense that the bug would turn up when running the Starpack
>> but not on my Linux systems since they have 8.4.14 or later. The weird
>> thing is that when I run the same
>> Starpack under Linux using Wine I get no such error. I don't see how
>> that is possible. The Tcl that is running under Wine is 8.4.9, not the
>> later Linux version, so the bug should appear when running under Wine
>> just as it does on a real Windows system.
>>
>> Does anyone understand how this could happen?
> 
> My guess is that when running in the Wine environment, the program calls
> a different strtod() routine that leads to the divergent behavior.

Agreed because the bug was rooted in the slight variance of trying to 
exactly match floating point values.

Jeff
0
jeffh (1291)
6/18/2007 11:28:00 PM
Don Porter wrote:

> > Does anyone understand how this could happen?

> My guess is that when running in the Wine environment, the program calls
> a different strtod() routine that leads to the divergent behavior.

Which poses an interesting problem:

In the event that one codes cross-platform, yet wants to tweak code 
based on such oddities, what, if anything, could be done?

I occasionally have to use tcl_platform(), less frequently [tk 
windowingsystem], and hopefully never [winfo manager] or [winfo server], 
but I imagine all of these are suitably trounced by Wine and similar 
compatibility layers.

-- 
MKS
0
6/19/2007 2:58:53 AM
Don Porter wrote:
>> My guess is that when running in the Wine environment, the program calls
>> a different strtod() routine that leads to the divergent behavior.

Melissa Schrumpf wrote:
> In the event that one codes cross-platform, yet wants to tweak code 
> based on such oddities, what, if anything, could be done?

Use Tcl 8.5, which fully defines its own number parser, and is
no longer reliant on the variable implementations of strtod().

DGP
0
dgporter (104)
6/19/2007 5:24:49 AM
On Jun 18, 7:58 pm, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> Don Porter wrote:
> > > Does anyone understand how this could happen?
> > My guess is that when running in the Wine environment, the program calls
> > a different strtod() routine that leads to the divergent behavior.
>
> Which poses an interesting problem:
>
> In the event that one codes cross-platform, yet wants to tweak code
> based on such oddities, what, if anything, could be done?
>
> I occasionally have to use tcl_platform(), less frequently [tk
> windowingsystem], and hopefully never [winfo manager] or [winfo server],
> but I imagine all of these are suitably trounced by Wine and similar
> compatibility layers.
>
> --
> MKS

When MS Windows Tcl is run from a Starpack on Linux under Wine,
tcl_platform(platform) has the value "windows" and tcl_platform(os)
has the value "Windows NT" or whatever. So you can find out what
version of the interpreter you've got but not what the underlying
system and libraries are.

I'm not sure how to do the latter in a cross-platform way.  On many
Unix systems you could [exec uname], but that doesn't work from within
wine on Linux. What does work from within wine on Linux is
$::env(OSTYPE), which has the value Linux. Wine imports Linux
environment variables and passes them into the Windows environment it
sets up, from which they are available to Tcl. This does at least
provide a way of finding out if Linux is the underlying system. I'm
not sure if one can be sure about others. Does Windows set the OSTYPE
environment variable?

0
billposer (379)
6/19/2007 7:05:34 AM
 billposer wrote:

> I'm not sure how to do the latter in a cross-platform way.  On many
> Unix systems you could [exec uname], but that doesn't work from within
> wine on Linux. What does work from within wine on Linux is
> $::env(OSTYPE), which has the value Linux. Wine imports Linux
> environment variables and passes them into the Windows environment it
> sets up, from which they are available to Tcl. This does at least
> provide a way of finding out if Linux is the underlying system. I'm
> not sure if one can be sure about others. Does Windows set the OSTYPE
> environment variable?

Offhand, I don't know.  OSX 10.4.10 sets it to darwin8.0, and OpenBSD 
does not set it at all.

However, this is unreliable, as any user could easily change or unset 
the environment variable before starting Wine.

-- 
MKS
0
6/22/2007 12:48:44 AM
In article <BMJdi.4504$%t6.1604@trnddc02>,
 Don Porter <dgporter@verizon.net> wrote:

> Don Porter wrote:
> >> My guess is that when running in the Wine environment, the program calls
> >> a different strtod() routine that leads to the divergent behavior.
> 
> Melissa Schrumpf wrote:
> > In the event that one codes cross-platform, yet wants to tweak code 
> > based on such oddities, what, if anything, could be done?

> Use Tcl 8.5, which fully defines its own number parser, and is
> no longer reliant on the variable implementations of strtod().

Well, yes, but it doesn't solve the general case of how to handle 
"partially-virtualized" environs.  For example, I've only ever used Wine 
once, and from what I recall, the interface displayed was /extremely/ 
X11-ish.  Nothing at all like Windows.  If one were to write a program 
that relied heavily in Windows GUI-isms: measurements, fonts, typical 
widget sizes and spacings, etc., one would be very surprised at the 
result when run under Wine.  (Then again, one would also likely be 
surprised at the result on a system where someone had changed the 
default font, or enabled "Accessibility" options.)

This is one of the downfalls of using platform-native GUI kit: to get 
the benefit of native look and feel, sometimes you have to work around 
the nuances.  Ask anyone who has ever used images in button widgets 
under Aqua.

-- 
MKS
0
6/22/2007 1:07:43 AM
On Jun 21, 5:48 pm, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> However, this is unreliable, as any user could easily change or unset
> the environment variable before starting Wine.

So what? Are you thinking that Joe-average-user is going to set OSTYPE
to a meaningless or false value for some reason? Doesn't seem likely
to me. If you're doing some kind of forensic work and need to know for
certain what the underlying OS is, no, this is not a guaranteed way to
find out, but if the purpose is simply to make a program run correctly
for users who have no reason to work against you, I don't see the
problem. The system sets OSTYPE. If the user just leaves things alone
and runs your program, it will correctly identify the underlying
system and work.


0
billposer (379)
6/22/2007 3:30:58 AM
billposer@alum.mit.edu wrote:

> On Jun 21, 5:48 pm, Melissa Schrumpf wrote:
> > However, this is unreliable, as any user could easily change or unset
> > the environment variable before starting Wine.

> So what? Are you thinking that Joe-average-user is going to set OSTYPE
> to a meaningless or false value for some reason? Doesn't seem likely
> to me. If you're doing some kind of forensic work and need to know for
> certain what the underlying OS is, no, this is not a guaranteed way to
> find out, but if the purpose is simply to make a program run correctly
> for users who have no reason to work against you, I don't see the
> problem. The system sets OSTYPE. If the user just leaves things alone
> and runs your program, it will correctly identify the underlying
> system and work.

Yes, provided you happen to be using your particular Linux distribution, 
or some other OS that does set the environment variable.

In my previous message, I already mentioned that OpenBSD does not set 
OSTYPE.  I suspect Windows does not, either.  I can check FreeBSD if 
another datum is required.  Point here being, spiffy for you if all you 
use is Linux, but for me, if OSTYPE doesn't exist, I still wouldn't know 
whether it was straight Windows or Wine under OpenBSD.

Thus, the reliability of using env(OSTYPE) is limited to a particular, 
specific, subset of controlled environment.  If you have that already, 
then there are many additional ways of determining if an instance is 
running under *NIX, *NIX/Wine, or Windows.

A quick Google search actually elicits the following tidbits:

   My guess is that the Makefile assumes that the OSTYPE environment
   variable is equal to "linux" on any linux box. This is not true
   for all distributions.

   If you are running bash, OSTYPE is set to "darwin7.0"
   (for 10.3.5) and further, the OSTYPE environment variable
   is not exported by the shell anyway.

   A "bash" shell may not set your OSTYPE environment variable
   or may set it differently than a csh or tcsh.

   In order to prepare your computer for installation, you must
   set the OSTYPE environment variable to either "solaris" or
   "linux", depending on your system.

Now, I'm not about to run off and verify every bit of this 
google-hearsay, but it would appear that the setting of OSTPYE is not 
only OS-specific, but also may be shell specific.

As a matter of fact, on my [reasonably stock install of] OSX:

sh: no OSTYPE
bash: OSTYPE
csh: OSTYPE
tcsh: OSTYPE
zsh: no OSTYPE
ksh: no OSTYPE

Certainly, you wouldn't put it past "Joe-average-user" to be using the 
"wrong" OS, to have changed his/her shell, or to have had a more 
computer-savvy friend have changed his/her shell once upon a time when 
using their computer.  Heck, the super-user that added their account may 
have specified their shell-of-choice at creation time.  Are you willing 
to bet all of your admins have the same shell preferences?  I'm 
certainly not.

As a matter of fact, in my experience, bash, tcsh, and zsh are more 
often used as a user's login shell, for their user-friendly features. 
Whereas sh and ksh are most often used as shell script executors, as 
they are, respectively, most standard and guaranteed-present (even in 
single-user mode), and best suited to scripting.

And that's not even to mention the possible differences in environment 
based on method of execution.  For example: who hasn't had a cron script 
fail because it executed with different a environment than the login 
shell?

It's not a matter of forensics, it's a matter of your statement that 
"The system sets OSTYPE" being inaccurate except for your very narrow, 
particular case of OS and login shell.

-- 
MKS
0
6/22/2007 6:20:20 AM
On Jun 21, 11:20 pm, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> billpo...@alum.mit.edu wrote:
> > On Jun 21, 5:48 pm, Melissa Schrumpf wrote:
> > > However, this is unreliable, as any user could easily change or unset
> > > the environment variable before starting Wine.

You've missed the point. Your objection to using OSTYPE was that the
user could change this. I asked why this was a problem. You haven't
answered that question. The entirety of your message concerns a
completely different issue, namely that many systems do not set
OSTYPE. I agree that that is a real problem, but its a completely
different problem from the one we were discussing.

0
billposer (379)
6/22/2007 8:32:17 AM
It may still be possible to get this information a good part of the
time, if one does some research into which OSes set which variables. I
just had a look at FreeBSD. It doesn't set OSTYPE, but it does set
HOSTTYPE (both in bash and in tcsh) to FreeBSD. Linux also sets
HOSTTYPE (to, e.g., i586-Linux), again under both bash and tcsh.

0
billposer (379)
6/22/2007 8:42:24 AM
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
>It's not a matter of forensics, it's a matter of your statement that
> "The system sets OSTYPE" being inaccurate except for your very narrow,
> particular case of OS and login shell.

I didn't make any assumption about the system always setting OSTYPE. I
didn't. In fact, I explicitly said that I didn't know if this worked
on non-Linux systems. Here's what I said in my earlier message:

>This does at least provide a way of finding out if Linux is the
>underlying system. I'm not sure if one can be sure about others.

My statement that "the system sets OSTYPE" was in the context of
investigating your scenario in which the user screws up the settings,
in other words, in a scenario that PRESUPPOSES that the the system
sets OSTYPE.

0
billposer (379)
6/22/2007 8:50:17 AM
Reply:

Similar Artilces:

Possible bug in Tcl or Windows or Tcl on Windows
Hi, There seems to be a bug in the way numbers are compared in Tcl. Consider the below script for calculating Pythagorean triplets. For hypotenuse upto a value of 100, there should have been 63 unique triplets. On Windows XP the script detects only 62. The script doesn't detect the case where c=99, b=20 ==> a=101. However running the same script under Tcl 8.4.1 in Cygwin detects 63 triplets. I don't have a Linux machine at hand to test it there. Following is the script and relevant output. Could anyone shed some light on the cause of this. Maybe it has something to do with how the numbers are represented internally? Running the script for N>100 shows up many more such missed values. An equivalent program in C runs correctly on the same machine. C code was compiled using both gcc and VC++6.0. ######################################################################### # a^2 = b^2 + c^2 proc pythag {MAX} { set i 0 for {set c 2} {$c <= $MAX} {incr c} { for {set b 1} {$b < $c} {incr b} { set a [expr hypot($c, $b)] ;# Calc. Hypot if { ($c == 99) && ($b == 20)} { ;# <<<<<<<< puts ">> [expr round($a)] == $a" } if {[expr round($a)] == $a} { puts "$a : $b : $c" incr i } } } return $i } if {$argc == 1} { set MAX [lindex $argv 0] } else { puts stderr "Usage: tclsh $argv0 N" exit } puts [pythag $MAX] ############# OUTPUT ################ Tcl 8.4.1 (Cygwi...

[TCL/TK interface] Passing variable to TCL/TK
Hi, I am trying to sent to a variable to tcl/tk and unify there it with a string. I wrote the prolog code: :- use_module(library(tcltk)). :- use_package(classic). go(A):- tk_new([name('Simple')], Tcl), tcl_eval(Tcl, 'source simple2.tcl', _), tcl_eval(Tcl, ['ask', br(write(A))], _), tk_main_loop(Tcl), tcl_delete(Tcl). and the tcl file simple2.tcl proc ask {var} { unify_term $var my_value } unfortunatelly when I query for go(S). the interpeter goes into a loop (!?). Where I am wrong. Are there any example code somewhere i...

Opening a TCL program from within another TCL program in ANSYS Tcl-Tk
Hi everyone, I have been pulling my hair with this one for a couple of days and still have not found a fix. I'm working within ANSYS Tcl-Tk implementation. I created a Tcl-Tk script that generates a simple window with three buttons. Each button opens another window which is created in a separate Tcl file. The second window have a lot of text entries, variables, procedures, etc. I can open the second Tcl file by itself and everything works as supposed, but when I open it using the button in the first window, it opens but any procedure called by the widgets on the second window are not found... Here's the deal... Since I'm working within the ANSYS implementation of Tcl-Tk, I'm actually using an ANSYS command to open the second window. The command I use is: ### ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' ### It actually sends a command back to ANSYS telling it to execute a Tcl command... I know this is not pretty but its the only way i was able to make it at least show the window. ############################## #Main Tcl (excerpt): ############################## namespace eval Tools { proc IBRCambpell {} { #source O:/mad_projects_2/ANSYS/Macros/IBR_CAS.tcl ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' } proc viewManager {} { ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ ViewManager.tcl' } proc powerAnnotation {} { ans_sendcommand ~eui,'source ...

Debugger for Tcl/Tk and [incr Tcl]
hi, where can i get Coverage for debugging tcl/tk, [incr Tcl] source? this tool is advised to use in 'Practical Programming in Tcl and Tk' or any other good debugger, which i could use? best, s. On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > hi, > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > or any other good debugger, which i could use? I see, at http://wiki.tcl.tk/8638 , a brief reference to the topic of coverage for tcl. I don't know whether or not any of the tools mentioned include coverage of itcl. On 23 jan, 12:52, "Larry W. Virden" <lvir...@gmail.com> wrote: > On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > > > hi, > > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > > or any other good debugger, which i could use? > > I see, athttp://wiki.tcl.tk/8638, a brief reference to the topic of > coverage for tcl. I don't know whether or not any of the tools > mentioned include coverage of itcl. I have a more complete version of the coverage tool mentioned on that page. I just never got around to publishing it more widely. As for debuggers: the Wiki has a lot of pointers on that subject as well. Regards, Arjen Larry W. Virden wrote:...

TCL/TK window with no window decoration, but with keyboard and mouse events
Hi all, I want to make a toplevel window that is shown without window decoration on a linux box, but I want it to receive all mouse and keyboard events. I am trying to build a GUI that looks a bit like an old DOS GUI: one full screen window without decoration, and with a menu on the top of the window that can be navigated both with the mouse and keyboard. I am trying the following piece of code, but if I type <Alt-F>, it does not open the file menu. Can anyone give me a hint on how to achieve this? Thanks a lot #!/usr/bin/wish # Hide the main window wm withdraw . # Make sure the main window covers the entire screen area wm geometry . 1440x900+0+0 # Make sure the main window is shown without any borders surrounding it wm overrideredirect . 1 # Create the menu menu .menu -tearoff 1 # The File menu ..menu add cascade -label "File" -menu .menu.file -underline 0 menu .menu.file -tearoff 0 ..menu.file add command -label "Quit" -underline 0 -command {destroy .} # Bind the menu to the main window .. configure -menu .menu # Show the main window wm deiconify . # Make sure the wm commands are sent to the menu after 100 grab set -global . dirk.debecker@gmail.com wrote: > Hi all, > > I want to make a toplevel window that is shown without window > decoration on a linux box, but I want it to receive all mouse and > keyboard events. > I am trying to build a GUI that looks a bit like an old DOS GUI: one > full screen window without decoratio...

Incr Tcl /Tk for Tcl 8.4
Hi, I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. I looked at: http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-source/3.4.1/ But only itcl seems to be there. And the CVS doesn't have the 3.4.1 tag. Do you know where I can get incr Tk and hopefully a corresponding iwidgets? Thanks, Andres On 5 Okt., 11:16, Andres Garcia <tclc...@gmail.com> wrote: > Hi, > > I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. > > I looked at: > > http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-sou... > > But only itcl seems to be there. And the CVS doesn't have the 3.4.1 > tag. There is no tag for this version. But you can use a date. cvs -d :pserver:anonymous@incrtcl.cvs.sourceforge.net:/cvsroot/incrtcl -z3 co -P -D 2010-10-28 incrTcl > > Do you know where I can get incr Tk and hopefully a corresponding > iwidgets? Itk is inside itcl sources. cvs -d :pserver:anonymous@incrtcl.cvs.sourceforge.net:/cvsroot/incrtcl -z3 co -P -D 2010-10-28 iwidgets HTH rene Thanks. Andres >> I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. >> >> I looked at: >> >> http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-sou... >> >> But only itcl seems to be there. And the CVS doesn't have the 3.4.1 >> tag. The released sources for Itcl 3.4.1 were not developed in SF CVS. SF CVS got abandoned during the January...

Bug in Tcl fconfigure / TclHttpd (upload.tcl)
Hi there, had some trouble tracking down a segfault problem in tclhttpd. Has anybody experienced this before? Is there a bugfix floating around? (see below for details) Thanks Bernd Bug in Tcl fconfigure / TclHttpd (upload.tcl) --------------------------------------------- Author: bernd.worsch@@pawisda.de Date: 05-04-12 DESCRIPTION upfile.tcl from tclhttpd 3.5.1 segfaults in proc UploadDomain due to "fconfigure $sock -trans auto". This happens using Tcl 8.4.2 and the Problem remains when using Tcl 8.4.9. COMMENT I think this happens in thread mode only. SOLUTION Using "...

E.J. Friedman-Hill's Tcl/Tk Course
E.J. Friedman-Hill's Tcl/Tk Course Tcl/Tk Programming in Five Easy Lessons http://www.linbox.com/ucome.rvt/any/doc_distrib/tcltk-8.3.2/TclCourse/ I am unable to open the ppt files that seem very promising. Can anyone see what is the problem with them and can convert/fix so that I can open in the office 2007 or open office ? Thanks Bolega On 24/03/2011 2:51 AM, bolega wrote: > E.J. Friedman-Hill's Tcl/Tk Course > Tcl/Tk Programming in Five Easy Lessons > > http://www.linbox.com/ucome.rvt/any/doc_distrib/tcltk-8.3.2/TclCourse/ > > I am unable to o...

Tcl/Tk hang on windows
Hi everybody, Please forgive me if my problem is a common one, but .. I'm not able to find any solution nor any related discussion on a similar one. Here is the problem. I'm working on a multi-platform software, and just develop something that works on linux but leads to a bug on windows. Basically, I have a tcl executable A.tcl (tclapp starpack 8.5.9), which run another tcl executable B.tcl (tclapp starpack 8.5.9) which will run a binary executable (let's say Binary.exe). The problem is on WinXP and Win7. Eveything seems to run fine, except that when B.tcl runs Binary.exe, it hangs during an random time (from 2mn to 15 !!) and then runs as expected. This seems to be a race condition, due to the fact that B.tcl is opened in r+ mode AND that a script is connected to stdin. I just found a way to resume the problem with two simple scripts, so here they are: ===================================================================== A.tcl ===================================================================== #!/bin/bash # the next line restarts using wish \ exec wish8.5 "$0" -- "$@" set Commande [ file join [pwd] B.tcl ] set Canal [open |[list wish85.exe $Commande ] r+ ] ===================================================================== B.tcl ===================================================================== #!/bin/bash # the next line restarts using wish \ exec wish8.5 "$0" -- "$@" proc InteractiveExecute {}...

tcl/tk & windows
Hello Please , can i use tcl/tk programming language under windows system , if yes , could you tell me how and what should i do ?? Thanks . Am 20.01.14 09:19, schrieb amerzoud@gmail.com: > Hello > Please , can i use tcl/tk programming language under windows system , if yes , could you tell me how and what should i do ?? > Thanks . > Download either ActiveTcl: http://www.activestate.com/activetcl or a tclkit, for example one with a lot of packages is available here: http://sourceforge.net/projects/kbskit/files/kbs/0.4.4/WindowsNT_kbsvq8.6-gui.exe Christian On Monday, January 20, 2014 10:19:09 AM UTC+2, abdelkrim merzoud wrote: > Hello >=20 > Please , can i use tcl/tk programming language under windows system , if = yes , could you tell me how and what should i do ?? >=20 > Thanks . =D9=85=D8=B1=D8=AD=D8=A8=D8=A7 =D8=B9=D8=A8=D8=AF =D8=A7=D9=84=D9=83=D8=B1= =D9=8A=D9=85! hello Abdelkrim! This is a free Tcl/Tk tutorial series packed in Android application. https://play.google.com/store/apps/details?id=3Dnet.superlinux.tcltktutoria= ls install it. Le lundi 20 janvier 2014 09:39:38 UTC+1, Christian Gollwitzer a =E9crit=A0: > Am 20.01.14 09:19, schrieb amerzoud@gmail.com: >=20 > > Hello >=20 > > Please , can i use tcl/tk programming language under windows system , i= f yes , could you tell me how and what should i do ?? >=20 > > Thanks . >=20 > > >=20 &g...

Tcl script window does not appear
Hi, when I choose in Quartuss Utility Windows > Tcl Console and then choose Tcl Script (Tools menu) I cannot see any Tcl tool. Is the Tcl tool only available for certain Quartus versions? I am using Quartus v. 4.1 SP1 (full version) I would appreciate your help. Rgds The Tcl console is interactive, so that the user can type in Tcl commands in there, or execute Tcl scripts which they write using the source command.. When you choose Tools->Tcl Scripts it opens a dialog which points to the canned Tcl scripts that ship with Quartus. You can then select the script and run it. The o...

tcl-pam: PAM authentication for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-pam Tcl-pam is a Tcl interface to the PAM* service of Linux. It provides a Tcl package that allows Tcl scripts to use PAM to authenticate users and programs. It relies on linux-pam library: http://www.kernel.org/pub/linux/libs/pam/ * PAM (Pluggable Authentication Modules): A mechanism to integrate multiple low−level authentication schemes into a high−level application programming interface (API). This enables programs that rely on authentication to be written independently of the underlying authentication scheme. Platform: Linux Home page: http://sourceforge.net/projects/tcl-pam/ Man page: http://tcl-pam.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

Bug in Macintosh Tcl/Tk
I have the Macintosh Tcl/Tk batteries Included implementation and have found a bug. This bug is not manifest on the linux implementation here are work. To whome do I submit the report and code that generates the bug? ...

tcl-gaul: Genetic Algorithms for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-gaul Tcl-gaul is a Tcl extension for genetic/evolutionary algorithm processing.It relies on the GAUL library: http://gaul.sourceforge.net/ * A genetic algorithm (GA) is a search technique used in computing to find exact or approximate solutions to optimization and search problems. Genetic algorithms are categorized as global search heuristics. They are a particular class of evolutionary algorithms that use techniques inspired by evolutionary biology such as inheritance, mutation, selection, and crossover. For an introduction to genetic algorithms visit: http://gaul.sourceforge.net/intro.html Platform: Linux (GAUL library dependency) Home page: http://sourceforge.net/projects/tcl-gaul/ Man page: http://tcl-gaul.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl/tk exec in windows
Is there any way to invoke built-in Windows NT commands from tcl/tk without having the black dos window flashing up every time. For example, I was trying: exec cmd.exe /c kill /f processname In this case, on NT the annoying dos terminal window flashes up every time I kill processes. Do I need to redirect stdout and sterr to keep the NT commands silent? Another question, is there a way to avod the tk 'Illegal command' message popping up if the command (kill) does not exist? I would assume the above command would not work on W98 or XP but only on NT and 2000. Is the way tcl handles the...

tcl-mmap: A POSIX mmap interface for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mmap Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides a Tcl package that allows Tcl scripts to: 1) Memory map files for improved access efficiency; 2) Share memory between related processes; 3) Easily implement cyclic persistent log files. * See the mmap(2) man page. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-mmap/ Man page: http://tcl-mmap.sourceforge.net/ Author: Alexandros Stergiakis On Sep 3, 11:48=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl project: tcl-mmap > > Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides > a Tcl package that allows Tcl scripts to: 1) Memory map files for > improved access efficiency; 2) Share memory between related processes; > 3) Easily implement cyclic persistent log files. > > * See the mmap(2) man page. > Great to see this and the other packages you made. Looking at the manpage it looks a bit misformatted before the usage example. Any specific reason to use GPL for this instead the usual Tcl/MIT/BSD style license used? Michael schlenk wrote: > On Sep 3, 11:48 am, Alexandros Stergiakis <alst...@gmail.com> wrote: >> This is an announcement for a relatively new Tcl project: tcl-mmap >> >> Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides >> a Tcl package that...

tcl-mq: POSIX Message Queues for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mp Tcl-mp is a Tcl interface to POSIX Message Queues*. It provides a Tcl package that allows scripts to create/open/close/unlink multiple parallel message queues, and to send/receive messages synchronously and asynchronously to/from them. * A POSIX message queue is an Inter-Process Communication mechanism available on Linux and some other POSIX-compliant operating systems. It allows to or more processes (or threads) to communicate under the same OS. The messages are buffered by the kernel, which gives them kernel persistency. A message queue can be thought of as a linked list of messages. Threads with adequate permission can put messages onto the queue, and threads with adequuate permission can remove messages from the queue. Each message is assigned a priority by the sender, and the oldest message of highest priority is always retrieved first. Unlike PIPES and FIFOS, no requirement exists that someone be waiting for a message to arrive on a queue, before some process writes a message to that queue. It's not even a requirement for both processes to exist at the same time. Read mq_overview(7) for more details Platform: Linux Home page: http://sourceforge.net/projects/tcl-mp/ Man page: http://tcl-mp.sourceforge.net/ Author: Alexandros Stergiakis alsterg On Sep 3, 11:37=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl pro...

tcl-syslog: Unix system logging for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-syslog Tcl-syslog is a Tcl interface to the *nix syslog service. It provides a Tcl package that allows Tcl scripts to log messages to syslog. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-syslog/ Man page: http://tcl-syslog.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

TCL/TK 8.4 for Windows
Hi, How can I get the 8.4 version of TCL/TK installed to work with my version of Ruby? I have installed Ruby for windows, and it appears to be 1.8.1-10 Ruby with 8.3 TCL/TK - so no TkPanedWindows. x = TkPanedWindow.new(root) gives a invalid command name `panedwindow' (NameError) , in tk_call Or do I have another alternative? Many thanks Ian -- Ian - posting to a Newsgroup. Please remove everything to reply. Ian, If you download the ActiveTCL 8.4.4 source you should be able to compile it with MSVC. I have gotten this to work, but I have not gotten ActiveTCL8.4.5 to work. If ...

same tcl different under ms windows and wine?
Something really odd just happened. I sent a friend a Starpack so that he could test a program under MS Windows. When he ran it, he encountered the old bug in which assigning a hexadecimal number like 0xFF to a scale variable fails because 0xFF is interpreted as non- numeric. I've encountered this before and fixed it (by using decimal), but evidently hadn't changed it here. The MS Windows runtime I used turns out to be tcl 8.4.9, so it makes sense that the bug would turn up when running the Starpack but not on my Linux systems since they have 8.4.14 or later. The weird thing is that when I run the same Starpack under Linux using Wine I get no such error. I don't see how that is possible. I don't need a solution to this since it is easy enough to fix the problem, but I am curious since this seems to be one of those things can't happen. ...

Building Tcl/Tk from source on Windows
Hi All, I just built Tcl/Tk under Win7 from the latest HEAD sources (using VC++). Tcl built without a hitch, though I had some issues with Tk. I'm sure they're probably related to the fact that I'm somewhat out of my element here, but I'd like to get this right... When building Tk, I received a fatal link error that tcl86.lib couldn't be found. Inspecting the folder it was looking at, I found that the Tcl build (made just prior) had created a tcl86t.lib file instead. Doing some digging, I discovered the trialing "t" suffix represents a threaded build (from the "rules.vc" file). Not being entirely sure how to properly rectify the situation, I found a copy of tcl86.lib on my system in the AS 8.6b1.1 lib folder. I ended up using that to build Tk against (by assigning TCLDIR to the AS lib folder). The final result is a working wish86.exe, but I wonder what I should have done? Thanks, Jeff Hi Jeff, >When building Tk, I received a fatal link error that tcl86.lib couldn't >be found. Inspecting the folder it was looking at, I found that the Tcl >build (made just prior) had created a tcl86t.lib file instead. > >Doing some digging, I discovered the trialing "t" suffix represents a >threaded build (from the "rules.vc" file). yes, different version get a suffix (e.g. a debug version gets a 'd'). >Not being entirely sure how to properly rec...

Tcl/Tk scripts to windows executable
Dear All, I am writing Tcl/TK based GUI aplication and I am using packages like Iwidgets 4.0.2 in the scripts. When I am wrapping these scripts to Exe using Freewrap application, it is giving error. After refering some of the documents I have included lappend auto_path /tcl/lib/iwidgets4.0.2 in the script file. But it is giving the error as "can't find package Itcl 3.2" and so on. Can anyone guide me how to wrap all the scripts to EXE which are using Iwidgets packages also? Thanks, Muthu Muthu wrote: > Dear All, > > I am writing Tcl/TK based GUI aplication and I a...

Compiling TCL/TK and extensions under windows
I have recently delved into the black art of compiling things tcl on windows (BLT/freewrap) and I am very surprised that everytning still uses VC 6.0. This compiler has not been available for sale (even apparently on ebay) for many years. I looked into trying to build a custom starpack with BLT statically linked in as windows cannot load a BLT dll and found that even the kitgen for 8.6 uses VC6. This is fine for all those who have a copy but using bittorrent to compile is not realy an option. Has anyone managed to change the makefile.vc for TCL/TK and especially BLT and starpacks to use the FREE visual C++ 2008 compiler. I have a stop gap solution for now but I prefer a more stable solution for a tool which is used regularly by several hundred users. Thanks in advance Martyn On 8 okt, 10:21, MSEdit <mse...@gmail.com> wrote: > I have recently delved into the black art of compiling things tcl on > windows (BLT/freewrap) and I am very surprised that everytning still > uses VC 6.0. =A0This compiler has not been available for sale (even > apparently on ebay) =A0for many years. > > I looked into trying to build a custom starpack with BLT statically > linked in as windows cannot load a BLT dll and found that even the > kitgen for 8.6 uses VC6. > > This is fine for all those who have a copy but using bittorrent to > compile is not realy an option. > > Has anyone managed to change the makefile.vc for TCL/TK and especially > BLT ...

Tcl/Tk for native Windows x64?
Folks: Is Tcl/Tk available for Windows x64 (2003 server 64 or XP-64) as native 64-bit binaries? I've seen Active Tcl's website but they don't mention 64-bit windows. I'm porting a 32-bit signal processing program (huge beast) written in C that uses curses for input, and I'm evaluating what to use for porting. I can't find a suitable x64 implementation of curses, so I'm checking other options. My target platforms are Win32, native x64 Windows, and Solaris (probably Linux in a couple of years), so I need a GUI method available on all those platforms. If you have any suggestions I'll appreciate it Sergio "Sergio Ramirez" <calzadas01@hotmail.com> writes: >Folks: > >Is Tcl/Tk available for Windows x64 (2003 server 64 or XP-64) as native >64-bit binaries? I've seen Active Tcl's website but they don't mention >64-bit windows. > >I'm porting a 32-bit signal processing program (huge beast) written in C >that uses curses for input, and I'm evaluating what to use for porting. I >can't find a suitable x64 implementation of curses, so I'm checking other >options. My target platforms are Win32, native x64 Windows, and Solaris >(probably Linux in a couple of years), so I need a GUI method available on >all those platforms. If you have any suggestions I'll appreciate it > >Sergio Get the Microsoft Windows Platform SDK and install it. Open the...

Web resources about - windows tcl/tk bug does not appear under Wine - comp.lang.tcl

Window - Wikipedia, the free encyclopedia
This article is about the part of a building. For the Microsoft operating system, see Microsoft Windows . For other uses, see Window (disambiguation) ...

Microsoft Windows Information, Solutions, Tools - Windows IT Pro
Microsoft Windows information and solutions for IT pros. Topics include cloud computing, Windows Server, Exchange, Outlook, PowerShell, virtualization, ...

The Windows Blog
The Windows Blog is Microsoft's Official Blog for the Windows Operating System.

'Please save my baby': dramatic footage as the man who caught baby dropped from burning apartment window ...
The mystery man who saved a newborn baby dropped by his mother out of a burning apartment window has been found, as dramatic footage sheds new ...


Apple confirms it will livestream March 21st event for iOS, Mac, Apple TV and Windows users
Apple has confirmed it will be livestreaming its just-announced March 21st media event , expected to feature several product unveilings including ...

Android N Multi-Window Includes Ability To Drag & Drop Text
Now that Android N is officially here in a preview form and everyone has had a chance to digest its arrival, the details on what is on offer ...

Microsoft is desperately nagging enterprise users to upgrade to Windows 10 even if they can't
Microsoft's incredibly aggressive pushing of Windows 10 has been going on for some time now. In many regards it is something that home users ...

The IPO window slammed shut in January
So far, 2016 is the worst year for IPO filings since the depths of the Great Recession in 2009. As this chart from Statista based on data from ...

Sydney mom drops baby and toddler from 2nd floor window
... say a mother trapped by fire in her Sydney apartment has safely dropped her 2-day-old baby and 2 year-old toddler from a second-floor window ...

Resources last updated: 3/13/2016 2:12:37 PM