i always thought that an active-desktop-esque window manager for linux would be cool, as it would allow users to write applications in HTML, Flash, or anything, and have them in the "Start" Menu, or as part of the desktop.
it turns out ironically that google's "chrome os" is pretty much exactly that, and the Palm Pre is already well on its way to being a "web" os, too.
thus we ironically come full circle, as the startling implications of ideas that microsoft creates over fifteen years ago eventually filter through the security nightmares and negative public perceptions of the windows OS....
read "Lord of Light" by Roger Zelazny. it illustrates not only that advanced tech is "magic" but the dangers of portraying onesself as a "God" as a result of access to such advanced tech.
gcc is an incredibly good test application. it's horrendously cpu-intensive, and it is designed to eat whatever physical memory is available. compiling c++ applications is particularly memory-intensive, but the best test of both disk and memory has to be simply to compile the linux kernel.
if you have multiple cores, you can use "make -j {number of cores + 1}" and this will test all of the CPUs, as well. if you particularly want to stress things, make that "make -j {number of cores * 2}" instead.
I've done a significant amount of PC construction and reconstruction: approximately 60 from-scratch builds in 20 years. One thing that that has taught me is: do not bother to try to diagnose motherboard or CPU faults: just replace them, end of story.
Even Integrated Motherboards can be had for £40, and CPUs for £25. You can get dual-core 1.6ghz Atom Integrated-everything-including-CPU motherboards for £90.
For the amount of time and effort spent unscrewing components and testing combinations that may, if there is some I.C. damage, result in EXTRA damage to other components, the risk and the time is *just* not worth it.
There is, however, short-circuit protection in Hard Drive channels (there is now: there used not to be!), USB devices, PCI cards etc. so the risk associated with these components of them causing further damage, if they themselves are damaged, is much lower (but still possible).
Additionally, short-circuit protection in the PSU is also present and helps mitigate the risk of further damage.
Basically: if you find that a machine is acting up, do an Internet Search for that model: there may be a firmware upgrade that fixes the problem. I once bought eight identical machines (£125 each) and they all had EXACTLY the same memory / unreliability fault. eighteen months later i found the firmware upgrade that changed the timings to workaround the problem.
Other than that: if you cannot find any evidence of firmware upgrades to potentially fix an unreliable machine - throw out the power supply, the motherboard and the CPU, without hesitation (or get them replaced under warranty). Simple as that.
*possibly* keep the memory, but bear in mind that when you upgrade the CPU and the motherboard, you will likely need a different kind of memory, and that memory is likely to be incredibly cheap, anyway.
Peripherals and cards: you should be okay (but test them one at a time).
Ultimately it's about risk management, and the level of integration is simply too high to take any risks. Throw the components out, and get new ones.
I've read it must be over 500 sci-fi books, and own over 300, so there is a long list that I'm aware of, to choose from.
The absolute first book to be read by a class, without a shadow of doubt, is "Last and First Men", by Olaf Stapledon. The reason is simple: this book covers from the 1930s when it was written, and from there each chapter jumps ten times further into the future than the previous one, spanning, eventually, four billion years into the future. Pretty much all other science fiction is, therefore, merely "filling in the gaps". The incredible thing about Olaf Stapledon's book is his startling prescience and ability to accurately predict World History up into the 21st Century, including the fall of the League of Nations and the rise and fall of its replacement, the United Nations; the creation and detonation of the Atomic Bomb; the rise and fall of the United States. This latter should cause much hilarity when, if the "Sci Fi Masterworks" version is put in front of the class, in the context of reading Stephen Baxter's foreword, where Mr Baxter (a sci-fi author to be avoided at all costs), basically splutters his polite indignation at Stapledon's "obvious mistake".
The second book must be Asimov's "The End of Eternity". It is again one of the defining books of Asimov's career, dealing with the consequences of Time Travel and hinting at the background behind the "Foundation" series. One of the key things to note in the book is the use of the word "Computer" as a title, like "Professor". Very few people now remember that the word "Computer" was originally given to "one who performs computation". Computer Harkan, the lead character of the book, is the person given the unbelievably responsible job of "computing" the "minimal necessary change" to a historical timeline that will result in the desired changes to the future _without_ causing other drastic side-effects. Eventually, Computer Harkan meets some of future humanity who explain things to him... I won't say more - it's a fascinating book, and quite short.
The third book I'd put on the list would be: "Lord of Light", by Roger Zelazny. In this book, a reasonable and perfectly plausible explanation is given as to how the old "Indian Gods and Legends" were considered to "perform magic", whereas in fact, just like Arthur C Clarke said famously, "any superior technology is indistinguishable from magic".
Other than that, I'd say that it was about authors.
Asimov. Asimov's Foundation series is very hard going, as are pretty much all of his books except those about "Robby the Robot", which, coauthored with his wife, are really quite fun. Also, the "detective series" novels are absolutely fascinating, but very dry, take getting used to. If there's one at all that has to be read, I would recommend the one where Isaac Bailey, a human, is called for to investigate a murder on the world Solaria, where the total number of humans (extended lifespans) is something like a million (50,000 acres is a small estate); the number of robots per human measures 1,000 to 1; the concept of "seeing" someone involves 3D Trimensional viewing (holograms), and it's part-way through the book that we discover that Solarians are utterly reviled by the concept of physical human contact. Later on we discover that the whole murder has been a setup (by a robot! despite the 3 laws!) in order to determine which of the species of humans is most suitable for robots to encourage to expand out into the galaxy. As a result, this book is again one of THE defining books behind the "Foundation" series (which is itself pretty dry and heavy reading).
Moving on from that, the books commissioned by the Asimov Trust are much more readable, such as the "Caliban" series, and "Forward the Foundation" which is in fact by Greg Bear. I very much actually enjoyed the books about the "No Law" robot, Caliban. Caliban was an experiment to see if a robot would develop its own laws, if it was given a brain on which the infamous "Three Laws" were NOT imprinted. The exper
Re:Crossbrowser libraries just perpetuate the prob
on
Learning Ext JS
·
· Score: 2, Insightful
Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.
the existence of dynamic framework compilers such as Google Web Toolkit and Pyjamas makes it perfectly possible to accommodate "multiple broken browsers".
in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.
this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.
this "trick" is actually something that even the developers can take advantage of. see browserdetect for the absolute most basic example (source code 2 levels below).
Please now can we update the wikipedia RIA page?
on
Learning Ext JS
·
· Score: 3, Interesting
One of the editors of the RIA wikipedia page keeps reverting any changes made which make reference to the fact that, overwhelming evidence to the contrary, extensive use of javascript does actually qualify as creating applications that are "Rich".
it would be very helpful if someone (other than myself) could review the discussion, add references to this book, citing it as an example of how javascript can, if utilised correctly, result in "Rich Media Applications".
the story is that i got into HTML/CSS Hell trying to do a cross-browser "centre" layout, vertically and horizontally. after two weeks and only 150 words on the page, i still wasn't done. pyjamas 0.3 i achieved what i wanted in under 40 minutes, learning pyjamas from scratch.
now i do all my web development in pyjamas, and flatly refuse to do HTML-based server-side web sites.
Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine.
It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.
thanks for posting this - it's interesting to see peoples' insights.
i'm aware of the unladen/swallow effort: they're replacing the FORTH-based bytecode engine with LLVM JIT compilation.
on their roadmap is "unboxing" of the http://python.org/ c code types (Object/longobject.c, Object/intobject.c, Object/stringobject.c etc.)
basically the plan is (i believe!) to provide reimplementations of intobject.c's __add__, __mul__ etc. to call LLVM routines instead of straight c code. in this way, they intend to keep python "c code" module interoperability, as long as you replace the libpython2.6.so with an unladen/swallow one.
_as long as_ the speed was still there, i would like, at some point to do the same trick - but with Google V8 javascript engine, instead (and, for fits and giggles, throw in spidermonkey as an option as well). basically, the implementation of intobject.c's __int__ would have a pointer to a javascript object, in which there would be an __int__ function; a call in python from a standard python c-based module to create an int would result in the creation of a javascript object representing the integer, and the intobject.c code would simply "look after it". in this way, you would have interoperability between python that was converted to javascript, and python c-based modules.
the thing is: the performance of the pyjamas LoopTest was a bit lower than i was expecting, so i double-checked things, especially that the original experiment showed conversion of python to javascript executed under V8 having a whopping 10x performance increase (over standard python).
pyv8run running the fibonacci algorithm, it's confirmed: when you set -O (optimisation mode in pyjamas) we have a 2.5x performance INCREASE over standard python, WITHOUT having made any special effort or analysed what is going on and without having profiled things to find out if it can be done any better.
also confirmed: when you switch on "--strict", the object-accessing test comes down to 10% the performance of python, which is truly dreadful, but hey, it's "safe", what do you expect?:)
also confirmed: a simple object-accessing test is 50% (HALF) the performance of python - again, with no investigation as to why that is.
yes - paul bonser's pybrowser is the beginnings of an implementation of a web browser in python. he uses python-cairo and pygame for the graphics and the event handling. a combination of flier liu's PyV8 or python-spidermonkey would bring javascript execution to this effort, completing the loop.
also i just accidentally encountered this which is confusingly also called pybrowser: it uses python-gtkhtml2 (which is considered deprecated since this project named pybrowser was written, in 2005).
[script type="text/python"][/script]. Let one of the major browsers implement it, and see if the others follow... there's probably already DOM-access libraries in Python, yes?
Seems to make a hell of a lot more sense than this translation stuff.
there's two main ways in which this can be achieved:
1) pyxpcomext
2) appcelerator / titanium, with IronPython, via Silverlight/Moonlight.
the problem is - one that both skulpt and pyjamas avoid - you need browser plugins, in each case, to achieve the goal. the pyxpcomext plugin is a whopping TEN MEGABYTES because it literally contains the entire python runtime.
i know you're joking, but there really _is_ a Visual Studio "universal translator" plugin available - i've seen it demo'd, converting c++ to java, to B, to ruby, to c#. it all used CLR as the intermediary. i heard that activestate were commissioned to add python to the mix, but, weirdly, it wasn't included in the release of the translator i saw.
What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years).
yes - it's these DOM interfaces that i used for the pure-python port of pyjamas. the first one (webkit) i literally had to create, myself (it took 8 weeks). the second one, xulrunner, used a component created by the OLPC team, called hulahop; the third one, for windows only, uses python COM (the comtypes library) and python ctypes.
But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.
From TFA: """ anyway, just thought there might be people who would be intrigued (or horrified enough to care what's being done in the name of computer science) by either of these projects. """
Not horrified, but I wonder if W3C politics is creating unforeseen consequences.
it has to be said that the attitude of the webkit developers (one in particular who can be easily identified) has been incredibly bad, towards the free software glib/gobject bindings i created for webkit's DOM model. nobody should have to put up with the kind of disrespectful treatment i was subjected to, and other contributors whom i've encouraged and trained to help out have been so intimidated by the webkit developers that they are unwilling to even make themselves known to the webkit team, in case they get treated the same way.
it's a long story, and the webkit team will get burned for it, one way or another.
there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.
Have you tried using a separate add() like method in which you can check for Array, int etc?
yes, that's in the --strict option. pyjamas actually comprises _two_ compilers, strictly speaking: one is "fast but more like javascript"; the other is "slower but more like python".
Or does that hurt performance too much?
i was surprised to find that it doesn't. (not as much as say creating an anonymous function on-the-fly in order to provide the full and correct semantics of getattr on class member functions)
that's exactly why i posted links to the GWTCanvas and the GChart demos, as they show that it is in fact possible to do "graphics" using DOM manipulation. also, with WebGL coming in HTML5 to both webkit and firefox, it will be a simple matter of having a framework that creates the relevant DOM elements.
voila - instant control over 3D graphics code (written in c), from python or javascript.
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
i'm working on it. last week i back-ported skulpt's parser and AST code from javascript to python, and regression-tested it; now it's a matter of improving the pyjamas compiler to be able to successfully compile that python into javascript, and we're bootstrapped.
Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.
nope. it's not. and i didn't mention in the article that pyjamas-desktop can run the python as a desktop app, either. including the GWT Canvas ported code, under the MSHTML engine. after all, the IE/MSHTML gwtcanvas is just creating VML nodes, so perhaps it shouldn't come as a surprise that it works, but it's still pretty cool all the same.
There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
wrong. sorry. javascript is a drastically underestimated language. dreadful to work with if you don't know what you're doing, but incredibly powerful at the same time.
a javascript implementation of "type" - not the 1-arg version but the full 3-arg version - was initially implemented in 85 lines of javascript (it's a bit more, now).
we use that functionality to dynamically create, classes, supporting multiple inheritance and more.
pyjamas has also implemented decorators _and_ properties; kees is currently working on "yield" after skulpt's developers started working on it. not "yield by cheating and using FF built-in support for yield", but "yield" as in doing it the hard way, by analysing the state of the function and adjusting / jumping to the correct point in the function on each loop.
Python itself already has a hard and slow slog trying to perform all its tricks.
To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.
slower, yes - "hopelessly" inexact: no. for GUI purposes, _if_ you've designed the application correctly (i.e. along MVC / client-server lines), then the "-O" option which switches off all the python "strict" compatibility, is perfectly sufficient.
so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".
Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.
wrong again. sorry. two reasons. three.
1) pygtkweb showed that it is perfectly possible to make a seamless / transparent JSONRPC service that ships function call arguments over to a server, for execution server-side, starting from e.g. "import md5"
2) pyjamas' implementations of datetime, md5, urllib, time and a few others is growing as users contribute to them. thus, the pyjamas GUI library fits the *users* needs, on an ongoing basis.
3) if you _really_ can't do without the full semantics of python, but want the benefits of full HTML, CSS, NPAPI plugins etc., use one of the pyjamas-desktop ports. there's MSHTML, XULRunner and PyWebkitGTK to choose from.
you're looking for RubyJS. sadly, funding has not been forthcoming in order to carry RubyJS forward. the compiler is excellent; the insights into the technical issues behind dynamic language translation were very useful (even to python translator developers) - but martin ran out of time/money/enthusiasm due to the lack of interest shown, so he only got as far as creating HTML and Button for RWT (Ruby Web Toolkit).
i spoke to someone studying engineering in 1990 who was being taught fortran. they were using a mathematical library that would solve partial differential equations, by presenting the user with the actual mathematical formulae to them.
these kinds of libraries are staggeringly complex to write, and they have been empirically proven over decades of use to actually work.
to start again from scratch with such libraries would require man-centuries or possibly man-millenia of development effort to reproduce and debug, regardless of the programming language.
so it doesn't matter what people in the slashdot community think: for engineers to use anything but these tried-and-tested engineering libraries, that happen to be written in fortran, would just be genuinely stupid of them.
* install two network cards (two wireless, one wired one wireless, whatever)
* connect one of them to the university network
* connect your personal computer(s) to the other
* bridge the two together
* install a VPN on a system out on the Internet (you can rent XEN Virtual Machines from e.g. bluelinux.co.uk for £15 per month)
* install a VPN client on your personal computer
* set up an HTTP Proxy and whatever other proxies you want in the system "out there"
* configure your personal machine(s) to use the proxies.
all that the university will see is some encrypted traffic.
if they get arsey about this, tell them that you demand extra credits on a research project involving computer privacy, for ingenuity and initiative.
if you want to wind them up, tell them that you're doing research into reactions of universities when students take initiative to enforce their right to privacy. get out a notebook whilst saying this and write down any responses made...
unfortunately, that would entail agreeing that it is a proprietary protocol, when in fact it is a bodged use of industry-standard crypto primitives (Diffie-Hellmann, HMACsha256 and RC4) to give the clients who buy FMS3 the illusion of security.
the lack of man-in-the-middle attack protection, the use of magic constants and the reliance on information that is publicly accessible all make it really difficult to accept the word "proprietary".
unless you redefine the word "proprietary" to be synonymous with "shit". then it aaalll makes sense.
i've done an analysis (and updated the document). RTMPE is nothing more than a way to link content with the original SWF file (by way of its hash and its size), and an SSL-like end-to-end secrecy algorithm.
i've updated the RTMPE.txt document, after doing some analysis this morning. there are two aspects to it: one is an end-to-end secrecy algorithm that is similar to SSL; the other aspect links the size and a hash of the original SWF file (through which the content is supposed to be streamed) into the handshake process.
there are no passwords used. there is no security. there is no authentication.
conclusion: RTMPE is definitely not a copyright protection mechanism. all the information needed to obtain the content is publicly available.
Slashdot Mirror
i always thought that an active-desktop-esque window manager for linux would be cool, as it would allow users to write applications in HTML, Flash, or anything, and have them in the "Start" Menu, or as part of the desktop.
it turns out ironically that google's "chrome os" is pretty much exactly that, and the Palm Pre is already well on its way to being a "web" os, too.
thus we ironically come full circle, as the startling implications of ideas that microsoft creates over fifteen years ago eventually filter through the security nightmares and negative public perceptions of the windows OS....
read "Lord of Light" by Roger Zelazny. it illustrates not only that advanced tech is "magic" but the dangers of portraying onesself as a "God" as a result of access to such advanced tech.
gcc is an incredibly good test application. it's horrendously cpu-intensive, and it is designed to eat whatever physical memory is available. compiling c++ applications is particularly memory-intensive, but the best test of both disk and memory has to be simply to compile the linux kernel.
if you have multiple cores, you can use "make -j {number of cores + 1}" and this will test all of the CPUs, as well. if you particularly want to stress things, make that "make -j {number of cores * 2}" instead.
I've done a significant amount of PC construction and reconstruction: approximately 60 from-scratch builds in 20 years. One thing that that has taught me is: do not bother to try to diagnose motherboard or CPU faults: just replace them, end of story.
Even Integrated Motherboards can be had for £40, and CPUs for £25. You can get dual-core 1.6ghz Atom Integrated-everything-including-CPU motherboards for £90.
For the amount of time and effort spent unscrewing components and testing combinations that may, if there is some I.C. damage, result in EXTRA damage to other components, the risk and the time is *just* not worth it.
There is, however, short-circuit protection in Hard Drive channels (there is now: there used not to be!), USB devices, PCI cards etc. so the risk associated with these components of them causing further damage, if they themselves are damaged, is much lower (but still possible).
Additionally, short-circuit protection in the PSU is also present and helps mitigate the risk of further damage.
Basically: if you find that a machine is acting up, do an Internet Search for that model: there may be a firmware upgrade that fixes the problem. I once bought eight identical machines (£125 each) and they all had EXACTLY the same memory / unreliability fault. eighteen months later i found the firmware upgrade that changed the timings to workaround the problem.
Other than that: if you cannot find any evidence of firmware upgrades to potentially fix an unreliable machine - throw out the power supply, the motherboard and the CPU, without hesitation (or get them replaced under warranty). Simple as that.
*possibly* keep the memory, but bear in mind that when you upgrade the CPU and the motherboard, you will likely need a different kind of memory, and that memory is likely to be incredibly cheap, anyway.
Peripherals and cards: you should be okay (but test them one at a time).
Ultimately it's about risk management, and the level of integration is simply too high to take any risks. Throw the components out, and get new ones.
I've read it must be over 500 sci-fi books, and own over 300, so there is a long list that I'm aware of, to choose from.
The absolute first book to be read by a class, without a shadow of doubt, is "Last and First Men", by Olaf Stapledon. The reason is simple: this book covers from the 1930s when it was written, and from there each chapter jumps ten times further into the future than the previous one, spanning, eventually, four billion years into the future. Pretty much all other science fiction is, therefore, merely "filling in the gaps". The incredible thing about Olaf Stapledon's book is his startling prescience and ability to accurately predict World History up into the 21st Century, including the fall of the League of Nations and the rise and fall of its replacement, the United Nations; the creation and detonation of the Atomic Bomb; the rise and fall of the United States. This latter should cause much hilarity when, if the "Sci Fi Masterworks" version is put in front of the class, in the context of reading Stephen Baxter's foreword, where Mr Baxter (a sci-fi author to be avoided at all costs), basically splutters his polite indignation at Stapledon's "obvious mistake".
The second book must be Asimov's "The End of Eternity". It is again one of the defining books of Asimov's career, dealing with the consequences of Time Travel and hinting at the background behind the "Foundation" series. One of the key things to note in the book is the use of the word "Computer" as a title, like "Professor". Very few people now remember that the word "Computer" was originally given to "one who performs computation". Computer Harkan, the lead character of the book, is the person given the unbelievably responsible job of "computing" the "minimal necessary change" to a historical timeline that will result in the desired changes to the future _without_ causing other drastic side-effects. Eventually, Computer Harkan meets some of future humanity who explain things to him... I won't say more - it's a fascinating book, and quite short.
The third book I'd put on the list would be: "Lord of Light", by Roger Zelazny. In this book, a reasonable and perfectly plausible explanation is given as to how the old "Indian Gods and Legends" were considered to "perform magic", whereas in fact, just like Arthur C Clarke said famously, "any superior technology is indistinguishable from magic".
Other than that, I'd say that it was about authors.
Asimov. Asimov's Foundation series is very hard going, as are pretty much all of his books except those about "Robby the Robot", which, coauthored with his wife, are really quite fun. Also, the "detective series" novels are absolutely fascinating, but very dry, take getting used to. If there's one at all that has to be read, I would recommend the one where Isaac Bailey, a human, is called for to investigate a murder on the world Solaria, where the total number of humans (extended lifespans) is something like a million (50,000 acres is a small estate); the number of robots per human measures 1,000 to 1; the concept of "seeing" someone involves 3D Trimensional viewing (holograms), and it's part-way through the book that we discover that Solarians are utterly reviled by the concept of physical human contact. Later on we discover that the whole murder has been a setup (by a robot! despite the 3 laws!) in order to determine which of the species of humans is most suitable for robots to encourage to expand out into the galaxy. As a result, this book is again one of THE defining books behind the "Foundation" series (which is itself pretty dry and heavy reading).
Moving on from that, the books commissioned by the Asimov Trust are much more readable, such as the "Caliban" series, and "Forward the Foundation" which is in fact by Greg Bear. I very much actually enjoyed the books about the "No Law" robot, Caliban. Caliban was an experiment to see if a robot would develop its own laws, if it was given a brain on which the infamous "Three Laws" were NOT imprinted. The exper
Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.
the existence of dynamic framework compilers such as Google Web Toolkit and Pyjamas makes it perfectly possible to accommodate "multiple broken browsers".
in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.
this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.
this "trick" is actually something that even the developers can take advantage of. see browserdetect for the absolute most basic example (source code 2 levels below).
One of the editors of the RIA wikipedia page keeps reverting any changes made which make reference to the fact that, overwhelming evidence to the contrary, extensive use of javascript does actually qualify as creating applications that are "Rich".
it would be very helpful if someone (other than myself) could review the discussion, add references to this book, citing it as an example of how javascript can, if utilised correctly, result in "Rich Media Applications".
the story is that i got into HTML/CSS Hell trying to do a cross-browser "centre" layout, vertically and horizontally. after two weeks and only 150 words on the page, i still wasn't done. pyjamas 0.3 i achieved what i wanted in under 40 minutes, learning pyjamas from scratch.
now i do all my web development in pyjamas, and flatly refuse to do HTML-based server-side web sites.
give me pyjamas plus JSONRPC or give me death :)
Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine.
It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.
thanks for posting this - it's interesting to see peoples' insights.
i'm aware of the unladen/swallow effort: they're replacing the FORTH-based bytecode engine with LLVM JIT compilation.
on their roadmap is "unboxing" of the http://python.org/ c code types (Object/longobject.c, Object/intobject.c, Object/stringobject.c etc.)
basically the plan is (i believe!) to provide reimplementations of intobject.c's __add__, __mul__ etc. to call LLVM routines instead of straight c code. in this way, they intend to keep python "c code" module interoperability, as long as you replace the libpython2.6.so with an unladen/swallow one.
_as long as_ the speed was still there, i would like, at some point to do the same trick - but with Google V8 javascript engine, instead (and, for fits and giggles, throw in spidermonkey as an option as well). basically, the implementation of intobject.c's __int__ would have a pointer to a javascript object, in which there would be an __int__ function; a call in python from a standard python c-based module to create an int would result in the creation of a javascript object representing the integer, and the intobject.c code would simply "look after it". in this way, you would have interoperability between python that was converted to javascript, and python c-based modules.
the thing is: the performance of the pyjamas LoopTest was a bit lower than i was expecting, so i double-checked things, especially that the original experiment showed conversion of python to javascript executed under V8 having a whopping 10x performance increase (over standard python).
pyv8run running the fibonacci algorithm, it's confirmed: when you set -O (optimisation mode in pyjamas) we have a 2.5x performance INCREASE over standard python, WITHOUT having made any special effort or analysed what is going on and without having profiled things to find out if it can be done any better.
also confirmed: when you switch on "--strict", the object-accessing test comes down to 10% the performance of python, which is truly dreadful, but hey, it's "safe", what do you expect? :)
also confirmed: a simple object-accessing test is 50% (HALF) the performance of python - again, with no investigation as to why that is.
yes - paul bonser's pybrowser is the beginnings of an implementation of a web browser in python. he uses python-cairo and pygame for the graphics and the event handling. a combination of flier liu's PyV8 or python-spidermonkey would bring javascript execution to this effort, completing the loop.
also i just accidentally encountered this which is confusingly also called pybrowser: it uses python-gtkhtml2 (which is considered deprecated since this project named pybrowser was written, in 2005).
[script type="text/python"][/script]. Let one of the major browsers implement it, and see if the others follow... there's probably already DOM-access libraries in Python, yes?
Seems to make a hell of a lot more sense than this translation stuff.
there's two main ways in which this can be achieved:
1) pyxpcomext
2) appcelerator / titanium, with IronPython, via Silverlight/Moonlight.
the problem is - one that both skulpt and pyjamas avoid - you need browser plugins, in each case, to achieve the goal. the pyxpcomext plugin is a whopping TEN MEGABYTES because it literally contains the entire python runtime.
i know you're joking, but there really _is_ a Visual Studio "universal translator" plugin available - i've seen it demo'd, converting c++ to java, to B, to ruby, to c#. it all used CLR as the intermediary. i heard that activestate were commissioned to add python to the mix, but, weirdly, it wasn't included in the release of the translator i saw.
What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years).
yes - it's these DOM interfaces that i used for the pure-python port of pyjamas. the first one (webkit) i literally had to create, myself (it took 8 weeks). the second one, xulrunner, used a component created by the OLPC team, called hulahop; the third one, for windows only, uses python COM (the comtypes library) and python ctypes.
But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.
From TFA: """
anyway, just thought there might be people who would be intrigued (or
horrified enough to care what's being done in the name of computer
science) by either of these projects.
"""
Not horrified, but I wonder if W3C politics is creating unforeseen consequences.
it has to be said that the attitude of the webkit developers (one in particular who can be easily identified) has been incredibly bad, towards the free software glib/gobject bindings i created for webkit's DOM model. nobody should have to put up with the kind of disrespectful treatment i was subjected to, and other contributors whom i've encouraged and trained to help out have been so intimidated by the webkit developers that they are unwilling to even make themselves known to the webkit team, in case they get treated the same way.
it's a long story, and the webkit team will get burned for it, one way or another.
there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.
Have you tried using a separate add() like method in which you can check for Array, int etc?
yes, that's in the --strict option. pyjamas actually comprises _two_ compilers, strictly speaking: one is "fast but more like javascript"; the other is "slower but more like python".
Or does that hurt performance too much?
i was surprised to find that it doesn't. (not as much as say creating an anonymous function on-the-fly in order to provide the full and correct semantics of getattr on class member functions)
that's exactly why i posted links to the GWTCanvas and the GChart demos, as they show that it is in fact possible to do "graphics" using DOM manipulation. also, with WebGL coming in HTML5 to both webkit and firefox, it will be a simple matter of having a framework that creates the relevant DOM elements.
voila - instant control over 3D graphics code (written in c), from python or javascript.
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
i'm working on it. last week i back-ported skulpt's parser and AST code from javascript to python, and regression-tested it; now it's a matter of improving the pyjamas compiler to be able to successfully compile that python into javascript, and we're bootstrapped.
Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.
nope. it's not. and i didn't mention in the article that pyjamas-desktop can run the python as a desktop app, either. including the GWT Canvas ported code, under the MSHTML engine. after all, the IE/MSHTML gwtcanvas is just creating VML nodes, so perhaps it shouldn't come as a surprise that it works, but it's still pretty cool all the same.
There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
wrong. sorry. javascript is a drastically underestimated language. dreadful to work with if you don't know what you're doing, but incredibly powerful at the same time.
a javascript implementation of "type" - not the 1-arg version but the full 3-arg version - was initially implemented in 85 lines of javascript (it's a bit more, now).
we use that functionality to dynamically create, classes, supporting multiple inheritance and more.
pyjamas has also implemented decorators _and_ properties; kees is currently working on "yield" after skulpt's developers started working on it. not "yield by cheating and using FF built-in support for yield", but "yield" as in doing it the hard way, by analysing the state of the function and adjusting / jumping to the correct point in the function on each loop.
you really should take a look at the regression tests
Python itself already has a hard and slow slog trying to perform all its tricks.
To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.
slower, yes - "hopelessly" inexact: no. for GUI purposes, _if_ you've designed the application correctly (i.e. along MVC / client-server lines), then the "-O" option which switches off all the python "strict" compatibility, is perfectly sufficient.
so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".
Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.
wrong again. sorry. two reasons. three.
1) pygtkweb showed that it is perfectly possible to make a seamless / transparent JSONRPC service that ships function call arguments over to a server, for execution server-side, starting from e.g. "import md5"
2) pyjamas' implementations of datetime, md5, urllib, time and a few others is growing as users contribute to them. thus, the pyjamas GUI library fits the *users* needs, on an ongoing basis.
3) if you _really_ can't do without the full semantics of python, but want the benefits of full HTML, CSS, NPAPI plugins etc., use one of the pyjamas-desktop ports. there's MSHTML, XULRunner and PyWebkitGTK to choose from.
you're looking for RubyJS. sadly, funding has not been forthcoming in order to carry RubyJS forward. the compiler is excellent; the insights into the technical issues behind dynamic language translation were very useful (even to python translator developers) - but martin ran out of time/money/enthusiasm due to the lack of interest shown, so he only got as far as creating HTML and Button for RWT (Ruby Web Toolkit).
i spoke to someone studying engineering in 1990 who was being taught fortran. they were using a mathematical library that would solve partial differential equations, by presenting the user with the actual mathematical formulae to them.
these kinds of libraries are staggeringly complex to write, and they have been empirically proven over decades of use to actually work.
to start again from scratch with such libraries would require man-centuries or possibly man-millenia of development effort to reproduce and debug, regardless of the programming language.
so it doesn't matter what people in the slashdot community think: for engineers to use anything but these tried-and-tested engineering libraries, that happen to be written in fortran, would just be genuinely stupid of them.
hooray! this comes at just the right time for coolruc p2p video broadcasting to make headway without legal threats.
try this:
* install two network cards (two wireless, one wired one wireless, whatever)
* connect one of them to the university network
* connect your personal computer(s) to the other
* bridge the two together
* install a VPN on a system out on the Internet (you can rent XEN Virtual Machines from e.g. bluelinux.co.uk for £15 per month)
* install a VPN client on your personal computer
* set up an HTTP Proxy and whatever other proxies you want in the system "out there"
* configure your personal machine(s) to use the proxies.
all that the university will see is some encrypted traffic.
if they get arsey about this, tell them that you demand extra credits on a research project involving computer privacy, for ingenuity and initiative.
if you want to wind them up, tell them that you're doing research into reactions of universities when students take initiative to enforce their right to privacy. get out a notebook whilst saying this and write down any responses made...
unfortunately, that would entail agreeing that it is a proprietary protocol, when in fact it is a bodged use of industry-standard crypto primitives (Diffie-Hellmann, HMACsha256 and RC4) to give the clients who buy FMS3 the illusion of security.
the lack of man-in-the-middle attack protection, the use of magic constants and the reliance on information that is publicly accessible all make it really difficult to accept the word "proprietary".
unless you redefine the word "proprietary" to be synonymous with "shit". then it aaalll makes sense.
i've done an analysis (and updated the document). RTMPE is nothing more than a way to link content with the original SWF file (by way of its hash and its size), and an SSL-like end-to-end secrecy algorithm.
i've updated the RTMPE.txt document, after doing some analysis this morning. there are two aspects to it: one is an end-to-end secrecy algorithm that is similar to SSL; the other aspect links the size and a hash of the original SWF file (through which the content is supposed to be streamed) into the handshake process.
there are no passwords used. there is no security. there is no authentication.
conclusion: RTMPE is definitely not a copyright protection mechanism. all the information needed to obtain the content is publicly available.