Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:Full of BS (Score 1) 292

by mandolin (#45177667) Attached to: OCZ May Be On Its Last Legs

As a data point of one, I'm still running with the 4GB of OCZ ram I bought from newegg (I think) in 2009 and have had no problems. The reviews on that product were also decent.

After reading reviews of their SSD drives, though, I'd avoid those.

I guess the message here (if any) is, pay attention to the reviews on the product. If people say it's crap, it probably is.

Comment: Re:Pay Decrease? (Score 2) 261

by mandolin (#42221757) Attached to: Python Creator Guido van Rossum Leaves Google For Dropbox

Money isn't everything to everyone. If you were being paid $500.00 per hour to shovel out a barn, wouldn't you take a job that offered something more fun like programing with python even if it paid $490.00 per hour?

Depends on the job. Which one do I take to wade through the least amount of bullshit?
I'm burnt out enough that I might try the barn for a year just for the variety.

Comment: Re:Wine (Score 1) 520

by mandolin (#33340272) Attached to: Steam Not Coming To Linux

Unfortunately I've had the opposite experience. Wine mostly works, and it's amazing it works as well as it does, but something is always broken just enough to make things suck.

In my case, I tried the Portal demo recently, and had random freezes every 10 sec or so that made the game unplayable. (Plus insanely slow startup on a system equipped w/an SSD, but I could deal with that.)

I was looking forward to trying a Linux version of the demo so I could buy the game if it worked. Oh well, too bad for me.

Comment: Re: Crooked Judge (Score 1) 691

by mandolin (#32661142) Attached to: Louisiana Federal Judge Blocks Drilling Moratorium

Why in the world would a judge hear a case when the outcome could effect his own wealth?

Not to distract from the topic at hand, but you do not appear to be familiar with the rich history of Louisiana politics. Try googling "Louisiana political corruption". (some of the links do say they've been getting sick of it post-Katrina.)

Comment: Re:Just like the other vendors (Score 1) 293

by mandolin (#31842022) Attached to: Microsoft's CoApp To Help OSS Development, Deployment

Thanks for the thoughtful and comprehensive reply.

I realize and understand that C99 is not a C++ standard and that VC++'s priority is C++ support. Of course, my priorities are different. I shouldn't claim that VC++ is bad for everybody, but it is bad for me.

Speaking of VLAs specifically, they have been broken in GCC until very recently

It is true VLAs are/were 'broken' in GCC in the sense that they are not fully C99 conformant. That has been documented in the info pages for a long time. However, speaking practically, for the simple declarations I have used, I have never had a problem. Perhaps I ought to double-check that :P

it's simply non-portable in practice

I agree that non-portability across compilers would be a problem, except that of course GCC itself is so incredibly portable, and is also the preferred compiler on many non-Windows platforms.

FWIW, I am not a C99 stickler -- I only care about the parts of it that I use, and I specifically don't worry about free-form variable declarations because there is an easy fix -- declare your variables only after a block begins.

VLAs have no "easy fix" -- the closest alternative is alloca(), which my manpage claims is "buggy" on many unspecified systems, and of course, it's not really portable or standard either. Using malloc() is slower, uglier (since if you're doing it right you'll want to check the return value), and has the potential to fragment your memory.

I apologize if these points have already been debated to death in the flamewars -- I don't read that group. I also expect you are already aware of these points and were simply trying to make yours, in which case, this was a superfluous post. Oh well :P

Comment: Re:Just like the other vendors (Score 1) 293

by mandolin (#31786164) Attached to: Microsoft's CoApp To Help OSS Development, Deployment

What exactly is bad about VC++ compiler? Can you be more specific? Are you unhappy about it not supporting C++ exception specifications (which no-one uses anyway)? Do you have a problem with optimization quality (in my experience, VC++ inlines things better and deeper than g++)?

VC++ doesn't support variable-length arrays. IOW it pukes on

void foobar(int i) { int myarray[i]; }

Variable-length arrays are part of the C99 standard. That's 10 years old at this point and it's a pattern I employ often. I am unsure of the status of this in VC++ 2010 (coming Real Soon) but last I heard, it still wasn't in.

Comment: Re:Grand Central Dispatch (Score 2, Interesting) 219

by mandolin (#31025380) Attached to: Intel Details Upcoming Gulftown Six-Core Processor

Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers). ... Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event.

I don't understand this. It's true Linux does not have kqueue. (as I recall Linus thought it was "ugly" ... whatever) But in theory (because I haven't actually used them), to achieve the same effect under Linux, you would use timerfd() + signalfd() + (your normal i/o fds like sockets etc.) ... and then epoll_wait()/poll()/select() on all of the fds you were interested in. In this way, one thread could wait for multiple different types of events, including timers and signals.

Would you please point out the flaws w/the above that make it impossible or impractical to achieve the functionality needed by Grand Dispatch? I would be enlightened -- thanks in advance.

Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth