Feed aggregator

Richard Hartmann: KDE battery monitor

Planet Debian - Sun, 25/01/2015 - 22:11

Dear lazyweb,

using a ThinkPad X1 Carbon with Debian unstable and KDE 4.14.2, I have not had battery warnings for a few weeks, now.

The battery status can be read out via acpi -V as well as via the KDE widget. Hibernation via systemctl hibernate works as well.

What does not work is the warning when my battery is low, or automagic hibernation when shutting the lid or when the battery level is critical.

From what I gather, something in the communication between upower and KDE broke down, but I can't find what it is. I have also been told that Cinnamon is affected as well, so this seems to be a more general problem

Sadly, me and anyone else who's affected has been unable to fix this.

So, dear lazyweb, please help.

In loosely related news, this old status is still valid. UMTS is stable-ish now but even though I saved the SIM's PIN, KDE always displays a "SIM PIN unlock request" prompt after booting or hibernating. Once I enter that PIN, systemd tells me that a system policy prevents the change and wants my user password. If anyone knows how to get rid of that, I would also appreciate any pointers.

Categories: Elsewhere

Chris Lamb: Recent Redis hacking

Planet Debian - Sun, 25/01/2015 - 21:52

I've done a bunch of hacking on the Redis key/value database server recently:

  • Lua-based maxmemory eviction scripts. (#2319)

    (This changeset was sponsored by an anonymous client.)

    Redis typically stores the entire data set in memory, using the operating system's virtual memory facilities if required. However, one can use Redis more like a cache or ring buffer by enabling a "maxmemory policy" where a RAM limit is set and then data is evicted when required based on a predefined algorithm.

    This change enables entirely custom control over exactly what data to remove from RAM when this maxmemory limit is reached. This is an advantage over the existing policies of, say, removing entire keys based on the existing TTL, Least Recently Used (LRU) or random eviction strategies as it permits bespoke behaviours based on application-specific requirements, crucially without maintaining a private fork of Redis.

    As an example behaviour of what is possible with this change, to remove the lowest ranked member of an arbitrary sorted set, you could load the following eviction policy script:

    local bestkey = nil local bestval = 0 for s = 1, 5 do local key = redis.call("RANDOMKEY") local type_ = redis.call("TYPE", key) if type_.ok == "zset" then local tail = redis.call("ZRANGE", key, "0", "0", "WITHSCORES") local val = tonumber(tail[2]) if not bestkey or val < bestval then bestkey = key bestval = val end end end if not bestkey then -- We couldn't find anything to remove, so return an error return false end redis.call("ZREMRANGEBYRANK", bestkey, "0", "0") return true
  • TCP_FASTOPEN support. (#2307)

    The aim of TCP_FASTOPEN is to eliminate one roundtrip from a TCP conversation by allowing data to be included as part of the SYN segment that initiates the connection. (More info.)

  • Support infinitely repeating commands in redis-cli. (#2297)

  • Add --failfast option to testsuite runner. (#2290)

  • Add a -q (quiet) argument to redis-cli. (#2305)

  • Making some Redis Sentinel defaults a little saner. (#2292)

I also made the following changes to the Debian packaging:

  • Add run-parts(8) directories to be executed at various points in the daemon's lifecycle. (e427f8)

    This is especially useful for loading Lua scripts as they are not persisted across restarts.

  • Split out Redis Sentinel into its own package. (#775414, 39f642)

    This makes it possible to run Sentinel sanely on Debian systems without bespoke scripts, etc.

  • Ensure /etc/init.d/redis-server start idempotency with --oknodo (60b7dd)

    Idempotency in initscripts is especially important given the rise of configuration managment systems.

  • Uploaded 3.0.0 RC2 to Debian experimental. (37ac55)

  • Re-enabled the testsuite. (7b9ed1)

Categories: Elsewhere

Dirk Eddelbuettel: RcppArmadillo 0.4.600.4.0

Planet Debian - Sun, 25/01/2015 - 21:19

Conrad put up a maintenance release 4.600.4 of Armadillo a few days ago. As in the past, we tested this with number of pre-releases and test builds against the now over one hundred CRAN dependents of our RcppArmadillo package. The tests passed fine as usual, and results are as always in the rcpp-logs repository.

Changes are summarized below based on the NEWS.Rd file.

Changes in RcppArmadillo version 0.4.600.4.0 (2015-01-23)
  • Upgraded to Armadillo release Version 4.600.4 (still "Off The Reservation")

    • Speedups in the transpose operation

    • Small bug fixes

Courtesy of CRANberries, there is also a diffstat report for the most recent release. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Jonathan Dowland: Frontier: First Encounters

Planet Debian - Sun, 25/01/2015 - 14:18

Cobra mk. 3

Four years ago, whilst looking for something unrelated, I stumbled across Tom Morton's port of "Frontier: Elite II" for the Atari to i386/OpenGL. This took me right back to playing Frontier on my Amiga in the mid-nineties. I spent a bit of time replaying Frontier and its sequel, First Encounters, for which there exists an interesting family of community-written game engines based on a reverse-engineering of the original DOS release.

I made some scrappy notes about engines, patches etc. at the time, which are on my frontier page.

With the recent release of Elite: Dangerous, I thought I'd pick up where I left in 2010 and see if I could get the Thargoid ship. I'm nowhere near yet, but I've spent some time trying to maximize income during the game's initial Soholian Fever period. My record in a JJFFE-derived engine (and winning the Wiccan Ware race during the same period) is currently £727,800. Can you do better?

Categories: Elsewhere

Drupal Association News: Drupal.org team week notes #31: 2014 in review

Planet Drupal - Sun, 25/01/2015 - 13:24

Now that we are few weeks into 2015, we’d like to look back at 2014 and share some interesting numbers about Drupal.org.

Audience

Last year Drupal.org received almost 48.9 million visits from 21.2 million unique visitors. The spike around September/October is due to spam-related traffic, and, of course, DrupalCon Amsterdam.

Users

152,200 users logged in to Drupal.org at least once during the year. Out of those, 31,466 users performed at least one activity on the site, such as commented, created a node or committed code.

More than 21,500 people left a comment or more in the issue queues. More than 4,000 people commented in the Drupal core issue queue.

Commits

Overall 145,907 commits happened on Drupal.org, with more than 4,000 commits to Drupal core specifically.

More than 3,200 people committed code to contributed projects (not counting Drupal core), with an average of 37.43 commits per user.

More than 1,400 people got commit mention in Drupal core patches.

Comments & Issues

Our users left 569,217 comments, 94% of them were comments in the issue queues. 30% of all comments in the issue queues happened in Drupal core queue.

On average there were 22.4 comments per user, with 38.74 comments per user in the Drupal core issue queue.

Our users created 78,505 issues, with an average of 4.55 issues per user.

5,192 contributed projects were created on Drupal.org in 2014. 31% of those are sandbox projects.

Infrastructure

On the infrastructure side our uptime was 99.97% over 12 months, and the average full page load time for the year is 3.64 across Drupal.org. It improved throughout the year; we are down to 3.08 as an average for December. Our time to first byte response was 1,374ms in January; we are down to 441ms for December.


Drupal.org testbots tested over 33,300 patches. An average test queue and test duration times for Drupal 8 core were about 35 minutes each.

Support

On support front 82% of issues in Drupal.org-related issue queues got a response within 48 hours after being created.

An average response time (time between an issue was created and first comment not by issue author) across all issue queues on Drupal.org was 82.87 hours. For Drupal core issue queue this number was 60.68 hours. For Drupal.org related queues 34.19 hours.

* * *

Full stats you can find in the 2014 stats spreadsheet.

Compared to 2013 some of the user activity numbers go down, which is directly related to the phase of the Drupal release cycle. Right after Drupal 7 release user activity peaked and then was slowly going down as Drupal 7 and contrib ecosystem matured. We are looking forward to Drupal 8 release! In the recent Drupal Association community survey about 80% of respondents said they have firm plans to adopt Drupal 8, suggesting that release will cause a huge boost in user activity on Drupal.org.

2014 was a great year, and thank you for spending some part of it on Drupal.org! We are excited to see what 2015 will bring.

Categories: Elsewhere

Wellnet Blog: Building Bridges - Webprofiler meets Drupal Console

Planet Drupal - Sun, 25/01/2015 - 10:50

The has the purpose to bring the Symfony Profiler to Drupal 8.

Categories: Elsewhere

Joey Hess: making propellor safer with GADTs and type families

Planet Debian - Sun, 25/01/2015 - 04:54

Since July, I have been aware of an ugly problem with propellor. Certain propellor configurations could have a bug. I've tried to solve the problem at least a half-dozen times without success; it's eaten several weekends.

Today I finally managed to fix propellor so it's impossible to write code that has the bug, bending the Haskell type checker to my will with the power of GADTs and type-level functions.

the bug

Code with the bug looked innocuous enough. Something like this:

foo :: Property foo = property "foo" $ unlessM (liftIO $ doesFileExist "/etc/foo") $ do bar <- liftIO $ readFile "/etc/foo.template" ensureProperty $ setupFoo bar

The problem comes about because some properties in propellor have Info associated with them. This is used by propellor to introspect over the properties of a host, and do things like set up DNS, or decrypt private data used by the property.

At the same time, it's useful to let a Property internally decide to run some other Property. In the example above, that's the ensureProperty line, and the setupFoo Property is run only sometimes, and is passed data that is read from the filesystem.

This makes it very hard, indeed probably impossible for Propellor to look inside the monad, realize that setupFoo is being used, and add its Info to the host.

Probably, setupFoo doesn't have Info associated with it -- most properties do not. But, it's hard to tell, when writing such a Property if it's safe to use ensureProperty. And worse, setupFoo could later be changed to have Info.

Now, in most languages, once this problem was noticed, the solution would probably be to make ensureProperty notice when it's called on a Property that has Info, and print a warning message. That's Good Enough in a sense.

But it also really stinks as a solution. It means that building propellor isn't good enough to know you have a working system; you have to let it run on each host, and watch out for warnings. Ugh, no!

the solution

This screams for GADTs. (Well, it did once I learned how what GADTs are and what they can do.)

With GADTs, Property NoInfo and Property HasInfo can be separate data types. Most functions will work on either type (Property i) but ensureProperty can be limited to only accept a Property NoInfo.

data Property i where IProperty :: Desc -> ... -> Info -> Property HasInfo SProperty :: Desc -> ... -> Property NoInfo data HasInfo data NoInfo ensureProperty :: Property NoInfo -> Propellor Result

Then the type checker can detect the bug, and refuse to compile it.

Yay!

Except ...

Property combinators

There are a lot of Property combinators in propellor. These combine two or more properties in various ways. The most basic one is requires, which only runs the first Property after the second one has successfully been met.

So, what's it's type when used with GADT Property?

requires :: Property i1 -> Property i2 -> Property ???

It seemed I needed some kind of type class, to vary the return type.

class Combine x y r where requires :: x -> y -> r

Now I was able to write 4 instances of Combines, for each combination of 2 Properties with HasInfo or NoInfo.

It type checked. But, type inference was busted. A simple expression like "foo requires bar" blew up:

No instance for (Requires (Property HasInfo) (Property HasInfo) r0) arising from a use of `requires' The type variable `r0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance Requires (Property HasInfo) (Property HasInfo) (Property HasInfo) -- Defined at Propellor/Types.hs:167:10

To avoid that, it needed "(foo requires bar) :: Property HasInfo" -- I didn't want the user to need to write that.

I got stuck here for an long time, well over a month.

type level programming

Finally today I realized that I could fix this with a little type-level programming.

class Combine x y where requires :: x -> y -> CombinedType x y

Here CombinedType is a type-level function, that calculates the type that should be used for a combination of types x and y. This turns out to be really easy to do, once you get your head around type level functions.

type family CInfo x y type instance CInfo HasInfo HasInfo = HasInfo type instance CInfo HasInfo NoInfo = HasInfo type instance CInfo NoInfo HasInfo = HasInfo type instance CInfo NoInfo NoInfo = NoInfo type family CombinedType x y type instance CombinedType (Property x) (Property y) = Property (CInfo x y)

And, with that change, type inference worked again! \o/

(Bonus: I added some more intances of CombinedType for combining things like RevertableProperties, so propellor's property combinators got more powerful too.)

Then I just had to make a massive pass over all of Propellor, fixing the types of each Property to be Property NoInfo or Property HasInfo. I frequently picked the wrong one, but the type checker was able to detect and tell me when I did.

A few of the type signatures got slightly complicated, to provide the type checker with sufficient proof to do its thing...

before :: (IsProp x, Combines y x, IsProp (CombinedType y x)) => x -> y -> CombinedType y x before x y = (y `requires` x) `describe` (propertyDesc x) onChange :: (Combines (Property x) (Property y)) => Property x => Property y => CombinedType (Property x) (Property y) onChange = -- 6 lines of code omitted fallback :: (Combines (Property p1) (Property p2)) => Property p1 -> Property p2 -> Property (CInfo p1 p2) fallback = -- 4 lines of code omitted

.. This mostly happened in property combinators, which is an acceptable tradeoff, when you consider that the type checker is now being used to prove that propellor can't have this bug.

Mostly, things went just fine. The only other annoying thing was that some things use a [Property], and since a haskell list can only contain a single type, while Property Info and Property NoInfo are two different types, that needed to be dealt with. Happily, I was able to extend propellor's existing (&) and (!) operators to work in this situation, so a list can be constructed of properties of several different types:

propertyList "foos" $ props & foo & foobar ! oldfoo conclusion

The resulting 4000 lines of changes will be in the next release of propellor. Just as soon as I test that it always generates the same Info as before, and perhaps works when I run it. (eep)

These uses of GADTs and type families are not new; this is merely the first time I used them. It's another Haskell leveling up for me.

Anytime you can identify a class of bugs that can impact a complicated code base, and rework the code base to completely avoid that class of bugs, is a time to celebrate!

Categories: Elsewhere

Daniel Pocock: Get your Github issues as an iCalendar feed

Planet Debian - Sun, 25/01/2015 - 00:07

I've just whipped up a Python script that renders Github issue lists from your favourite projects as an iCalendar feed.

The project is called github-icalendar. It uses Python Flask to expose the iCalendar feed over HTTP.

It is really easy to get up and running. All the dependencies are available on a modern Linux distribution, for example:

$ sudo apt-get install python-yaml python-icalendar python-flask python-pygithub

Just create an API token in Github and put it into a configuration file with a list of your repositories like this:

api_token: 6b36b3d7579d06c9f8e88bc6fb33864e4765e5fac4a3c2fd1bc33aad bind_address: ::0 bind_port: 5000 repositories: - repository: your-user-name/your-project - repository: your-user-name/another-project

Run it from the shell:

$ ./github_icalendar/main.py github-ics.cfg

and connect to it with your favourite iCalendar client.

Consolidating issue lists from Bugzilla, Github, Debian BTS and other sources

A single iCalendar client can usually support multiple sources and thereby consolidate lists of issues from multiple bug trackers.

This can be much more powerful than combining RSS bug feeds because iCalendar has built-in support for concepts such as priority and deadline. The client can use these to help you identify the most critical issues across all your projects, no matter which bug tracker they use.

Bugzilla bugtrackers already expose iCalendar feeds directly, just look for the iCalendar link at the bottom of any search results page. Here is an example URL from the Mozilla instance of Bugzilla.

The Ultimate Debian Database consolidates information from the Debian and Ubuntu universe and can already export it as an RSS feed, there is discussion about extrapolating that to an iCalendar feed too.

Further possibilities
  • Prioritizing the issues in Github and mapping these priorities to iCalendar priorities
  • Creating tags in Github that allow issues to be ignored/excluded from the feed (e.g. excluding wishlist items)
  • Creating summary entries instead of listing all the issues, e.g. a single task entry with the title Fix 2 critical bugs for project foo
Screenshots

The screenshots below are based on the issue list of the Lumicall secure SIP phone for Android.

Screenshot - Mozilla Thunderbird/Lightning (Icedove/Iceowl-extension on Debian)

Categories: Elsewhere

Commerce Guys: Platform.sh hosting for eCommerce – it’s a game changer

Planet Drupal - Sat, 24/01/2015 - 21:05
Agency and online customer Use Case & experiences

Platform.sh is a 2nd generation Platform as a Service (PaaS). It accelerates your PHP/Drupal/Symfony based project development and reduces the risk of moving new features into live. Some customers are seeing circa. 40% reduction in project budgets and revenue loss prevention, whilst gaining huge improvements in developer productivity, eliminating environmental resource management and reducing live downtime to zero, all at commodity hosting prices! For an Agency providing web development, commerce and hosting services, or the end customer themselves, understanding the detail behind these very powerful messages is an important factor to making the right decisions around the critical tools and technologies that impact their business, especially if say the pricing structure appears to be a little higher than the known alternatives.
 

There is a huge amount of eCommerce experience built into Platform.sh

Commerce Guys are involved in many leading edge developments that are pushing the boundaries of how eCommerce is being utilized and evolved to meet new business models, many of which are tied into faster development, more frequent changes and better uptime. These include the migration of offline customers into advanced online purchase environments; encouraging said customers to spend more money whilst at the same time becoming less expensive to support, requiring tighter integrations of support and customer care functions; also important is the delivery of B2C-like experience for B2B customers; as well as defining online and mobile strategies in conjunction with each other; Drupal 8, Distributions etc. etc.

What gives Commerce Guys the credibility to offer such a convincing project development tool? We are a commercial software vendor, and we’ve invested several $m into building the Drupal Commerce application and its Kickstart distribution (deployed into over 50,000 active sites), so we know how to develop successful software products on an industrial scale. Of further relevance is the deep involvement we have in so many of our partner projects each year, providing analysis, design authority and development skills that puts us in the middle of hundreds of individual and unique development processes ! What we have engineered into the heart of Platform.sh is the flexibility to overcome the big problems and common manual activities that hold project teams back.
 

Different customers, all with common problems

Let’s take a look at a handful of typical eCommerce customers, and work through their issues:

  • A Digital Agency (DA) with a global pharmaceutical client who has many simple but different web-shop brands across 18 European countries.
  • A Systems Integrator (SI) with a high street optician as their customer, with an eCommerce system covering 14 territories. They have all the usual requirements of a high end client plus an unusually complex hosted infrastructure accommodating various index sites and 10 plus environments in each location, totalling 150 service instances.
  • A Retail Fashion client rolling out a Distribution based eCommerce system to 4 geographies.
  • A pureplay online marketing business providing 4,000 products through a Social Media community exceeding 200,000 people in 22 countries around the world, of which the mobile traffic accounts for over 70% of their revenues.

And although both the Agency and the Integrator are at the high end of technical capability, and the 2 retailers have way less experience, they all have similar sets of problems that only Platform.sh seems to be able to solve.

 

Complex eCommerce applications versus simple brochure-ware sites

 

To properly emphasize the advantages that Platform.sh brings to an eCommerce system, we first need to draw a comparison between the complex and transactional nature of these customers’ applications, and that they usually work differently in each country, and as such require various different code bases. By comparison, these are very different for example, to brochure-ware sites with a central content repository, combined with simple language differences plus content change workflow pushed out through a multi-site architecture.
 

Typical lifecycle issues that all 4 of these online businesses worry about

To start with, the development process differences between these two project personalities (multi-region eCommerce and multi-site brochure ware) are significant, the differences being 1) many more environments through which the upstream movement of code is being managed, 2) a much longer code-test-production timeframe, 3) bigger testing overheads (including tools, time and people), 4) complex content approval workflows, 5) higher consequential management costs, and 6) a severe risk impact of changes not working in production and feature release delays due to poor Continuous Integration (CI).

All the above are directly related to revenue loss - exacerbated by reputational damage in severe circumstances – which of course make them fairly unique to eCommerce. The effects on cost, time and business risk all increase exponentially when considering multi-country implementations.

 

What Platform.sh does for eCommerce that nobody else can !

Platform.sh solves many problems specific to this eCommerce Use Case, as well as easing various issues that make such projects more expensive to deliver and very laborious to manage,as follows:

  1. Many development process issues are greatly affected, resulting in a significantly reduced number of coding errors due to inconsistent environments, and greatly reduced elapsed times in the code delivery process from local environment through test, staging and user sign-off.
  2. Hugely improved Continuous Integration (CI) process that speeds up the change process for similar features across multiple environments into different local production services.
  3. True Continuous Delivery (CD) now becomes possible because the process no longer requires large number of changes to be bundled up and tested together before going to production say every 6-8 weeks. In this new regime, even the smallest of changes can whistle through in less than 60 minutes, which is vital for changes to aspects of the ‘Sale Offer’ during peak season, modifying coupon functionality for instance, or making micro changes during the advertising campaign.
  4. Steep cost reductions associated with maintaining multiple static environments (because re-creating from staging for new development environments isn’t possible or takes too long). Developers now have the power to create and destroy their own full-stack environments that mirror staging or say the master.

We’ve learned from various retailers using Platform.sh in the run up to holiday periods and promotions (especially Black Friday, Cyber Monday and December 26th) that the reduced risk of making changes into live offered by Platform.sh, plus the triple redundancy we provide in the Platform Enterprise (PE) offering with its ability to seamlessly upscale around traffic peaks are all regarded as extremely valuable to their business, the combination of which simply cannot be provided by alternate vendors ! This makes Platform.sh a must for any mission critical eCommerce site.

Categories: Elsewhere

Dirk Eddelbuettel: Rcpp 0.11.4

Planet Debian - Sat, 24/01/2015 - 16:44

A new release 0.11.4 of Rcpp is now on the CRAN network for GNU R, and an updated Debian package will be uploaded in due course.

Rcpp has become the most popular way of enhancing GNU R with C++ code. As of today, 323 packages on CRAN depend on Rcpp for making analyses go faster and further; BioConductor adds another 41 packages, and casual searches on GitHub suggests dozens mores.

This release once again adds a large number of small bug fixes, polishes and enhancements. And like the last time, these changes were made by a group of seven different contributors (counting code commits) plus three more providing concrete suggestions. This shows that the Rcpp development and maintenance rests a large number of (broad) shoulders.

See below for a detailed list of changes extracted from the NEWS file.

Changes in Rcpp version 0.11.4 (2015-01-20)
  • Changes in Rcpp API:

    • The ListOf<T> class gains the .attr and .names methods common to other Rcpp vectors.

    • The [dpq]nbinom_mu() scalar functions are now available via the R:: namespace when R 3.1.2 or newer is used.

    • Add an additional test for AIX before attempting to include execinfo.h.

    • Rcpp::stop now supports improved printf-like syntax using the small tinyformat header-only library (following a similar implementation in Rcpp11)

    • Pairlist objects are now protected via an additional Shield<> as suggested by Martin Morgan on the rcpp-devel list.

    • Sorting is now prohibited at compile time for objects of type List, RawVector and ExpressionVector.

    • Vectors now have a Vector::const_iterator that is 'const correct' thanks to fix by Romain following a bug report in rcpp-devel by Martyn Plummer.

    • The mean() sugar function now uses a more robust two-pass method, and new unit tests for mean() were added at the same time.

    • The mean() and var() functions now support all core vector types.

    • The setequal() sugar function has been corrected via suggestion by Qiang Kou following a bug report by Søren Højsgaard.

    • The macros major, minor, and makedev no longer leak in from the (Linux) system header sys/sysmacros.h.

    • The push_front() string function was corrected.

  • Changes in Rcpp Attributes:

    • Only look for plugins in the package's namespace (rather than entire search path).

    • Also scan header files for definitions of functions to be considerd by Attributes.

    • Correct the regular expression for source files which are scanned.

  • Changes in Rcpp unit tests

    • Added a new binary test which will load a pre-built package to ensure that the Application Binary Interface (ABI) did not change; this test will (mostly or) only run at Travis where we have reasonable control over the platform running the test and can provide a binary.

    • New unit tests for sugar functions mean, setequal and var were added as noted above.

  • Changes in Rcpp Examples:

    • For the (old) examples ConvolveBenchmarks and OpenMP, the respective Makefile was renamed to GNUmakefile to please R CMD check as well as the CRAN Maintainers.

Thanks to CRANberries, you can also look at a diff to the previous release As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Dirk Eddelbuettel: RcppGSL 0.2.4

Planet Debian - Sat, 24/01/2015 - 16:20

A new version of RcppGSL is now on CRAN. This package provides an interface from R to the GNU GSL using our Rcpp package.

This follows on the heels on the recent RcppGSL 0.2.3 release and extends the excellent point made by Qiang Kou in a contributed section of the vignette: We now not only allow to turn the GSL error handler off (to not abort() on error) but do so on package initialisation.

No other user-facing changes were made.

The NEWS file entries follows below:

Changes in version 0.2.4 (2015-01-24)
  • Two new helper function to turn the default GSL error handler off (and to restore it) were added. The default handler is now turned off when the package is attached so that GSL will no longer abort an R session on error. Users will have to check the error code.

  • The RcppGSL-intro.Rnw vignette was expanded with a short section on the GSL error handler (thanks to Qiang Kou).

Courtesy of CRANberries, a summary of changes to the most recent release is available.

More information is on the RcppGSL page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Dirk Eddelbuettel: RcppAnnoy 0.0.5

Planet Debian - Sat, 24/01/2015 - 15:22

A new version of RcppAnnoy is now on CRAN. RcppAnnoy wraps the small, fast, and lightweight C++ template header library Annoy written by Erik Bernhardsson for use at Spotify. RcppAnnoy uses Rcpp Modules to offer the exact same functionality as the Python module wrapped around Annoy.

This version contains a trivial one-character change requested by CRAN to cleanse the Makevars file of possible GNU Make-isms. Oh well. This release also overcomes an undefined behaviour sanitizer bug noticed by CRAN that took somewhat more effort to deal with. As mentioned recently in another blog post, it took some work to create a proper Docker container with the required compiler and subsequent R setup, but we have one now, and the aforementioned blog post has details on how we replicated the CRAN finding of an UBSAN issue. It also took Erik some extra efforts to set something up for his C++/Python side, but eventually an EC2 instance with Ubuntu 14.10 did the task as my Docker sales skills are seemingly not convincing enough. In any event, he very quickly added the right fix, and I synced RcppAnnoy with his Annoy code.

Courtesy of CRANberries, there is also a diffstat report for this release. More detailed information is on the RcppAnnoy page page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Diego Escalante Urrelo: Link Pack #05

Planet Debian - Sat, 24/01/2015 - 02:03

Lever Rukhin Photographs Los Angeles From His Car
Lever Rukhin shoots the sketchiest parts of Los Angeles from his car, taking a really unique perspective that helps you perceive what LA looks like, if you were in a car… An experience that is apparently common to all LA people. People drive too much in the US :-).

It’s a very interesting interview that goes well with his full site: Lev Rukhin.

What I love about this, besides the whole premise, is that Lev went the extra mile and actually hacked his car to make the images he wanted:

Phoblographer: It looks like many of these images have artificial lighting in them. What’s your gear setup, and how do you introduce so much light into the scene from your car?

Lever: About 9 months ago, I affixed a Mola beauty dish onto the roof rack of my ’75 Volvo and juice it with a profoto bi-tube. This takes a bit of practice, as making a turn changes the light completely, which I always try to keep balanced. The Canon 5D3 with a 24mm f1.4 is set up on a tripod. The strobe has allowed me to capture more detail as well as creating a somewhat surreal feel to the sets.

Lev Rukhin http://www.levrukhin.com/

The Invisible Woman: A conversation with Björk
Björk is that Icelandic singer we all hear about but never really pay much attention to because her music is too smart for our simple ears. In this interview she goes over how her latest album is a very personal work, and unexpectedly (?) ends talking about how problematic it’s been to be a female auteur in her generation.

I have seen the same problem she denounces about people assuming that the male members of a team did all the work while the women just sticked to making coffee and sandwiches. I’ve worked with exceptional women that don’t get enough credit, but I’ve also worked with potentially exceptional women who don’t give themselves enough credit.

It’s a very interesting read, specially since it comes from someone who couldn’t be higher in the “art” food chain. Björk is god-damn Björk.

Only thing that bugs me is that Pitchfork decided to hold back most of the interview for publishing next month. I’ll try to go back and read it in full, but I wonder if the technique works for them or if perhaps they are missing the opportunity for a bigger impact. But I digress.

Pitchfork: The world has a difficult time with the female auteur.

B: I have nothing against Kanye West. Help me with this—I’m not dissing him—this is about how people talk about him. With the last album he did, he got all the best beatmakers on the planet at the time to make beats for him. A lot of the time, he wasn’t even there. Yet no one would question his authorship for a second. If whatever I’m saying to you now helps women, I’m up for saying it. For example, I did 80% of the beats on Vespertine and it took me three years to work on that album, because it was all microbeats—it was like doing a huge embroidery piece. Matmos came in the last two weeks and added percussion on top of the songs, but they didn’t do any of the main parts, and they are credited everywhere as having done the whole album. [Matmos’] Drew [Daniel] is a close friend of mine, and in every single interview he did, he corrected it. And they don’t even listen to him. It really is strange.

In Defense of the Selfie Stick
Miguel proposes a different take on the consequences of the selfies stick:

When you ask someone to take a picture of you, technically, they are the photographer, and they own the copyright of your picture.

(…)

All of a sudden, your backpacking adventure in Europe requires you to pack a stack of legal contracts.

Now your exchange goes from “Can you take a picture of us?” to “Can you take a picture of us, making sure that the church is on the top right corner, and also, I am going to need you to sign this paper”.

I don’t know what’s with the selfie stick hate. Let people have fun, it doesn’t hurt. If anything, it prevents them from asking you to take their photo, and if we already established you are the kind of people not a big fan of strangers, all the better, right?

Why Top Tech CEOs Want Employees With Liberal Arts Degrees
Here’s a small extra. When I decided to pursue a humanities/art formal training, I got many naysayers telling me that I was screwing up not specializing even more as a formal (titled) engineer. I argued then, and now, that if I was gonna pay for training, I might as well pay for training outside my comfort zone.

The result resonates perfectly with this article. Of course, it’s not like the thing is settled, but I can back the various quotes in there.

Working with purely technical/engineering types can be an echo chamber, and having trained myself in the humanities and arts I have become incredibly much more sensitive to the human factor of things. I used to think I was already good at this (because we hacker types have lots of confidence), but studying humanities like human communication, social conflict and development, film language, etc; it all has made me a much more capable hacker of things.

There’s also a nice argument to be made about joining the arts when you are already highly skilled on technical matters. Like Robert Rodríguez’s teacher (mentioned in his diary/book Rebel Without a Cause, which I also have to review soon) used to say (generous paraphrasing here): the world is of those who can be their own creative and their own technician.

Both Yi and Sheer recognize that the scientific method is valuable, with its emphasis on logic and reason, especially when dealing with data or engineering problems. But they believe this approach can sometimes be limiting. “When I collaborate with people who have a strictly technical background,” says Yi, “the perspective I find most lacking is an understanding of what motivates people and how to balance multiple factors that are at work outside the realm of technology.”

Interesting food for thought, specially if you know an engineer that ditches the arts as of little value for personal growth in their careers/life.

Read more Link Pack, you’ll love it
  • Link Pack #04 - Writing Your Way to Happiness (nytimes.com) Researches believe that the way we think about, and remember, “our story” can be so powerful that it can actually influence our happiness and success. It’s a nice little article summarizing actual research. The main study referred put fresh university students to test: a group received tools to “rewrite”…
  • Link Pack #03 - What’s that? The third edition of Link Pack of course! Playing with Power (7 minutes, Vimeo) A super awesome story about a stop motion animator that turned a Nintendo Power Glove into the perfect animation tool. It’s a fun, inspiring video :-). I love the Power Glove, it’s so bad. The Power Glove – Angry…
  • Link Pack #02 - First sequel to my Link Pack “series” (I’ll remove the quotes when it’s LP#05): Link Pack #01. This time I’m going for fewer articles, to try to keep things less overwhelming. There’s no special theme, and I’m actually leaving out some nice things I read recently. On the plus side, that means I have good…
  • Link pack #01 - Following the lead of my dear friend Daniel and his fantastic and addictive “Summing up” series, here’s a link pack of recent stuff I read around the web. Link pack is definitely a terrible name, but I’m working on it. How to Silence Negative Thinking On how to avoid the pitfall of being a Negatron…
Categories: Elsewhere

DrupalCon News: Send Us Your Sessions and Training Proposals

Planet Drupal - Sat, 24/01/2015 - 01:28

Think you’ve got Drupal or web smarts? We’re seeking mind-blowingly good sessions for DrupalCon Los Angeles, and want to hear from you about what you know best.

You don’t have to be the best in everything, but if there’s one topic you know inside and out, you should submit a session.

We’re looking for topics for the following tracks:

Categories: Elsewhere

Chris Lamb: Slack integration for Django

Planet Debian - Fri, 23/01/2015 - 23:46

I recently started using the Slack group chat tool in a few teams. Wishing to add some vanity notifications such as sales and user growth milestones from some Django-based projects, I put together an easy-to-use integration between the two called django-slack.

Whilst you can use any generic Python-based method of sending messages to Slack, using a Django-specific integration has some advantages:

  • It can use the Django templating system, rather than constructing messages "by hand" in views.py and models.py which violates abstraction layers and often requires unwieldy and ugly string manipulation routines that would be trivial inside a regular template.
  • It can easily enabled and disabled in certain environments, preventing DRY violations by centralising logic to avoid sending messages in development, staging environments, etc.
  • It can use other Django idioms such as a pluggable backend system for greater control over exactly how messages are transmitted to the Slack API (eg. sent asynchronously using your queuing system, avoiding slowing down clients).

Here is an example of how to send a message from a Django view:

from django_slack import slack_message @login_required def view(request, item_id): item = get_object_or_404(Item, pk=item_id) slack_message('items/viewed.slack', { 'item': item, 'user': request.user, }) return render(request, 'items/view.html', { 'item': item, })

Where items/viewed.slack (in your templates directory) might contain:

{% extends django_slack %} {% block text %} {{ user.get_full_name }} just viewed {{ item.title }} ({{ item.content|urlize }}). {% endblock %}

.slack files are regular Django templates — text is automatically escaped as appropriate and that you can use the regular template filters and tags such as urlize, loops, etc.

By default, django-slack posts to the #general channel, but it can be overridden on a per-message basis by specifying a channel block:

{% block channel %} #mychannel {% endblock %}

You can also set the icon, URL and emoji in a similar fashion. You can set global defaults for all of these attributes to avoid DRY violations within .slack templates as well.

For more information please see the project homepage or read the documentation. Patches and other contributions are welcome via the django-slack GitHub project.

Categories: Elsewhere

cs_shadow: Tips for Google Summer of Code

Planet Drupal - Fri, 23/01/2015 - 23:41

Google Summer of Code 2015 is approaching and few people started asking me about how to get selected in GSoC 2015 and where to start. So I though to go ahead and write a blog post so that others can also benefit. This post targets students who have never participated in GSoC before and want to know how to get started with the application process and open source in general.

What is Google Summer of Code? How it works?

The GSoC FAQ page should suffice to answer most of your queries and I strongly suggest to go through it before looking anywhere else for answers.

Google Summer of Code is a program that offers student developers stipends to write code for various open source projects. We work with many open source, free software, and technology-related groups to identify and fund projects over a three month period. Since its inception in 2005, the program has brought together over 8,500 successful student participants from over countries and over 8,000 mentors from 109 countries worldwide to produce over 55 million lines of code.

So, basically this is how it works:

  • Different orgs (open source organizations) submit their applications to be part of the program and Google chooses about 190 of those based on their application and past record.
  • Once the orgs are selected, the list will be available on Melange. Each org will have an ideas list and a homepage.
  • You need to choose one of the ideas from the list on the ideas page and submit your proposal. (Details on this below)
  • Then you wait for Google to announce the list of selected proposals. If you find your proposal there, then the hardest part is over and now you code with your org for about three months and complete the proposed project.
  • If everything went smoothly so far, you'll get a handsome paycheck for your contribution and you'd have learnt a lot about your project, org and open source.
There are so many orgs, which one do I choose?

This is probably the single most asked question every year around this time. The answer is pretty straightforward if you're already involved with any open source organization and want to continue work with the same org, then go for that one. If the answer to the previous question is no (which might be the case for most of you reading this post), then you need to choose a few orgs from the list of all accepted orgs. Although you will finally work with only one org, it might be a nice idea to select 1-3 orgs to which you may submit your proposals. You can shortlist the orgs based based on tags, for example if you're familiar with C++, you can filter the orgs which have the C++ tags mentioned on Melange.

If the org list of this not out yet, you can look at the list of orgs which participated in GSoC last year. For instance, you can take a look at the list of orgs which took part in 2014 and 2013. Filter the orgs based on the tags you're either familiar with or want to work on. Orgs which participated in previous years and took in more than a couple of students are more likely to get accepted again this year. Based on this and your favorite tags, you filter out 1-3 orgs.

After this, the next task is to go through the idea list for those orgs and decide what ideas interest you most. If you don't fully understand the ideas, it's completely fine and the next step will be to get your doubts cleared up by contacting the org and/or the mentor of the task (more on this in the next section).

Okay, I've decided an org and project idea, what do I do next?

Once you've decided what project idea interests you most and some parts of the description are either unclear to you or you want to clarify a few details, you should get in touch with the task mentor and the organization in general. All the orgs have a contact section on Melange which will tell you how to contact the org. Most orgs prefer communication either via IRC or mailing lists so you can get in touch with the org. You can also ping the task mentor in IRC or mail him to clarify any doubts that you might have regarding the project.

Although its not compulsory, its usually a good idea to contribute to the org before sending your proposal. In order to that, you can ask questions like "Hey I'm new here, can anyone help me get started on how to contribute." either on IRC or the mailing lists. Since orgs get asked such questions very frequently, many of those have a 'Getting Started' page and if it'll be very helpful if you find that page and follow the instructions. If you've any doubts don't hesitate to ask those. Mentors are generally nice people and will help you through.

How to start contributing

Contributing to an org means either helping to fix bugs (issues), writing documentation or doing testing etc. All the orgs use an issue tracker to keep track of their issues/bugs and most of those orgs have a novice/beginner/quick-fix tag which lists tasks which are easy to fix for beginners. You can get more info on that by contacting the org. Contributing to open source is fun and if you're not having fun, you're doing it wrong.

Writing a good proposal

Once you've finalized the project idea, and have got started contributing to the org, the next and the most important step is to write a proposal. Many orgs have a application template of sorts and if your org has one, you need to follow that. Otherwise, you can start by specifying your personal information and then moving on to project description. Following are a few tips for writing your project proposal:

  • Include a detailed timeline based on how you intend to complete the project.
  • Make sure to list any bugs you've worked on and/or links to your contributions.
  • Double, actually triple check for spelling mistakes.
  • Don't forget to mention your contact info.
  • Last but not the least, don't forget to update Melange with your latest proposal.

Once your proposal is ready, you can ask the task mentor (and/or the org admin) to review it before you submit it finally to Melange. Ask them if you could explain any parts of it in a better manner and follow up on their feedback. The most important part is really understanding the project idea and reflecting that in your proposal.

Some Do's and Don'ts

Following are some miscellaneous tips for communicating with your org in a better manner:

  1. Don't ask to ask: Don't hesitate to ask any questions and its much better than asking something like "Hello! I ran into an isuue, can anyone help me?" Instead you're more likely to get a helpful answer by asking your real question instead of asking to ask your question.

  2. Be patient and don't spam: Once you've asked your question, wait for some time for someone to answer it. Its not a good idea to spam the channel again and again with the same question at short intervals.

  3. Mentors are humans (and volunteers): After mailing a mentor, at least wait for 48 hours for them to reply. You need to understand that they are humans and most of them contribute in their volunteer time.

  4. Use proper English language: Its really not a good idea to use SMS language while communicating on IRC or mailing lists. Also, note that excessive use of question marks is frowned upon. Although you need to be respectful, but addressing mentors as Sir/Ma'am is not such a great idea.

Final words

If you follow the steps mentioned above sincerely, you'll have a great chance of getting selected into GSoC this year. If you have any doubts, feel free to ask those in comments below.

PS: A little background about me

I was a Google Summer of Code student with Drupal in 2014 and org admin for Drupal in Google Code-In 2014.

Tags: Google Summer of Codegsocgsoc2015Drupal Planet
Categories: Elsewhere

Drupal Association News: India – Embracing a Contribution Culture

Planet Drupal - Fri, 23/01/2015 - 21:25

While we know there are over 33,000 Drupal developers around the globe, I had no idea how strong Drupal was in India until I was there with Rachel Friesen, scouting locations for a possible DrupaCon Asia. By meeting with the community at camps, meetups, and dinners, we saw first hand how strongly India is innovating with Drupal and contributing back to the Project.

When it comes to geographic referrals, India is second in driving traffic to Drupal.org. However, they aren’t second in contributions, but things are changing. I was especially impressed with the relationship between Tata Consultancy Services (TCS) and Pfizer, a $51.5B life sciences company. Pfizer allows TCS to contribute their code, which is often not allowed for legal reasons. Since contributing back is a one of Pfizer’s top values, they asked TCS to make contribution part of their culture - and they did. At TCS, Rachit Gupta has created contribution programs that teach staff how to contribute and gives them time during work hours each week to contribute code. With a staff of several hundred developers, this can make TCS become a mighty contribution engine for the Project.

I’m equally impressed by other Indian web development consulting agencies that I met like Axelerant, Blisstering Solutions, Kellton Tech, and Srijan, who also have a contribution culture in their organizations. They even set up KPIs around staff contributions to make sure they are keeping this initiative top of mind.

While India celebrates its 68th birthday on January 25, it’s a time to celebrate its growth as a nation-- and, in its own way, Drupal has a hand in the country’s prosperity. Shine.com, a Drupal job search site, shows there are over 15,000 Drupal jobs in India.  All of the companies I talked to are growing their teams to meet that demand. Imagine if this contribution culture is fully embraced by Indian web development companies? The impact on the Project will be significant.

Individuals are also stepping up to support the Project and there is a passion for contribution that is spreading. I keynoted DrupalCamp Delhi, where over 1,000 people registered and 575 people attended. I saw first hand how dedicated the organizers were to make the event informative and fun. Several sprint mentors were on hand to lead more than 75 people through a full day sprint. Plus, the following weekend was Global Sprint Weekend and sprints popped up all over India in Bangalore, Chennai, Delhi, Goa, Hyderabad and Pune.

Not only are Drupalers in India helping the Project, but they are also using Drupal to create change in India with leapfrog solutions that give Indians access to more digital services. For example, many villages don’t have access to products found in major cities due to lack of infrastructure. The village stores simply can’t scale to buy and hold large quantities of inventory.

Iksula, an Indian eRetail consulting agency,  created a headless Drupal solution for Big Bazaar, India’s largest hypermarket, which provides lightweight tablets for store owners throughout India. Using those tablets, villagers can go into their local store and buy their goods online. The products are delivered to the shop owner, who hand delivers products to the consumer, giving people easier access to goods that can improve their quality of life.

As another example, we can look at IIT Bombay, India’s top engineering university, which uses Drupal at the departmental level. Professors P Sunthar and Kannan are taking Drupal to the masses by creating a MOOC in conjunction with MIT’s EDx. The work is funded by a government initiative called FOSSEE (Free and Open Source Software for Education), and through it, Indian university students can watch videos on several open source technologies, including Drupal.

The initiative bridges learning divides by providing the trainings in several languages found throughout India and provides low cost tablets for students who do not have a personal computer. This well thought-out program can help students learn the tools faster to meet the needs of of future employers. 

India has clearly embraced Drupal. They are making innovative solutions with the software and they are learning to contribute that back to the Project. Its for these reasons we want to host DrupalCon Asia. It will be a chance to highlight India’s Drupal talent and accelerate their adoption of a contribution culture.

A huge thank you to Chakrapani R, Hussain Abbas, Rahul Dewal, Jacob Singh, Mayank Chadha, Parth Gohil, Ankur Gupta, Piyush Poddar, Karanjit Singh, Mahesh Bukka, Vishal Singhal, Ani Gupta, Rachit Gupta, Sunit Gala, Professor P Sunthar and all the other community members who helped organize our trip to India. I’m personally moved and professionally inspired by all that you do.

Image credit to DrupalCamp Delhi

Categories: Elsewhere

Richard Hartmann: Release Critical Bug report for Week 04

Planet Debian - Fri, 23/01/2015 - 18:59

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1117 (Including 191 bugs affecting key packages)
    • Affecting Jessie: 187 (key packages: 116) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 132 (key packages: 89) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 24 bugs are tagged 'patch'. (key packages: 15) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 3) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 104 bugs are neither tagged patch, nor marked done. (key packages: 71) Help make a first step towards resolution!
      • Affecting Jessie only: 55 (key packages: 27) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 25 bugs are in packages that are unblocked by the release team. (key packages: 8)
        • 30 bugs are in packages that are not unblocked. (key packages: 19)

