Le 01/05/2023 à 11:00, [email protected] a écrit :
I use Visual Studio 2022 to build tcl/tk 8.6.12 with some customized command bulit into tcl. But I have been doing this for quite a while without any problem.
For tcl shell 8.6.12 and 8.6.13(with tk86t.dll loaded), use exec to run an external programs will take more than 3 times of executipn time than using tcl 8.6.0 (from star to end of the external program).Did you by any chance switch from Win10 to Win11? I have seen something resembling your report when I did (there was no delay on Win10 Tcl/Tk
built with VS 2022). A 5 seconds (timeout?) delay got introduced in my
app. for no obvious reason (Tcl code unchanged). I didn't go to the
bottom of this problem though, I resolved it in quick and dirty mode by
a judiciously placed update in my script.
Also I found there is an error during the bulding of 8.6.13, which is related toI'm building with VS2022 on Win11 and I'm not seeing an error. Could you show how exactly you are building (show the commands you output), along
"git rev-parse HEAD"
It doesn't seem to affect the final outcome of tcl and tk, so I just ignored it. What is this "git rev-parse HEAD" for anyway ? Should I be cautious about this ?
with the the exact error?
From a quick look, "git rev-parse HEAD" is used in makefile.vc to put
the commit hash of the bleeding edge (i.e. HEAD) of the current branch
in the manifest.uuid file. Sounds like we need git in the path for this
to work, perhaps that's the issue you are seeing.
Regards,
Francois
git rev-parse HEAD >>C:\...\Tcltk_8_6_13\tcl\win\..\manifest.uuid(begin)
(end)
I use Visual Studio 2022 to build tcl/tk 8.6.12 with some customized command bulit into tcl. But I have been doing this for quite a while without any problem.
For tcl shell 8.6.12 and 8.6.13(with tk86t.dll loaded), use exec to run an external programs will take more than 3 times of executipn time than using tcl 8.6.0 (from star to end of the external program).
Also I found there is an error during the bulding of 8.6.13, which is related to
"git rev-parse HEAD"
It doesn't seem to affect the final outcome of tcl and tk, so I just ignored it. What is this "git rev-parse HEAD" for anyway ? Should I be cautious about this ?
No not Win 11. I built and run it in Win 10. And it is not only a delay problrm. If the same external program run for 200 seconds in exec of 8.6.0, it will run about 700 seconds in 8.6.12/8.6.13. So I beleive there is something to do with how exechandle the external programs in the OS (or the opposite way).
The error message related to git is like
git rev-parse HEAD >>C:\...\Tcltk_8_6_13\tcl\win\..\manifest.uuid(begin)
'git' is not an internal or external command, excutable program or batch file NMAKE : fatal error U1077: 'git rev-parse HEAD >>C:\...\Tcltk_8_6_13\tcl\win\..\manifest.uuid:
return code '0x1'
(end)
... (there was no delay on Win10 Tcl/Tk
built with VS 2022). A 5 seconds (timeout?) delay got introduced in my
app. for no obvious reason (Tcl code unchanged) ...
Thanks for the pointer (any reason you point into Androwish instead of
Tcl?) and thanks for the idea...
Francois Vogel schrieb am Montag, 1. Mai 2023 um 17:18:54 UTC+2:
... (there was no delay on Win10 Tcl/Tk
built with VS 2022). A 5 seconds (timeout?) delay got introduced in my
app. for no obvious reason (Tcl code unchanged) ...
Francois,
5 seconds rings an alarm bell in my head et voila I found this weird snippet
https://www.androwish.org/home/file?ci=tip&name=jni/tcl/win/tclWinPipe.c&ln=977-998
Laziness prevented me from writing a ticket in the Tcl core repo. So I believe
that those 5 seconds may be caused by some Win32 non-console process
without a GUI and thus without implicitly making a message queue which can
be waited on by the parent process. But that's only wild guesswork on an even wilder process management design, to put it mildly.
... Deserves a ticket in Tcl repo, isn't it?
Le 01/05/2023 à 18:38, Christian Werner a écrit :
Francois Vogel schrieb am Montag, 1. Mai 2023 um 17:18:54 UTC+2:
... (there was no delay on Win10 Tcl/Tk
built with VS 2022). A 5 seconds (timeout?) delay got introduced in my
app. for no obvious reason (Tcl code unchanged) ...
Francois,
5 seconds rings an alarm bell in my head et voila I found this weird
snippet
https://www.androwish.org/home/file?ci=tip&name=jni/tcl/win/tclWinPipe.c&ln=977-998
Laziness prevented me from writing a ticket in the Tcl core repo. So I
believe
that those 5 seconds may be caused by some Win32 non-console process
without a GUI and thus without implicitly making a message queue which
can
be waited on by the parent process. But that's only wild guesswork on
an even
wilder process management design, to put it mildly.
Thanks for the pointer (any reason you point into Androwish instead of
Tcl?) and thanks for the idea. I'll have to figure out how this relates
to the 5 sec issue, and even more why there was a change of behavior
when switching from Win10 to Win11.
Le 01/05/2023 à 18:11, S-Y. Chen a écrit :handle the external programs in the OS (or the opposite way).
No not Win 11. I built and run it in Win 10. And it is not only a delay problrm. If the same external program run for 200 seconds in exec of 8.6.0, it will run about 700 seconds in 8.6.12/8.6.13. So I beleive there is something to do with how exec
OK, so it's not the same problem I have seen. Sorry.
The error message related to git is likeSeems like you don't have git installed.
git rev-parse HEAD >>C:\...\Tcltk_8_6_13\tcl\win\..\manifest.uuid(begin)
'git' is not an internal or external command, excutable program or batch file
NMAKE : fatal error U1077: 'git rev-parse HEAD >>C:\...\Tcltk_8_6_13\tcl\win\..\manifest.uuid:
return code '0x1'
(end)
TIP #599 has introduced a dependency on fossil or git to get the commit
id of the thing being compiled. The error message you get should
indicate both fossil and git are missing from your environment. If it's
the case: how did you check out the source code? If it's not the case: please file a bug report here: https://core.tcl-lang.org/tcl/tktnew
Regards,
Francois
No I didn't install fossil or git. I just pull out the code archive from SourceForge.
Is the problem of slow exec related to this ?
Le 02/05/2023 à 05:03, S-Y. Chen a écrit :
No I didn't install fossil or git. I just pull out the code archive from SourceForge.OK. No bug then.
Is the problem of slow exec related to this ?With 99% chances it's not.
Regards,
Francois
* "[email protected]" <[email protected]>
| I have this very strange problem, and is wondering if anyone has this experience.
| I use Visual Studio 2022 to build tcl/tk 8.6.12 with some customized
| command bulit into tcl. But I have been doing this for quite a while
| without any problem.
| For tcl shell 8.6.12 and 8.6.13(with tk86t.dll loaded), use exec to
| run an external programs will take more than 3 times of executipn time
| than using tcl 8.6.0 (from star to end of the external program).
Could you check whether a stock precompiled 8.6.13
(eg. https://sourceforge.net/projects/magicsplat/files/magicsplat-tcl/)
shows the same slow-down as your version?
A difference of 700s vs 200s as you noted elsethread sounds very
severe. I have difficulties to imagine what exec would do to cause this.
* "[email protected]" <[email protected]>
| I use Visual Studio 2022 to build tcl/tk 8.6.12 with some customized
| command bulit into tcl. But I have been doing this for quite a while
| without any problem.
Same compiler, 8.6.13 here, with no such problem observed.
| For tcl shell 8.6.12 and 8.6.13(with tk86t.dll loaded), use exec to
| run an external programs will take more than 3 times of executipn time
| than using tcl 8.6.0 (from star to end of the external program).
Another idea would be to wrap the external program in a batch file which logs the start and end times around the call, so you could see whether
it is indeed 'exec' or the external program taking different runtimes in both circumstances.
@echo off
time /t < nul > timelog.txt
your command goes here
time /t < nul >> timelog.txt
REM EOF
On Wednesday, May 3, 2023 at 4:59:09 PM UTC+8, Ralf Fassel wrote:
* "[email protected]" <[email protected]>
| I use Visual Studio 2022 to build tcl/tk 8.6.12 with some customized
| command bulit into tcl. But I have been doing this for quite a while
| without any problem.
Same compiler, 8.6.13 here, with no such problem observed.
| For tcl shell 8.6.12 and 8.6.13(with tk86t.dll loaded), use exec to
| run an external programs will take more than 3 times of executipn time
| than using tcl 8.6.0 (from star to end of the external program).
Another idea would be to wrap the external program in a batch file which
logs the start and end times around the call, so you could see whether
it is indeed 'exec' or the external program taking different runtimes in
both circumstances.
@echo off
time /t < nul > timelog.txt
your command goes here
time /t < nul >> timelog.txt
REM EOF
I will take some time to test. Please wait for my result.
Chen
* "S-Y. Chen" <[email protected]>
| On Wednesday, May 3, 2023 at 4:59:09 PM UTC+8, Ralf Fassel wrote:
| > Another idea would be to wrap the external program in a batch file which | > logs the start and end times around the call, so you could see whether
| > it is indeed 'exec' or the external program taking different runtimes in | > both circumstances.
| >
| > @echo off
| > time /t < nul > timelog.txt
| > your command goes here
| > time /t < nul >> timelog.txt
| > REM EOF
| >
| >
| I will take some time to test. Please wait for my result.
Better make those 'time' commands
time < nul > timelog.txt
(without the /t) since non-interactive /t only shows minutes (no
seconds) on my Windows 10.
I don't know any simple command line program like Unix' 'date' on
Windows, so I'd suggested 'time'. The redirection from < nul is
necessary since time is interactive by default.
HTH
R'
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:52:12 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,941 |