|
Oddly, I have a Canon Pixima ip6700D printer that seems to just work. I have not used it for up to 3-4 months and then when I do I print one test sheet and then it is ready to go with no issues. I find it amazing that this keeps being the case. I never have used any cartridges that are not original Canon OEM ones in it. I keep expecting to have to pitch it but it likes its home i guess.
It is also capable to print on CD's. Although the option was unavailable for US models and you could not order the parts from Canon for US. So I asked a work associate in Canada to get me the pieces. they where less than $15. Changed the firmware to Europe version and away she went.
Of course now that I said all this the ink in my 6700D just flashed dried out and nozzles melted. 
|
|
|
|
|
MikeMSA wrote: Oddly, I have a Canon Pixima ip6700D printer that seems to just work
[...]
MikeMSA wrote: Of course now that I said all this the ink in my 6700D just flashed dried out and nozzles melted
You jinxed it. So the lesson is...
[Basic Fawlty]
Don't mention the...printer?
[/Basic Fawlty]
|
|
|
|
|
Here's what worked for me. I bought an inexpensive 'pigment base' inkjet printer that could do CDs and could also use refillable ink cartridges. I then used 'dye based' inks in the cartridges instead of the normal pigment inks. The pigment ink particles are larger than the dye ink particles so the pigment ink printer heads have larger holes than the dye ink printers. Basically, I wore out the printer mechanism before I got a clog (very infrequent) that wouldn't clear with a simple cleaning.
There are issues with the dye based inks. The 'print' will be more likely to fade and be less 'wear' resistant than a pigment ink print. Normally when you make a print with a dye based printer you should use a swellable polymer paper to make the print more wear/fade resistant.
|
|
|
|
|
I've had a couple of Epson inkjets over the years and always been impressed (surprised even) on how well they handle my lack of use. Very occasionally I need to run the "head clean" routine but not more than once. Not sure if always using genuine Epson cartridges contribute it that.
Currently I have an Epson XP-6000 (scanner + A4/CD printing) and am happy with it. Only thing I'm nervous about is the ink cartridges only suit this one model so Epson might stop making them sooner than other multi-model cartridges and render my printer useless.
|
|
|
|
|
So I was fixing my Midi lib's streaming Send() routine to work with large sysex messages and generally be more efficient.
I get called back on send completion - from a different thread. However, list here is never touched again. I just hang on to the enumerator. The enumerator doesn't get touched outside the callback once its filled, and the callback never happens until its filled, so it's "safe" threadwise.
I need to keep the enumerator around so I have a member var called _sendQueue and to be safe I always do Interlocked operations when writing it.
Interlocked.Exchange(ref _sendQueue , list.GetEnumerator());
Anyway, the above succeeds, but a bit later when I'm packaging it for sending, I call _sendQueue.Current to get the current event and it returns null frome Current!!!
There are never nulls in that list I built.
I instead replaced the code above with this:
var e = list.GetEnumerator();
Interlocked.Exchange(ref _sendQueue , e);
And it works.
For the life of me, I have no idea why. I'm about to dive into the IL out of curiosity but I don't think it's going to tell me much.
There have been a lot of oddities in writing this MIDI code, but the above takes the cake.
Real programmers use butterflies
|
|
|
|
|
Might it be a scoping problem? "e" has a scope that is larger than the enumerator received from the .GetEnumerator() call.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
except that the scope is the same, or it should be for the duration of that call? The routine returns immediately after that, without doing anything else except calling a method that takes no parameters and returns no value.
furthermore it's not like the enumerator stored in e/_sendQueue is failing at all in terms of accessing it - it's that the Current member is returning null so the failure is relatively far downstream from this.
I'm stumped.
Real programmers use butterflies
|
|
|
|
|
".Current" will be null if you haven't done a .MoveNext or something else to traverse it. If you do use MoveNext then check its return value is true, as if you're doing something under the covers to alter the list (such as remove an item from it) but not using the proper methods then the enum and list will get out of sync and you'll get null from Current, but in that instance MoveNext will have returned false.
|
|
|
|
|
actually it's supposed to throw if you haven't moved yet, but in this i have.
Real programmers use butterflies
|
|
|
|
|
That's not my experience. Of List<T> anyway, you didn't mention what types you are using.
|
|
|
|
|
the type is a reference type known as MidiMessage.
If List<T>'s enumerator doesn't throw on the first fetch of Current before calling MoveNext() then I promise you it's a bug. It should fail with (IIRC) InvalidOperationException
Real programmers use butterflies
|
|
|
|
|
|
i stand corrected
Real programmers use butterflies
|
|
|
|
|
I've got this idea rolling around in my head - building a rig that provides a server and four players for playing quake 1, 2, 3, and 4.
The "box" will contain a raspberry pi 4 (8gb) to serve as a dedicated server that will run all four quake servers, an 8-port gigabit switch, and a surge protector that provides power for up to eight devices.
Additionally, there will be one pi 4 (2gb) for each player, and it will already be connected to the switch and surge protector, and be booting from a USB drive that already contains all of the quake versions on it.
The idea is to set it on a table, and let players connect their own monitor, keyboard, mouse, and headphones. Since all hardware is equal, all players would have the same "experience" and connectivity quality.
The will be an external ethernet port and power outlet that will allow the user to daisy chain additional "tower" units to add players (four at a time, or however many players are supported by the secondary tower).
Just something taking up space in my brain box...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Sheesh, back in the day Quake was pushing my hardware to its limits. Now you're gonna run this on a freakin' Raspberry Pi?
|
|
|
|
|
Heck, I remember when company networks fell like ninepins because of multiplayer Doom ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
from what i understand, you can get upwards of 100fps on a pi4 in quake 3. And it'll be running on a gigabit LAN, so player experience should be outstanding compared to 25 years ago, when it first came out.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Good times. 
|
|
|
|
|
|
Somehow I missed the Quake experience growing up, but a build that encourages local multiplayer gets a  from me.
|
|
|
|
|
My credit union forced me to change my password but won't let me use a previous password.
I don't know why I get irrationally angry over this - I guess I feel passwords are kind of personal and telling me that I cannot use an old one doesn't improve security at all and seems invasive.
If I write insecure passwords changing guest1 to guest2 isn't an improvement.
If I write secure passwords changing TsfI$)#%(fikea;f to IDJOfe30235 isn't an improvement.
There is more B.S. superstition around password management than I can handle.
One of the most boogered things in all of IT are password management systems.
If you write a password management system and force people to change passwords every 30 days YOU ARE A BAD PERSON IN REAL LIFE.
Because of this I need to take a hostage.
I hope she's cute. 
|
|
|
|
|
Their is a simple solution to your problem.
Please log in for further information.
"SWORDFISH"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I too particularly despise this policy!   
That sure must have been a true password story, somehow!
|
|
|
|
|
Quote: If you write a password management system and force people to change passwords every 30 days YOU ARE A BAD PERSON IN REAL LIFE.
 I completely agree!
|
|
|
|
|
Agree. Ten days should be the absolute maximum 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