>How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie 43 284 (213+71) 468 (332+136) 319 (240+79) 44 261 (201+60) 408 (265+143) 274 (224+50) 45 261 (205+56) 425 (291+134) 295 (229+66) 46 271 (200+71) 401 (258+143) 427 (313+114) 47 283 (209+74) 366 (221+145) 342 (260+82) 48 256 (177+79) 378 (230+148) 274 (189+85) 49 256 (180+76) 360 (216+155) 226 (147+79) 50 204 (148+56) 339 (195+144) ??? 51 178 (124+54) 323 (190+133) 189 (134+55) 52 115 (78+37) 289 (190+99) 147 (112+35) 1 93 (60+33) 287 (171+116) 140 (104+36) 1 93 (60+33) 287 (171+116) 140 (104+36) 2 82 (46+36) 271 (162+109) 157 (124+33) 3 25 (15+10) 249 (165+84) 172 (128+44) 4 14 (8+6) 244 (176+68) 187 (132+55) 5 2 (0+2) 224 (132+92) 6 release! 212 (129+83) 7 release+1 194 (128+66) 8 release+2 206 (144+62) 9 release+3 174 (105+69) 10 release+4 120 (72+48) 11 release+5 115 (74+41) 12 release+6 93 (47+46) 13 release+7 50 (24+26) 14 release+8 51 (32+19) 15 release+9 39 (32+7) 16 release+10 20 (12+8) 17 release+11 24 (19+5) 18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

Categories: Elsewhere

Enrico Zini: mozilla-facepalm

Planet Debian - Fri, 23/01/2015 - 15:13
Mozilla marketplace facepalm

This made me sad.

My view, which didn't seem to be considered in that discussion, is that people concerned about software freedom and security are likely to stay the hell away from such an app market and its feedback forms.

Also, that thread made me so sad about the state of that developer community that I seriously do not feel like investing energy into going through the hoops of getting an account in their bugtracker to point this out.

Sigh.

Categories: Elsewhere

OpenLucius: Drupal REST Web Services - What, why and how

Planet Drupal - Fri, 23/01/2015 - 10:06

So, here at Lucius HQ we are planning on building a RESTful API (web services) on top on Drupal distribution OpenLucius.

We want to do this so all 3rd party programmers, thus 3rd party applications, can integrate with OpenLucius. And not only Drupal developers and Drupal modules. 

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator