I'm able to run the smlnj repl in a Powershell window but when I try to run it with a file or "use" a file inside the REPL, it fails - smlnj

This is the error I get with I start it, in Windows 10 Powershell, with a file name: sml first.sml
or try to: use "first.sml"
"uncaught exception SysErr [SysErr: access: cannot get file attributes] raised at: Basis/Implementation/Win32/os-filesys.sml:32.30-32.74"
When I run it inside emacs with the sml package, the "use" function works just fine.
If I use OS.FileSys.getDir() it shows that it's pointing to my working directory.
I'm using the latest version 10.98.1 (version 10.98.0 also had this issue).

Okay, nevermind. It appears that the error I'm getting is just indicating that it can't find the file?! I was trying to access files that were in a subdirectory and so, of course, it couldn't find them.
Dave

Related

VS Code Error: "You don't have an extension for debugging YAML. Should we find a YAML extension in the Marketplace?"

I'm trying to compile a program, and when I try to debug and run the script I get an error that reads "You don't have an extension for debugging YAML. Should we find a YAML extension in the Marketplace?"
I opened VS Code and tried to run the script, but I got the error.
Assuming you already have the necessary language support, and the program you are attempting to compile is in dart, you may be encountering this issue.
As stated in the linked thread, select main.dart so it's the currently active file, then attempt to debug and run. One cause of this error seems to stem from having pubspec.yaml as the current file open in VS Code.

Exception has occurred: ModuleNotFoundError in VScode but no other editors

This error occurs in VS code for pip installed modules.
Exception has occurred: ModuleNotFoundError
It was working on all previous days.
I believe that i may have deleted a *.pyc file or something to this extent.
If i do pip freeze i can see the module.
For example import tweepy could not be resolved, but i can see that it exists in pip freeze tweepy==3.10.0 and i can see with python --version that i have the correct version Python 3.9.0.
If i run the same on IDLE (python3.9) the code works, which leads me to believe that this is a VScode issue, but i cannot tell what this is or how to fix it.
In fact, if i recreate new folders in VS code, the imports work too.
So the quesiton is, how can i identify where (which folder or file) the corruption is or what has caused VS code to break in this way ?
One solution (which works) is to recreate all the folders and subfolders.
It is also noted that this is not specific to python as seen here:
https://github.com/Microsoft/vscode/issues/10391
There is also a suggestion here (which is close, but did not resolve the issue):
vscode import error for python module.
I have noticed that if I use File -> Close folder and then File -> Open Folder... and open the project folder again, the errors are
gone.
VStudio may be using a different python interpreter. Just click here and select the proper one:

Commands fail - cannot load ntsdexts

I'm new to using WinDbg and am running into a problem. I've set the server for symbols and downloaded them, but I keep getting stuck when I try to run !htrace (or any other command actually). The error message I get is
Cannot load 'ntsdexts'
I get this on any command that starts with an exclamation point (i.e. !drivers, !heap, !htrace, etc.) which is making tracking down a handle leak a problem.
I'm using the srv*...* link direct to Microsoft for symbols.
The last line before I get the breakpoint is:
Module Load: C:\WINDOWS\SYSWOW64\VFRCORE.DLL (no symbols loaded)
From the comments:
Somehow I managed to get two different version of windbg installed and the one in the path is the wrong one. Put the dll file into the right place, ran from that specific directory and now it works.

Using MATLAB's diary function in an executable (MATLAB Application Compliler Toolbox)

I've created a code that will be run as an executable. However, the running of an executable has an error that doesn't exist in the MATLAB scripts. Trying to document this, I ran across the "diary" command which seems like an appropriate way of logging the error. Command: diary('LogFile.txt')
However, when running the compiled version, I immediately get a pop up error: LogFile.txt: Cannot open file: permission denied.
I'm getting a bit flummuxed as it appears to be having trouble writing to its own folder. Should I be trying to store to C:\Users, or is there some other glitch I'm running into?
Thanks a lot to 'Daniel' for his suggestion of getenv('appdata'). I would add that my path was ..\AppData\Roaming\ so I would suggest a way of viewing the location of the log file in your gui just to be sure you can find (or that others using your app can find it). Thanks!

TLBIMP.EXE - Error TI0000 - *.dll is not a valid type library

While building our project on the Build Server, the compilation fails with the error message:
TlbImp: error TI0000 : The input file 'C:\*.dll' is not a valid type library.
We tried to manually invoke the TlbImp command thru the VS2005 Command Prompt and the same error message appeared.
To investigate, we tried to create a clean build environment in a Virtual Machine (Vbox), then we run the build there. It went fine.
We also tried to invoke the same TlbImp command thru the VS2005 Command Prompt and it succeeded.
With that, we are assuming that there is nothing wrong with the DLL. Do you have any idea what scenario(s) can cause this problem?
EDIT:
Found the problem, see my answer. ;)
If it is working on one machine and not on the other, then most probably some dependency of this DLL is missing in your machine. Inspect the dll through DependencyWalker and you will get to know that which dependency hasn't been built properly.
After closer inspection, we found out that the environment variables on the official build server is FUBAR.
The official build server was installed with both VS2003 and VS2005. Our project is VS2005. The build script is using components from VS2003 instead of VS2005 because the VS2003 paths (Path, LIB, LIBPATH and INCLUDE) were first declared before the VS2005 paths.
A simple SET command to override the environment variables with the "correct ones" fixed the build!
Thanks!