|
I heard they are especially good for cherry-picking with Git 
|
|
|
|
|
RickZeeland wrote: Git
Gaah! Someone hand me a barf bag. 
/ravi
|
|
|
|
|
You're doing it again, Ravi. Just wait until the zealots come out. 
|
|
|
|
|
Hmmm, the zealots seem to be asleep, must be a Post-Thankgiving effect
|
|
|
|
|
Custom layout, custom design, and in my case another encoder/interface don't come off the shelf. I'm also going to need a hexadecimal keyboard
with address and data displays. Guess what, these encoders and display drivers are also hard to get. If at all, you get them from chip collectors with no guarantee that they are still functional and at a price higher than their weight in gold.
For me it's yet another job for PIC microcontrollers + key switches + 3D printing.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Cool - Can you get it in red? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
The keyboard in the video is just a plain straightforward design. You are absolutely free to draw up anything you like in a §D program of your choice and then print it. Of course you can get filament in all colors of the rainbow to print it. It's also not too hard to first prepare the surface with fine sandpaper, then spraypaint it in some color(s), apply lettering/decals and last a nice coat of clear paint to protect the decals and for the finish.
That's the good part about DIY. You can custom design everything as you like. For example, I might the numeric keypad with a hex keypad for the Elf.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I need a replacement for Microsoft's Queue<t> that allows for efficient indexed access to the items therein.
So I made one.
The trouble is, I don't know what to name it.
By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List<t> - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList<t>
So while I'd name mine ArrayQueue<t> that itself is inconsistent with microsoft's naming conventions post 1.x
Queue<t> itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this.
Another option I considered was ListQueue<t> because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either.
To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: Queue<t> itself conflicts
Not if you namespace it. 
/ravi
|
|
|
|
|
Yeah I did namespace it. Still, conflicting with Microsoft's class name irks me a little. I think it can get confusing and icky if you reference System.Collections.Generic in your usings, which is really common (and I think by default when you create a new C# file in a VS .net framework project)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
'cept it's a list. Collection doesn't guarantee order. List does, and provides indexed access, which my queue does.
I'll consider QueueList, thanks
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When Microsoft extend something they usually (well quite often) add the suffix Ex. So how about QueueEx ? Does it not show up in Reference Source[^]?
|
|
|
|
|
They do that more in Win32 and COM than .NET
Usually with .NET they just stick new objects under a new namespace and try to name them differently. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
How is about _001<t> 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Bob.
Bob<T> myBob = new Bob<T>();
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Oooh, I like that one. I'll definitely consider it. So far it looks like it might be a winner. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
That was my first thought as well.
You beat me to it!
|
|
|
|
|
honey the codewitch wrote: I wish Microsoft would have simply exposed the internal method they have in the reference source
Add an extension method and use reflection to call it. 
Oh wait, you said efficient indexing. 
|
|
|
|
|
Yeah, I was gonna say.
Not only that, it's kind of terrible to rely on a non-public method in someone else's code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
From the top of my head.
public static T GetAtIndex(this Queue<T> queue, int index)
{
T obj = default(T);
int count = queue.Count;
for (int i = 0; i < count; i += 1)
{
T temp = queue.Dequeue();
if (i == index)
{
obj = temp;
}
queue.Enqueue(temp);
}
return obj;
}I'm pretty sure that's how Microsoft intended it 
It's lightning fast if you have only a few items and you don't do it too often
Or you could do whatever you're doing an name it IndexedQueue, like Greg also suggested.
|
|
|
|
|
That reorders the queue. I can't have my indexing have side effects. If I didn't have to worry about that your solution would be a decent one.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I misread your code. I thought you were just enumerating until you found the item.
Anyway, I'm not sure that would be faster. See based on what I know from the reference source, there's no reallocations taking place with your technique. It's just setting array elements and incrementing some integers.
Reflection can be kinda nasty. I'd have to profile. It definitely depends on the number of items in the queue as well, but for what I'm currently using it for, it shouldn't be more than a half dozen to a couple dozen items.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
