Guus started a new section in the OpenGL wikibook about scientific uses!
In a first tutorial, he showcases how to interactively plot a simple mathematic function:
http://en.wikibooks.org/wiki/OpenGL_Programming#The_scientific_arc
The lighting front is also progressing with a new tutorial on ambient
and specular lights:
http://en.wikibooks.org/wiki/GLSL_Programming/GLUT/Specular_HighlightsEnjoy!
There was another question recently on StackOverflow that I had meant to
discuss in a follow-up post here. User deltanovember asked
about slow recursive functions
and used the very classic
Fibonacci number
as an example. To recap, Fibonacci number are defined with two initial
values F(0) = 0 and F(1) = 1; thereafter the Fibonacci number F(n) is defined
as the sum of the two preceding numbers: F(n) = F(n-2) + F(n-1).
This leads to very straightforward implementations using recursion:
Unfortunately, this elegant implementation which remain close to the abtract formulation of the recurrence algorithm performs very poorly in R as there is noticeable overhead in function calls which becomes dominant in a recursion. This lead to the original question on StackOverflow, and the accepted answer uses a trick presented by Pat Burns in his lovely R Inferno: rewrite the solution using a computer science trick called memoization:## R implementation of recursive Fibonacci sequence fibR <- function(n) if (n == 0) return(0) if (n == 1) return(1) return (fibR(n - 1) + fibR(n - 2))
That is a fair answer, and even more was suggested with a link to a terrific analysis calling the Fibonacci recurrence the worst algorithm in the world. That is also fair, but all the basic research into better algorithms exploiting some structure of the problem to advance performance (and of course understanding) is overlooking one crucial part: algorithm analysis is essentially independent of the language. So whatever improvements we obtain by thinking really hard about a problem are then available for other implementations too. So with a tip of the hat to the old Larry Wall quote about Lazyness, Impatience and Hubris, I would like to suggest what I consider a much simpler route to much better performance: recode it in C++ using both Rcpp (for the R/C++ integration) and inline for the on-the-fly compilation, linking and loading of C++ code into R.fibonacci <- local( memo <- c(1, 1, rep(NA, 100)) f <- function(x) if(x == 0) return(0) if(x < 0) return(NA) if(x > length(memo)) stop("'x' too big for implementation") if(!is.na(memo[x])) return(memo[x]) ans <- f(x-2) + f(x-1) memo[x] <<- ans ans )
This single R function call## inline to compile, load and link the C++ code require(inline) ## we need a pure C/C++ function as the generated function ## will have a random identifier at the C++ level preventing ## us from direct recursive calls incltxt <- ' int fibonacci(const int x) if (x == 0) return(0); if (x == 1) return(1); return (fibonacci(x - 1)) + fibonacci(x - 2); ' ## now use the snippet above as well as one argument conversion ## in as well as out to provide Fibonacci numbers via C++ fibRcpp <- cxxfunction(signature(xs="int"), plugin="Rcpp", incl=incltxt, body =' int x = Rcpp::as<int>(xs); return Rcpp::wrap( fibonacci(x) ); ')
cxxfunction() takes the code
embedded in the arguments to the body variable (for the core
function) and the incltxt variable for the helper function we
need to call. This helper function is needed for the recursion as
cxxfunction() will use an randomized internal identifier for the
function called from R preventing us from calling this (unknown) indentifier.
But the rest of the algorithm is simple, and as beautiful as the initial
recurrence. Three lines, three statements, and three cases for F(0), F(1) and
the general case F(n) solved by recursive calls. This also illustrates how
easy it is to get an integer from R to C++ and back: the
as and wrap simply do the right thing
converting to and from the SEXP types used internally by the C
API of R.
A performance comparison of the basic R version fibR, its
byte-compiled variant fibRC and
and the C++ version fibRcpp shown above is very compelling.
We have added a file fibonacci.r to the large and still growing
set of examples included with Rcpp, and we can just
execute that script with Rscript or (as here) r
from the littler package:
So the recursion for the original argument of N=35 takes just over a minute at about 61.5 and 61.9 seconds, respectively, for the R version and its byte-compiled variant (as per the column titled elapsed). So byte-compilation essentially offers no help for the bottleneck of slow function calls. The C++ versions relying on Rcpp which created in a few lines of code and a single call toedd@max:~/svn/rcpp/pkg/Rcpp/inst/examples/Misc$ r fibonacci.r Loading required package: inline Loading required package: methods Loading required package: compiler test replications elapsed relative user.self sys.self 3 fibRcpp(N) 1 0.092 1.0000 0.09 0.00 2 fibRC(N) 1 61.480 668.2609 61.47 0.00 1 fibR(N) 1 61.877 672.5761 61.83 0.02 edd@max:~/svn/rcpp/pkg/Rcpp/inst/examples/Misc$
cxxfunction however takes just 92
milliseconds---or a relative gain of well over six-hundred times.
That provides another nice demonstration of what Rcpp can do. Improved
algorithms for well-understood problems are surely one way to accelerate solutions.
But there are (many ?) times when we do not have the luxury of being able to
think through to a new and improved approach. Or worse, such an approach may
even introduce new errors or inaccurracies if we get it wrong on a first try.
With Rcpp, we are able to the express the problem as written in its original statement: a simple
recursion. The gain relative to a slow R implementation is noteworthy---and
could of course be improved further if we really needed to by relying on
better algorithms like memoization. But for day to day tasks, I gladly take
speedups of (up to) a few hundred times thanks to
Rcpp without having to do hard
algorithmic work.
Before closing, a quick reminder that I will be giving two classes on
Rcpp in a few weeks. These will be in New York on September 24, and San Franciso on October 8, see
this blog post as well as
this page at Revolution Analytics (who are a
co-organiser of the classes) for details and registration information.
I have been a long-time user of
So next time I requested a file to# find /var/cache/approx -size 0 xargs rm
strstr() applied to the respective project (full)
names does not return NULL, up to the the common
objective of building a UNIX-like operating system that grants
fundamental software freedoms to its users. That is why I've been
very pleased when the organizers of GNU Hackers Meeting 2011
(GHM) invited me to attend and speak about Debian and its
relationships with GNU at the event. Slides
of my talk are already available, while a video is being encoded
(it will probably show up on both GHM homepage and IRILL website).
Acknowledging the commonalities of goals on both Debian and GNU
sides, we took the chance of this encounter to review how
each project feel about relationships with the other (my
original inquiries for the Debian community can be found on
debian-project) and to talk it over during a
discussion session scheduled to happen just after my talk.
Yesterday, I've summarized all my notes from GHM 2011 in a
report posted to debian-project. Quoting from
there:
After this experience, it is striking for me how much we have in common with GNU (ideally, culturally, socially, etc.) and at the same time how harsh can our "family battles" become at a times. Let's avoid that the remaining [few] differences get too much in the way [of collaboration], especially when that can be easily avoided.Enjoy!
A commentor on my
previous post asked why I think MySQL is a toy.
I've actually blogged about that a number of times, but when
wanting to point that out, I found that most of those posts point out
just one thing, rather than having one post that enumerates them all. So
let's remedy that, shall we?
There are many things wrong with MySQL, including, but not limited
to:
Now back to Google Summer of Code: Google sponsored 5 talented students who were working
hard on various subjects. As a result we now have a new core developer and various new features
implemented in shogun: Interfaces to new languages like java, c#, ruby, lua
written by Baozeng; A model selection framework written by Heiko Strathman,
many dimension reduction techniques written by Sergey Lisitsyn, Gaussian
Mixture Model estimation written by Alesis Novik and a full-fledged online
learning framework developed by Shashwat Lal Das. All of this work has already been
integrated in the newly released shogun 1.0.0. In case you
want to know more about the students projects continue reading below, but
before going into more detail I would like to summarize my experience with GSoC 2011.
My Experience with Google Summer of Code
We were a first time organization, i.e. taking part for the first time in GSoC.
Having received many many student applications we were very happy to hear that
we at least got 5 very talented students accepted
but still had to reject about
60 students (only 7% acceptance rate!). Doing this was an extremely tough decision for us. Each of us
ended up in scoring students even then we had many ties. So in the end we
raised the bar by requiring contributions even before the actual GSoC started.
This way we already got many improvements like more complete i/o functions,
nicely polished ROC and other evaluation routines, new machine learning
algorithms like gaussian naive bayes and averaged perceptron and many bugfixes.
The quality of the contributions and independence of the student aided us
coming up with the selection of the final five.
I personally played the role of the administrator and (co-)mentor and scheduled
regular (usually) monthly irc meetings with mentors and students. For other org admins or mentors wanting into GSoC here come my lessons learned:
.png)
Cross-Validation Framework
Heiko Strathmann (Mentor: Soeren Sonnenburg)
Nearly every learning machine has parameters which have to be determined manually. Before Heiko started his project one had to manually implement cross-validation using (nested) for-loops. In his highly involved project Heiko extend shogun's core to register parameters and ultimately made cross-validation possible. He implemented different model selection schemes (train,validation,test split, n-fold cross-validation, stratified cross-validation, etc and did create some examples for illustration. Note that various performance measures are available to measure how good'' a model is. The figure below shows the area under the receiver operator characteristic curve as an example.
Interfaces to the Java, C#, Lua and Ruby Programming Languages
Baozeng (Mentor: Mikio Braun and Soeren Sonnenburg)
Boazeng implemented swig-typemaps that enable transfer of objects native to the language one wants to interface to. In his project, he added support for Java, Ruby, C# and Lua. His knowlegde about swig helped us to drastically simplify shogun's typemaps for existing languages like octave and python resolving other corner-case type issues. The addition of these typemaps brings a high-performance and versatile machine learning toolbox to these languages. It should be noted that shogun objects trained in e.g. python can be serialized to disk and then loaded from any other language like say lua or java. We hope this helps users working in multiple-language environments.
Note that the syntax is very similar across all languages used, compare for yourself - various examples for all languages (
python,
octave,
java,
lua,
ruby, and
csharp) are available.
Largescale Learning Framework and Integration of Vowpal Wabbit
Shashwat Lal Das (Mentor: John Langford and Soeren Sonnenburg)
Shashwat introduced support for 'streaming' features into shogun. That is instead of shogun's traditional way of requiring all data to be in memory, features can now be streamed from e.g. disk, enabling the use of massively big data sets. He implemented support for dense and sparse vector based input streams as well as strings and converted existing online learning methods to use this framework. He was particularly careful and even made it possible to emulate streaming from in-memory features. He finally integrated (parts of) vowpal wabbit, which is a very fast large scale online learning algorithm based on SGD.
Expectation Maximization Algorithms for Gaussian Mixture Models
Alesis Novik (Mentor: Vojtech Franc)
The Expectation-Maximization algorithm is well known in the machine learning community. The goal of this project was the robust implementation of the Expectation-Maximization algorithm for Gaussian Mixture Models. Several computational tricks have been applied to address numerical and stability issues, like
Final Remarks
All in all, this year s GSoC has given the SHOGUN project a great push forward and we hope that this will translate into an increased user base and numerous external contributions. Also, we hope that by providing bindings for many languages, we can provide a neutral ground for Machine Learning implementations and that way bring together communities centered around different programming languages. All that s left to say is that given the great experiences from this year, we d be more than happy to participate in GSoC2012.
After many years of successfully dodging doing any serious programming in PHP, I had to get my feet wet with PHP for my RL job: I was requested to develop a simple but non-trivial module for our Institute's Drupal-based webpage.
It basically meant two and a half weeks devoted to head-scratching: I had read the very good John van Dyk's Pro Drupal Development book, and knew it would be an important resource were I to face writing a module or work on a theme beyond the most basic stuff So I checked it out of the library, and started basically writing something similar to my good and trusty Perl code. After all, PHP seems quite similar to Perl, although forcing you to write more for no gain (i.e. requiring an array() declaration whenever you want to store more than one value together) or lacking important and useful constructs (not having a sane way to prepare a SQL statement for multiple executions with different parameters Yes, there are DB access methods that do provide it, but Drupal 6 does not use them).
Anyway, book in hand, I started understanding while implementing (which is way different than just reading the book, right?) Drupal's notions. I cannot say I like them, but it's ahem doable.
Now, I hit a problem twice. I chose to ignore it the first time, as it was a corner case I'd look into later on, but had to devote for hours of my attention later on. When designing the menu (which for Drupal means not only the facility which prepares/displays links to the bits of functionality, but also the access control layer and the action dispatcher a huge yay! for responsability separation!), I had only two access levels: Public and administrator. So, this seemed like a good fit:
$public refused to be publicly visible.
It was not until after a severe amount of head-scratching I came across this jewel in the PHP online manual:
Warning This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE, such as 0 or "". Please read the section on Booleans for more information. Use the === operator for testing the return value of this function.GRAH. Using a sane language for some time had made me forget about the problems of true/false sharing space with other meaningful values. So, yes, checking for inclusion of a value in an array in PHP this way should be compared with class-bound identity (that's what
=== means) to FALSE, or better yet, using a function that exclusively returns a boolean (as in_array()).
Anyway While arrays (which in PHP are any kind of list, be it keyed as a hash or consecutive as a traditional array) are such an usual construct in any language, please do take a look at PHP's array-handling API. Too long. Too complex. Too many corner cases.
I cannot but wonder what keeps PHP as a popular language. It hurts.
I've said it before: I think MySQL is a toy, and I want as little to
do with it as possible.
Unfortunately, since the KDE PIM suite depends on akonadi, which
depends on a database, which was initially implemented against MySQL,
not having MySQL installed on a Debian machine if you want to use the
KDE PIM suite, for the longest time, wasn't even possible. Today it is,
but it requires some manual steps:
sudo apt-get --purge install akonadi-backend-postgresql akonadi-backend-mysql- akonadictl stop rm -rf .config/akonadi rm -rf .local/share/akonadi cat > .config/akonadi/akonadiserverrc <<EOF [%General] Driver=QPSQL [QPSQL] Name=akonadi-wouter Host= Options= StartServer=false EOF createdb akonadi-wouterChange "akonadi-wouter" for a suitable database name. And now it should work. Note that this requires you run PostgreSQL system-wide and create a system-wide database in that server. It should, in theory, be possible to have akonadi run its own private PostgreSQL instance, much like how the MySQL backend does things, but a) I couldn't get that to work, and b) I don't think having each user run their own database server instance is a good idea to start with, so honestly I didn't try very hard. And there, pronto! I now no longer have toy databases on my laptop. Word.
apt-get -t squeeze-backports install sympaFor lenny users For lenny users with a running sympa installation who plan to upgrade to squeeze and use sympa from squeeze-backports, it is recommended to upgrade directly from the version 5.3.4 (lenny's version) to 6.1.4. To do so, you just need to add some apt pinning in /etc/apt/preferences (see below) and then dist-ugprade normally.
Package: sympa Pin: version 6.1.4* Pin-Priority: 500Sympa 6.1.6 is already out and should be uploaded in unstable soon, it should also be backported to squeeze-backports if all goes fine. Special thanks to Gerfried (rhonda) and Alexander (formorer) for their work on Debian Backports.
I recently bought a Simtec Entropy Key.
It's a hardware randomness generator encapsulated as a USB device, the
size of a flash drive. It's good for any host or cluster that uses
a lot of kernel-provided random numbers (
/dev/random), or does things
that cause the kernel to use a lot of random numbers. Opening a lot
of network connections, or generating session keys for public key
encryption. That kind of stuff. If the kernel has too little entropy
available to generate good random numbers, things will stall until it
gets some more.
The ekey gives you real random bits, not just software-produced
pseudo-random numbers. In other words, it's some kind of magic.
I got the device in a DVD box, with a leaflet explaining how to install
stuff, a CD with the software, an envelope with a secret key, and the
actual device itself.
I read the leaflet, which said to install the ekeyd daemon first.
I ignored the CD, since a) my laptop has no optical drive and b) the
software is in Debian stable (squeeze) anyway, so apt-getting it is
easier and faster.
I was utterly disappointed with the software. I didn't have to edit
a single hard disk sector, or do a BIOS upgrade, or anything. Utterly,
totally, boring. I had reserved an afternoon and evening for this,
but I had to find something else to do instead.
After plugging in the device in a spare USB port, I opened the
envelope and ran a command to specify the secret key. The key and
host processors use encryption to make sure nobody can eavesdrop
on the randomness -- that would give them an edge in cracking SSL
and GPG encryption, I guess.
Here's an example of how it works. Before I plug in the device,
the kernel has some, but not too much entropy available:
liw@havelock$ cat /proc/sys/kernel/random/entropy_avail
1053
liw@havelock$ cat /proc/sys/kernel/random/entropy_avail
3968
This is just a quick post to remind myself in the morning, as soon as I've made it I intend to turn my computer off and leave it off until I can re-organize my office.
I've been using mutt for my email for the past few years. Nothing compares to the flexibility of procmail/sieve for organizing server-side mail, and then mutt is ideal for reading them.
With the addition of the mutt-patched sidebar mode you can even go for a few days before realizing you're not in a graphical environment. But one thing I do long for is the ability to execute scripts at various times.
Thus far I've not actually planned what I'd like to do, but as a starting point imagine being able to execute a hook when new mail arrives? Or when you send a message matching a pattern in some fashion?
There are some things out there, such as the various hacks which are designed to abort sending a message if you mention "See attachment" in a message body but fail to add one before sendign the message. These hacks generally abuse the sendmail configuration such that they're extremely ad-hoc and hard to chain/nest.
I've mellowed out over the years and I have no interest in attempting to write a mail-client (though at the same time how hard can it be? Just restrict yourself to using inotify on ~/Maildir and offload delivery to exim and you're almost done? I guess the hard part is the UI, though I do like the mutt + sidebar layout. Write the whole thing in some scripty language?)
I'll re-examine notmuch and gnus over the next week or two, but I suspect both will continue to disappoint in various ways.
Anyway, for the moment I'm just pondering. But threading is an obvious concern. Most current mutt hooks relate to the local folder, or the local message. If I were viewing a message in one directory and a new mail notification fired for a delivery to both ~/Maildir and ~/Maildir/.people.foo I'd need to either serialise them or thread them.
Ponder ponder.
In other news I've been doing more photography recently. Nothing cohesive except for my recent experiment with shooting a "street-girl" outdoors in falling light, but that was an interesting challenge and the results were sufficient to make me want to try shooting outdoors in an organized fashion again. (Some random images have been linked to from my wee twitter page.)
ObFilm: "She doesn't get eaten by the eels at this time " - The Princess Bride
I'm in the middle of setting up new build machines for the armhf
port (see the
wiki for more details). We'll shortly have six machines set up in
the machine room here at ARM in Cambridge:
All of these machines are Freescale i.MX53 Quickstart (aka "loco")
development boards. They include a 1GHz i.MX53 CPU (based around the
ARM Cortex A8, one of the ARMv7-A family). They have 1GB of RAM and
native SATA. They're lovely little machines, measuring just 3 inches
square. To mount them usefully in a machine room, I've mounted each
board with a 320GB notebook hard drive and the necessary cabling onto
a small perspex card as you can see here. Then we can fit 6 such
machines and a normal PC-style ATX PSU into a 3U mini-rack. Well,
it almost fits - the power supply pokes out a little so we'll
need 4U of space when we come to mount it.
The Quickstart boards have been sponsored
by Linaro, and ditto my time
setting up these machines. Thanks!
As is common with new development boards, these machines are
not quite fully supported in Debian yet. The kernels we're
using are locally-built, using the sources supplied by Freescale. For
now, that means a heavily-patched "2.6.35" kernel but we're expecting
to be able to switch to mainline very soon. The .config I'm using
is kernel.config,
and I've built it natively on harris using
fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=1buildd1
Similarly to the setup for
the armel
machines, for now I've tweaked things when installing the
kernel:
/etc/kernel/postinst.d/depmod to do this.
/etc/kernel/postinst.d/initramfs-tools into
place from my amd64 machine; I'm guessing this would be there
automatically on a new-enough version of initramfs-tools on
the armel machines, but we're still using Lenny as a base
system for now even if I'm using a Squeeze-based kernel.
/etc/kernel/postinst.d/zz-flash-kernel) to
create uImage and uInitrd files from the kernel zImage and the
initramfs.
MX53-LOCO U-Boot > setenv loadaddr 0x70800000
MX53-LOCO U-Boot > setenv initrdaddr 0x71000000
MX53-LOCO U-Boot > setenv bootargs_sata set bootargs \$\ bootargs\ root=/dev/sda2 rw rootwait
MX53-LOCO U-Boot > setenv load_sata_kernel ext2load sata 0:1 \$\ loadaddr\ /uImage
MX53-LOCO U-Boot > setenv load_sata_initrd ext2load sata 0:1 \$\ initrdaddr\ /uInitrd
MX53-LOCO U-Boot > setenv load_sata run load_sata_kernel load_sata_initrd
MX53-LOCO U-Boot > setenv bootcmd_sata sata init\; run bootargs_base bootargs_sata load_sata\; bootm \$\ loadaddr\ \$\ initrdaddr\
MX53-LOCO U-Boot > setenv bootcmd run bootcmd_sata
MX53-LOCO U-Boot > setenv bootcmd_rescue sata init\; run bootargs_base bootargs_sata\; mmc read 0 \$\ loadaddr\ 0x800 0x1800\; bootm
I'm not very good with dates. For the last two years now, Joshua's anniversary
has snuck up on me and caught me by surprise.
I don't think that I'd really appreciated until this year that we lost him on
the Labor Day long weekend. I'll have to remember that for next year so I don't
forget.
I don't know what my problem was this year. I just didn't realise that it
was this early in September that we lost him. Last year I was just too
exhausted from dealing with a new baby to realise when his anniversary was,
and I felt terrible for missing it.
This year, I just felt terrible for not realising when it was, but at least
Sarah pointed it out before the fact.
For added irony, the 4th of September this year is Father's Day in Australia.
Yesterday, I was looking at photos of Joshua to remember him, and Gallery
gave me a random photo of Zoe in the corner. That was something. I'm not
sure what.
I feel like Zoe being a wonderful child is some sort of consolation prize
from the universe for taking Joshua, but I often wonder what Joshua would be
like today if he were almost four.
Went to see One
Day yesterday. As I usually do after watching a movie, I next went
to wikipedia to read up more about it.
Was shocked to read that it received 'mostly negative' reviews. I
thought it was pretty good.
After reading a few of the aforementioned reviews, I understand what
the problem is, and though I disagree with the resulting negativity in
the review, I can see where it's coming from.
You see, One Day is a novel-turned-movie. As with most movies that
were sourced from a novel, the movie is a disappointment to those who
read the book, mainly because there's always going to be more material
in the book, and therefore some of your favourite passages from the book
are going to be removed, or changed so that they'll lose some
of their original goodness. This is even true for beyond-feature-length
movies sourced from novels; for instance, when I saw
the horse whisperer
after reading the book, I found it a disappointment too, even if my
brother and sister who saw it at the same time as me did like it.
Ignoring that, there's a second problem; while it's a love story, I
don't think it qualifies as a 'romantic comedy'. For it to be a romantic
comedy, you'd expect 'happily ever after', and you'd expect a story
about two people quickly (or slowly, as the case may be) falling in love
with eachother, overcoming some problems that stand in the way of their
relationship. Most importantly, you'd expect it to be lighthearted and
funny you'd expect it to be a comedy.
One day doesn't deliver that; if you go see it, expecting a romantic
comedy, you'll be sorely disappointed. But if you accept the fact that
it isn't a romantic comedy, it's still a very interesting film. It's not
lighthearted, but that doesn't mean there isn't a laugh or a cry in
there. And, without wanting to spoil the plot, while the movie doesn't
bring 'happily ever after', it does still come up with a believable,
emotional, and very compelling ending.
The plot takes you through the 15th of July in the lives of the two
main characters, every year for two decades. Sometimes they're spending
that day together, sometimes they're not. Sometimes they're calling,
sometimes they're fighting, sometimes they're kissing. The days shown
are snapthots of both their lives; this adds an interesting angle to the
plot, as much of the story, much of what is going on, can't actually be
shown on-screen, since it happened in between the two 15ths of July.
While, as said, I wouldn't describe the movie as a romantic comedy, I
think it can be accurately described as a romantic drama. It's not going
to be a legendary movie, a must-have-seen, one which you'll grow to hate
over watching it on every TV station's prime time over the next few
years. But it's a charming, novel, and interesting piece of drama.
Did I like it? Definitely. When I go to the movies, sometimes I want
a silly movie, some action flick that I can have a bit fun laughing at;
but sometimes I want a movie that touches my heart and makes me reflect
on my own life while feeling for the characters. When I went to see The Expendables, I have
a lot of fun for one night, and then promptly forgot about it. But 'One
Day' rang true with me on an emotional level; and for that alone, I can
recommend it.
Even if that wasn't the reason why I chose to pay 8 for this movie
rather than anything else. I'll be perfectly honest: Anne Hathaway. Good
actress, and sporting the most interesting pair of bright eyes
you've ever seen; what more could one want?
A film that allows these two eyes, and acting talent to
shine, of course. And One Day delivers.
--enable-texture-float to confflags-dri in the Mesa
source package's debian/rules). But some programs really like to have
this extension, thus I started building Mesa myself. The resulting packages can
be found on dev.carbon-project.org.
Big fat warning: please check, whether you're affected by the US
patent #6,650,327 (i.e. if it's a valid patent in your jurisdiction) before
you use the packages. If in doubt, consult with your lawyer.
By the way, if you're not working in an area where knowledge of the specifc
claims/content of the patent might be harmful, you have some time on your hands
and you want to learn, what's "patentworthy" these days, have a look
at the claims of the patent. Otherwise the three links from the beginning must
do.
Before I end this post, just one more remark about my Mesa packages: they'll
follow upstream's Git and thus might have problems from time to time. If
Debian's Mesa packages suffice your needs, stay with them. If not, feel free to
use my packages or use them as a base for your own packages.
Am I online or not?
There is a summary at the end for the quick readers.
It is in many modern applications important to be able to more or less gracefully handle if the application user is online or not. For example, there is no need to try to fetch emails if the device (computer, phone, tablet, laptop, ) doesn t have network (wifi, cable, umts, ip over avian carriers, ..).
KDE has of course made nice functionality for this, and here I will try to describe how to make your app network status aware and what to be aware of in the process.
Solid background
All this is going on in Solid, using two parts of Solid and a bit of KDE s infrastructure:
enum Status
Unknown,
Unconnected,
Disconnecting,
Connecting,
Connected
;
Solid::Networking::Status currentStatus = Solid::Networking::status();
if(currentStatus==Connected currentStatus==Unknown)
//try to do networking things
else
//mark application as offline.
class MyNetworkAwareClass : public QObject
Q_OBJECT
public:
MyNetworkAwareClass();
void doNetworkActivity();
private Q_SLOTS:
void networkStatusChanged(Solid::Networking::Status newstatus);
private:
Solid::Networking::Status m_current_state
;
MyNetworkAwareClass::MyNetworkAwareClass : m_current_state(Solid::Networking::Status())
connect(Solid::Networking::notifier(), SIGNAL(statusChanged(Solid::Networking::Status),this,SLOT(networkStatusChanged(Solid::Networking::Status)));
void MyNetworkAwareClass::networkStatusChanged(Solid::Networking::Status newstate)
m_current_state = newstate;
void MyNetworkAwareClass::doNetworkActivity()
if(m_current_state == Unknown m_current_state == Connected)
//try to do network activity
I guess this should be pretty self explaining.
Summary
Next.