Insert and remove quotes around pathing for debugger where appropriat…#1277
Insert and remove quotes around pathing for debugger where appropriat…#1277JeremyYao wants to merge 1 commit intoapache:mainfrom
Conversation
JeremyYao
added
bug
|
OmegaEdit server seems to be hanging when starting on my end (Windows 10). Can anyone else confirm they are seeing the same issue. |
Did some debugging and the extension seems to be hanging on this line in dataEditorClient.ts // Start the server and wait up to 10 seconds for it to start
const serverPid = (await Promise.race([
startServer(
omegaEditPort,
OMEGA_EDIT_HOST,
getPidFile(omegaEditPort),
logConfigFile
),
new Promise((_resolve, reject) => {
setTimeout(() => {
reject((): Error => {
return new Error(
`Server startup timed out after ${SERVER_START_TIMEOUT} seconds`
)
})
}, SERVER_START_TIMEOUT * 1000)
}),
])) as number | undefinedThe timeout doesn't seem to be hitting nor getting past this line even though there's a timeout promise set as the second promise. |
JeremyYao
requested review from
hdalsania,
lrbarber,
naga-panchumarty,
rthomas320,
scholarsmate and
shanedell
|
Re-tested on a windows VM and OmegaEdit is still hanging. |
|
The data editor when opening it not through a debugging session also hangs. |
JeremyYao
force-pushed
the
jy/1075
branch
2 times, most recently
from
2d36759 to
7de6c11
Compare
|
Something I found, there doesn't seem to be a .pid or a .log file that exists in C:\Users<USER_NAME>\AppData\Roaming\xdg.data\omega_edit
The results for 9090 that were generated were from trying to open the data editor in a extension debugging session where the path to the repository doesn't contain a space. The results for 9069 were from an extension debugging session where the path to the repo contains a space. |
|
I'm not running into any issues on Ubuntu 24.04 |
|
Upgraded omegaedit to 0.9.88 to see if issues are resolved. It's still throwing an error on the startServer() call as referenced in #1277 (comment). |
|
Log file contents: |
|
serv-9069.logconf.xml file in C:\Users\USERNAME\AppData\Roaming\xdg.data\omega_edit looks like <?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>C:\Users\USERNAME\AppData\Roaming\xdg.data\omega_edit\serv-9069.log</file>
<encoder>
<pattern>[%date{ISO8601}] [%level] [%logger] [%marker] [%thread] - %msg MDC: {%mdc}%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE" />
</root>
</configuration> |
|
Changing the bottom half of serverSTart() to try {
const serverPid = await startServer(
omegaEditPort,
OMEGA_EDIT_HOST,
getPidFile(omegaEditPort),
logConfigFile
)
clearInterval(animationIntervalId)
if (serverPid === undefined || serverPid <= 0) {
statusBarItem.dispose()
throw new Error('Server failed to start or PID is invalid')
}
// this makes sure the server if fully online and ready to take requests
statusBarItem.text = `Initializing Ωedit server on port ${omegaEditPort}`
for (let i = 1; i <= 60; ++i) {
try {
await getServerInfo()
break
} catch (err) {
statusBarItem.text = `Initializing Ωedit server on port ${omegaEditPort} (${i}/60)`
}
// wait 1 second before trying again
await new Promise((resolve) => {
setTimeout(() => {
resolve(true)
}, 1000)
})
}
try {
serverInfo = await getServerInfo()
} catch (err) {
statusBarItem.dispose()
await serverStop()
throw new Error('Server failed to initialize')
}
statusBarItem.text = `Ωedit server on port ${omegaEditPort} initialized`
const serverVersion = serverInfo.serverVersion
// if the OS is not Windows, check that the server PID matches the one started
// NOTE: serverPid is the PID of the server wrapper script on Windows
if (
!os.platform().toLowerCase().startsWith('win') &&
serverInfo.serverProcessId !== serverPid
) {
statusBarItem.dispose()
throw new Error(
`server PID mismatch ${serverInfo.serverProcessId} != ${serverPid}`
)
}
const clientVersion = getClientVersion()
if (serverVersion !== clientVersion) {
statusBarItem.dispose()
throw new Error(
`Server version ${serverVersion} and client version ${clientVersion} must match`
)
}
statusBarItem.text = `Ωedit server v${serverVersion} ready on port ${omegaEditPort} with PID ${serverInfo.serverProcessId}`
setTimeout(() => {
statusBarItem.dispose()
}, 5000)
} catch (err) {
logError(err)
}results in the const serverPid = await startServer(
omegaEditPort,
OMEGA_EDIT_HOST,
getPidFile(omegaEditPort),
logConfigFile
)call to hang. |
|
Created some test in OmegaEdit: #1024 (comment). Doesn't seem to have the hanging issue. It may be a VS-Code specific thing |
The .xml file is for configuring the Ωedit server-side logger(e.g., the configured log level for the Ωedit server). |
|
From conversation with on Friday 8.15.2025, @scholarsmate mentioned he will work on the OmegaEdit side as well as put out a release for OmegaEdit too. Potentially after this, will make a PR on the extension side too. The overall work so far to this ticket is seeing if we can expose the underlying Typescript code as we're debugging the extension's library/node package calls instead of compiled webpack code. |
JeremyYao
removed request for
hdalsania,
lrbarber,
naga-panchumarty,
rthomas320 and
shanedell
|
@JeremyYao, @stricklandrbls merged a nice linking feature into Ωedit that will allow you to easily install Ωedit into your VSCode extension repo along with the debug mappings. With the tests in the Ωedit client working fine with abnormal filenames, my suspicion is when we call java that we're loosing those quotes so the command is being broken. |
This is good info! Thanks for the heads up regarding the linking feature in OmegaEdit. |
|
@JeremyYao Can you just update the PR description to make the template so that it will pass the CI? I will give this a test and approve if everything works as expected. |
JeremyYao
force-pushed
the
jy/1075
branch
2 times, most recently
from
71cbd54 to
33d069e
Compare
Updated PR description to fit template |
|
@hdalsania, re-tested this PR on Windows 10. Running a debugging session appears to work fine and you are able to generate an infoset. Attempting to open the data editor via command pallete still results in the following error being displayed. The dataEditor log file looks like this: 
Additionally, the latest version of OmegaEdit is 0.9.88 per https://github.com/ctc-oss/omega-edit/releases and testing it w/ this version still results in the Data Editor not opening and hanging on the bottom |
|
Currently struggling w/ installing and getting omega edit to package on windows before getting to the linking script. See the following output. |
Spoke with @stricklandrbls regarding this issue. From our conversation, he suspects that the sbt build isn't resolving the OE_LIB_DIR variable. For now, it'll be worth attempting to run the yarn linking script in Omega edit on WSL and see if it can resolve the path to Windows. |
|
I'm attempting to link OmegaEdit on WSL -> W10 repo. During the process, I ran into an issue with giving the linking script spaces, so I created ctc-oss/omega-edit#1160 and ctc-oss/omega-edit#1161 which addresses ctc-oss/omega-edit#1160. After getting the linking script to accept the pathing with spaces (I call the linking script via 
|
|
From conversation with @hdalsania, this and #1075 will get pushed to next version of Daffodil-VS Code. This is due to this PR and ticket affecting an extremely small, rare use-case for developers on W10 platforms debugging the extension on a path containing a space. |
|
#1075 is easily resolved on the user's end by moving the working directory / repo to a folder and/or path without spaces. The only edge case I can see where this wouldn't work is if the user's username contains a space. |
@JeremyYao - I just witnessed this same issue from a completely clean build, install, and link of the Omega Edit packages. However, when I cleaned the repo and tried again it worked fine. The issue is due to the fact that, at least for me initial attempt, the @omega-edit/client package in the dfdl extension's As a quick workaround, try removing the @omega-edit/client package in the dfdl extension node_modules. Then in the Omega Edit repo, after a successful build and install via packages/build.sh -fl <path/to/dfdl/extension>`The key difference here being the inclusion of the |
I'm still running into the same issue after following the steps. 
For tracing my steps, I ran git clean -fdx
cmake -S . -B _build -DCMAKE_BUILD_TYPE=Debug -DBUILD_DOCS=NO -DBUILD_EXAMPLES=NO -DBUILD_SHARED_LIBS=YES
cmake --build _build --config Debug
ctest --build-config Debug --test-dir _build/core --output-on-failure
cmake --install _build --config Debug --prefix _install
yarn install
yarn workspace @omega-edit/server package
yarn workspace @omega-edit/client package
yarn workspace @omega-edit/client testinside of my Omega Edit repo in WSL I then ran in the extension repo and then proceeded to remove the node_modules/@omega-edit/client in the extension repo. Inside of WSL, I did a and then encountered the above screenshot. |
…e to handle folder names w/ spaces
5 participants
…e to handle folder names w/ spaces
Closes #1075
Description
See #1075
Wiki
Review Instructions including Screenshots
[Add review instructions including screenshots or GIFs to help explain the change visually.]
sampleWorkspace: sampleWorkspace.zip
Verifying Functionality While Debugging the Extension
Clone the jy/1075 branch onto your machine where a space exists in the path. Example:
C:\Users\jeremy.yao\repos\space test\daffodil-vscode-ctc>Copy the sampleWorkspace contents into the same folder where the is a space in the path. Example:
C:\Users\jeremy.yao\repos\space test\sampleWorkspaceDebug the extension as normal
Run the
jpeglaunch.json configuration and verify that debugging went as expected.You may want to run
jpegagain but also have the following be set to true in launch.jsonC:\Users\jeremy.yao\reposVerifying Functionality with Packaged Extension
Package the extension via
yarn packageand install it into VSCodeCopy the sampleWorkspace contents into a folder where the is a space in the path. Example:
C:\Users\jeremy.yao\repos\space test\sampleWorkspaceRun the
jpeglaunch.json configuration and verify that debugging went as expected.You may want to run
jpegagain but also have the following be set to true in launch.json