What does Win32_Printer class PrinterStatus "6 (0x6) Stopped printing" mean? - winapi

See this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa394363%28v=vs.85%29.aspx
Search for "PrinterStatus"
What does "Stopped printing" mean? Did the print job finish? Or is this an "error" state?

It means exactly what it says: the printer has stopped printing for some reason. The most likely reason would be a paper jam, out of paper, or similar problem.

Related

What could be causing ruby NoMethodError backtrace to be so slow?

I have a pretty large ruby (non-rails) application that I'm developing. It's reasonably fast considering how large and complex it is (go ruby!), but sometimes I fat finger a method name and get the NoMethodError.
And usually when this happens, the application hangs for like 20 to 30 seconds to just print out the backtrace.
Specifically, if I do something like this:
puts "about to crash!"
Array.new().inspekt # NoMethodError here
I see the "about to crash!" right away, and then 20s or so nothing seems to happen before I finally get the NoMethodError and backtrace.
At first I thought it might be the "did you mean" gem, so I turned that off with --disable-did_you_mean on the command line, and that turned off the "did you mean" suggestions, but nothing sped up the backtrace.
What's interesting is that this is only for NoMethodError.
If I cause some other exception, such as:
puts "about to crash!"
a = 3/0
Then I see the backtrace immediately.
And to make things even weirder, if I interrupt the process right after the "about to crash!" (such as with a ctrl-c on unix) then I immediately get the NoMethodError and it's backtrace. So it has the information - but ruby is stuck on trying to clean something up perhaps, something that only gets cleaned up on NoMethodError?
Info: ruby 2.7.0
OS: CentOS Linux release 7.5.1804
UPDATE - to responses so far:
Everyone seems to be concerned about the backtrace and profiling the ruby code.
Except the slowdown is NOT happening there. There are NO LINES OF RUBY CODE that are executed during the slowdown. All of the lines prior to this, "in the backtrace" are already executed and in a matter of a second or so. Then the system hangs, between the puts and the NoMethodError. There is no ruby code in between to profile, so any profiler that is looking at code written in my ruby script isn't going to help. The slowdown is something internal to ruby and is not in my code, unless I'm terribly confused about what's happening.
To be very clear:
Line 10042: puts "HERE" # Happens at ~1s
Line 10043: Array.new().inspekt # Happens at ~20-30s
There is no code between those lines to profile. The 20-30s is not happening in any code before line 10042 executes, so profiling that will not help.
I do have other Fibers that are paused. But there is no code here that yields to them. Is it possible that there's some strange built-in yield code that attempts to run other (paused) fibers when an exception is hit? I can't think of a reason you'd ever want this behavior, and many reasons why it would be catastrophic, but I can't think of anything else that would cause this problem (that is also killable with a ctrl-c!)
I would try to debug the full backtrace in there to see what is actually happening
begin
puts "about to crash!"
Array.new().inspekt
rescue => e
puts e.backtrace
raise # raise anyway
end
In my case I get 20 lines of backtrace with ruby 2.6.3 and irb, if that doesn't really tell you anything interesting I would then do the tedious work of measuring each runtime by modifying each file of the backtrace and printing the times at each step, debugging yay!

app is not stopping at "gets" - is my online interpreter forcing a timeout?

While starting an assignment (Towers of Hanoi), I leave my code in a very basic state while I ponder the logic of how to continue.
while arr3.count < 6
puts "Move ring FROM which tower?"
from = gets.chomp
puts "Move ring TO which tower?"
to = gets.chomp
end
Before I can start building the rest of the app, however, gets seems to fall through without any input from me, and the second puts displays on the screen. This continues looping every, say, 30 seconds or so. Should I assume this is a feature of online interpreters (like codeacademy labs)?
Now I'm distracted from continuing the assignment and have to find a better place to do my code.
I'm installing Aptana (based on some advice on this forum) to see if I can get a better environment to do my assignments. Or do most people use a text editor then run their .rb file through the windows console window?
Thx

