I'm using VSCode + CodeLLDB + LLDB to debug a JIT'ed language (KL), however I'm having trouble getting LLDB to recognize the source files.
This is a duplicate question to LLDB equivalent of gdb "directory" command for specifying source search path?, however it's accepted answer doesn't work for me.
LLDB seems to think every source unit is compiled to the local directory - so if I execute
kl /MyWork/someFile.kl
and this file includes /any/other/path/external.kl, LLDB will believe the file is located as /MyWork/external.kl
So far, I'm (mostly) working around this problem by using
settings set target.source-map /MyWork/ /any/other/path/
However this only seems to work for a single folder. If I tried:
settings set target.source-map /MyWork/ /any/other/path/
settings set target.source-map /MyWork/ /I/use/many/dependencies/
Then LLDB seems to not be able to find -any- files in either folder. Interestingly, when I tried this LLDB errored with accurate messages
can't find external.kl in /I/use/many/dependencies/
can't find dependencies.kl in /any/other/path/
Which are accurate messages, but seems almost as if LLDB is just looking for an excuse to error-out :).
Note - I can set breakpoints and view locals, I just can't seem to view the source code at that spot.
Anywho - is there any suggestions on how to deal with this issue? There are 3 possibilities to work with:
- Modify/work with LLDB to find the source files
- Modify CodeLLDB to modify paths between LLDB + VSCode
- Somehow convince VSCode to ignore the path given to it, and search its own folders for any file matching the name.
My suspicion is that LLDB is the right place to fix this, but I am open to any suggestions (right up to the point of linking each and every source file into a flat folder I can redirect to).
lldb only knows about source paths from what is written in the debug information. The rule in DWARF (the debug format lldb uses) is that if an include file is just given by relative path or base name then it is taken to be relative to the compilation directory. Looks like that's what is happening in your case. That sounds like a compiler bug. lldb's not going to be able to reconstruct the file hierarchy at this point.
The source maps should give you a manual way to fix this, and from the sound of it, what you are describing should work. But maybe there's something else odd in the DWARF output from kl that is confusing it. You'll need to file a bug with some example binary to http://bugreporter.apple.com.
Related
I'm getting 4 errors for malformed JSON and one command compileSwift failed with a nonzero exit code error.
I have no clue how to debug this since it doesn't list what file this is occurring in.
I have tried deleting the workspace and pods directory and doing a new pod install && pod update.
I have tried deleting the derived data.
Neither have worked.
I was getting the same error and after reading above comments i went through my code and saw this "return 93à"
So after removing this "à" it's working fine now.
So here is my story on the exact same issue but a totally different cause and resolution.
TL;DR - Decode that problematic array as a string and read it, that is your real issue, not the one with JSON.
And here is my full story ...
First things first ... I got to this error by moving my app files to a framework project and changing their target.
I tried all you guys suggested, but with no luck, it just took me some time to find out how to report those files recursively. If anyone wants to check their encoding in the whole project, here is how to do that:
find . -type f -name "*.swift" -exec file {} +
All my files reported either ASCII and UTF-8, I even removed all Unicode characters to make them all ASCII, and it still didn't help.
Anyway, totally desperate, I decided on the last attempt ... trying to decode whatever was in that undecodable sequence of bytes.
I opened up my browser console, and did this:
String.fromCharCode(...[123, 10, 32, 32, 34, <the rest of the error array from XCode>])
And it saved my day, giving away the actual problem information.
What I got was the actual error message that for some reason (still unknown to me) the compiler wasn't able to process.
Here is a short extract from which you can also see why all people see the same sequence at the beginning:
{
"kind": "finished",
"name": "compile",
"pid": 27181,
"output": ...
... /RecognizedSymbolBlock.swift:5:15: error: use of undeclared type 'CGRect'\n let rect: CGRect;\n ...
... /RecognizedTextBlock.swift:3:7: error: type 'RecognizedTextBlock' does not conform to protocol 'Decodable'\nclass RecognizedTextBlock ...
So it turned out my problem was not having CoreGraphics framework included in the target, as well as not having it added with import CoreGraphics in the file itself.
Strangely enough, when I looked at that file in XCode (which I didn't do before as it was all just move of a code that worked before), I suddenly got all these errors displayed clearly.
My last weird finding was after I asked myself ... "Why the hell did it work in the original target without the import CoreGraphics?"
It turned out that having this in the bridging header file automatically brought it linked frameworks with it as if they were imported in all my files (it is one of the linked frameworks I use which is using UIKit):
#import <TesseractOCR/TesseractOCR.h>
But it can be anything, really, like:
#import <UIKit/UIKit.h>
The point is if you are using the bridging header file, it may easily hide the fact that you are not being forced to write consistent code with all necessary imports.
Anyway, my primary goal is to let everyone know that their original problem is most probably something totally different and the original issue is actually encoded in that error byte array everyone is getting. Even if you face encoding problems, this byte array may tell you what is wrong with your code.
Happy fixing!
In the navigator pane, the reports tab (last one) is your go-to for these situations. You can see detailed logs of build actions and can track down from there.
I had the same errors from the question. I dragged a file from project_1 to project_2 and all of a sudden all those errors appeared inside project_2. The odd thing was the new file that I dragged in had nothing to do with the errors because they appeared in completely different files that I had previously dragged in from project_1. Those files worked fine for months and the errors didn’t appear until after I dragged in the new file.
I closed Xcode, opened it back up, and the beachball of death started spinning. Xcode was basically frozen, I had to wait about 45 minutes for it to unfreeze.
I added screenshots of the errors and steps of what I had to do to resolve this issue.
1- These were the original errors, just like the ones from the op's question. I had 151 errors:
2- After the beachball stopped spinning I started to look through all of my files. I ran into a file that was somehow corrupted and its normal code was somehow replaced with the odd code inside the middle/right pane below.
Copying and Pasting the corrupted code from the middle/right pane didn't work at all which was odd but I did a global search (cmmnd+4) for "bookmark" and 6 more files appeared that also contained the corrupted code (shown inside the left navigation pane).
"bookmark" is the first word on line 1 inside the file in the middle/right pane, that's why I choose it:
3- I c+p the 6 files from the original project back into this project (the corrupted one) and the errors went from 151 to 10 new errors. All 10 errors were Invalid UTF-8 found in source file:
4- I looked inside all 6 files and inside the commented out code at the very top of the file there was a strange symbol in place of the copyright symbol on line 6:
5- I deleted the strange symbol and everything worked again.
I don't know how those files were corrupted. I think it has something to do with dragging them in from one project to another. Probably was just a random bug. To be safe I deleted the 6 files then added them back in one by one by actually creating a fresh file inside project_2’s Xcode. Then I c+p the code from same file from project_1 back to project_2. No more dragging Swift files from project to project for me.
Very strange.
In my case this compile error was thrown because of source code encode/decode issue. Try to close Xcode and programs which work with a code simultaneously and restart Xcode
I hit the exact same error message converting a workspace from Swift 4.2 to Swift 5. Even with the same numeric sequence in the error message.
The swiftc command was dying on some unicode characters in my source file (in the copyright boilerplate at the top of my file). As suggested by t0rst, you can use the inspector to see which file the command died on.
After removing the unicode characters, the build worked. I suspect there may be some issues with the update to use UTF-8 as the default storage class.
EDIT - Just discovered that the Unicode storage on the offending file was indeed wrong. In the terminal, run file *.swift on your source files. Files with 'UTF-8 Unicode text' are fine. The file that was a problem reported as 'ISO-8859 text'. Use iconv -t UTF-8 src dst to fix the file.
In my case, I had accidentally added a shortcut to a swift file, rather than the swift file itself.
To decode the above code. Right click on browser page, click on inspect and open console tab. In console tab String.fromCharCode(123, 10, 32,23) replace with your numbers and hit enter. You will receive the exact problem in readable format.
I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.
So I noticed, while answering this question, that the one who asked the question appears to be a javascript developer. And as the code I wrote in haskell is easy enough, I thought I give haste a try and try to compile it to javascript.
So, I downloaded the Windows binary package of haste (why does the .msi require a reboot?!!?), added it to my path, issued haste-cabal update and haste-cabal install split and after a bit of reading the output of hastec --help, I issued:
PS E:\h\stackoverflow> hastec -o hexagon.js --pretty-print hexagon.hs
as my best guess on how to get the output I am looking for.
Opposite to my expectation, haste output was this:
hastec.exe: user error (shell expression failed in readModule: Data.Binary.Get.runGet at position 8: not enough bytes)
So, my question: What do I have to do to get a java script source file?
Is it possible that you have an old version of Haste lying around, or have intermediate files (.jsmod, for instance) from a different version of the compiler in your source directory? This sounds like the (quite unhelpful) error message Haste produces when it runs into a corrupted intermediate file.
Check that the version of the binary you're calling is what you expect (hastec --version). Then, try getting rid of all intermediate files in the directory as well as any files in %USERPROFILE%\AppData\Roaming\haste, reinstalling split, and recompiling with the -fforce-recomp flag. You should also add a main function, so that Haste has an entry point to your program from which to start linking. If all you want to do is to make some Haskell function available to external JavaScript, you can use the export foreign function interface:
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Haste.Foreign
import Hexagon
main = export "picture" Hexagon.picture
You will probably also want to compile your program with the --onexec flag, to make sure that main runs and exports picture immediately when loaded, and not on page load which is the default:
> hastec -o hexagon.js --pretty-print --onexec hexagon.hs
After doing this, any code included after hexagon.js will be able to call e.g. Haste.picture(5); in order to produce a picture of size 5.
(Re: MSI installer requiring a reboot, this is required since it adds the Haste binaries to your %PATH%, which does not take effect immediately. I assume that a re-login would be enough to make it take effect, however.)
I'm trying to convert a program from S5 to S7. I've taken a look into the tutorials and documents that are available. But I cant seem to find any information about this problem:
The program is pretty complicated and I should need the XR.INI file to convert it with the S5 Converter program that came with Simatic S7. When I open the folder with the project I see all the files I need and that are described in the tutorial made by Siemens.
.ST.S5D
.XR.INI
.Z0.SEQ
I start the converter and open .ST.S5D. When I did this I get the error there is no .XR.INI file. But I can see it in the folder. Its called CERMST.INI. So I guess the name isnt correct?
In PG2000 I remade the XRF with CTRL Q but nothing changed. I also tried to rename the file to CERM.XR.INI because I saw somewhere these files can only be 6 characters long (not sure if this is true).
I tried first without the XRF. There were some errors because of the ASM command. In the tutorial I saw the converter cant handle these so I removed these functions from the program to rewrite manually later on. After this I had an error because I had no XRF. Error was:
Error No PLC type description found for called or addressed block
So I really need the .XR.INI file but the program can't find it, but its clearly in the folder. How can I fix this? How can I make a new .INI file?
Link to tutorial: http://www.sankotek.com/TR/Dokumanlar/STEP%207%20-%20From%20S5%20to%20S7.pdf
Thanks in advance!
Siemens S5 file extensions used also last two letters before file extension to mark file type, like xxxxxxXX.XXX where x is file name and X is file type for S5, without second dot in the middle like you have. File name length limit exists, I think it comes from DOS or some older operating system file length limit.
If you don't have XRF file then if i remember correctly compiler does not have compile order. Some blocks have not been compiled but are referenced in caller block that the compiler tries to compile. Compiler does not find called block in compiled blocks folder and wham... fatal error. When i had such troubles i compiled called blocks independenly before calling blocks. So you can do without XRF file. But try to include Z0.SEQ, that file has assignment list so you get nice variable names instead of just variable address numbers.
Also, stackoverflow is not the correct place to ask questions about Siemens S5-S7 conversion. You should post your questions in http://www.plctalk.net, they have guys there who used to program S5 plc-s.
My Project Euler setup is a PyDev project that I work on from two different computers (one is a Mac, the other is Windows 7). The file structure of the project looks like this:
PROJECT_LOC/
unsolved/
The .py files for the problems I haven't solved
solved/
Problems_001_025/
.py files for problems 1-25
... etc ...
texts/
Any input files provided by Project Euler (e.g., Problem 22)
Every file is named in the pattern Problem###.py or Problem###.txt.
Once I solve a problem, I move it from unsolved to the correct directory in solved, which is where my difficulty comes in:
Given a problem with input, say Problem022.py:
for line in open("../texts/Problem022.txt"):
# read file in
# code to solve the problem
Since I solved Problem 22 a while back, I moved it from PROJECT_LOC/unsolved/ to PROJECT_LOC/solved/Problems_001_025/. Now, (not surprisingly) when I try to run it again, it gives me a no such file error.
So, without changing my file structure, is there a way for me to access the input text files from wherever I am in the project directory?
I was thinking I could do something like open(${PROJECT_LOC}/texts), but I have no idea how to get the PROJECT_LOC from Eclipse at run time, and have it work on both Windows and OS X. I played with what this person did in his question, but couldn't get it to work for me.
I figured it out...
I added an environment variable to the interpreter with the value ${PROJECT_LOC:texts}/ in my Eclipse preferences. I can now use os.environ["PROJECT_EULER_TEXT_FILES"] to pull the location of the input.