Closed SAbboushi closed 11 months ago
I could not identify this issue in my environment.
Am I correct in understanding that this problem is caused by debugging scripts containing non-existent standard libraries using a runtime that exists not in the C drive?
Maybe it is an environment-dependent bug. Do similar problems occur on other devices (or Windows Sandbox)?
Am I correct in understanding that this problem is caused by debugging scripts containing non-existent standard libraries using a runtime that exists not in the C drive?
Yes
Thanks for your follow-up and my apologies for wasting your time. I tried on a different device and could not reproduce the problem. If you have any thoughts on how I can track down such an environment-dependent bug, please advise.
Also wondering about your parser project?
Thanks for the report.
If you have any thoughts on how I can track down such an environment-dependent bug, please advise.
Generally, this could be due to a malfunction in the permissions of the target folder or anti-virus software.
It may also be a bug caused by one of the software, although it may not be related to this case, as there was apparently a bug in older versions of node.js that caused Access Violation Errors.
As a last resort, a clean install is the fastest way to fix the issue. Nowadays, it is possible to do a clean install while keeping the user files, so the hassle is surprisingly small. However, if you have a lot of software installed in your environment, the hassle may be greater. This hassle can be reduced considerably by creating an environment that automates the installation using Windows Package Manager or Chocolatey.
Also wondering about your parser project?
I am currently rebuilding the parser from scratch with reference to the TypeScript compiler. The lexical parsing process is almost complete, and I have just started to create the parser. I have come back to this project as I realised that it would take a lot of time at this stage. I am now working on two projects in parallel.
The reason for creating a new parser was that it was very difficult to parse the AutoHotkey syntax in treesitter.
Although completed to some extent, it has become so complex that it cannot be refactored and is likely to be unable to deal with any future problems that may arise, so it has been given up completely.
I am currently rebuilding the parser from scratch with reference to the TypeScript compiler... Although completed to some extent, it has become so complex that it cannot be refactored and is likely to be unable to deal with any future problems that may arise, so it has been given up completely.
I'm sorry but I did not understand your answer regarding the parser. When you say "it has been given up completely", does that mean you have stopped development on a parser?
I am now working on two projects in parallel.
Two parser projects?
I'm sorry but I did not understand your answer regarding the parser. When you say "it has been given up completely", does that mean you have stopped development on a parser?
No, the parser is created. What was aborted was the parser using treesitter. I am currently creating AutoHotkey parser using TypeScript instead of treesitter.
The reason for the abort is that AutoHotkey v1 requires context-sensitive lexical parsing to parse correctly, and treesitter has not been able to address this issue well.
For example, command arguments can either be legacy syntax strings or expressions. This means that the syntax is the same but needs to be separated into different tokens depending on the context.
; The following `1 + 1` is 1 token.
MsgBox, 1 + 1
; The following `1 + 1` is 5 tokens. `1`, ` `, `+`, ` `, `1`
Sleep, 1 + 1
I decided that it would be more efficient to parse such a special syntax by creating a dedicated parser on my own, rather than using a library or tool such as the Parser Combinator.
Another reason is that treesitter is still unstable and previously consumed an inordinate amount of time for me to deal with problems such as not compiling properly on Windows, or not compiling unless the software is a specific version.
Two parser projects?
This refers to two separate projects, vscode-autohotkey-debug and another project that includes a parser. Since these are sub-project and the main project, it was not appropriate to describe them as two projects.
To rephrase, I wanted to say that we will maintain the subproject vscode-autohotkey-debug while working on the main project.
Currently, I am reviewing the work done a year ago and writing documentation (i.e. wiki) to finalize the specifications for the new version.
Thank you for the clarification and my continued best wishes for you and your project
Thank you. I still need more time, but I will definitely complete it.
Hi-
Using AHKV2 2.0.10.0 and vscode 1.85.0: I'm receiving an Access Violation Error (but only) when specifying alternate runtime location.
Code to reproduce:
AbortTest.ahk:
Make sure there is no
OpenProcess
library function: this correctly generates errorScript library not found
when using default runtime location (i.e. either don't specify runtime in settings or specify"runtime": "C:\\Program Files\\AutoHotkey\\v2\\AutoHotkey.exe"
or"runtime": "C:/Program Files/AutoHotkey/v2/AutoHotkey.exe"
:But, when specifying a non-default location for runtime, an
Access Violation Error
is thrown:To confirm debugger is functioning with the non-default location to runtime, comment out the code except for first line:
I've tested and find the same behavior regardless of whether launch settings are in User, Workspace or Workspace Folder JSON settings.