Windows 7 task scheduler keeps returning operational code 2

I set up a scheduled task to run under my account. Everything it runs, even if it is successful, returns an operational code of (2). I looked this up this error code at the below link, and it claims it cannot find the specific file.
http://www.hiteksoftware.com/knowledge/articles/049.htm
Even if I do something very simple, I get back operational code of (2). For example:
run program: cmd.exe
start in path: c:\windows\system32
I start the task and I see the process running in my task manager, so I kill the task. I then check in the history of scheduled task and it shows up as (2).
Something more realistic of what I am doing:
<?
/* file in c:\php\test.php */
echo "hello";
?>
run program: php.exe
start in path: c:\php
arguments: -f test.php
Everything works in the command line, but Windows schedule task keeps returning operational code (2). I should be seeing an operational code of (0), which means successful, correct?
You may not have put a path in the "Start In (Optional) box of the Edit Action dialog box.
Even though you had a path on the program that was being executed, Windows 7 still wants you to tell it where to run the program.
TL/DR: Don't worry about it. This just means the task finished, but tells you nothing about whether it was successful or how it failed. Look at the "Last Run Result" for that information.
The question and the top answer are confusing the notion of a "return code", which shows up in Task Scheduler as the "Last Run Result" with the "OpCode"/"Operational Code" that shows up in the history of a task.
If I create a simple Python program that does nothing more than sys.exit(7), and run it via task scheduler, I get a Last Run Result of 0x7, and an opcode of 2. If I have it do nothing, or sys.exit(0), I get a Last Run Result of "The operation completed successfully (0x0)" and still an opcode of 2. In other words, the return code from the executed program determines the Last Run Result. The OpCode appears to be a constant 2. This also establishes that the opcode 2 is not related to the return code 2 that likely means the file's not found. We know the file was found as it executed, and returned different Last Run Results depending on the code contained.
Further, a Windows forum post points out that this history view is really coming out of the event log. Sure enough, I can find the same events in the event log (always with a value of 2). This means the definition of the OpCode is going to be the same as the definition used for events, and is less of a task scheduler concept than a Windows event concept.
What is an opcode for an event? I've struggled to get a clear answer, but as best I can tell, it appears it's ultimately controlled by the program writing to the event log. There's documentation around for defining opcodes in your program. In this case, the thing writing to the event log would be Task Scheduler itself or something else in Windows.
A final observation: If I go to the event viewer and look for Log: Microsoft-Windows-TaskScheduler/Operational, Source: Microsoft-Windows-TaskScheduler and Event ID: 102,201, add the column for Operational Code, and sort, I see it is always a 2. And events 100 and 200 are always a 1. This applies not just to my manual experiments, but also includes every other random program that's using scheduled tasks, e.g. Dropbox and Google updaters that are working as far as I know.
Put all this together and I would strongly bet that the events generated while starting up a scheduled task are hardcoded by Windows to use an opcode of 1 when writing to the event log, and the events generated while finishing a task (successful or not - which goes in the Last Run Result) are hardcoded by Windows to use an opcode of 2 when writing to the event log. This opcode appears to be a red herring that doesn't affect anything we need to worry about beyond curiosity.
I was striking out until I just deleted & re-created the scheduled task...now it works. Don't know why but there it is.
Okay I know I am late to the party here, but I think a lot of the problem stems from confusing the Operational Code with a Return Code. I'm not an expert in Windows programming or internals (I make a living using a Windows system to program, but my programming isn't for Windows systems).
If I understand correctly:
The Operational Code is set by what ever routine being run at whatever value the programmer decided to set it at.
The Return Code is indicative of success or failure.
Consider the following (edited) example from the history of one of my scheduled tasks:
Event 201, Task Category "Action completed" shows an Operational Code of (2).
Down below under the General tab, is the message:
Task Scheduler successfully completed task "\My_task" , instance "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" , action "C:.....\blahblah.exe" with return code 0.
There's the indication of success. A different return code would indicate a failure. The Operational Code of (2) merely indicates that the routine was finished (in this case) when reported. I don't believe there's any set values to be interpreted for the Operation Code.
I've been having a similar issue and found that in addition to what was suggested in both the accepted answer and its comments I had to do one other thing. I had to re-create the task and set its "configure for" to Windows Server 2003, Windows XP, or Windows 2000 I dont understand why, since its not for any of those OS' but after I did so my task actually worked.
If this runs, and works, yet you still get an error code try entering exit 0 at the end of your script.
It took me a lot of googling to find that so hopefully this is helpful to someone.
#ojchase is right.
Opcodes are attached to events by the event provider. An opcode defines a numeric value that identifies the activity or a point within an activity that the application was performing when it raised the event.
Opcode 1 means that, when producing the event, the application was in the start of an activity.
Opcode 2 means that, when producing the event, the app. was at the end of an activity.
So opcodes have little to do with success or failure.
Sources:
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventing.reader.standardeventopcode?view=net-5.0
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventing.reader.eventopcode?view=net-5.0

