Um, no, I'm talking in terms of ints as immutable objects, not primitive value types.
Think of how you'd implement it *now*, with a wrapper class around int. All "1"'s in the system will be a reference to your immutable "1" object instance, so without help from the compiler you cannot make a "++" method increment the value, because that means changing the object.
You either make them mutable, or you make "++" into another assignment operator.
Obviously it's *possible*, and for Java where it's used so often it's perhaps even a good idea, but that doesn't make it particularly clean, since it just complicates the language for the sake of saving a bit of typing.
No. Not unless you're going to hack it about to make it so.
String s = "hello";
s += " world";
This produces three objects - "hello", " world", and the "hello world" produced by concatinating them. There's no in-place changes going on here.
"hello world" <- "hello".+(" world")
i++ is more equivilent to:
"hello" << " world";
Where the string "hello" is asked to concatinate " world" onto itself; changing "hello" directly. Of course, with immutable strings, you can't do that, unless you're willing to magically turn it into an assignment too.
If you're going to make your int an immutable object, then call 1.++(), 1 has to deal with it itself. How exactly do you make 1 know who's referencing it? Why on earth would you even concider letting it?
About the only way I can think of is a transparent proxy object that will track the return values of these methods, so all the variables pointing to it actually only see the proxy containing an object that changes.
Sure, you *could* just hack it so when the compiler see's i++ it writes i += 1, or i = i.next, but that doesn't mean it's the same thing, and you'll really notice that when you start referencing objects from multiple points and use i++ expecting it to change the object when it really changes the actual object i is pointing to.
Um, is nothing new; it was in HTML 4 and looks much the same.
It's effectively an img/embed tag which can be nested to allow the UA to fall back if it doesn't support something.
The draft's example includes showing the use of embedding an applet - so what? If the UA wants to execute it outside a sandbox, that's no the W3C's problem, just like Java or ActiveX security or Flash's security isn't their problem. If Python applets were ever to appear I'm sure they'd be secured similarly.
Seems like if they're going to make it backwards incompatible,
Not entirely, clients shouldn't need particularly huge modifications to support it. Certainly with Mozilla it's mostly some CSS work.
For example, are nested tables really the best way to lay out a page?
This is what CSS is for.
Go poke around the CSS3 working drafts, and maybe join www-style if you want to discuss it with clueful people.
How about the script and noscript tags?
What about them? <noscript> may be removed in favour or JS/DOM/CSS, but it's unlikely. <script> may be replaced by <link>, but again probably unlikely given that it makes it harder and less reliable to use client side scripting (a good thing? Maybe, but I'd be wary of pushing yet more ways of things going wrong).
Any chance we can stop having to put comments around the script code?
Um, from XHTML 1.0 it's been explicitly stated that you should not do this, since UA's are allowed/expected to strip the comments.
CDATA is the proper way to do this if you must; comment hacks are available if you want to hide from broken clients, but typically you should be using <link> for your stylesheets and <script> for your scripts if they're complex enough to require such hacks. Think of it as a handy code smell;)
How about separating the 2 distinct uses of anchor tags?
What distinct uses? As links and named anchors in a page? We already have that; just apply an id attribute to any element on the page and it should work as if it was an <a name="foo">.
Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and:hover as seen on CSS/Edge
<q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
<a> is still here; no XLink in this draft, despite it being a recommendation.
Forms are now replaced by XForms, also a Working Draft.
No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
CSS 1 is about 6 years old, it's only seriously been usable for the last couple of years. Just because a standard isn't used much or handled properly doesn't mean it won't be eventually, or that the standard is worthless and hence shouldn't have been created.
XHTML is already quite popular, because it provides a path to XML without breaking legacy clients. The top three clients already support parsing XML and rendering closely to the standards when it's served with the right Content-Type.
XHTML 2 is another step towards this, loosing the legacy crap of HTML 4 and fixing problems without worrying about backwards compatibility. Hell, stick to the basics and you can provide for most of the tags for *current* clients with a bit of CSS.
This is only a working draft, anyway. I wouldn't expect it to reach recommendation stage this year. Don't forget, they need two interoperable implimentations of each feature to even be concidered:)
SETI will bring the CPU to the limit. If it's overclocked and/or badly cooled or otherwise unstable, you'll see that quickly.
Better to use a dedicated util for this, like CPUBurn, which will exercise the CPU as much as possible to generate heat and verify everything's still working.
Just because SETI/RC5/etc push CPU usage to 100%, doesn't mean they fully exercise all the various units on the CPU, or even that they'll notice if a bit flips here or there.
The String class is immutable and yet you can still say String a = "Hello"; a = a + " world"
Yes, this is creating a new String object and assigning a to it. It's nothing like changing the string object itself.
a is not the object, a just happens to point at the object.
When you perform operations such as the autoincrement operator on immutable objects, it doesn't frickin change the object, it creates a new object and reassigns the variable to that new one.
How do you do this while making ++ a method on the Numeric object? How do you give it the power to change what a variable name points to? Typically you'd return the next object, but without an assignment there's no place for the return value to go.
You *could* make it magic and mean foo += 1, or make it take the return value and assign it to the lvalue, but it doesn't mean it's a good idea. It's certainly not going to make the language any cleaner or easier to write or understand.
What's wrong with i++? It's just shorthand for "i=i+1"
No, i++ is shorthand for "i.increment()". If you make ints etc immutable you can't do this, because it's like trying to write 1++, hence making all instances of 1 in the system into 2.
It's no great loss imo; I thought I'd miss it in Ruby, but it turns out that i+=1 isn't much more to type and there's a lot to be said for having a nice clean object model.
Of course from a backward compatibility standpoint it would suck somewhat. It'd have to be called Java++ or something;)
I have a Quantum Fireball that had some nasty problems; it would click and sometimes disappear from the system and refuse to come back up for a while.
I noticed it was running very hot, so I put an old Pentium heatsink on top of it and mounted a card cooler blowing into my case (it's open, since airflow in my case really bites). It's been fine since.
It's a good port; it has a proper installer, a native Win32 GUI, and it's fast.
If it's unstable for you, try submitting a bug report; it's been rock solid for me since the early 6.0 beta's.
What build did you get? I've stuck with a perfectly good 6.1 beta, but I've heard of some specific builds being dodgy. ATM it's at about patchlevel 90 past release, and I'm sure Bram and co will be very happy to look into any problems you have. Seriously; it should be solid as a rock even in Windows.
Er, yes, so how do you stop someone compromising root and setting -a? In FreeBSD, with a securelevel, the equivilent of chattr -a would fail with a permission denied even for the superuser.
Setting the right things immutable would result in even you being unable to replace the base system or drop the securelevel without local access.
if you use ext2 or ext3. See chattr(1), options a (append only) and s (secure deletion).
How do you unset them? In FreeBSD the kernel can have a secure level set which can only be raised without rebooting; setting the kernel into a securelevel stops the various immutable/undeletable/etc flags being unset, among other things.
Check security(7) under "SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS".
Re:Now begins the hardest part...
on
Ogg Vorbis 1.0
·
· Score: 2
> Now, if you could get me totally lossless compression of sound, then I'll consider switching...
I always find my eye searching for the ending delimiter at the end of each block of code; this basically means I'm forever having to stop myself from thinking the code is somehow incomplete when I read Python.
I also found Python conciderably more opaque than Ruby, although I strongly suspect that had more to do with the documentation I found on it than anything else.
That most of the examples of Python apps I looked at were pretty messy didn't really help either:)
Unfortunately for Python, Ruby's filled my requirement for a clean dynamic language; I expect my next language to be more along the lines of SmallTalk or Lisp. Python just doesn't look that interesting anymore:)
<eagarly awaits a flood of examples and docs that'll make me change my mind and fall in love with it>
Slashdot Mirror
Hum, doesn't that make it difficult do use standards like CSS which make it conciderably easier to construct accessable websites?
Or does Mozilla/IE5 work on something so old?
Which has turned into the audio player equivilent of Mozilla, for which it competes with in the category of Biggest Resource Hog.
At version 3, it actually uses about twice as much memory as WMP 8 (which I count at about 12MB). Don't really blame AOL though.
Um, no, I'm talking in terms of ints as immutable objects, not primitive value types.
Think of how you'd implement it *now*, with a wrapper class around int. All "1"'s in the system will be a reference to your immutable "1" object instance, so without help from the compiler you cannot make a "++" method increment the value, because that means changing the object.
You either make them mutable, or you make "++" into another assignment operator.
Obviously it's *possible*, and for Java where it's used so often it's perhaps even a good idea, but that doesn't make it particularly clean, since it just complicates the language for the sake of saving a bit of typing.
This produces three objects - "hello", " world", and the "hello world" produced by concatinating them. There's no in-place changes going on here.
"hello world" <- "hello".+(" world")
i++ is more equivilent to:
"hello" << " world";
Where the string "hello" is asked to concatinate " world" onto itself; changing "hello" directly. Of course, with immutable strings, you can't do that, unless you're willing to magically turn it into an assignment too.
If you're going to make your int an immutable object, then call 1.++(), 1 has to deal with it itself. How exactly do you make 1 know who's referencing it? Why on earth would you even concider letting it?
About the only way I can think of is a transparent proxy object that will track the return values of these methods, so all the variables pointing to it actually only see the proxy containing an object that changes.
Sure, you *could* just hack it so when the compiler see's i++ it writes i += 1, or i = i.next, but that doesn't mean it's the same thing, and you'll really notice that when you start referencing objects from multiple points and use i++ expecting it to change the object when it really changes the actual object i is pointing to.
Um, is nothing new; it was in HTML 4 and looks much the same.
It's effectively an img/embed tag which can be nested to allow the UA to fall back if it doesn't support something.
The draft's example includes showing the use of embedding an applet - so what? If the UA wants to execute it outside a sandbox, that's no the W3C's problem, just like Java or ActiveX security or Flash's security isn't their problem. If Python applets were ever to appear I'm sure they'd be secured similarly.
Go poke around the CSS3 working drafts, and maybe join www-style if you want to discuss it with clueful people. What about them? <noscript> may be removed in favour or JS/DOM/CSS, but it's unlikely. <script> may be replaced by <link>, but again probably unlikely given that it makes it harder and less reliable to use client side scripting (a good thing? Maybe, but I'd be wary of pushing yet more ways of things going wrong). Um, from XHTML 1.0 it's been explicitly stated that you should not do this, since UA's are allowed/expected to strip the comments.
CDATA is the proper way to do this if you must; comment hacks are available if you want to hide from broken clients, but typically you should be using <link> for your stylesheets and <script> for your scripts if they're complex enough to require such hacks. Think of it as a handy code smell
- Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and
:hover as seen on CSS/Edge - <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
- New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
- <a> is still here; no XLink in this draft, despite it being a recommendation.
- Forms are now replaced by XForms, also a Working Draft.
- No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
- Frames replaced by XFrames (nothing public yet).
- A few more global attributes, and the use of XML Events for scripting events.
Also, for those interested in such things, the CSS 2.1 Working Draft has been released too.CSS 1 is about 6 years old, it's only seriously been usable for the last couple of years. Just because a standard isn't used much or handled properly doesn't mean it won't be eventually, or that the standard is worthless and hence shouldn't have been created.
:)
XHTML is already quite popular, because it provides a path to XML without breaking legacy clients. The top three clients already support parsing XML and rendering closely to the standards when it's served with the right Content-Type.
XHTML 2 is another step towards this, loosing the legacy crap of HTML 4 and fixing problems without worrying about backwards compatibility. Hell, stick to the basics and you can provide for most of the tags for *current* clients with a bit of CSS.
This is only a working draft, anyway. I wouldn't expect it to reach recommendation stage this year. Don't forget, they need two interoperable implimentations of each feature to even be concidered
Always is a very long time.. you better be able to qualify that statement well
Just because SETI/RC5/etc push CPU usage to 100%, doesn't mean they fully exercise all the various units on the CPU, or even that they'll notice if a bit flips here or there.
a is not the object, a just happens to point at the object. How do you do this while making ++ a method on the Numeric object? How do you give it the power to change what a variable name points to? Typically you'd return the next object, but without an assignment there's no place for the return value to go.
You *could* make it magic and mean foo += 1, or make it take the return value and assign it to the lvalue, but it doesn't mean it's a good idea. It's certainly not going to make the language any cleaner or easier to write or understand.
No, i++ is shorthand for "i.increment()". If you make ints etc immutable you can't do this, because it's like trying to write 1++, hence making all instances of 1 in the system into 2.
It's no great loss imo; I thought I'd miss it in Ruby, but it turns out that i+=1 isn't much more to type and there's a lot to be said for having a nice clean object model.
Of course from a backward compatibility standpoint it would suck somewhat. It'd have to be called Java++ or something
Um, not quite.
:)
Microns are micrometers - 1/1000th of a mm, so transistors on a modern chip are somewhere of the region of 1/10,000th of a mm.
Nanometers are 1/1000th of a micrometer, hence 0.1 micron = 100 nanometer, 1 micron = 1000 nanometer, 0.1mm = 100 micron, 1mm = 1000 micron.
If transistors really were 0.13mm or so your newfangled GF4 or Athlon XP would be a few metres across
/usr/ports/sysutils/pkg_tree
Manpage
Of course, it's not graphical, but it's the same sort of thing.
I have a Quantum Fireball that had some nasty problems; it would click and sometimes disappear from the system and refuse to come back up for a while.
I noticed it was running very hot, so I put an old Pentium heatsink on top of it and mounted a card cooler blowing into my case (it's open, since airflow in my case really bites). It's been fine since.
Aren't the Caviar's all WD's stuff? Although I imagine the distinction will loose importance after a while.
It's a good port; it has a proper installer, a native Win32 GUI, and it's fast.
If it's unstable for you, try submitting a bug report; it's been rock solid for me since the early 6.0 beta's.
What build did you get? I've stuck with a perfectly good 6.1 beta, but I've heard of some specific builds being dodgy. ATM it's at about patchlevel 90 past release, and I'm sure Bram and co will be very happy to look into any problems you have. Seriously; it should be solid as a rock even in Windows.
Versioning of filenames (and other metadata) so you can svn mv something, cheap branching/tagging, binary diffs, and atomic commits.
Er, yes, so how do you stop someone compromising root and setting -a? In FreeBSD, with a securelevel, the equivilent of chattr -a would fail with a permission denied even for the superuser.
Setting the right things immutable would result in even you being unable to replace the base system or drop the securelevel without local access.
Check security(7) under "SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS".
> Now, if you could get me totally lossless compression of sound, then I'll consider switching...
LPAC and FLAC may be worth a look, as may this comparison.
Water wetters tend to also act as an anti-freeze. I'd expect the tubes and so to have a degree of flexibility too.
I always find my eye searching for the ending delimiter at the end of each block of code; this basically means I'm forever having to stop myself from thinking the code is somehow incomplete when I read Python.
:)
:)
I also found Python conciderably more opaque than Ruby, although I strongly suspect that had more to do with the documentation I found on it than anything else.
That most of the examples of Python apps I looked at were pretty messy didn't really help either
Unfortunately for Python, Ruby's filled my requirement for a clean dynamic language; I expect my next language to be more along the lines of SmallTalk or Lisp. Python just doesn't look that interesting anymore
<eagarly awaits a flood of examples and docs that'll make me change my mind and fall in love with it>