And a rather close one, too. It is amazing people let Apple get away with rebranding KHTML "Webkit", but hey. As long as it makes the world better, and the less code from Apple the better:P
Originally, XFS lacked support for the equivalent to write:ordered in ext3. In practice that meant that while the metadata would be intact, your files (and thereby directories) might be blobs of zeros/gone. That is probably what happened to him, and it is what happened to me when I used it long ago. I think I have read that XFS has gotten this capability later.
For the topic, I'd recommend ext3 too. It's proven, can do the online grow/offline shrink that is so handy, has 3 different settings for speed/reliance, and is well supported. But I am not a sysadmin.
I'm tempted to say you don't know what you're talking about, since using exceptions is one of the worst thing for making all your 'new's actually hit matching delete statements.
If you are using delete, you are most likely doing something wrong. If you are new'ing many objects, you are most likely doing something wrong. Writing exception safe is not hard, and besides, is the same for every sort of language. Remember that it is not just your new/deletes, but (more commonly, too!) you lock()/unlock(), open()/close(), beginTransaction()/endTransaction() and so on that have to balance. If you want to know how much Java people struggle with getting that right, try searching on finally. Or try writing a program that copies one file to another, in C++ and Java:)
Of course, linters help, but really, a decently designed language would not have this problem at all. Object::clone, equals, hash at least are flawed design. Object should only have functions that *any* conceivable class can implement at no cost.
The reason while these flaws are there is that Java supports neither mix-in classes nor static polymorphism nor operator overloading.
It is on the way, but (apparently like Bjarne, wow!) I find this to be of little matter. I very seldom have memory resource problems.
On the other hand, our team of programmers have had quite a lot of issues, especially when different programmers have different ideas about how to manage memory. I definitely prefer to have garbage collection so as that this particular problem (which can become seriously nasty) is solved.
Perhaps a programmer going solo does not have a problem, but for projects in the enterprise, where programmers come and go, it's very serious.
I have worked in the enterprise, with no problems stemming from this. I made a short text and a seminar to get the ball rolling, and that pretty much eliminated that problem. On the other hand, I have been in Java projects where resource management was truly problematic --- I ended up solving that with Javas pitiful excuse for functional support. The syntax sucked, but it worked.
But of course, gc might solve *your* problem, which of course makes it important to you:) Personally, I think it is of little consequence --- gc is the last memory management method I would pick.
True, but newer and better parsers are getting there. But I agree that the syntax is the worst bit about C++. KDevelop 4.0 is looking good, though, once they get the memory consumption under control:D
Newer and better parsers? I have Visual Studio 2008, and Intellisense still lags a lot behind me. On the other hand, in the Java world, for example, by the time I have finished writing an identifier, the environment already knows what I am talking about and has already pointed out the errors.
KDevelop 4 (alpha) does completion in realtime, including type information etc. I'm told that the on-the-fly error checking will come. And of course parsing is easier in Java, which cannot do as much as C++. My point is that I believe you can retain the power of C++ and still make the parsing a lot easier for tools, but that on the other hands, the tools are getting more powerful and the problem might be solved that way around.
None is a bit rich, but the syntax is very bothersome at best. Lambdas will land in the next standard (as the article also mentions)
None is a short of an understatement. You can't combine functions in the way ML or Haskell does. You need a lot of boilerplate code and a lot of hacking to get the same results.
...eh, no. You can easily make a functor object that takes two other functor objects and combines them. The syntax sucks, the error message would be worse and so on... but there is no boilerplate code. In fact, I think you would be able to use boost::lambda to do this directly today.
I've seen the proposal about lambdas, and I wasn't impressed. There are many redundant declarations, for example you have to declare your enclosed variables twice.
I can't remember the exact details, but I don't recall any redundancy, except that you had to explicit tell which local vars should be available to the function --- something I regard as a good thing.
.... you will get a compile error?! shared_ptr's one-parameter constructor that takes a pointer is declared explicit. Were you hit by a bad implementation, or a bad compiler perhaps?
Try the following code:
As I thought. The library tries to prevent you from making that mistake, but you overrode it with an explicit cast, and the code does something you didn't mean to. We call that error for "error 40" around here... it originated 40cm from the screen.
It does not matter that the shared_ptr constructor is explicit. When you have a precompiled library that accepts shared_ptrs and you want to use 'this', you are basically screwed.
1. no *optional* (I repeat: optional) garbage collection.
It is on the way, but (apparently like Bjarne, wow!) I find this to be of little matter. I very seldom have memory resource problems.
2. many syntax problems: not context-free grammar (great problem for tools), various semicolons that are reduntant etc.
True, but newer and better parsers are getting there. But I agree that the syntax is the worst bit about C++. KDevelop 4.0 is looking good, though, once they get the memory consumption under control:D
3. no functional programming(no lambdas, etc).
None is a bit rich, but the syntax is very bothersome at best. Lambdas will land in the next standard (as the article also mentions)
4. shared_ptr sucks (just try to pass 'this' to a function that requires a shared ptr and deletes the current object).
.... you will get a compile error?! shared_ptr's one-parameter constructor that takes a pointer is declared explicit. Were you hit by a bad implementation, or a bad compiler perhaps?
5. no consistency: primitives are not classes, although I could program classes that behave as primitives.
I don't quite agree, but I do find the distinction unnecessary and think it should be done away with in any case. So we are more or less in accord here.
6. no import statements; still using old boring header files.
That critique is a bit weak. There are pro's and cons to either approach.
C++ is built on some excellent ideas, it's just the execution of those ideas that sucks. There can be another C++ like language with none of the problems of C++ and all its benefits.
Yeah, I dream about this:) Be sure to shout it from the mountaintops if you make it or find it someday!
Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion.
Really? I have lost count of the number of errors in Java code I find because someone wrote either something like string_a=="cheese" (which is only the right thing to do in a few cases) or string_a.equals("cheese") (which is also likely to crash). In C++, you get to do string_a=="cheese", and it will also work with any other class. Oh, and it will correctly fail at compile-time if you make a non-sensical comparison. You get all this free from operator overloading.
Then there is the map-like classes, the array-like classes, and as others already have mentioned, all the classes that acts more or less like numbers. In short, almost all C++-programs ends up using operator overloading in a positive way. A programming language that does not provide operator overloading is either a toy (nothing wrong with that), dumped down (likewise) or lacking (worse).
I pointed out that this isn't just any omission and addition. When you omit Israel and add Palestine (which is not even recognized as a country by the United Nations) to a country drop-down menu, you seem to be making a very loaded political statement. Ugh, this is not a story. Not the least because the country list (iso 3166) includes "PALESTINIAN TERRITORY, OCCUPIED, PS". So it could very well simply be an error.
If you think AS400 == mainframe then you have never seen a real mainframe up close.
I have. They are unreliable, slow, and run either z/OS (which sucks badly) or linux, which turn them into a slow server instead of a horrible slow server.
I still remember one of my pro-mainframe colleagues telling me that "it does 1 million (or whatever) MD5-sums in under a minute!". Same thing ran on my (from about the the same year) old PC on 13s. Then they tell me "but the IO is good. Afterwards, it turns out that one of our applications are performing badly because the executable code is too big. Say what? Then they tell me it is more reliable... after which a single point of failure (a disk array controller I think it was) floored the system for 6 hours. Weee.
In conclusion, the only thing a mainframe is really good for is as a paper press:)
How about letting me plug in two monitors (possibly with different resolutions) and - with the click of a few checkboxes - configuring them as a primary display and a secondary display so that I can drag windows between them, but new windows and dialogues are sized to fit & centered on the primary display?
Yes, I know X can support multiple monitors (but so far I've always ended up editing xorg,conf to make it happen) - but the options seem to be (a) mirroring, (b) one big desktop so new windows and dialogues straddle both screens or (c) two totally separate desktops which don't let you drag windows across.
For record, without wanting to enter this pissing competition, I am running two monitors with different resolution working like you want (maximizes to one monitor, but windows draggable between) without touching any textfile. The interface was xrandr--- a command line tool, but surely there is agui for it somewhere. If not, it should be trivial to make.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 3, Informative
Yeah, I have. Of course, I use the magic -C to ssh, that helps quite a lot. Certainly fast enough to be usable, though I could be better.
"
Just having unicode strings is not enough to "support unicode". Can I sort a list of strings written in french with the built-in unicode libs in Ruby 1.9 ? no, they won't be sorted correctly. Can I do it with Java out of the box ? yes.
That is a hopeless endeavor. It will screw up at least in Danish, where e.g. aa might be sorted first or last, depending on (meaning of) the word. I think we have even seen some court battles over whether Aabenraa (a town) gets to be to be first or late in the telephone book.
Better to sort in a predictabe, semi-correct way
And I am not defending ruby here, as I have not attempted to do i18n in ruby yet.
Not sure I understand this, how are Lists and Hashes not first class objects in Java?
If you have ever used perl or ruby you would know what I mean, I think. You cannot do things like this in Java
myfunc({"key1"=>"value1", "key2"=>"value2"});
where you construct and pass an anonymous hash. You can simulate it, but it quickly gets either cumbersome or brittle.
I'd also love something more explanatory than: 'less-broken this' and 'less-broken that'. Can you be more specific?
Of course, I was trying to be brief. The type system is Java is tied to inheritance. That is neither sensible nor desirable, and leads to problems like the.clone(),.equals() and similar methods that either does something non-sensible or fails at runtime, while the compiler was in a perfectly position to determine that at compile time. C++ does a better job in this regard. In ruby, the type system is not tied to inheritance, which is good, but it is on the other hand runtime which is not-so-good. Thus, less-broken.
less-broken syntax is of course somewhat more debatable, but most of those who likes ruby seems to prefer the syntax of ruby. Personally, I like that you avoid the ending } } } } which is so easy to get in Java, and often leads to wasted time. Also, the lack of operator overloading leads to syntax sillyness such as a.times(b.add(c).toThePowerOf(d))) --- which isn't exactly beautiful:)
For example, many people decry the int vs Integer issue, is that what you're talking about?
Given that using the natives is completely optional, and you could write huge java projects without ever touching them, except where you need to optimize by using the stack, how is this that big of a problem?
I mainly thinking of null not being an object. The other bit is stupid too, and no you cannot avoid it since it is used all over the standard library, but the null is much worse. It means that for two objects a,b of class A, a.equals(b) might well be different from b.equals(a) --- no matter the implementation of A.equals(A a). (since b or a might be null).
How is it worse than Ruby having this ? you can put at the end of a method, but it doesnt really mean anything and not enforced in the runtime. So its an equally optional thing, but its use is pure sugar, and its not actually seen or heard by the runtime at all. I am completely with you there, brother:)
I'm not saying that there arent aspects of ruby that are superior.... but your statements are very vague and over-arching.
Sorry, I was trying to be terse. No idea what over-arching means, but then, English is not my native tongue. In any case, I apologise, but if you look at my posting history, you will be able to find a lot of post going into this in some detail:) Computer languages is something of a hobby for me, and I dislike them all. I have a simple list of things I want a computer language to do, butno language fulfils that list yet, though C++ and ruby together does, as I recall.
I can't speak for everyone, but ruby's main features over Java is: closures, less-broken type model, less-broken syntax, lists and hashes as firstclass objects, mix-ins and closures. I know I mentioned closures twice, and that was on purpose.
Because only one thread can write to an instance of that structure at a time?
Except this is unlikely to be true. The structure could reside in both CPUs cache, and thus be corrupted. Of course. you would have to be very unlucky on several counts.
Otherwise I'd need a real semaphore.
Or similar, sure. That is the only way to be sure, the more's the pity. One reason why multi-threaded code is sometimes slower than single-threaded.
It's called a "lock-free design", which is a lot more efficient than requiring an operating-system semaphore. Your multithreaded code must thrash the hell out of the operating system. Have you ever profiled any of it?
I prefer to avoid locks, which works fine for me. But I suspect that my code is very different from what you do, so my methods might not work for you:)
I have never had to work with [the PowerPC line of processors], so I really don't know why I should have read up on it.
General education? To improve the breadth of your knowledge? So that the principles you learn can be applied to other situations? Intellectual cross-training? These things really didn't occur to you?
Learning new things are something I do continually, but obscure processors are quite far down my list:)
You seem to me to be a perfectly normal computer programmer. Problem is, no one ever got anywhere by being normal.
Looks like your opinion of me has improved somewhat;) Anyway, I am a mathematician first, programming is just something I do.
Oh really. So if I write to my thread-communication structure through a pointer to volatile memory, do a lightweight sync, then write the flag that tells other threads that the structure is ready for use, then lightweight-sync again, you're telling me that's not valid?
On the condition I gave, no that is not valid. The sync only works on the specific core to provide a barrier to some internal state. But if the memory is cached in two different processors, both will be able to take that "lock" and not discover it.There is nothing magic about this, really. What should prevent this from happening?
I hope you know about lightweight-sync; it's part of the PowerPC architecture. That's only been around for nearly twenty years. The hot burning feeling is the realization that your obsolescence is measured in decades.
I have never had to work with that particular processor, so I really don't know why I should have read up on it. My criticism was about your codes portability, not whether it would work on some specific platform.
I was hinting at the fact that we are talking of an unnamed system with unnamed processors. It makes it harder to give a qualified answer
Hmmm, let's see. There are exactly two next-generation game consoles in existence. One is symmetric-multiprocessing, the other is asymmetric-multiprocessing. And you're willing to admit, in public, that you're confused by this?
Confused? No. But I refuse to guess.
I guess it's a stroke of luck that you're too dense to understand how humiliated you should feel.
You are still funny. Do you understand how volatile works now?:p
Seriously, I am sorry I exposed your ignorance, I know that rubs some people the wrong way. It is just that what you did is --- in general --- such a grave error I thought a warning was appropriate. I am still not speaking of the specific case --- the Cell architecture is not something I have studied in detail, but my understanding was that the was one power-something processor and several non-ram-sharing co-processors, so I think you luck out in your case. It only applies if two cores that do not share cache (typically because they reside on two different chips) attempts to modify the same, cached data.
But unless that mystery instruction sync's all the processors' caches (and registers, if your compiler decided to put your variable in a register), you will still have these errors.
Mystery instruction? It's well documented.
I was hinting at the fact that we are talking of an unnamed system with unnamed processors. It makes it harder to give a qualified answer
Also, anything you need communicated to other threads needs to be put into what C++ would call a "volatile" variable. You can't expect randomly-architected code to just magically work in a multithreaded context.
Volatile won't help you. Volatile just disables some optimisations, and does not sync the caches in the processors - which I admit your mystery instruction might, though I find it unlikely. Try reading
volatile considered harmful - I know it is for the linux kernel dev, but it does a fair job of explaining the issues at hand. As an extract
[...]one must protect shared data structures against
unwanted concurrent access, which is very much a different task
In short, you almost never want to use volatile, unless you are manipulating memory mapped IO through a pointer or similar strange tasks. The key point is that volatile does *not* sync caches in any way.
At the risk of sounding "uptight", you sound like a very lazy programmer. You don't understand the subject of multithreading, you don't even read what I write, and yet you act as if your opinion has merit.
I'm sure it does. But unless that mystery instruction sync's all the processors' caches (and registers, if your compiler decided to put your variable in a register), you will still have these errors. Of course, if I understood you correctly, and the system in question only had one processor, this is not an issue and atomic operations works just fine.
Threading is always easier on one processor, likewise on one computer unit.
Don't confuse your lack of knowledge with the lack of an answer.
No need to get all uptight, it was not a criticism of you.
And of course, should you program ever run a multi-processor system, it will fail in all sort of subtile, non-predictive way. E.g., in all cases where a variable has been loaded into a register, but likely there are also cases involving caching to some degree.
Slashdot Mirror
Did you boot an install, or just a livecd? I was under the impression that livecds generate a RAMdisk for things like /home and /tmp
I just booted, so that is indeed an interesting observation. I will check that on Monday :)
It's more like 3.5. Note that the hard limit for all 32-bit operating systems is 4GB. Windows manages to lose half a gig somewhere.
Even 64-bit linux looses some RAM when you have 4G installed. And yes, I booted a 64-bit livecd just to test this :)
E.g, I have a machine here with 16 GiB = 16384 MiB RAM, but free reports only 16239.
So it seems there's quite a ways to go in making captchas harder: don't just distort the image; use the craziest fonts you can.
Already, captchas tends to beat me. I don't want them any harder! In fact, I could use that program of theirs....
ok, so I suck at image recognition. Is that some sort of crime these days?
And a rather close one, too. It is amazing people let Apple get away with rebranding KHTML "Webkit", but hey. As long as it makes the world better, and the less code from Apple the better :P
Originally, XFS lacked support for the equivalent to write:ordered in ext3. In practice that meant that while the metadata would be intact, your files (and thereby directories) might be blobs of zeros/gone. That is probably what happened to him, and it is what happened to me when I used it long ago. I think I have read that XFS has gotten this capability later. For the topic, I'd recommend ext3 too. It's proven, can do the online grow/offline shrink that is so handy, has 3 different settings for speed/reliance, and is well supported. But I am not a sysadmin.
Some do manage it. Last game I bought this way was Savage 2 --- awsome game, runs on linux, and with the dollar so low, quite cheap :)
I'm tempted to say you don't know what you're talking about, since using exceptions is one of the worst thing for making all your 'new's actually hit matching delete statements.
If you are using delete, you are most likely doing something wrong. If you are new'ing many objects, you are most likely doing something wrong. Writing exception safe is not hard, and besides, is the same for every sort of language. Remember that it is not just your new/deletes, but (more commonly, too!) you lock()/unlock(), open()/close(), beginTransaction()/endTransaction() and so on that have to balance. If you want to know how much Java people struggle with getting that right, try searching on finally. Or try writing a program that copies one file to another, in C++ and Java :)
I have to point you to the argus codewatch eclipse plugin: http://arguscodewatch.sourceforge.net/
(which is the one I know, there may be more)
Of course, linters help, but really, a decently designed language would not have this problem at all. Object::clone, equals, hash at least are flawed design. Object should only have functions that *any* conceivable class can implement at no cost.The reason while these flaws are there is that Java supports neither mix-in classes nor static polymorphism nor operator overloading.
On the other hand, our team of programmers have had quite a lot of issues, especially when different programmers have different ideas about how to manage memory. I definitely prefer to have garbage collection so as that this particular problem (which can become seriously nasty) is solved. Perhaps a programmer going solo does not have a problem, but for projects in the enterprise, where programmers come and go, it's very serious.
I have worked in the enterprise, with no problems stemming from this. I made a short text and a seminar to get the ball rolling, and that pretty much eliminated that problem. On the other hand, I have been in Java projects where resource management was truly problematic --- I ended up solving that with Javas pitiful excuse for functional support. The syntax sucked, but it worked.
But of course, gc might solve *your* problem, which of course makes it important to you :) Personally, I think it is of little consequence --- gc is the last memory management method I would pick.
Newer and better parsers? I have Visual Studio 2008, and Intellisense still lags a lot behind me. On the other hand, in the Java world, for example, by the time I have finished writing an identifier, the environment already knows what I am talking about and has already pointed out the errors.
KDevelop 4 (alpha) does completion in realtime, including type information etc. I'm told that the on-the-fly error checking will come. And of course parsing is easier in Java, which cannot do as much as C++. My point is that I believe you can retain the power of C++ and still make the parsing a lot easier for tools, but that on the other hands, the tools are getting more powerful and the problem might be solved that way around.
None is a short of an understatement. You can't combine functions in the way ML or Haskell does. You need a lot of boilerplate code and a lot of hacking to get the same results.
I've seen the proposal about lambdas, and I wasn't impressed. There are many redundant declarations, for example you have to declare your enclosed variables twice.
I can't remember the exact details, but I don't recall any redundancy, except that you had to explicit tell which local vars should be available to the function --- something I regard as a good thing.
Try the following code:
As I thought. The library tries to prevent you from making that mistake, but you overrode it with an explicit cast, and the code does something you didn't mean to. We call that error for "error 40" around here... it originated 40cm from the screen.
It does not matter that the shared_ptr constructor is explicit. When you have a precompiled library that accepts shared_ptrs and you want to use 'this', you are basically screwed.
sounds like yo
1. no *optional* (I repeat: optional) garbage collection.
It is on the way, but (apparently like Bjarne, wow!) I find this to be of little matter. I very seldom have memory resource problems.
2. many syntax problems: not context-free grammar (great problem for tools), various semicolons that are reduntant etc.
True, but newer and better parsers are getting there. But I agree that the syntax is the worst bit about C++. KDevelop 4.0 is looking good, though, once they get the memory consumption under control3. no functional programming(no lambdas, etc).
None is a bit rich, but the syntax is very bothersome at best. Lambdas will land in the next standard (as the article also mentions)
4. shared_ptr sucks (just try to pass 'this' to a function that requires a shared ptr and deletes the current object).
.... you will get a compile error?! shared_ptr's one-parameter constructor that takes a pointer is declared explicit. Were you hit by a bad implementation, or a bad compiler perhaps?
5. no consistency: primitives are not classes, although I could program classes that behave as primitives.
I don't quite agree, but I do find the distinction unnecessary and think it should be done away with in any case. So we are more or less in accord here.
6. no import statements; still using old boring header files.
That critique is a bit weak. There are pro's and cons to either approach.
C++ is built on some excellent ideas, it's just the execution of those ideas that sucks. There can be another C++ like language with none of the problems of C++ and all its benefits.
Yeah, I dream about this :) Be sure to shout it from the mountaintops if you make it or find it someday!
Really? I have lost count of the number of errors in Java code I find because someone wrote either something like string_a=="cheese" (which is only the right thing to do in a few cases) or string_a.equals("cheese") (which is also likely to crash). In C++, you get to do string_a=="cheese", and it will also work with any other class. Oh, and it will correctly fail at compile-time if you make a non-sensical comparison. You get all this free from operator overloading.
Then there is the map-like classes, the array-like classes, and as others already have mentioned, all the classes that acts more or less like numbers. In short, almost all C++-programs ends up using operator overloading in a positive way. A programming language that does not provide operator overloading is either a toy (nothing wrong with that), dumped down (likewise) or lacking (worse).
1. it is a joke, you know :) Smile!
2. I would answer the rest, but given that you posted anonymous, you wouldn't get the answer.
I have. They are unreliable, slow, and run either z/OS (which sucks badly) or linux, which turn them into a slow server instead of a horrible slow server.
I still remember one of my pro-mainframe colleagues telling me that "it does 1 million (or whatever) MD5-sums in under a minute!". Same thing ran on my (from about the the same year) old PC on 13s. Then they tell me "but the IO is good. Afterwards, it turns out that one of our applications are performing badly because the executable code is too big. Say what? Then they tell me it is more reliable ... after which a single point of failure (a disk array controller I think it was) floored the system for 6 hours. Weee.
In conclusion, the only thing a mainframe is really good for is as a paper press :)
How about letting me plug in two monitors (possibly with different resolutions) and - with the click of a few checkboxes - configuring them as a primary display and a secondary display so that I can drag windows between them, but new windows and dialogues are sized to fit & centered on the primary display?
Yes, I know X can support multiple monitors (but so far I've always ended up editing xorg,conf to make it happen) - but the options seem to be (a) mirroring, (b) one big desktop so new windows and dialogues straddle both screens or (c) two totally separate desktops which don't let you drag windows across.
For record, without wanting to enter this pissing competition, I am running two monitors with different resolution working like you want (maximizes to one monitor, but windows draggable between) without touching any textfile. The interface was xrandr--- a command line tool, but surely there is agui for it somewhere. If not, it should be trivial to make.
Yeah, I have. Of course, I use the magic -C to ssh, that helps quite a lot. Certainly fast enough to be usable, though I could be better.
That is a hopeless endeavor. It will screw up at least in Danish, where e.g. aa might be sorted first or last, depending on (meaning of) the word. I think we have even seen some court battles over whether Aabenraa (a town) gets to be to be first or late in the telephone book.
Better to sort in a predictabe, semi-correct way
And I am not defending ruby here, as I have not attempted to do i18n in ruby yet.
If you have ever used perl or ruby you would know what I mean, I think. You cannot do things like this in Java myfunc({"key1"=>"value1", "key2"=>"value2"}); where you construct and pass an anonymous hash. You can simulate it, but it quickly gets either cumbersome or brittle.
I'd also love something more explanatory than: 'less-broken this' and 'less-broken that'. Can you be more specific?Of course, I was trying to be brief. The type system is Java is tied to inheritance. That is neither sensible nor desirable, and leads to problems like the .clone(), .equals() and similar methods that either does something non-sensible or fails at runtime, while the compiler was in a perfectly position to determine that at compile time. C++ does a better job in this regard. In ruby, the type system is not tied to inheritance, which is good, but it is on the other hand runtime which is not-so-good. Thus, less-broken.
less-broken syntax is of course somewhat more debatable, but most of those who likes ruby seems to prefer the syntax of ruby. Personally, I like that you avoid the ending } } } } which is so easy to get in Java, and often leads to wasted time. Also, the lack of operator overloading leads to syntax sillyness such as a.times(b.add(c).toThePowerOf(d))) --- which isn't exactly beautiful :)
For example, many people decry the int vs Integer issue, is that what you're talking about? Given that using the natives is completely optional, and you could write huge java projects without ever touching them, except where you need to optimize by using the stack, how is this that big of a problem?I mainly thinking of null not being an object. The other bit is stupid too, and no you cannot avoid it since it is used all over the standard library, but the null is much worse. It means that for two objects a,b of class A, a.equals(b) might well be different from b.equals(a) --- no matter the implementation of A.equals(A a). (since b or a might be null).
How is it worse than Ruby having this ? you can put at the end of a method, but it doesnt really mean anything and not enforced in the runtime. So its an equally optional thing, but its use is pure sugar, and its not actually seen or heard by the runtime at all. I am completely with you there, brotherSorry, I was trying to be terse. No idea what over-arching means, but then, English is not my native tongue. In any case, I apologise, but if you look at my posting history, you will be able to find a lot of post going into this in some detail :) Computer languages is something of a hobby for me, and I dislike them all. I have a simple list of things I want a computer language to do, butno language fulfils that list yet, though C++ and ruby together does, as I recall.
I can't speak for everyone, but ruby's main features over Java is: closures, less-broken type model, less-broken syntax, lists and hashes as firstclass objects, mix-ins and closures. I know I mentioned closures twice, and that was on purpose.
I very likely forgot some important points.
Because only one thread can write to an instance of that structure at a time?
Except this is unlikely to be true. The structure could reside in both CPUs cache, and thus be corrupted. Of course. you would have to be very unlucky on several counts. Otherwise I'd need a real semaphore.Or similar, sure. That is the only way to be sure, the more's the pity. One reason why multi-threaded code is sometimes slower than single-threaded.
It's called a "lock-free design", which is a lot more efficient than requiring an operating-system semaphore. Your multithreaded code must thrash the hell out of the operating system. Have you ever profiled any of it?I prefer to avoid locks, which works fine for me. But I suspect that my code is very different from what you do, so my methods might not work for you :)
General education? To improve the breadth of your knowledge? So that the principles you learn can be applied to other situations? Intellectual cross-training? These things really didn't occur to you?
Learning new things are something I do continually, but obscure processors are quite far down my listYou seem to me to be a perfectly normal computer programmer. Problem is, no one ever got anywhere by being normal.
Looks like your opinion of me has improved somewhat ;) Anyway, I am a mathematician first, programming is just something I do.
Seems unnecessarily idiosyncratic.
I really don't care what it seems to be to you.
Oh really. So if I write to my thread-communication structure through a pointer to volatile memory, do a lightweight sync, then write the flag that tells other threads that the structure is ready for use, then lightweight-sync again, you're telling me that's not valid?
On the condition I gave, no that is not valid. The sync only works on the specific core to provide a barrier to some internal state. But if the memory is cached in two different processors, both will be able to take that "lock" and not discover it.There is nothing magic about this, really. What should prevent this from happening? I hope you know about lightweight-sync; it's part of the PowerPC architecture. That's only been around for nearly twenty years. The hot burning feeling is the realization that your obsolescence is measured in decades.I have never had to work with that particular processor, so I really don't know why I should have read up on it. My criticism was about your codes portability, not whether it would work on some specific platform.
Hmmm, let's see. There are exactly two next-generation game consoles in existence. One is symmetric-multiprocessing, the other is asymmetric-multiprocessing. And you're willing to admit, in public, that you're confused by this?
Confused? No. But I refuse to guess.
I guess it's a stroke of luck that you're too dense to understand how humiliated you should feel.
You are still funny. Do you understand how volatile works now? :p
Seriously, I am sorry I exposed your ignorance, I know that rubs some people the wrong way. It is just that what you did is --- in general --- such a grave error I thought a warning was appropriate. I am still not speaking of the specific case --- the Cell architecture is not something I have studied in detail, but my understanding was that the was one power-something processor and several non-ram-sharing co-processors, so I think you luck out in your case. It only applies if two cores that do not share cache (typically because they reside on two different chips) attempts to modify the same, cached data.
Mystery instruction? It's well documented.
I was hinting at the fact that we are talking of an unnamed system with unnamed processors. It makes it harder to give a qualified answer
Also, anything you need communicated to other threads needs to be put into what C++ would call a "volatile" variable. You can't expect randomly-architected code to just magically work in a multithreaded context.
Volatile won't help you. Volatile just disables some optimisations, and does not sync the caches in the processors - which I admit your mystery instruction might, though I find it unlikely. Try reading volatile considered harmful - I know it is for the linux kernel dev, but it does a fair job of explaining the issues at hand. As an extract
[...]one must protect shared data structures against unwanted concurrent access, which is very much a different taskIn short, you almost never want to use volatile, unless you are manipulating memory mapped IO through a pointer or similar strange tasks. The key point is that volatile does *not* sync caches in any way.
At the risk of sounding "uptight", you sound like a very lazy programmer. You don't understand the subject of multithreading, you don't even read what I write, and yet you act as if your opinion has merit.
lol. You are cute.
I'm sure it does. But unless that mystery instruction sync's all the processors' caches (and registers, if your compiler decided to put your variable in a register), you will still have these errors. Of course, if I understood you correctly, and the system in question only had one processor, this is not an issue and atomic operations works just fine.
Threading is always easier on one processor, likewise on one computer unit.
Don't confuse your lack of knowledge with the lack of an answer.
No need to get all uptight, it was not a criticism of you.
And of course, should you program ever run a multi-processor system, it will fail in all sort of subtile, non-predictive way. E.g., in all cases where a variable has been loaded into a register, but likely there are also cases involving caching to some degree.