why github classroom's auto-grading runs so long and gives me "error::Setup timed out in 571113 milliseconds"? - github

Does this mean I have some codes missing? As when I have some codes wrong, it will be shown as red rather than "timeout".

Related

VSCode showing weird errors in my Haxe Code

i just started learning Haxe today and i got a couple of problems with my VSCode.
There are 3 "Errors" in total, to be exact 2 errors and 1 info, but the info seems kind of wrong and i would like to know how to get rid of it aswell.
Before i go into more detail, some info that might be relevant:
I created my project using the "Haxe: Initialize Project" from the Haxe VSCode extension
I changed nothing in the build.hxml file
If i run my code via VSCode (Ctrl-Shift-B) i get an error
If i run it on a normal CMD with "haxe build.hxml" it works totally fine, no errors at all
The Code:
class Main {
static function main() {
trace("Hello, World!");
var t:String = Sys.stdin().readLine().toString();
trace(t);
}
}
The build.hxml file:
-cp src
-D analyzer-optimize
-main Main
--interp
The first error i get:
It seems that this error is not even in my own file, how can this be?
The Sys.stdin().readLine() seems to have something to do with it, since this error came the moment i added this line.
Uncaught exception Not implemented in haxe.io.input.readByte at haxe/io/Input.hx tasks [180. 1]
Screenshot from VSCode
The second error i get:
Once again it seems to have something to do with Sys.stdin().readline() this time this exact part of my code is red underlined and the error message is pointing at this exact line.
Called from here tasks [4, 18]
Screenshot from VSCode (Error)
Screenshot from VSCode (red underline)
The (kind of) error / Info i get:
This is the most weird one imho..
Its a blue "~" i get at the beginning of my trace("Hello, World!"); line.
Screenshot from the weird Blue Symbol
Screenshot from the VSCode "Problem" regarding this line
Thanks in advance!
I looked through the internet the whole day hoping to find something to get this things solved on my own, but since its my first time ever using Haxe and i was not able to find something even similar to this i hope some of you 5heads out there can help me with this. :)

is there a way to disable a mega-detailed error message in Rundeck's failed executions?

The message that is posted every time an execution fails is too verbose and creates too much noise. Is there a way to disable or hide it somehow? We have our own error messages within the scripts and don't need a red chunk of extra text displayed in the logs. Adding an error handler that will exit with code 0 is not an option because we still need the job to fail if a step fails.
That message is Rundeck standard output in case of failure (you can manipulate the loglevel but that doesn't affect the NonZeroResultCode last line, just the text from your commands/scripts), you can suggest that here. The rest are just workarounds as you mentioned.
This occurs even using the Quiet output.

Update TestStand Socket Test status (Execution Annunciator) while test is running?

I am looking for a way to update the test socket test status (the color: Green, Yellow, Red etc) indicator while the test is running. What I am experiencing is that the red color would appear only at the end of the entire test sequence if any of the test steps fail. If any of the tests in any of the subsequences fail, I can see Red appear on the right side in status indicator for any particular steps however, I would like to know how to have the status of the Execution Annunciator updated during run time as opposed to at the end of the test. As the sequence execution pointer goes through various steps during it's hard to see what failed as the pointer moves to next step after execution. In sequences that run for a long period of time, I would like to know by looking at the socket status whether any of the steps failed rather than waiting till the end of the sequence.
I tried looking at the report but it scrolls down and makes it impossible to see if anything has failed so far...!
See the screenshot below:
Thank you,

SocketError handling in Prolog

I'm a bit unfamiliar with the mechanics of error recovery in prolog, so I apologize in advance if the question seems stupid.
I am looking for a way to properly handle SocketError in swi-prolog. So far I have only found the following snippet:
setup_call_catcher_cleanup(tcp_socket(Socket),
tcp_connect(Socket, Host:Port),
exception(_),
tcp_close_socket(Socket)).
Whenever a connection is refused, it raises the appropriate exception and performs the cleanup action, closing the socket.
Problem is, i want to embed this in a predicate test_socket/3 that sets a status code whenever a connection gets refused and I cannot seem to find a way to do so. I tried doing:
test_socket(Host, Port, Status) :-
setup_call_catcher_cleanup(tcp_socket(Socket),
tcp_connect(Socket, Host:Port),
exception(_),
(tcp_close_socket(Socket), Status = 1).
but this doesn't seem to do the trick. Any ideas?
The purpose of the argument Cleanup is to perform some cleanup action, and then to continue, as if this cleanup has not happened. That is, the exception goes further up and Status = 1 is superfluous. The construct is not made to do everything. But probably a catch/3 above all of this, is what you want.
– false

In Pure Data is there any way to track down a "signal outlet connect to nonsignal inlet (ignored)" error?

I have a Pd patch which calls in a second patch as an abstraction.
The second patch works fine by itself. But when I try to use it from inside the first, I'm seeing this
signal outlet connect to nonsignal inlet (ignored)
error. But I can't see WHERE it's happening.
Doing "Find last error" just gives me.
... sorry, I couldn't find the source of that error.
How can I find out which two objects Pd is referring to with that outlet / inlet?
(The outlets of the subpatches are being wired into [dac~] in the main patch)
These subpatches USED TO work, until I tried to add Open Sound Control to them with udpreceive. And, like I say, they still do work, accepting the OSC if I run them on their own.
actually, Pd (>=0.43) became quite good at locating the source of errors, but unfortunately this is little known (and less documented).
if you get a findable error (usually those in red; and the error you get is one of them!), you can click on the error-line and it will take you to the object that complained (and select it)
the actual click-sequence is OS-dependent:
linux: Ctrl+LeftMouseButton
w32 : Ctrl+LeftMouseButton
OSX : ⌘+LeftMouseButton
alternatively you can get to the error, by clicking on the error-message and then hitting
Return
(Enter should work as well).