Patino made it clear that Ecuador had asked Sweden for a guarantee that it would not extradite him to the US, were such a request made. But Sweden had said no, he said
This argument bears a superficial resemblence to the "Support our TRUUPES!" argument:
"Our men and women in uniform fight to protect our freedoms from dangerous terrorists overseas. If you dont support our men and women in the armed forces, you are selling out our country, and are complicit in the terrorist's cause."
I'm against any abuse of power, but "support our troops" means - even if you don't support the political agenda, you should support and respect the soldiers who have to fight - they don't have a choice. So that makes them potential victims of abuses of the system as well, so from my point of view, it's exactly the opposite of what you're saying.
At least that's what it's supposed to mean - a lot of people misuse that slogan to mean something else....
Not in itself. But if he was seriously trying to be ironic by doing so, then the fact that it was not ironic and in a post requesting correct usage of irony, was itself ironic.
Actually, by intentionally stating the incorrect artist's name in a post intending to correct someone's misuse of the word irony, was itself punny.
Kind of OT, but actually the judges in Texas are anti-corporate if anything, if we're talking about south-east Texas where most of the huge class-action lawsuits get filed (and won).
from my point of view "multi-core" programming is just "SMP" programming - the programmer doesn't care where the cores are distributed on which chips.
there are two interrelated parts to designing languages for SMP scalability in my opinion: designing the programming interface (the syntax - the concept of how the programmer works with the language) and making the right implementation in the compiler or virtual machine to achieve SMP scalability, i.e. maintaining maximum efficiency of usage of each core while providing maximum flexibility in manipulating data.
The first part is more art and the second more technical; both make up the overall language solution.
I've designed the qore programming language for SMP scalability, however using a more traditional approach to threading - as opposed to interesting techniques such as those taken by Erlang or Scala
Basically in qore there are a lot of optimizations aimed at reducing the amount of cache invalidations while still providing as much shared state as possible between threads. It's basically a dynamically-typed language where global variables and objects are shared between all threads and local variables are thread-specific. For such nice and easy-to-use (i.e. thread-safe) access to data it has very good performance, even on single-threaded code (particularly upcoming version in svn trunk which has a completely re-written type system and some massive new optimizations).
While the art of design of the programming language in this case is not as exotic or interesting as scala or erlang, for example, the more traditional approach and the fact that the entire language was designed to be thread-safe and scalable on SMP machines can serve to make it easier for some programmers to write multi-threaded code.
Qore supports deadlock detection and will throw exceptions on outright threading errors as well to make multi-threaded programming a little easier to work with in comparison to some other languages.
Qore supports a pretty unique feature set, in that it's designed to support embedding (and arbitrarily restricting) code, interfacing, and SMP scalability in a dynamically-typed language.
It also supports native XML and JSON de/serialization, powerful and very easy-to-use database drivers (including a DatasourcePool class that offers transparent datasource pooling on a per-thread basis), perl5 regular expressions, and a lot more.
the new version (coming "real soon now":-) ) in svn trunk has a qt4 module (just starting working on the opengl support:-) ) and a documented (with doxygen) and stable API.
well qore ( http://qoretechnologies.com/qore ) was designed for multi-threaded programming, but it does so in a more "classical" way, meaning that it offers easy and safe access to shared data, where global variables are shared between threads and everything else is thread-local more or less. It has thread synchronization primitives, deadlock detection, etc and was designed for interfacing and logic embedding. It also has a strong focus on SMP scalability where a significant amount of time was spent to reduce the amount of cache invalidations (which can cause a big performance hit on SMP machines); so to my knowledge it is unique in this respect - being a dynamically-typed scripting language with such a focus on threading, SMP scalability, and logic embedding.
I describe it as a cross between perl and java, but being small it doesn't have the huge APIs and class libraries that those languages have.
However the new version (still in svn) has a QT module for GUI programming and a documented and stable API and ABI...
It's got some other cool features, like perl5 regex support, easy XML and JSON serialization, HTTP and other socket and socket-based protocol classes, many database drivers and some cool features for transaction management and even transparent per-thread datasource allocation with the DatasourcePool class, and more...
You will be unique. Your friends and colleagues will applaud your taste in esoteric programming languages.
You just might get a great new job out of it too. Somehow it could lead you to winning the lottery. Or even getting that significant other of your dreams. The possibilities are virtually endless...
You make a good point, but I would take it a bit farther than that with regards to race conditions in general.
For example, I designed the Qore programming language (http://qoretechnologies.com/qore/) to provide a powerful and easy-to-use multithreaded development platform (it's a dynamically-typed, interpreted scripting language).
A lot of underlying c++ code is dedicated to safely managing concurrent access to data (and code - meaning safely avoiding race conditions) so that qore programmers have far less to worry about than for example I do writing the qore execution engine.
Additionally there is deadlock detection and (IMO) a really neat approach designed to reduce the number of SMP cache invalidations (on many CPU architectures this means reducing the number/frequency of atomic reference count operations) while guaranteeing a consistent and coherent view of data from each CPU.
I would say managed languages are "easier" to use but to be used effectively you still have to understand the fundamental concepts of multithreaded programming and what's going on underneath the hood of your runtime environment.
Absolutely right, but there's still a lot a higher-level language to do to make managing the development of multithreaded apps easier. It's one of my primary goals for qore, and I believe it's very relevant for the near future of programming language design.
It makes it really easy to manipulate data in XML format.
However, qore supports deserialization of mixed text and data and multiple out-of order elements, XML attributes (imagine parsing a docbook file for example), as well as serialization (conversion of a qore data structure to an XML string) with the same features.
The same limitations regarding streaming input and very large files affect this approach, but in all other common cases, it makes it really remarkably easy to manipulate and create data in XML format using this approach.
(Qore also supports JSON with the same approach -- serialization and deserialization between JSON strings and qore data structures...)
was an interesting article, particularly the part about the hybrid "roadrunner" architecture.
However what is more relevant to today's non-supercomputing needs is SMP scalability.
One of the challenges with SMP scalability is cache coherency; synchronizing the caches on the processors is a costly operation (this is necessary to ensure that each processor has the same view of certain memory at the same time), normally (always?) done with a cache invalidation.
So the more invalidations you do, the more often the processor has to fetch memory from main memory, and the less it's using its cache. Processing slows down dramatically.
I've tried to design the qore programming language http://qore.sourceforge.net/ to be scalable on SMP systems. The new version (released today) has some interesting optimizations that have resulting in a large performance boost on SMP machines - the optimizations involve reducing the number of cache invalidations to the minimum (more than just reducing locking, although that is a part of it too - even an atomic update - for example on intel an assembly lock and increment - involves a cache invalidation and therefore is an expensive operation on SMP platforms). There is more work to be done, but in simple benchmarks of affected code paths the performance increase was between 2 and 3 times as fast with the optimizations on the same qore code.
Anyway it would be interesting to know if other high-level programming languages have also taken the same approach (or will do so); as we go forward, it's clear that SMP scalability will be an important topic for the future...
Slashdot Mirror
this is the most insightful summary of why the US might feel justified in prosecuting Assange that I have seen yet.
no mod points or I'd mod you up.
let's be a little more specific:
Patino made it clear that Ecuador had asked Sweden for a guarantee that it would not extradite him to the US, were such a request made. But Sweden had said no, he said
(from the guardian's live coverage)
This argument bears a superficial resemblence to the "Support our TRUUPES!" argument:
"Our men and women in uniform fight to protect our freedoms from dangerous terrorists overseas. If you dont support our men and women in the armed forces, you are selling out our country, and are complicit in the terrorist's cause."
I'm against any abuse of power, but "support our troops" means - even if you don't support the political agenda, you should support and respect the soldiers who have to fight - they don't have a choice. So that makes them potential victims of abuses of the system as well, so from my point of view, it's exactly the opposite of what you're saying.
At least that's what it's supposed to mean - a lot of people misuse that slogan to mean something else....
slashdot is dead when there are 2 misspellings of Linus' last name in the same thread and nobody corrects it
funny, but no mod points :-)
Not in itself. But if he was seriously trying to be ironic by doing so, then the fact that it was not ironic and in a post requesting correct usage of irony, was itself ironic.
Actually, by intentionally stating the incorrect artist's name in a post intending to correct someone's misuse of the word irony, was itself punny.
good one!
man that was funny
Kind of OT, but actually the judges in Texas are anti-corporate if anything, if we're talking about south-east Texas where most of the huge class-action lawsuits get filed (and won).
no kidding, that's what I got out of it too. some people just can't see the forest for the trees.
It appears that the screenshot was taken from the real Windows XP, and Ylmf OS does not look much like XP, but rather exactly like Gnome.
Here's a screenshot taken from someone who installed the ISO in VMWare and changed the locale to English: http://i50.tinypic.com/2lar9s0.jpg
but there certainly is in American't
5 for osx: you forgot ppc64
Looks like mammatus clouds - something any pilot would instantly recognize (and avoid)
http://en.wikipedia.org/wiki/Mammatus
you mean like columbo? :-)
to see the local time with qore, type:
qore -X 'localtime(1234567890)'
(requires qore 0.7.0 or better) :-)
from my point of view "multi-core" programming is just "SMP" programming - the programmer doesn't care where the cores are distributed on which chips.
:-) ) in svn trunk has a qt4 module (just starting working on the opengl support :-) ) and a documented (with doxygen) and stable API.
there are two interrelated parts to designing languages for SMP scalability in my opinion: designing the programming interface (the syntax - the concept of how the programmer works with the language) and making the right implementation in the compiler or virtual machine to achieve SMP scalability, i.e. maintaining maximum efficiency of usage of each core while providing maximum flexibility in manipulating data.
The first part is more art and the second more technical; both make up the overall language solution.
I've designed the qore programming language for SMP scalability, however using a more traditional approach to threading - as opposed to interesting techniques such as those taken by Erlang or Scala
Basically in qore there are a lot of optimizations aimed at reducing the amount of cache invalidations while still providing as much shared state as possible between threads. It's basically a dynamically-typed language where global variables and objects are shared between all threads and local variables are thread-specific. For such nice and easy-to-use (i.e. thread-safe) access to data it has very good performance, even on single-threaded code (particularly upcoming version in svn trunk which has a completely re-written type system and some massive new optimizations).
While the art of design of the programming language in this case is not as exotic or interesting as scala or erlang, for example, the more traditional approach and the fact that the entire language was designed to be thread-safe and scalable on SMP machines can serve to make it easier for some programmers to write multi-threaded code.
Qore supports deadlock detection and will throw exceptions on outright threading errors as well to make multi-threaded programming a little easier to work with in comparison to some other languages.
Qore supports a pretty unique feature set, in that it's designed to support embedding (and arbitrarily restricting) code, interfacing, and SMP scalability in a dynamically-typed language.
It also supports native XML and JSON de/serialization, powerful and very easy-to-use database drivers (including a DatasourcePool class that offers transparent datasource pooling on a per-thread basis), perl5 regular expressions, and a lot more.
the new version (coming "real soon now"
Anyway, if anyone's interested in checking it out, the homepage is:
http://qoretechnologies.com/qore
and the project is also hosted on sourceforge:
http://sf.net/projects/qore
-David
well qore ( http://qoretechnologies.com/qore ) was designed for multi-threaded programming, but it does so in a more "classical" way, meaning that it offers easy and safe access to shared data, where global variables are shared between threads and everything else is thread-local more or less. It has thread synchronization primitives, deadlock detection, etc and was designed for interfacing and logic embedding. It also has a strong focus on SMP scalability where a significant amount of time was spent to reduce the amount of cache invalidations (which can cause a big performance hit on SMP machines); so to my knowledge it is unique in this respect - being a dynamically-typed scripting language with such a focus on threading, SMP scalability, and logic embedding.
I describe it as a cross between perl and java, but being small it doesn't have the huge APIs and class libraries that those languages have.
However the new version (still in svn) has a QT module for GUI programming and a documented and stable API and ABI...
It's got some other cool features, like perl5 regex support, easy XML and JSON serialization, HTTP and other socket and socket-based protocol classes, many database drivers and some cool features for transaction management and even transparent per-thread datasource allocation with the DatasourcePool class, and more...
check it out if you're interested!
why not be different? Why use a standard, popular language with large function/class libraries and a huge user base? Try qore instead!
http://qoretechnologies.com/qore
You will be unique. Your friends and colleagues will applaud your taste in esoteric programming languages.
You just might get a great new job out of it too. Somehow it could lead you to winning the lottery. Or even getting that significant other of your dreams. The possibilities are virtually endless...
For example, I designed the Qore programming language (http://qoretechnologies.com/qore/) to provide a powerful and easy-to-use multithreaded development platform (it's a dynamically-typed, interpreted scripting language).
A lot of underlying c++ code is dedicated to safely managing concurrent access to data (and code - meaning safely avoiding race conditions) so that qore programmers have far less to worry about than for example I do writing the qore execution engine.
Additionally there is deadlock detection and (IMO) a really neat approach designed to reduce the number of SMP cache invalidations (on many CPU architectures this means reducing the number/frequency of atomic reference count operations) while guaranteeing a consistent and coherent view of data from each CPU.
Absolutely right, but there's still a lot a higher-level language to do to make managing the development of multithreaded apps easier. It's one of my primary goals for qore, and I believe it's very relevant for the near future of programming language design.
that really wasn't very punny.
This is the same approach that is built-in to the qore language http://qore.sourceforge.net/.
It makes it really easy to manipulate data in XML format.
However, qore supports deserialization of mixed text and data and multiple out-of order elements, XML attributes (imagine parsing a docbook file for example), as well as serialization (conversion of a qore data structure to an XML string) with the same features.
The same limitations regarding streaming input and very large files affect this approach, but in all other common cases, it makes it really remarkably easy to manipulate and create data in XML format using this approach.
(Qore also supports JSON with the same approach -- serialization and deserialization between JSON strings and qore data structures...)
thanks,
David
welcome to slashdot :-)
was an interesting article, particularly the part about the hybrid "roadrunner" architecture.
However what is more relevant to today's non-supercomputing needs is SMP scalability.
One of the challenges with SMP scalability is cache coherency; synchronizing the caches on the processors is a costly operation (this is necessary to ensure that each processor has the same view of certain memory at the same time), normally (always?) done with a cache invalidation.
So the more invalidations you do, the more often the processor has to fetch memory from main memory, and the less it's using its cache. Processing slows down dramatically.
I've tried to design the qore programming language http://qore.sourceforge.net/ to be scalable on SMP systems. The new version (released today) has some interesting optimizations that have resulting in a large performance boost on SMP machines - the optimizations involve reducing the number of cache invalidations to the minimum (more than just reducing locking, although that is a part of it too - even an atomic update - for example on intel an assembly lock and increment - involves a cache invalidation and therefore is an expensive operation on SMP platforms). There is more work to be done, but in simple benchmarks of affected code paths the performance increase was between 2 and 3 times as fast with the optimizations on the same qore code.
Anyway it would be interesting to know if other high-level programming languages have also taken the same approach (or will do so); as we go forward, it's clear that SMP scalability will be an important topic for the future...
If the tectonic plates of the Earth spelt out "Made by God", then that would be pretty damning evidence.
That could have been just a coincidence.