VS Codespaces bash shell failed to initiate - bash

I'm using VS codespaces to complete the current CS50X course.
I've been getting on very well with it but have hit a snag where the Terminal doesn't seem to be loading correctly. I think i'm missing a couple of options at the top of the Terminal section - Debug and Port. I'm trying to complete the Finance section of the course which involves connecting to a development server but when i try i get the following erroe message:
{"type":"https://tools.ietf.org/html/rfc7231#section-6.5.4","title":"Not Found","status":404,"traceId":"00-76b8a3e0c4eaccf805373ec05e5ec917-dccabf0efd4cf681-00"}
I've tried to Google what might be going on but i'm very new to programming and don't understand a lot of what i'm reading!!
I did notice that the shell has failed to initiate, but again, i don't really know what that means.
I've tried re-loading the window repeatedly but still get the same situation.
Any ideas would be much appreciated!!

Related

Why can't I access terminal on vscode dev neither on edge nor chrome?

I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.

Extendscript Toolkit debugger fails: Can't start debug session

Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.

Access Violation when debbuging windows phone 8.1 app

recently I encountered a problem. Every time when I make some changes in page after I debug it on device when going to said page the app minimizes (crashes) and after about 30-50 seconds in output window I get
The program 'XXX' has exited with code -1073741819 (0xc0000005) 'Access violation'.
But when I uninstall and then debug again It works. I already tied reseting phone. Is it something with my debbuger or more likely with my code?
Edit:
Right now sometimes it occurs and sometime it doesnt ... I'll need to inspect code more. Is there a way to obtain more debug info with Access violation information?
I'll post as answer so others can see it easily.
You can see the dump of debug on the test device, Follow this
link.
Basically the link explains how to turn on "Save Information option" from Feedback application inside Settings of your device. After that when you debug the app, you will find dump file of your application inside,Phone -> Documents ->Debug.
Please post a sample of your code. I had similar problems when I tried using {unsafe code} and included pointers. They are extremely useful, but often lead you to memory problems (reading from a NULL pointer or something like that), so check if that's your problem.
Good luck

Applescript "mixed credentials" error

I asked this question over on the Apple Communities and got a grand total of ZERO responses. You guys seem a whole lot smarter, so thought I would ask here to see what you think.
An error has started occuring when I attempt to trigger an Applescript via an external process. The console error is as follows:
12/09/2012 11:01:39.205 osascript[269]: Scripting addition loading restricted to system domains because this process has mixed credentials (issetugid=0 r/e uid=501/0 gid=20/20)
When I run the script locally on the Mac(Mini - Mountain Lion 10.8.1) it works perfectly.
What is happening is as follows.
I have a MacMini as a music server in a home automation environment powered by a Crestron processor. The MacMini is connected to two zones, one via the Optical output and another to a DAC from one of the USB ports. When I selected "Listen to iTunes" in one of the two zones the controller sends a command via UDP to a program running on the MacMini which triggers the scripts to change to the appropriate audio out.
All was working well until yesterday when all of a sudden the program triggering the script, whilst reporting that it has executed the correct script correctly, isn't switching the output and the above message is appearing on the console.
I have read what I can on here and as such have reset the PRAM and SMC (all three dongs...) and deleted the script triggering program, run Clean My Mac and rebooted, all to no avail.
Can anyone help me with this, it has to be something simple given that it was working...surely? I haven't run an update or changed anything else that I can think of.....
Any and all thoughts and input would be greatly appreciated.
Thanks
Marc
From the error it seems that you have an add-on to applescript called a "Scripting addition" installed, and that's causing the error. Most likely you do not need this add-on to perform your applescript code. So I would remove all scripting additions from my system and see if the applescript still works.
Search your system for scripting additions... ~/Library/ScriptingAdditions and /Library/ScriptingAdditions.
If you do need to do something that the scripting addition is doing for you, then there's probably other ways to perform the same task without the add-on.

ANTLR “Cannot launch the debugger. Time-out waiting to connect to the remote parser.”

One of my ANTLR grammars running in AntlrWorks throws:
“Cannot launch the debugger. Time-out waiting to connect to the remote parser.”
In the past this message usually goes away but this one is persistent. On searching the ANTLR lists (e.g. http://www.antlr.org/pipermail/antlr-interest/2009-June/034659.html) there are hints that the error message is nothing to do with what it seems but could be a grammar error.
Has anyone got tips as to how to "reboot" or find the bugs in this situation?
I've found that the Windows firewall rules can really interfere with the debugger, so make sure you haven't set it to block the Java VM.
Also, try waiting a bit and then choosing the "Debug Remote" option, often the debugger just takes a little while and the main process times out, but the debugger does still come up.
It may or may not relate - but we got rid of the problem as follows:
On a UNIX box it didn't occur. On Windows it did. There were two parser rules that differed by case (e.g. myfoo and myFOO). When they were resolved the error went away.
I updated the ANTLRworks but the error persisted until we "solved" it as above.

Resources