Cucumber: background fails still exits with code 0

I was wondering about something, cucumber returns an exit code 0 (which means "ok" as far as i know) when a Background fails.
Now failing steps shouldn't probably be in the Background (at best in a 'before'-hook i guess??). But does anybody know with what philosophy it returns this exit code?
Is it a bug or a feature?
Appendix:
A more concrete example:
Lets say this code passes:
Feature: Figuring out how Cucumber works
As a developer
I want to find out why cuccies fail, but my build doesnt
In order to have more confidence in my build
Background: logging in into the system
Given I am logged in
Scenario: creating a new test set
When I do something
Then I should see "you've done something"
It returns with exit code 0.
Lets make it fail:
Background: logging in into the system
Given I am logged in
Scenario: creating a new test set
Then I should see "there's no way you see this"
When I do something
Then I should see "you've done something"
The output shows a failing step and it returns with exit code 1
When I move the failing step to the Background:
Background: logging in into the system
Given I am logged in
Then I should see "there's no way you see this"
Scenario: creating a new test set
When I do something
Then I should see "you've done something"
The output still shows it failed, but it returns with exit code 0
I've asked the Cucumber guys (their mailing list) and they agree its a bug
http://groups.google.com/group/cukes/browse_thread/thread/e56699f0fabfc75f
Background is really like Before, with the only difference being, that it is run after Before. And since you're using Background/Before (in general) to set prerequisites for your Scenario(s) it wouldn't be very helpful, if the testing-process fails, which an error code different from 0 would suggest, just because you made a mistake in your prerequisites.
So my guess is, although i can't be sure, that this is a 'feature' and very much intended so.

how to produce delay in ruby

How to produce delay in ruby?
I used sleep statement but it didn't give me what I want.
puts "amit"
sleep(10)
puts "scj"
I want it to first print amit, then a delay of 10 seconds, then print scj.
But in above case what happens is it will pause for 10 seconds and then it will print amit and scj together. I don't want that.
I hope you got what I want to say.
I can't reproduce this. From a console, this does exactly what you'd expect:
puts "amit"
sleep 10
puts "scj"
(Ruby 1.8.6 on Linux)
Can you provide a similar short but complete example which doesn't do what you want - or explain your context more?
If you're writing a web application, then the browser may well only see any data once the whole response has been written - that would explain what you're seeing. If that's the case, you'll need a different approach which would allow the initial response to be written first, and then make the browser make another request. The delay could be at the server or the client, depending no the scenario.
Call $stdout.flush before the call to sleep. The output is probably buffered (although usually output is only line-buffered so puts, which produces a newline, should work without flushing, but apparently that's not true for your terminal).

Resources