Timeline
Jan 20, 2021:
- 8:31 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
-
Replying to Ant:
> Sadly, neither did the trick. Tried them in the beta, AutoIt3 and SciTE4AutoIt3 set-ups.
>
> So, to summarise:
> 1. the full version of ScITE fails,
> 2. the "lite" version runs fine, even though it uses the same project file as the full version, and
> 3. the full version runs fine when compiled under Visual Studio 2017 with the
<EnableEnhancedInstructionSet>option set toNoExtensions. > > The/arch:IA32compiler option seems to be the right one. A Visual Studio bug that causes SSE2 code to be generated unintentionally with that option is described here. > Thanks for your feedback. I had a look at that article and it does sound similar but I am not seeing that /fp: build flag so am not sure it is. To test, I changed the buildflags to: […] as they indicate that the second parameter shold be a tempory workaround. The result is stored in directory ia32/namkeia32. Could you try that set aswell? Thanks Jos - 7:33 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
-
Sadly, neither did the trick. Tried them in the beta, AutoIt3 and SciTE4AutoIt3 set-ups.
So, to summarise:
1. the full version of ScITE fails,
2. the "lite" version runs fine, even though it uses the same project file as the full version, and
3. the full version runs fine when compiled under Visual Studio 2017 with the
<EnableEnhancedInstructionSet>option set toNoExtensions. The/arch:IA32compiler option seems to be the right one. A Visual Studio bug that causes SSE2 code to be generated unintentionally with that option is described here.
Jan 14, 2021:
- 1:59 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- I have added 2 versions to the ia32 directory: maknono compiled mak file with: -DUSE_MSVC_SSE=OFF -DUSE_MSVC_SSE2=OFF makyesno compiled mak file with: -DUSE_MSVC_SSE=ON -DUSE_MSVC_SSE2=OFF Have a go and see if that solves anything... else I might have to consider doing the compile with Visual Studio instead of nmake.
Jan 13, 2021:
- 4:54 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Unfortunately, it doesn't. When dropped into each of the beta, AutoIt3 and SciTE4AutoIt3 set-ups, the original error occurs. I'm way out of my depth here, but could the desired command line options be as follows? […] In other words, use SSE (compatible with my machine) but don't use SSE2 (incompatible with my machine). Feel free to ignore me; this is an uninformed stab in the dark. If it exists, I can't find the on-line documentation for these options.
Jan 8, 2021:
- 8:04 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Ok, adding this in the vcxproj file does the trick then for the VC2017 build: […] Previously I added this to the standard scite.mak and scitilla.mak files but that doesn't seem to work: […] Found somewhere another option to try: […] .. and uploaded that to https://www.autoitscript.com/autoit3/scite/download/beta_SciTE4AutoIt3/ia32/mak/ Could you try that version for me to see if that fixes it? Jos
- 3:25 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Btw, thanks very much for that, mLipok. I only just spotted the new username.
- 3:15 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- We have progress. Having successfully installed the (2015) redistributable package, both the lite and the full versions of SciTE that you compiled with Visual Studio (in "comment9") open and seem to run fine when dropped into the beta set-up. So this means the recent Visual Studio SciTE compilations have something (that ensures compatibility with my device) that the published versions don't.
- 3:21 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Replying to Jos: > .....which I believe are standardly installed these days....... Unfortunately not. I have similar issue at my work, when we install some software on fully udpated Win10 Pro, then we must to especially install this following vcredist pack. @Ant Try to install those 3 following MS Visual C++ Redistributable package: vcredist_x86_2005.exe vcredist_x86_2008.exe vcredist_x86_2015.exe EN version->vcredist_x86_2015.exe
Jan 7, 2021:
- 9:14 AM Ticket #3800 (Number() - case sensivity with scientific notation by using $NUMBER_AUTO) closed by
- Fixed: Already solver for the next Beta/Release
- 7:48 AM Ticket #3800 (Number() - case sensivity with scientific notation by using $NUMBER_AUTO) created by
- Following Script: […] produces: […] The capitalized letter "E" …
Jan 6, 2021:
- 7:21 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- I feels like you are running on a (very) old/limited OS as these files are part of the standard Microsoft Visual C ++ Redistributable package, which I believe are standardly installed these days. So it could very well be that older systems aren't compatible with the latest version of the VisualStudio compiler and SciTE options set for the compiler/linker. When this is the case, you will have to use the latest version available of WinXP on the downloadpage, unless you have other ideas. Jos
- 4:23 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Sorry for taking a while to reply. Both sets of files when placed in their respective installations produce an application error message reporting that the file MSVCP140.DLL is missing. Presumably, this is a runtime file that's been added to the project, perhaps by Visual Studio, but isn't included as a distributable with any of the AutoIt, SciTE or beta packages (and is therefore unrelated to the original error). If the file is needed, are you able to include it with the beta files?
Jan 5, 2021:
- 10:06 AM Ticket #3001 (Added AutoIt3x_64.dll to Excel Add-in list loads it as initial spreadsheet.) closed by
- Works For Me: After deep analysis with Water it is working for us
Jan 3, 2021:
- 4:01 PM Ticket #3702 (Make Execute capable of processing declarations) updated by
- Hi sorry for this long delay, but I thing that using Dim $a[$d1] or Dim $a[$d1][$d2] or Dim $a[$d1][$d2][$d3] when needed do the job no need to extend Execute() Can you provide a more complete script which can describe what you need? Thanks Happy new year
- 2:31 PM Ticket #2652 (Allow ExpandVarStrings to expand com properties as well.) updated by
-
Owner, Status changed
Hi, I introduce a new option to expand expression Opt("ExpandExpStrings", 1) to expand string containing expression such as "($vars.widget.window.title)" a COM evariable must be evaluated before it can be used. Fix sent to Jon - 8:51 AM Ticket #3525 (Support for binding to multicast group) updated by
-
Owner, Status changed
I add a new function UDPJoinMulticastGroup(Ipaddr, Port, IPMulticastGroup) I sent the fix to Jon Thank, sorry for the long delay
Jan 1, 2021:
- 6:13 AM Ticket #2866 (regread cant read x64 keys remote) updated by
-
Owner, Status changed
Fix sent to Jon
Dec 29, 2020:
- 1:47 PM Ticket #3182 (MouseGetPos may return the wrong value when used with mulitple display ...) updated by
-
Owner, Status changed
Finaly I found access to a multiple screen. I confirm that the error was in MouseMove() Fix Sent to Jon
Dec 28, 2020:
- 6:21 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Ok, well I have no idea at this moment why the full version crashes and have no means to test. When the official version of SciTE also crashes, it does make sense my full version does too as that is more or less similar. I do not see any obvious difference between the lite and full builds of SciTE. I have done a recompile of the lite and the full version with visual studio 2017 and put them in this directory in their own subdirectory: https://www.autoitscript.com/autoit3/scite/download/beta_SciTE4AutoIt3/ia32/ Could you try both version to see if it is still the case that the lite version works and the full version crashes? Jos
- 10:29 AM Ticket #2835 (Change the TCP*() funktions to optional use non blocking ports.) closed by
- Completed: Sorry to be so late on the subject. I recheck the AutoIt code and find out that TCPConnect() is doing exactly except for the Shutdown(ConSock, 2); in fact this possibility has been added in a new TCPShutdownSocket(2) perhaps in your case the complete closing of the socket is better with the new extension of the TCPCloseSocket(sock, 2)
Dec 27, 2020:
- 11:11 PM Ticket #3575 (TCP functions slow and TCPCloseSocket with shutdown) updated by
-
Summary changed
- 10:51 PM Ticket #3575 (TCP functions slow and TCPCloseSocket with shutdown) updated by
-
Owner, Status changed
Re thinking of the pb I think it can be useful to add a TCPShutdownSocket(listensocket,1) which can be called before TCPCloseSocket(listensocket) this can be combined with an extension of TCPCloseSocket(listensocket, 1) Addition sent to Jon My last addition are to help the Jos finding. Nothing to do with TCP Slowdown I could have open another ticket - 10:47 PM Ticket #3575 (TCP functions slow and TCPCloseSocket with shutdown) reopened by
- 5:09 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by
- Yes... dropping the two files into a full / fresh installation of SciTE4AutoIt. (I don't know what the dependencies are.) Plus, my working environment is SciTE-Lite and I don't want to break it.
- 4:59 PM Ticket #3575 (TCP functions slow and TCPCloseSocket with shutdown) closed by
- Works For Me: sorry for this very late updating under the current beta every thing work fine. #1 is OK #3 is even a little be better
Dec 25, 2020:
- 2:17 PM Ticket #2695 (For ... in ... next loop modifying items) closed by
- Rejected: Sorry for the so late answer. But the doc has been written on what can be reasonably implemented, so we will not add such improvement
- 10:39 AM Ticket #2794 (FileDelete ability to remove the file stream) closed by
- Rejected: Sorry for the late answer, In fact the internal autoIt code handle wildcard so it involve a lot of internal change So as _WinAPI_DeleteFile() is OK just use it for Metadata
Note:
See TracTimeline
for information about the timeline view.
