This is probably a simple fix, but I'm trying to walk through the MarkEdit example in the Ceramic tutorial, and I'm having trouble getting the files to build.
I'm not sure what context I need to be in or to create -- I've tried running the instructions they provide:
(ql:quickload :ceramic)
(ceramic.bundler:bundle :markedit)
and I get the error in my title line. I've also tried cloning the MarkEdit repo (which has slightly different instructions, but gives me the same result) and loading markedit.asd before running these quickload and ceramic.bundler calls, but I get the same error.
What's the correct way to build the context that I need in order to run the bundler?
Related
I followed the Flow installation guide for npm & babel and when I get to the second stage where you flow init I keep getting the error message zsh command not found: flow. I installed flow into my project (a branch of my Gatsby blog) for testing/debugging purposes. It is not installed globally, which is what the Flow docs state is the best practice:
Flow works best when installed per-project with explicit versioning rather than globally.
I have been having a similar issue with Lume that returns zsh command not found: lume
If I enter echo $PATH
The colon delimited list should have user/local/.deno/bin:$PATH but it is not there. If I add it by running:
export PATH="/Users/yourUserName/.deno/bin:$PATH"
Than I am able to run lume commands. However, when I try to run lume commands the next day I have to go through the whole process once more as the error crops up again...
My question here today is regarding the Flow error and getting it sorted. I only mention the Lume error because it makes me fairly certain something is messed up in $Path or my Zsh config. I am just not sure what. The only caveat to that hunch though is that Deno is a global install, whereas Flow is installed directly into my project...
So, maybe the two errors while the same syntax are totally separate?
Thank you in advance for any guidance/suggestions. Cheers!
I came across this video from 2017 no less and the host had issues with flow not working within the project and so he installed it globally. I gave it a shot and the flow error zsh command not found: flow has been resolved...
So I have anaconda installed and make a separate environment for all my projects. Normally I just use PYDEV to create a new interpreter pointing to the anaconda enviornment and load the project in eclipse and all is good. After doing the last one though 95% of the time I go to debug I keep getting the error
An internal error occurred during: "Debug Source Lookup".
java.lang.IllegalArgumentException
The other 5% it kind of works as I can follow one script or a function before it starts breaking.
I've tried reloading the project, interpreter and conda enviornment to no luck. All my past projects which use to work are also now giving the same error.
The funny thing is when I'm in the debug perspective though it does seem to be working (I can see the Variables and use the interactive console to test stuff), but anytime I try to step into, over ect I get the error (even though it does seem to be working). So for the image above I can go through the code fine until it tries to jump to the other file which throws the error, but if I step into it I can manually open that file and walk through the function (just each step throws the error) and still interact with the code which is in the position through the console.
Any ideas how to fix?
Well, it may be something specific to this use-case (for instance, if the code for some object is evaluated and the source code is not really available for the debugger this is actually expected).
Can you provide the full stacktrace from the error log? (see: http://www.pydev.org/faq.html#HowdoIReportaBUG for details on how to get it)
I'm trying to run a simple example of OpenCV on Eclipse [which was perfectly buit and installed before (using CMake and MinGw), even libraries and all includes are in place !].
When building, I'm getting no errors or warning, all seems good, but when I try to run, I get a message as if the project had no Binaries, even if all binaries are there. I even specified the path to the ".exe" (run->run conf-> new launch-> browse ...etc.).
You can notice on the images attached that the project is built and the binaries are generated.
Notice: when I run an example of a (Hellow world) on the console ... it displays the messag without errors.
I read a lot on Internet before posting here, but I found nothing that matches to this case.
Thank you so much,
Error Capture
Build Capture
Regards
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.
I have a SBCL program that works fine in the REPL (and I've successfully built it before), but after a few changes to the code, the build doesn't work anymore. It still successfully build, but running the binary gives me strange errors:
fatal error encountered in SBCL pid 940(tid 2953912320):
thread_state: os_sem_wait(0x1408000): 4, No such file or directory
It still works fine in the REPL (the binary is also in same folder)
What is the best way to debug this situation? So far, I've been just trying things and rebuilding -- is there a better way?
The ASDF central registry is temporarily extended with the --asdf-path and --asdf-tree
arguments at load time, and reverts back to the default central registry value after that.
To avoid conflicts with this behavior, changes to the central registry should be done at
startup time instead of application load time.
Buildapp. Implementation
So, if you use some asdf utility in runtime, it could cause such an error, I think.