It's a British colony in the middle of Europe: the last residue of the British Empire. Spain and GB are in negotiations about making it a shared territory.
See http://www.gibraltar.gi/history/ for the locals point of view.
The single one that has impressed me more is Thomas Young's one, in which he demonstrated that light is a wave.
It reasonable simple, and very visual on the results. You set up the stuff, and voi-la! one of the majors results on the history of physics, lays in front of you, right now.
It is a striking proof of how deep results of physics can show simple, observable effects.
Before seeing it, i didn't believe a single word of "modern" (20-century) phsyics. It change it all, at least for me. (This one, and seeing an electric microscope work)
For an explanation of how to reproduce it, go to
here It's a nice experiment for a High School pyshics class...
>And, IIRC, you can still use this with a normal >TV, you just won't get that great of resolution. >I'm not sure how it would work with say a 1080i >HDTV
No, the article says it simply won't work unless you have a computer monitor.
Re:I still don't see...
on
Perl6 for Mortals
·
· Score: 2, Informative
>All the things you say about Perl 6 I can say
>about Python but now rather than tomorrow
Well, that's not true. The MT support in Python is rather limited, and python's Garbage Collector is like perl5's one.
On the other hand, I am was not comparing perl to python, but perl5 to perl6. So yes, many of this thing were in python or ruby. This means to me that perl was lagging behind in some areas, and so it did need this rewrite.
I like python. I like perl too. And i will like perl6 more than perl5.
>What is it with Parrot? Why can't we stick
>to the JVM?
Oh, Parrot and JVM are rather different. Stack-based vs Register-based. Designed for static languages vs designed for Scripting languages. They are totally different in the inners, and parrot is (will be) much more suited to scripting languages.
There will be probably a JVM port of Perl though. And there is people developing tools for translating Java bytecode to Parrot bytecode and the reverse.
Re:I still don't see...
on
Perl6 for Mortals
·
· Score: 5, Insightful
Well. Here are some:
* True OO. This the killer one. Everything will be an object. Core functions will return objects. And you will have a decent (and probably extraordinary) syntax for creating classes. This is something that perl5 lacked, and it was killing slowly perl.
* Unicode support. Perl didn't have Unicode support, and adding it to perl5 was making everybody crazy. Not having unicode support is something too bad to bear in the age of XML and Unicode-supporting databases.
* A GC system that sucks less.
* Real multi-thread support. Perl didn't play well with MT, even worse than python (which forces you to have a global lock for everything). Perl6, on the other hand, will have MT support build from the start, and it will be as good as it can get.
* A general clean-up of the syntax, which will surely pay off on the long-term.
* A complete change on the inners. Perl will run on top of Parrot, which is a general-purpose register-based VM for scripting languages. There is the real possibility that in the mid-term languages like python, ruby, and probably many other will target Parrot, and thus getting all the benefits (true GC, real MT, and many others) of Parrot without having to duplicate all the effort.
This will also give the ability to call Perl modules from Python or Ruby objects from any other Parrot language. Considering the good response that MS.NET has get, I would say that people will love this feature. Or think of having a single mod_perl-like Apache module that can efficiently run Perl, Python, Ruby, Php, without needing a separte scripting engine for each one.
Perl 6 is important. Please don't let the little details you may don't like make you forget about the fact, that Perl definitetly needed a rewrite, and that it can be a very good thing for the OS community as a whole, not just for Perl hackers.
Slashdot Mirror
It is very obvious, but the same guys that develop ResierFS offer support for this kind of problems.
Go to Namesys.com, and purchase support there. Maybe they can help you.
There is a new regulation comming in Europe that is going to do exactly this: allowing you to buy any car brand in any dealer. -angel
I had been not following the development of 5.8, so It's been a bit of shocking to see the impresssing range of changes.
It looks that the two major issues that had been hampering perl (threads and unicode) have now improved a lot. And the PerlIO api is great.
I've downloaded it and I am testing it already. Big Kudos and thanks for the hard work.
Gibraltar is not an island.
It's a British colony in the middle of Europe: the last residue of the British Empire. Spain and GB are in negotiations about making it a shared territory.
See http://www.gibraltar.gi/history/ for the locals point of view.
It reasonable simple, and very visual on the results. You set up the stuff, and voi-la! one of the majors results on the history of physics, lays in front of you, right now.
It is a striking proof of how deep results of physics can show simple, observable effects.
Before seeing it, i didn't believe a single word of "modern" (20-century) phsyics. It change it all, at least for me. (This one, and seeing an electric microscope work)
For an explanation of how to reproduce it, go to here It's a nice experiment for a High School pyshics class...
Well, here is a good reason for kvim: network transparency (i.e. ioslaves)
I spend most of my time editing remote files: with vim, I have to download them using FTP, edit them, and upload them.
With kwrite (kde's simple editor), i can just open them remotely, edit and save them, and they will be downloaded and uploaded automagically.
This is a significant speed bonus (if you do this all day), so i use kwrite, even if I like much more vim.
Yes, i could mount a NFS, but the remote system is windoze, and FTP is the only thing I can hope.
So I have been waiting for a long time for kvim, and now I am __very__ happy that it's here.
And of course, using the vim editor in kdevelop is going to make it a much more useful toy.
>And, IIRC, you can still use this with a normal >TV, you just won't get that great of resolution. >I'm not sure how it would work with say a 1080i >HDTV No, the article says it simply won't work unless you have a computer monitor.
>All the things you say about Perl 6 I can say
>about Python but now rather than tomorrow
Well, that's not true. The MT support in Python is rather limited, and python's Garbage Collector is like perl5's one.
On the other hand, I am was not comparing perl to python, but perl5 to perl6. So yes, many of this thing were in python or ruby. This means to me that perl was lagging behind in some areas, and so it did need this rewrite.
I like python. I like perl too. And i will like perl6 more than perl5.
>What is it with Parrot? Why can't we stick
>to the JVM?
Oh, Parrot and JVM are rather different. Stack-based vs Register-based. Designed for static languages vs designed for Scripting languages. They are totally different in the inners, and parrot is (will be) much more suited to scripting languages.
There will be probably a JVM port of Perl though. And there is people developing tools for translating Java bytecode to Parrot bytecode and the reverse.
Well. Here are some:
.NET has get, I would say that people will love this feature. Or think of having a single mod_perl-like Apache module that can efficiently run Perl, Python, Ruby, Php, without needing a separte scripting engine for each one.
* True OO. This the killer one. Everything will be an object. Core functions will return objects. And you will have a decent (and probably extraordinary) syntax for creating classes. This is something that perl5 lacked, and it was killing slowly perl.
* Unicode support. Perl didn't have Unicode support, and adding it to perl5 was making everybody crazy. Not having unicode support is something too bad to bear in the age of XML and Unicode-supporting databases.
* A GC system that sucks less.
* Real multi-thread support. Perl didn't play well with MT, even worse than python (which forces you to have a global lock for everything). Perl6, on the other hand, will have MT support build from the start, and it will be as good as it can get.
* A general clean-up of the syntax, which will surely pay off on the long-term.
* A complete change on the inners. Perl will run on top of Parrot, which is a general-purpose register-based VM for scripting languages. There is the real possibility that in the mid-term languages like python, ruby, and probably many other will target Parrot, and thus getting all the benefits (true GC, real MT, and many others) of Parrot without having to duplicate all the effort.
This will also give the ability to call Perl modules from Python or Ruby objects from any other Parrot language. Considering the good response that MS
Perl 6 is important. Please don't let the little details you may don't like make you forget about the fact, that Perl definitetly needed a rewrite, and that it can be a very good thing for the OS community as a whole, not just for Perl hackers.