• Eric Gunnerson's Compendium

    Troubleshooting holiday lights


    I spent a fair bit of time putting up my lights this weekend, and had to do some troubleshooting sets that weren't working.

    This can be tough to do without a bit of help. While many bulbs have shunts that prevent the string from going out, they don't always work, nor do they help when lamp wires break.

    When that happens, I fall back on a non-contact voltage detector. Mine is a Fluke VoltAlert 1AC, which I bought at Home Depot for about $20. This is wonderful for general electrical work, since you can detect hot wires without having to have access to the conductor. Great if you're replacing an outlet and you want to make sure that the power is really off.

    For holiday lights, here's the way you find the bad lights.

    Find which section of lights is off (duh). This may be only half of a 100-light string. Start at one end of the string, testing each light, working your way along the until you find a difference in state. Test the light by holding the tester near the bulb part; if you get too close to the cable part, you'll get a positive from the traveler wire that's in the cable. I generally like to start at the end where there is power. The bad bulb will show power to it, but because it's bad, it won't be passing on power to the next bulb in line.

    One little note. Most plugs on US devices are polarized - the two plugs are different in size - for safety purposes. This ensures (for example) that a lamp socket has the hot lead for the tip, so that if you change a bulb without turning the light off, the screw part will not be hot. Most holiday lights, however, don't have this issue, so they're generally not polarized. This means that you can turn the plug around 180 degrees, and switch the hot and dead sets of bulbs in your broken set, which can sometimes make things more convenient.

    One final note: It's a lot easier to do this before you put the bulbs up on the roof, or 25' into the air.


  • Eric Gunnerson's Compendium

    Unmanaged objects and memory usage


    I few years ago I wrote a small utility class named Win32Window, so that I could write an automated tool to close down some of the dialogs that would appear whenever outlook lost a server connection (which was often, since it happened whenever I opened or closed my laptop). It wraps some of the high-level Win32 window handling functions. As part of that, I wrote a couple of routines to do screen and window capture, though I've never really used them.

    Yesterday I got an email from someone who was using the routine for real, and it was eating his system's lunch (not actually the term he used, but words to those effects). It's always unfortunate when a poorly-coded sample makes it out into the wild. One would hope not to have any of those, but I learned in writing my book that a) It's not possible to be perfect on technical details, b) that if you cover enough details, you will make some mistakes, and c) some of them will be howlers, and make people think you are a total moron.

    I was hoping this case wouldn't be that bad.

    I opened up my project, modified my test app so that it would capture screenshows on a timer, started up perfmon to look at the .NET memory counters, and set it running, with one screenshot ever 100 mS. Though the counters on perfmon barely budged, in about 15 seconds things were getting slow, and soon after that, things got *really* slow - so slow, that I had to reboot.

    In looking at my code, I found that I hadn't released some of the unmanaged graphics items, but fixing that issue didn't change the behavior at all. I switched to watching the normal (ie not .net) memory counters, and found that they went up a big chunk every time I did a screenshot.

    I played around with the excelled CLR Profiler, but the current problem with the CLR profiler is that it doesn't have a very good delta view, and it's optimized for looking only at managed objects, not managed wrappers, which tend to be small in the managed world but big in the unmanaged world (think of a bitmap. On the managed size, there is a single IntPtr reference to the unmanaged object, which might easily exceed a megabyte in size). So, I didn't get anywhere with it.

    I next added a "CLR" button in my app, to call:


    If my hunch was correct, this would find that managed object and finalize it, and the memory use would go down. That proved to be correct, which led me on a hunt further.

    The final issue was actually two issues. First, I wasn't freeing a Graphics object that I should have. Second, I had code that was something like:

    desktopWindow.Image = Win32Window.DesktopAsBitmap;

    which works fine, but has the side effect of never disposing the current bitmap.

    But I thought managed code meant I didn't have to think about such things...

    Unfortunately, this is a case where our current solution doesn't work very well. In an ideal world, the GC would have cleaned up after those huge bitmaps, but unfortunately, it has no way of knowing how expensive the underlying unmanaged objects really are, so I could allocate tons of new Images with creating enough memory pressure to force a GC to occur. That's somewhat unfortunate.

    The fix for the second issue is to call dispose on the old image. That gets me back to a steady-steate situation. The code will make its way up to the GDN archive in the next few days; if you're using this code, drop me a line and I'll send you an updated version.

  • Eric Gunnerson's Compendium

    How do you look for code?


    Another question, this time from one of the other PMs on the team:

    The C# team is trying to understand how you look for code when stuck or trying to learn some new technology. Currently the solution we provide is in the documentation – you can find among other things -

    • Walkthroughs on the product
    • Documentation for each method
    • How to articles that target specific tasks
    • Code snippets
    • Working pieces of code that we ship in the product that do a specific task.

    How do you try to find code for a task that you don’t know how to write? Is the Help content in VS organized well and is it adequate? What would you change to help people ramp up on new code, tasks, or the capabilities of the tool faster? What annoys you about the samples we provide today?


  • Eric Gunnerson's Compendium

    The Mad Scientist's Club


    The year is 1974. Disco was at it's height (or depth, depending on how you look at it).

    And I was reading a book by Bertrand Brinley called The Mad Scientist's Club. I has a story of a bunch of boys who have various adventures and make their townspeople look foolish.

    I loved it. Unfortunately, I lost the book.

    Last year, I thought of it again, and found a website run by one of the children of Brinley. I bought a copy of The Mad Scientist's Club and "The new adventures of the mad scientist's club", and introduced them to my 9-year-old daughter, who loved them.

    Definitely recommended if you have kids. I just ordered the prequel ("The Big Kerplop") to give to my daughter as a holiday present.




  • Eric Gunnerson's Compendium

    Floating Point Arithmetic


    Waaaaaay back in college, I spent some time on queueing theory (you know, Poissan distributions and all that). The most surprising part for me was that a random distribution of arrivals pretty much ensures that you will have clusters that are very busy, and times when you are totally idle. Once you work on the math a bit, you understand why, but our commonplace notion is that "random" should be "smooth".

    Incidentally, this also explains why it's so hard to determine whether environmental factors are causing health issues. You can't just look at a cluster of cancer cases (for example) and surmise that there is something causing it, since a random distribution will give you clusters. So you have to do some fairly sophisticated mathematics to determine whether the cluster is due to random chance or whether there is something else going on.

    If the average person understood this - and they could with some very simple experiments - it would help science understanding immeasurably. Humans are programmed to extract patterns from data, and it's not surprising that we see patterns that are really just random chance.

    So, once again, I've digressed a bit, but I assure you that this really does have something to do with floating point arithmetic. The point of the journey is not to arrive...

    I was talking about clustering, which brings us to the topic of newsgroup questions. It's not uncommon to not get a specific question for 6 months, and then get the same question 3 times in a week. The question for this week is "I'm doing something mathematical, and the answers are wrong."

    The problem usually has to do with the fact that the person asking the question doesn't understand that floating point is an imprecise representation. I got this drummed into me long ago in my numerical analysis class, where I learned (and promptly forgot) all about poorly conditioned matrices and the like.

    Back, once again, to the topic.

    The canonical discussion of FP arithmetic (for this audience, at least) is a 1991 paper by David Goldberg titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic"

    Even if you know a fair bit about FP math, there's a lot of good stuff there.

  • Eric Gunnerson's Compendium

    Barbecued TurkeyAlt


    Reading Chris Anderson's post about Deep Fried Turkey got me thinking...

    I've been barbecuing turkey for about 5 or 6 years now, and in the spirit of sharing, here's my recipe:


    • Bird, 1, large. We generally have a lot of people over (~15), so this means somewhere around a 22 pound bird. I prefer a fresh turkey over a frozen one, but it's up to you.
    • Grill, Weber, charcoal, 22" size. Some people use gas barbecues, but I'm very much a traditionalist. It helps if it has the fold up edges so you can get under the grill easily.
    • Briquets. I'm a Kingsford man. Some swear by chunk charcoal, but I prefer briquets.
    • Roasting tray, 8" x 10"
    • Thermometer. You can use a normal dial-indicator kind, but I prefer a remote digital one. If you use a dial one, cover the dial with aluminum foil.
    • Wood chips. Turkey has a fairly mild flavor, so you want a subtle wood. I usually use a fruitwood, like apple or cherry. This year, I used alder (because I forgot my apple wood and had some alder logs), which my wife liked better but I didn't like quite so much. You want to avoid strong woods, such as mesquite, or hickory (my least favorite wood).
    • Two "turkey lifter" thingies. Look a little like goalposts.


    1. Prepare the bird. At the minimum, you'll want to remove the "yuckola blobs" from the inside. Some people like to brine their turkey before hand. I think it helps a little in moistness, but the barbecue will give you a fairly wet heat anyway, so it's not that much of an issue. Rub on butter and add salt/pepper as desired.
    2. Start around 30 briquets.
    3. Put the briquets on the edges of the grill, with the roasting pan between them.
    4. Put the bird on the grill.
    5. Put the thermometer into the thickest part of the breast.
    6. Lift up the edge parts of the grill, and put some chips on the briquets.
    7. Close the lid

     Now, every 30-60 minutes, open the lid, add briquets to keep the amount constant, and add wood chips if desired. Less is more on the wood chips - I usually don't add any after the first hour.

    Continue until it reaches the desired temperature. I've typically gone to 165 degrees, but I notice that Alton Brown says 161 degrees.

    Remove from the grill, and use the drippings to make gravy. Carve the turkey, and enjoy.


  • Eric Gunnerson's Compendium

    Have you ever asked yourself "Why am I here?"


    I'm not talking about the metaphysical question of whether there is a purpose of existence. I'm speaking of a more concrete concern. Why am I here, sitting at my desk, working on a computer, at 1:48 PST, on a late November day?

    When I could be here...


  • Eric Gunnerson's Compendium

    C# PDC Sessions now on line


    The C# PDC sessions are now online. Experience what we saw at PDC last month, minus the pervasive campfire smell.

    You can either download the slides or watch the presentation (using Microsoft Producer, IIRC). I'd suggest watching:

    TLS320 - Visual C# "Whidbey": Language Enhancements (Anders Hejlsberg)

    TLS321 - Visual C# "Whidbey": IDE Enhancements for the C# Developer (Scott Wiltamuth and Anson Horton)

    TLS343 - Visual Studio "Whidbey": Advanced Debugging Techniques (Habib Heydarian)

    Oh, and I understand that there was some sort of announcement about some "OS thingy" at the conference - you might want to look at those presentations as well.


  • Eric Gunnerson's Compendium

    C# Sneak Preview Document


    We've put a C# Whidbey Sneak Preview document on the dev center. It has a good overview of the new cool stuff that will show up in Whidbey.

    Note that this isn't an exhaustive list; there are some things that will show up that aren't in the document.

  • Eric Gunnerson's Compendium

    Tantric snacking...


    This afternoon after lunch I ambled over to our admin's office in search of a small snack. I opted for some m&m's brand chocolate candies with peanuts. As I ate the 7 m&m's that were in the package, I noticed that the package was labelled "Fun Size".

    Others may disagree, but personally, I don't think that 7 m&m's produce an experience I would label 'merry' or even 'jocular', much less "fun", but I'm willing not to quibble on that point, especially when a far more important issue looms.

    What do you call the larger sized packages? What word do you use for something that is more fun than fun?

    There really is no English word that works. You have to move to more philosophical descriptions. The one that first springs to mind is "transcendent", which has all the right connotations, but unfortunately lacks the popularity of "tantric" (as demonstrated by the relative sales ranks of the top books with each title on Amazon).

    So, "Tantric snacking" it is...

    If you don't like this kind of entry, you may comfort yourself that at least I'm not writing about my sump pump...

  • Eric Gunnerson's Compendium

    What are you planning on using Visualizers for?


    One of the big new features for VS in Whidbey is the ability to write custom visualizers for your classes. Visualizers are written in managed code, and present whatever interface they want to view and edit the data.

    There are some obvious place where we're going to use this - if you've ever tried to look at the data in a dataset, you know that there's a lot of room for improvement. But we're interested in how you're planning on using it. Specifically:

    1) How many visualizers do you think you will write?

    2) What kind of objects will you write visualizers for?

  • Eric Gunnerson's Compendium

    C# Team Chat in 20 minutes (2PM PST)

  • Eric Gunnerson's Compendium

    As the weather turns colder, a young man's thoughts turn toward...


    Holiday lights.

    The first house that my wife and I bought was in a development with an active homeowner's association. The first year, we got a flier from the association that said:

    Holiday decoration contest

    $100 first prize
    $50 second prize
    $25 third prize

    With hundreds of houses in the development, we didn't figure we had any chance, but we did put up a few more lives than usual, and somehow won second prize.

    A monster was born.

    After a trip to Point Defiance Zoo's excellent Zoolights got me thinking about animated light displays. I had wanted to do some microcontroller programming, but didn't have an application until now. I hooked up with one of the robotics experts in my group, and bought the parts to build a BotBoard, and did the hardware and software for an 8-channel light sequencer.

    The sequencer was destined for a Santa animation. It starts with some flashing landing lights, and then Santa and his reindeer appear. A few seconds later, Santa and the presents move onto the roof, then up to the chimney, then disappearing down the chimney. Pause, and the sequence repeats.

    It was a lot of fun to write the software - the BotBoard runs a Motorola 68HC11E2 processor that is programmed over the serial port. A very cool processor with built-in timers and other useful subsystems, but it's a 8-bit architecture, and you get to program it in assembly language (you can find compilers if you want). Debugging is interesting...

    So, we got that project done, but only won third prize.

    A few years passed, and I had some leftover BotBoards, so I built the second controller. This one was a 16 channel controller, but uses the same basic architecture. It runs a 10' tree made up entirely of lights (well, lights, electrical conduit, and a whole lot of wire).

    For my most recent application, I wanted to do something different. One of the things that I found annoying was that the lights that outlined the house were white, and static. I wanted some thing different. I could have built another sequencer, but that would have given me a quick switch between colors. I wanted something more subtle.

    To do this, you have to get into dimming. That makes the project tougher, as you now need to have tight control on the timing to get it to work. It's also a bit harder to fit everything into the 2K of EEPROM and 512 bytes (yes, bytes) of memory you have.  This one took me a while, but ultimately gave me a very good project.

    In fact, I was able to write an article on it for Nuts & Volts magazine.

    So, as Thanksgiving approaches, I need to get ready to put up all three of the animated displays and a few thousand over lights. The total number of lights is around 13,000.

    I've been hoping to spend some time building some new sequencing - perhaps one that can be driven over a serial port.

    If you happen to live in the Bellevue area, you can stop by. I'm going to try to post some pictures when it's all up and running.

    Oh, and if you think I'm out of control, take a look at this, and of course, the granddaddy of them all, PlanetChristmas. 35,000 Lights.  Here's a video.

  • Eric Gunnerson's Compendium

    Book Review: The Salmon of Doubt


    Like many people, I was saddened when I heard about Douglas Adams' death last May.

    Of course, I had read Hitchhikers many years ago, and had also read his Dirk Gently series. I also had the unique (well, not *truly* unique) privilege of hearing him speak when he did a talk at Microsoft a few years ago.

    I recently came across a copy of The Salmon of Doubt, which I would describe as a brain dump of a bunch of useful things that Douglas had on his computers at the time of his death. There are a lot of short articles and essays, and then a few chapters from a never published Dirk Gently book. The articles and essays are varied and interesting, and the chapters, while a bit uneven, are definitely good stuff.

    Overall, I liked the book a lot, and found out a lot about Douglas that makes me more convinced that the world has truly lost a unique soul.

    One especially poignant part of the book is the order of service for his memorial. If you have Richard Dawkins speaking at your memorial service and David Gilmour performing "Wish You Were Here" (my absolute favorite Floyd song), you're hangin' in the right crowd in my book.

  • Eric Gunnerson's Compendium

    New CLR Profiler release


    From Jan Gray's blog (Jan is another of the Perp team members), a new release of the CLR Profiler. This tool, which used to be known as the "Allocation Profiler", was written by Peter Sollich, who also happened to be a member of the C# design team for a while.


  • Eric Gunnerson's Compendium

    Generics Algorithms


    A few weeks ago, Anders walked into the C# design meeting and said, "I think I have a way to get generic algorithms to work with our current support", and then proceeded to outline a scheme on the whiteboard. I dutifully copied it into our design notes (after being away from the design process for a couple of years, keeping the notes up to date is my big contribution).

    Today, I was home taking care of my sick daughter, so I spent some time playing around with his idea.

    The basic idea is to create a generic class that defines the operations that can be performed on a data type, and then create specialized implementations. Something like:

    public abstract class Calculator<T>
        public abstract T Add(T a, T b);

    and then derive a specific class from it:

    namespace Int32
        public class Calculator: Calculator<int>
            public override int Add(int a, int b)
                return a + b;

    We'll be using Int32.Calculator to perform operations on ints. We could extend thte calculator class to perform more operations, and create implementations to deal with different types. So that's the first part of the scheme. It's somewhat reminiscent of template specializations in C++, but it's not

    We can now define a library to use it: 

    class AlgorithmLibrary<T> where T: new()
        Calculator<T> calculator;

        public AlgorithmLibrary(Calculator<T> calculator)
             this.calculator = calculator;

        public T Sum(List<T> items)
            T sum = new T();

            for (int i = 0; i < items.Count; i++)
               sum = calculator.Add(sum, items[i]);

           return sum;

    This class encapsulates algorithms inside of it. When we want to use it, we can write:

    AlgorithmLibrary library = new AlgorithmLibrary<int>(new Int32.Calculator());

    I should perhaps explain how this works. When we construct library with int as the type argument, that means that constructor is looking for a Calculator<int> rather than a Calculator<T>, which is convenient, since that's the class we passed into it.

    Ultimately, we end up with a version of Sum that uses the int calculator to do its operations.

    That gives us a workable scheme, though it is a bit ugly because we have to create the calculator and pass it in. The neat way that Anders came up to get around this is to use a pattern-based approach, and use reflection. We first look for the calculator class off of the type, and if we don't find it, we look in the standard place. This means that you can have the AlgorithmLibrary constructor find the right calculator for us.

    This all worked out fairly well. I'd show you the whole code, but I'm not quite happy with it, and I'm not sure it would run on the PDC bits, so you'll probably have to wait for a while. Here's a sample of using it:

      List<double> ld = new List<double>();


      AlgorithmLibrary<double> cd = new AlgorithmLibrary<double>();

      Console.WriteLine("Sum is {0}", cd.Sum(ld));
      Console.WriteLine("Mean is {0}", cd.Mean(ld));
      Console.WriteLine("SD is {0}", cd.StandardDeviation(ld));

    One concern with this approach is performance. I did a few quick benchmarks, and for lists, this approach takes about 50% longer than coding it by hand. For arrays, it's about twice as slow. I think the major problem is the virtual function, but there may be a way to make that faster.


  • Eric Gunnerson's Compendium

    C# Performance


    If you're concerned about performance, you should read Rico Mariani's blog.

    Rico is an architect on the CLR team, and, coincidentally, is one of the developers who interviewed me way back in 1994.


  • Eric Gunnerson's Compendium

    Public fields vs properties


     If you search on MSDN, you won't find any general C# coding guidelines. When people have asked how they should write their code, they often get pointed to the class library design guidelines. There is lots of good advice there, but not all of it applies universally.

    One of the guidelines says:

    • Do not use instance fields that are public or protected

    it goes on to say that this is important because properties don't version well.

    Some people have taken this as an absolute rule, so I've been seeing lots of code that uses properties on every class. If you don't need the versioning advantages of properties, you don't need to spend the time writing lots of trivial properties (those where the getter and setter don't do anything special).

    In fact, I'll say that a bit stronger. You probably shouldn't use properties unless you need them, as it takes more work and makes your classes harder to read and maintain.

    So, when should you use properties that you don't need? My suggestion is to only use them at versioning boundaries. If a class and the classes that use it are always compiled together, than properties don't buy you any advantage. If they are compiled separately, then using properties instead of fields looks like a better idea.

    Or, to put it another way, writing trivial properties makes sense at the locations where your component interfaces with other components.




  • Eric Gunnerson's Compendium

    Note to my younger self


    Note to my younger self: Eat better.

    There won't be any programming content here, so you may choose to ignore this post, though you may regret it in a decade or two. Don't say I didn't warn you.

    A few weeks before PDC, I started have a problem of a very personal nature. That's right, I had an outbreak (incident? flare up? episode?) of hemorrhoids. It's not something you generally want to publicize, and in fact, I didn't talk about it. I've decided to blog about it, for a simple reason:

    If somebody had told me what I'm going to tell you when I was in my 20s, I would have had the opportunity to change my habits.

    Most Americans eat less than half the fiber they should, which also means they're probably eating fewer vegetables than they should be. Trust me when I tell you that you don't want this condition. And since over 50% of Americans have it at one time or another, the odds aren't good. A decent diet can make it unlikely you will ever have to deal with it. Not to mention the other benefits.

    After my first "encounter" about a decade ago, I changed my diet a fair bit and got better, but after the recent episode - and a fairly miserable few weeks, including a unhappy week at PDC, I decided to see a specialist, who last Tuesday did a small bit of surgery. After which I found out an interesting pharmaceutical fact.

    Well, perhaps "found out" isn't really the right term. Something like, "had beat into me over five increasingly miserable days".

    My doctor had written me a prescription for Vicodin, the trade name for Hydrocodone, an opiate that's more potent than morphine, to help control the pain. It is wonderful against pain. But it is not without side effects.

    If you go to a drug website, you'll find a list of side effects. There are a lot of fun "mind altering effects", which I like to call "crazy thinkin'", but the most important one is the second one. Apparently opiates are well known to utterly and completely shut down the later stages of digestion. For me, two vicodin did me in. Saturday night found me in the emergency room treating that condition, and today I'm feeling better than I have in the last 6 months.

    The choice is yours.



  • Eric Gunnerson's Compendium

    An Introduction to C# Generics


    An Introduction to C# Generics

    By one of my friends, Juval Lowy, founder of IDesign.



  • Eric Gunnerson's Compendium

    C# Team Chat: New Features in Whidbey


    The C# team is hosting a chat on MSDN next week discussing the changes in Visual C#, including both language changes and IDE changes.

    November 20, 2:00 P.M. Pacific time/5:00 P.M. Eastern time - You can find more information about this chat on

  • Eric Gunnerson's Compendium

    Quiet CPU Fans?


    I recently built a music system for the ski cabin (you can only listen to Infinity so many times). It's a Micro-ATX system with a 40Gig drive, a CD ROM, and 256M of memory. More than enough for music. It runs the same custom MFC application that I use for my music system at home, and I'm using an old PocketPC as the remote control.

    The system works great, except that the CPU fan that I got at my local PC store (the original one I got was too tall) sounds like a hair dryer. So, I'm shopping for a new CPU fan that's quiet.

    The search has been a bit confusing, so I'm looking for some help. The CPU is an Athlon 1.3GHz, and the fan needs to be not much bigger than the "small heatsink" size (ie about 3" square), and it can't be too tall (about 3" max).


  • Eric Gunnerson's Compendium

    Things My Girlfriend and I have argued about

    One of my favorite pages on the net:
  • Eric Gunnerson's Compendium

    C# IDE: New Features for Whidbey


    I'm sitting in a large conference room watching my manager, Scott Wiltamuth, do a presentation about the new features in the C# IDE. The highlights are:

    1. Expansions, which are user-written "code templates" which are triggered through the standard CTRL-Space syntax. They are somewhat like a Cut/Paste, except that you can define fields in the text that can be replaced, and the IDE will highlight as you step through them.
    2. Code formatting. Formatting is always a religous issue, and previous versions of C# didn't give you very much freedom in following your own formatting beliefs. In Whidbey, we've developed an approach with much finer-grained control on how you code is formatted. There are 80-some different settings that you can set to control exactly how your code is formatting
    3. Refactoring. VC# in Whidbey contains support for some commonly-used refactorings. One of our goals WRT refactorings is to be able to make the refactorings that we do very trustworthy. In other words, to make sure that they work every time. To do that, we've hooked in to the C# compiler, so that refactoring can use the "gold standard" information about the code when doing refactorings.
    4. Debug visualizers. Visualizers are C# forms that the debugger uses to display values. If you've ever tried to figure out what's going on in a hashtable or a dataset, you know that the current model isn't great. With visualizers, you can use a custom viewer on top of the data.
    5. New build system (ie msbuild). Think of something like Nant.
  • Eric Gunnerson's Compendium

    PDC: New C++ language syntax


    I spent a bit of time in the session on the new C++ language syntax, and I saw a similar presentation a few weeks ago back in Redmond. The current release of VC++ uses an extension syntax to "add on" the managed (ie clr) concepts onto the existing C++ syntax.

    For Whidbey, the C++ team has ingrained the managed concepts deeply into the language syntax, which should make it easier to write managed code using C++.

Page 42 of 46 (1,140 items) «4041424344»