FLOSS Project Planets

UX @ Akademy 2014

Planet KDE - Fri, 2014-08-29 18:46

We are going to Akademy 2014.

Keep on reading: UX @ Akademy 2014

Categories: FLOSS Project Planets

Lazy declarative programming in C++11

Planet KDE - Fri, 2014-08-29 18:05
KDE Project:

make does it, Haskell does it, spreadsheets do it, QML can do it and below I explain how to do it with C++11: declarative programming. And not just any declarative programming, but my favorite kind: lazy evaluation.

I have written a few C++ classes that wrap imperative C and C++ functions into functional expressions. A simple example illustrates the difference between the common imperative programming and declarative programming.

/** * This is our business logic. */ int sum(int a, int b) { return a + b; } /** * In the imperative example, c and d are just storage locations for the results. */ void imperative() { int a = 3; int b = 4; auto c = sum(a, b); auto d = sum(a, c); // correct std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; a = 4; // error: c and d have not been updated std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; } /** * In the lazy example, c and d are defined by the function sum() * and the actual values of c and d are determined when these variables * are accessed. Any C or C++ function can be used, but the outcome * should depend only on the input values. */ void lazy() { InputValue<int> a = 3; InputValue<int> b = 4; auto c = makeLazy(sum, a, b); auto d = makeLazy(sum, a, c); std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; a = 4; std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; }

The function makeLazy() which turns imperative functions to functional use, relies on a new feature in C++: variadic templates. Variadic templates give C++ great flexibility in the use of functions in templates. The example above shows that the functions can be chained.
The biggest advantage of this style of programming is that the programmer does not have to worry about whether the results are up to date. Programming like this feels like writing a spreadsheet: you give the logic and the computer takes care of how and when to get the result. It is nice to see that clean lazy functional programming can be done in C++ too.

Categories: FLOSS Project Planets

James Duncan: Napping + Coffee = Awesome

Planet Apache - Fri, 2014-08-29 18:00

If you caffeinate yourself right before taking a twenty minute nap, you may be more alert after than if you simply have coffee or take a nap. I have a hard time keeping my naps to twenty minutes, but I’m definitly going to have to give this a try next week now that we have a nap room at work.

via permalink
Categories: FLOSS Project Planets

FSF Blogs: GNU Spotlight with Karl Berry: 26 new GNU releases!

GNU Planet! - Fri, 2014-08-29 17:01

To get announcements of most new GNU releases, subscribe to the info-gnu mailing list: https://lists.gnu.org/mailman/listinfo/info-gnu. Nearly all GNU software is available from https://ftp.gnu.org/gnu/, or preferably one of its mirrors (https://www.gnu.org/prep/ftp.html). You can use the url http://ftpmirror.gnu.org/ to be automatically redirected to a (hopefully) nearby and up-to-date mirror.

This month, we welcome Raman Gopalan as a new co-maintainer of GNU gengen (with its author Lorenzo Bettini), Marcel Schaible as the new maintainer of GNU gperf, and Sergey Poznyakoff adds yet another new package, direvent, to his long list. I'd also like to specially thank Assaf Gordon (the author and maintainer of GNU datamash, new last month) for a significant amount of effort with all aspects of Savannah; new Savannah volunteers are always needed, and welcome. Thanks to all.

A number of GNU packages, as well as the GNU operating system as a whole, are looking for maintainers and other assistance: please see https://www.gnu.org/server/takeaction.html#unmaint if you'd like to help. The general page on how to help GNU is at https://www.gnu.org/help/help.html. To submit new packages to the GNU operating system, see https://www.gnu.org/help/evaluation.html.

As always, please feel free to write to me, karl@gnu.org, with any GNUish questions or suggestions for future installments.

Categories: FLOSS Project Planets

GNU Spotlight with Karl Berry: 26 new GNU releases!

FSF Blogs - Fri, 2014-08-29 17:01

To get announcements of most new GNU releases, subscribe to the info-gnu mailing list: https://lists.gnu.org/mailman/listinfo/info-gnu. Nearly all GNU software is available from https://ftp.gnu.org/gnu/, or preferably one of its mirrors (https://www.gnu.org/prep/ftp.html). You can use the url http://ftpmirror.gnu.org/ to be automatically redirected to a (hopefully) nearby and up-to-date mirror.

This month, we welcome Raman Gopalan as a new co-maintainer of GNU gengen (with its author Lorenzo Bettini), Marcel Schaible as the new maintainer of GNU gperf, and Sergey Poznyakoff adds yet another new package, direvent, to his long list. I'd also like to specially thank Assaf Gordon (the author and maintainer of GNU datamash, new last month) for a significant amount of effort with all aspects of Savannah; new Savannah volunteers are always needed, and welcome. Thanks to all.

A number of GNU packages, as well as the GNU operating system as a whole, are looking for maintainers and other assistance: please see https://www.gnu.org/server/takeaction.html#unmaint if you'd like to help. The general page on how to help GNU is at https://www.gnu.org/help/help.html. To submit new packages to the GNU operating system, see https://www.gnu.org/help/evaluation.html.

As always, please feel free to write to me, karl@gnu.org, with any GNUish questions or suggestions for future installments.

Categories: FLOSS Project Planets

Mediacurrent: Highlights from Drupalcamp Asheville

Planet Drupal - Fri, 2014-08-29 15:58

On August 22nd and 23rd, members of the Mediacurrent team attended the 4th annual Drupalcamp Asheville. With over 100 attendees convening at the Crowne Plaza Resort, our team experienced quality sessions, code sprints, and meaningful one-on-one coversations. Below are their highlights of the weekend.

Categories: FLOSS Project Planets

Alec Munro: It's yer data! - how Google secured its future, and everyone else's

Planet Python - Fri, 2014-08-29 13:31
Dear Google,

This is a love letter and a call to action.

I believe we stand at a place where there is a unique opportunity in managing personal data.

There is a limited range of data types in the universe, and practically speaking, the vast majority of software works with a particularly tiny fraction of them.

People, for example. We know things about them.

Names, pictures of, people known, statements made, etc.

Tons of web applications conceive of these objects. Maybe not all, but probably most have some crossover. For many of the most trafficked apps, this personal data represents a very central currency. But unfortunately, up until now we've more or less been content with each app having it's own currency, that is not recognized elsewhere.

You can change that. You can establish a central, independent bank of data, owned by users and lent to applications in exchange for functionality. The format of the data itself will be defined and evolved by an independent agency of some sort.

There are two core things this will accomplish.

1) It will open up a whole new world of application development free from ties to you, Facebook, Twitter, etc.

2) It will give people back ownership of their data. They will be able to establish and evolve an online identity that carries forward as they change what applications they use.

Both of these have a dramatic impact on Google, as they allow you to do what you do best, building applications that work with large datasets, while at the same time freeing from you concerns that you are monopolizing people's data.

A new application worldWhen developing a new application, you start with an idea, and then you spend a lot of time defining a data model and the logic required to implement that idea on that data model. If you have any success with your application, you will need to invest further in your data model, fleshing it out, and implementing search, caching, and other optimizations.

In this new world, all you would do is include a library and point it at an existing data model. For the small fraction of data that was unique to your application, you could extend the existing model. For example:
from new_world import Model, Field

BaseUser = Model("https://new_world.org/users/1.0")

class OurUser(BaseUser):
our_field = Field("our_field", type=String)

That's it. No persistence (though you could set args somewhere to define how to synchronize), no search, no caching. Now you can get to actually building what makes your application great.

Conceivably, you can do it all in Javascript, other than identifying the application uniquely to the data store.

And you can be guaranteed data interoperability with Facebook, Google, etc. So if you make a photo editing app, you can edit photos uploaded with any of those, and they can display the photos that are edited.

Securing our futurePeople have good reason to be suspicious of Google, Facebook, or any other organization that is able to derive value through the "ownership" of their data. Regardless of the intent of the organization today, history has shown that profit is a very powerful motivator for bad behaviour, and these caches of personal data represent a store of potential profit that we all expect will at some point prove too tempting to avoid abusing.

Providing explicit ownership and license of said data via a third-party won't take away the temptation to abuse the data, but will make it more difficult in a number of ways:

  • Clear ownership will make unfair use claims much more cut-and-dried
  • A common data format will make it much easier to abandon rogue applications
  • Reduced application development overhead will increase the competitive pressure, lowering the chance of a single application monopolizing a market and needing to grow through exploitation of its users data
A gooder, more-productive, GoogleBy putting people's data back in their hands, and merely borrowing it from them for specific applications, the opportunities for evil are dramatically reduced.

But what I think is even more compelling for Google here is that it will make you more productive. Internally, I believe you already operate similar to how I've described here, but you constantly bump up against limitations imposed by trying not to be evil. Without having to worry about the perceptions of how you are using people's data, what could you accomplish?

ConclusionGoogle wants to do no evil. Facebook is perhaps less explicit, but from what I know of its culture, I believe it aspires to be competent enough that there's no need to exploit users data. The future will bring new leadership and changes in culture to both companies, but if they act soon, they can secure their moral aspirations and provide a great gift to the world.

(Interesting aside, Amazon's recently announced Cognito appears to be in some ways a relative of this idea, at least as a developer looking to build things. Check it out.)
Categories: FLOSS Project Planets

Doug Vann: A Few Days Left To Vote For Ten SxSw 2015 Drupal Session Submissions

Planet Drupal - Fri, 2014-08-29 11:54
Vote for my session: Web Content Publishing with Drupal Eight
[You must be signed in to vote, registration is free]Mark Your Calendar: The 2015 Dates for SXSW Interactive are March 13-17 in Austin TX, the same place we just had Drupalcon 2014.Read more at the official SxSwi site: http://sxsw.com/interactive/news/2014/mark-your-calendar-2015-dates-sxsw... Last year I was invited by the SxSw organizers to deliver a 2.5hr Advanced Drupal Workshop. This year I encouraged many ppl to submit sessions and quite a few did. Now it's time to vote! For 2015 there are TEN submissions which either include Drupal or are entirely about Drupal. 

In order to vote, you must create an account on the Panel Picker Website: http://panelpicker.sxsw.com/
Voting is free, even if you're not sure wether or not you will make it to Austin for SxSw Interactive.

Here's a list of SxSw Interactive submitted sessions that are Drupal related, some more than others.
  1. The Drupal 8 Console Scaffolding Module Generator Solo 
  2. Web Content Publishing with Drupal Eight Workshop 
  3. Large Drupal Site Builds Workshop 
  4. Drupal 8 Modules for PHP Devs: Now with Symfony! Workshop 
  5. Introduction to Drupal 8 Theming with Twig Workshop 
  6. Winning Lifecycle Technology Adoption Strategies Solo 
  7. There is a CMS for everything... but content. Solo 
  8. Managing Communities: Tales from Open Source Panel 
  9. Interconnected: The Future of the Experience Web Solo 
  10. Content Personalization for Web Teams of All Sizes -

See all sessions at: http://panelpicker.sxsw.com/vote#sthash.O5Ix4fBG.dpuf
Search for the word "DRUPAL" and you'll see links to the 10 sessions listed above.

Drupal Planet

View the discussion thread.

Categories: FLOSS Project Planets

Zivtech: Simple Custom Page Layout With Panelizer

Planet Drupal - Fri, 2014-08-29 10:39

Using blocks to lay out content on your Drupal site can be a tedious and inflexible process. Panels improves this process by providing a simple way to display dynamic content based on relationships, contexts, and conditions without the user needing to learn to Drupal theming. If this sounds a bit like the Views module, it's because both Views and Panels were written by Earl Miles.

Panels has come a long way since its inception, and has several helper modules that take it beyond what it can do with its seamless integration with Views. Those include Panelizer, Panels Everywhere, and one that our own Jody Hamilton wrote more recently called Page Manager Templates. Page Manager is actually a module within Chaos Tools, a dependency of both Panels and Views now, that does most of the magic that we see on the front end of the Panels module. Because of its integration with many other modules and its overall power by itself, the Panels module is one of the most useful modules to have installed on your Drupal website. Views is finally making it into Drupal Core in Drupal 8, so maybe we will see Panels in Drupal 9!

Whether you are looking to create a simple 1 column layout, or a fully responsive multi-column layout, Panels has all of the tools needed to get it done. Panels layouts are easy to create, and can actually be exported and re-used across different sites. You can export the whole panel as well if you like. Here at Zivtech, we use a module called Features to export all sorts of settings, including Panels, Views, and content types to ensure all of our work is in code and can be committed to our git version control system. Panels can make your job easier as a Drupal site builder and allow you to display content without editing your theme much. You can even add additional CSS classes and IDs to give your panels the CSS selectors you need to get the page looking just right.

Beyond the layout flexibility and ability to display content dynamically, Panels also has robust access and visibility settings. You can easily set up whole pages or parts of pages to display or not based on user permissions, the user viewing, and many other conditions. This gives the flexibility to build the robust, responsive, and dynamic content and page layouts that we build here at Zivtech. This post is really just the tip of the iceberg for what Panels can do for your Drupal website. Want to learn more about Panels? Check out our upcoming Panels Training on September 17, 2014.

Terms: panelspanelizerdrupal trainingDrupal Planet
Categories: FLOSS Project Planets

scaling the UI by screen DPI

Planet KDE - Fri, 2014-08-29 10:03
tl;dr version
  • default DPI settings are usually wrong under x.org
  • thankfully, they can be easily configured
  • KScreen ought to manage that configuration along with the other screen information
  • EDID is right often enough to allow autoconfiguration when paired with user configuration
  • fonts are not an accurate surrogate for DPI
The longer version ...(Before we get into this topic, I should note that I wrote on this same topic almost exactly one month ago. In retrospect, I realized that that blog entry was really not clear enough, so I'm going to give it one more try ...)

The Plasma team decided that for Plasma 5 they would scale the user interface in relation to the size of the font being used in the UI.  The goal is to have the UI look nicely proportional and remain usable across screens with different DPI. Why fonts, and not simply use the DPI of the screen?

The developers note that the information that comes from device hardware which holds that information (the EDID block) is sometimes incorrect and so you get bad data from the device. They also point to the output of QScreen in Qt5 and note that it gives wrong values in default configurations and assert that the least-worst solution is to just use font sizes to scale against.
Font size is actually just a DPI surrogateThe reason font sizes "work" for scaling the UI is that the user typically configures the fonts to something "reasonable" for the screen. So one can generally assume, or so the theory goes, that the font size is a good indicator of screen DPI. (We'll see later why this isn't so, but let's accept this assertion for now.)
The easiest way to get your fonts to a readable size on a high-DPI screen is to go into the fonts control panel define the DPI directly.
 
This way you don't have to tweak any of the actual font settings. (Well, except in a handful of applications with broken font handling, which tend not to be KDE applications.) When you plug into a lower DPI screen (e.g. a project, beamer or TV) you then change the one DPI setting to match the screen's actual DPI and everything is back to normal size. Yes, this means changing it over and over again and knowing what the DPI of your screens are.

The alternative is to change each font size in every application, and that just doesn't make much sense. Not only is it a lot more effort, mostly because far too many applications have their own custom font settings, but when a new screen with a different DPI is used you have repeat the whole lengthy process all over again. It's much more sensible to just hit that DPI setting.

So when managed in this fashion, font size is really responding to a DPI setting. This means that font size is just a surrogate for the DPI setting. In fact, QScreen reports this value quite correctly as the logical DPI. In fact, I use that API in one project I am working on to scale a window to a physical size (i.e. in mm) on the screen, and it works very reliably.

So QScreen does work when fonts are set using the DPI setting, and in that case the font size is just a surrogate for DPI. So why not use the DPI directly to determine the scaling factor?
An old enemy: default settingsQScreen reporting what the DPI setting is makes sense, but it assumes things are sanely configured. On my "high-DPI" laptop with the default X.org configuration as shipped in openSUSE, even though the EDID block on the built-in screen is absolutely correct, X.org defaults to a typical low-resolution DPI by default The monitor-edid tool, which is a hundred or so lines of perl, manages to accurately report the DPI as 277 using the EDID information. So the machine is reporting correctly, but X.org doesn't seem to be using that information. That's pretty odd, isn't it?
Fortunately there is a tool in Plasma's arsenal that automatically manages screen settings: KScreen. It remembers user settings and tries to guess as best it can what a sensible default setup should be. It would be pretty easy to extend KScreen to use the EDID information to take a reasonable guess at a sensible scaling factor for the screen, just as it tries to figure out a sensible default resolution and position for a new monitor.
So while default settings tend to render QScreen useless, a little work in KScreen could fix that.Perfect is the enemy of goodOf course, some screens misreport the necessary information in their EDID block. Some devices are just broken, and some devices, such as projectors/beamers simply can not present this information. Consider: what is the physical size of the screen of a projector/beamer? Depends on how far from the surface (e.g. a wall or projector screen) it is.
It is these "bad DPI information" cases that are cited as a reason not to even try to use EDID information. Forget that the majority of devices actually do report this information correctly, it's those devices that get it wrong that wreck it for everyone! Right? Wrong. This is a case of perfect being the enemy of good.
In many of the "wrong information" cases it is possible to detect that this is the case because the results make no sense. The trusty monitor-edid tool manages to do this. In such situations, defaulting to no scaling and assuming it is just a lowly old low-resolution display, at least by default, would be enough.
If KScreen does guess it wrong, what can be done? Well, the same thing that is done when it guesses the resolution wrong, or guesses where you want the screen to be placed wrong ... the user configures it and KScreen remembers it for the next time. Yes, this is not a perfect situation, but it would be far better than the current recommendation of going to the fonts panel every time you plug into a different monitor and manually adjust that setting.
In other words, it's already pretty bad. By trying to use EDID based information it will only get better in most cases and when it isn't any better it's only as bad as it is now. Having KScreen oversee the DPI setting would be an improvement even if fonts continued to be used as a scaling metric, since at the very worst configuration would be a one-time thing and at best it wouldn't be necessary at all. In fact, for every single screen in the house right now (televisions, laptops, desktop LCDs, tablets...) it would Just Work(tm) and no configuration would be necessary.So why not fonts if they are a surrogate for DPI?If fonts are a surrogate for DPI, then why not just use them? Because in reality they are not a surrogate for DPI. They are only an approximation for DPI in the common case
For people with various sight related disabilities, cranking up the font size often helps quite a bit. For these people, the size of the font has very little to do with the DPI of the screen.
Additionally, when I'm viewing content on the TV screen from across the room, I like the fonts to be unreasonably large given the DPI of the screen. Again, in this case the font size is completely divorced from the screen DPI.
In both of these cases, if one scales the UI to the font size, you end up with cartoonishly poor UI sizing. Having giant window shadows or excessive margin padding is entirely inappropriate in many of these cases.
So if one can get to the DPI of the screen to guess a default, and allow the user to quickly and easily tweak that behavior when needed, then using the DPI directly will deliver better results in more cases.In hopes for a better Plasma Desktop experience ...I finally got around to installing a full Plasma Desktop 5 environment on a test system  this past week. Truthfully, it is not ready to be my default desktop, but it shows promise. It did remind me of the scaling-to-fonts situation, though, as I keep running into DPI related annoyances. I re-read my posting from last month and realized I really wasn't clear enough. Meanwhile, commits that keep pushing this scale-to-font-size idea into more and more places in Plasma (such as a new branch in plasma-framework just today that fiddles with icon sizes) which doesn't really address the situation properly at all. So I thought I would take one more run at it. Hopefully someone will pick up the task and this will be one less thing that Microsoft Windows and MacOS X does better than Plasma Desktop.
Categories: FLOSS Project Planets

Code Karate: Drupal 7 Node Expire module

Planet Drupal - Fri, 2014-08-29 09:58
Episode Number: 165

The Drupal 7 Node Expire module allows you to use the power of the Rules module to perform actions on nodes at a specific point in time (when the node "expires"). This is useful for things such as unpublishing your content after a certain amount of time, or removing your content from the front page after it's been published for a week. You can also create rules actions to send an email at a specific time to serve as a reminder to do something related to a node on your Drupal site.

Tags: DrupalDrupal 7Drupal Planet
Categories: FLOSS Project Planets

Steve Kemp: Migration of services and hosts

Planet Debian - Fri, 2014-08-29 09:28

Yesterday I carried out the upgrade of a Debian host from Squeeze to Wheezy for a friend. I like doing odd-jobs like this as they're generally painless, and when there are problems it is a fun learning experience.

I accidentally forgot to check on the status of the MySQL server on that particular host, which was a little embarassing, but later put together a reasonably thorough serverspec recipe to describe how the machine should be setup, which will avoid that problem in the future - Introduction/tutorial here.

The more I use serverspec the more I like it. My own personal servers have good rules now:

shelob ~/Repos/git.steve.org.uk/server/testing $ make .. Finished in 1 minute 6.53 seconds 362 examples, 0 failures

Slow, but comprehensive.

In other news I've now migrated every single one of my personal mercurial repositories over to git. I didn't have a particular reason for doing that, but I've started using git more and more for collaboration with others and using two systems felt like an annoyance.

That means I no longer have to host two different kinds of repositories, and I can use the excellent gitbucket software on my git repository host.

Needless to say I wrote a policy for this host too:

# # The host should be wheezy. # describe command("lsb_release -d") do its(:stdout) { should match /wheezy/ } end # # Our gitbucket instance should be running, under runit. # describe supervise('gitbucket') do its(:status) { should eq 'run' } end # # nginx will proxy to our back-end # describe service('nginx') do it { should be_enabled } it { should be_running } end describe port(80) do it { should be_listening } end # # Host should resolve # describe host("git.steve.org.uk" ) do it { should be_resolvable.by('dns') } end

Simple stuff, but being able to trigger all these kind of tests, on all my hosts, with one command, is very reassuring.

Categories: FLOSS Project Planets

Drupal Commerce: Commerce 2.x Stories - Internationalization

Planet Drupal - Fri, 2014-08-29 09:00

Welcome to the first article in the “Commerce 2.x Stories” series. As Commerce 2.x development heats up, we’ll be covering interesting developments, ideas, and contributors.

Our first topic of interest is internationalization and localization. This involves tasks from translating UIs and content to representing numbers, currencies, and dates in a locale specific manner. It’s also a current pain point with Drupal 7 / Commerce 1.x - especially as it relates to currency management.

Read on to see what we're doing to improve it...

Categories: FLOSS Project Planets

Mark Shropshire: Drupal Camp Asheville 2014

Planet Drupal - Fri, 2014-08-29 08:06

I had a great time at this year's Drupal Camp Asheville. This year's camp was held at the beautiful Crowne Plaza Resort on Saturday, August 23rd. Amenities included coffee, breakfast foods, a ping-pong table, and a great lunch (surprisingly good for a conferenc center). Thanks to Matthew Connerton, the Asheville Drupal User Group, and all of the sponsors, presenters, and attendees for making this a great camp! I attended a few sessions and hung out in the hallways chatting with long time Drupal friends and meeting new ones. I really enjoyed the presentations I attended:

I am looking forward to having the presentation videos posted to the Drupal Camp Asheville website so I can catch up on the ones I missed.

I had the pleasure of presenting "Digital Signage with Drupal and Metoer". A good number of session attendees were interested in Meteor, so I am glad to spend a bit of time talking about what Meteor is all about and how it works. The session was well attended and the questions from the attendees really made it a lot of fun!

Check out the slide deck below. I have also attached a PDF version so links in the presentation can be followed.

Blog Category:  AttachmentSize Digital Signage with Drupal and Meteor.pdf4.79 MB
Categories: FLOSS Project Planets

Scripting GDB to execute commands at particular breakpoints

Planet KDE - Fri, 2014-08-29 08:02

This might be old news for the more experienced programmers out there, but yes, we can script GDB to do $stuff whenever it hits a breakpoint. With GDB's logging to file feature this can be super handy when trying to get a backlog of backtraces whenever a certain event arises.

Example use-case

Let's consider the following problem we'd like to debug: In KDevelop (Frameworks branch) we always got this annoying warning from Qt when exiting the application:

Output: QMutex: destroying locked mutex

Now, we can easily find out by grepping the Qt code base that this message is printed in qmutex.cpp:201 (which is inside ~QMutex). So, in order to figure out who's calling the destructor of QMutex and causing this output, let's put a breakpoint on qmutex.cpp:201 and re-run KDevelop and try to close it.

(gdb) break qmutex.cpp:201 Breakpoint 1 at 0x7ffff58f04bf: file /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp, line 201.

This leads to the following backtrace:

Breakpoint 1, QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 201 qWarning("QMutex: destroying locked mutex"); #0 QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 #1 0x00007ffff51638aa in __cxa_finalize (d=0x7ffff3428b78) at cxa_finalize.c:56 #2 0x00007ffff33f1573 in __do_global_dtors_aux () from /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKDevPlatformUtil.so.9 #3 0x00007fffffffd830 in ?? () #4 0x00007ffff7dea73a in _dl_fini () at dl-fini.c:252

Unfortunately, the QMutex is destroyed during static deinitialization (notice the __do_global_dtors_aux call in the backtrace). Now, due to backtrace, we still don't know which QMutex in our code base got destroyed while being locked. We see that it is being statically initialized and must come out of libKDevPlatformUtil.so, but nothing more.

Problem: How do we find out which QMutex this was? Well, we need to check where this particular QMutex was first constructed.

GDB scripting to the rescue

I'd now like to print a backtrace each time we encounter the QMutex constructor (thus, QMutex::QMutex)

(gdb) break QMutex::QMutex Breakpoint 2 at 0x7ffff58f040e: file /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp, line 178.

Additionally, I want to print a backtrace each time the breakpoint is encountered:

(gdb) command 2 Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >backtrace 10 >continue >end

The command function makes GDB do the following each time it hits breakpoint 2: Print a backtrace limited to 10 frames and continue. (You can put whatever you need inside the command/end block.)

Furthermore, I'd like to get this logged to a file:

(gdb) set logging file gdb.txt (gdb) set logging on Copying output to gdb.txt. (gdb) set pagination off

Now, let's restart KDevelop and close it again

(gdb) run

We'll again hit the breakpoint when printing the QMutex warning when static deinitialization happens:

Breakpoint 1, QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 201 qWarning("QMutex: destroying locked mutex"); #0 QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 #1 0x00007ffff51638aa in __cxa_finalize (d=0x7ffff3428b78) at cxa_finalize.c:56 #2 0x00007ffff33f1573 in __do_global_dtors_aux () from /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKDevPlatformUtil.so.9 #3 0x00007fffffffd830 in ?? () #4 0x00007ffff7dea73a in _dl_fini () at dl-fini.c:252

Duly note the this pointer of the QMutex destroyed from the backtrace (QMutex::~QMutex (this=0x7ffff3428ba0 ...): It's 0x7ffff3428ba0

Note that in gdb.txt we now have the following contents (some parts replaced by ... for increased readability):

(...) Breakpoint 2, QMutex::QMutex (this=0x7ffff7dd8b78 <(anonymous namespace)::resInit+24>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff7dd8b78 <(anonymous namespace)::resInit+24>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff7be0e29 in (anonymous namespace)::ResInitUsage::ResInitUsage (this=0x7ffff7dd8b60 <(anonymous namespace)::resInit>) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:166 #2 0x00007ffff7be2067 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:237 #3 0x00007ffff7be2096 in _GLOBAL__sub_I_k3resolvermanager.cpp(void) () at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:815 #4 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #5 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #6 _dl_init (...) at dl-init.c:126 #7 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #8 0x0000000000000003 in ?? () #9 0x00007fffffffde39 in ?? () Breakpoint 2, QMutex::QMutex (this=0x7ffff7dd8b98 , mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff7dd8b98 , mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff7be68fe in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolverstandardworkers.cpp:97 #2 0x00007ffff7be6956 in _GLOBAL__sub_I_k3resolverstandardworkers.cpp(void) () at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolverstandardworkers.cpp:1049 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #7 0x0000000000000003 in ?? () #8 0x00007fffffffde39 in ?? () #9 0x00007fffffffde62 in ?? () Breakpoint 2, QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff33f23ba in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29 #2 0x00007ffff33f24ab in _GLOBAL__sub_I_foregroundlock.cpp(void) () at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:235 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #7 0x0000000000000003 in ?? () #8 0x00007fffffffde39 in ?? () #9 0x00007fffffffde62 in ?? () (...a lot more...)

Every time QMutex::QMutex was encountered, GDB printed a backtrace and logged it to the file.

Now, in order to find out where the QMutex comes from we simply search the string 0x7ffff3428ba0 inside gdb.txt and we'll find:

Breakpoint 2, QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff33f23ba in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29 #2 0x00007ffff33f24ab in _GLOBAL__sub_I_foregroundlock.cpp(void) () at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:235 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2

Frame 2 shows: This mutex comes from /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29, which says QMutex internalMutex;

We've found it!

At this point we can finally start solving our original problem of the destruction of a locked mutex, because now we at least know which mutex is causing this.

Other use-cases Tracing ref-counting issues

You know that some object (for example QCoreApplication in Qt5) has a refcount higher than zero when exiting the application, but you don't know which object is still keeping a reference on it.

How to debug: Print backtraces each time we call the hypothetical ref() and deref() (for example QCoreApplication::{de}ref()). Now simply check which object never calls deref() in the GDB output file.

Verdict

GDB's scripting capabilities can be tremendously useful when attempting to debug issues where the backtrace at the point of crash or some other event just isn't enough.

This helped me to fix several issues in KDevelop already, which would have been hard to tackle otherwise.

Also see: https://sourceware.org/gdb/current/onlinedocs/gdb/Break-Commands.html

Categories: FLOSS Project Planets

Jakub Wilk: More spell-checking

Planet Debian - Fri, 2014-08-29 07:51

Have you ever wanted to use Lintian's spell-checker against arbitrary files? Now you can do it with spellintian:

$ zrun spellintian --picky /usr/share/doc/RFC/best-current-practice/rfc* /tmp/0qgJD1Xa1Y-rfc1917.txt: amoung -> among /tmp/kvZtN435CE-rfc3155.txt: transfered -> transferred /tmp/o093khYE09-rfc3481.txt: unecessary -> unnecessary /tmp/4P0ux2cZWK-rfc6365.txt: charater -> character

mwic (Misspelled Words In Context) takes a different approach. It uses classic spell-checking libraries (via Enchant), but it groups misspellings and shows them in their contexts. That way you can quickly filter out false-positives, which are very common in technical texts, using visual grep:

$ zrun mwic /usr/share/doc/debian/social-contract.txt.gz DFSG: | …an Free Software Guidelines (DFSG) | …an Free Software Guidelines (DFSG) part of the ^^^^ Perens: | Bruce Perens later removed the Debian-spe… | by Bruce Perens, refined by the other Debian… ^^^^^^ Ean, Schuessler: | community" was suggested by Ean Schuessler. This document was drafted ^^^ ^^^^^^^^^^ GPL: | The "GPL", "BSD", and "Artistic" lice… ^^^ contrib: | created "contrib" and "non-free" areas in our… ^^^^^^^ CDs: | their CDs. Thus, although non-free wor… ^^^
Categories: FLOSS Project Planets

Kubuntu on LinkedIn

Planet KDE - Fri, 2014-08-29 05:43

We can sit in our own nerdy world in open source communities too much so at Kubuntu we have been setting up social media forums and we have just added a LinkedIn page for Kubuntu which should get the usual news stories of new releases and updates.  There is also a Kubuntu Users group on LinkedIn if you want to share experiences with people who like to take more of a business approach to their computers than users of other social media websites.

14.10 Beta 1 is out, you can give us feedback on Google + or Facebook or Twitter or Linkedin

Categories: FLOSS Project Planets

Intermediate results of the icon tests: Tango

Planet KDE - Fri, 2014-08-29 05:37

With a series of icon tests we currently study effects on the usability of icon design. This article however does not focus on these general design effects but presents findings specific to the Tango icon set.

Keep on reading: Intermediate results of the icon tests: Tango

Categories: FLOSS Project Planets

Antti-Juhani Kaijanaho: Licentiate Thesis is now publicly available

Planet Debian - Fri, 2014-08-29 04:45

My recently accepted Licentiate Thesis, which I posted about a couple of days ago, is now available in JyX.

Here is the abstract again for reference:

Kaijanaho, Antti-Juhani
The extent of empirical evidence that could inform evidence-based design of programming languages. A systematic mapping study.
Jyväskylä: University of Jyväskylä, 2014, 243 p.
(Jyväskylä Licentiate Theses in Computing,
ISSN 1795-9713; 18)
ISBN 978-951-39-5790-2 (nid.)
ISBN 978-951-39-5791-9 (PDF)
Finnish summary

Background: Programming language design is not usually informed by empirical studies. In other fields similar problems have inspired an evidence-based paradigm of practice. Central to it are secondary studies summarizing and consolidating the research literature. Aims: This systematic mapping study looks for empirical research that could inform evidence-based design of programming languages. Method: Manual and keyword-based searches were performed, as was a single round of snowballing. There were 2056 potentially relevant publications, of which 180 were selected for inclusion, because they reported empirical evidence on the efficacy of potential design decisions and were published on or before 2012. A thematic synthesis was created. Results: Included studies span four decades, but activity has been sparse until the last five years or so. The form of conditional statements and loops, as well as the choice between static and dynamic typing have all been studied empirically for efficacy in at least five studies each. Error proneness, programming comprehension, and human effort are the most common forms of efficacy studied. Experimenting with programmer participants is the most popular method. Conclusions: There clearly are language design decisions for which empirical evidence regarding efficacy exists; they may be of some use to language designers, and several of them may be ripe for systematic reviewing. There is concern that the lack of interest generated by studies in this topic area until the recent surge of activity may indicate serious issues in their research approach.

Keywords: programming languages, programming language design, evidence-based paradigm, efficacy, research methods, systematic mapping study, thematic synthesis

Categories: FLOSS Project Planets

Daniel Pocock: Welcoming libphonenumber to Debian and Ubuntu

Planet Debian - Fri, 2014-08-29 04:02

Google's libphonenumber is a universal library for parsing, validating, identifying and formatting phone numbers. It works quite well for numbers from just about anywhere. Here is a Java code sample (C++ and JavaScript also supported) from their web site:


String swissNumberStr = "044 668 18 00";
PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();
try {
  PhoneNumber swissNumberProto = phoneUtil.parse(swissNumberStr, "CH");
} catch (NumberParseException e) {
  System.err.println("NumberParseException was thrown: " + e.toString());
}
boolean isValid = phoneUtil.isValidNumber(swissNumberProto); // returns true
// Produces "+41 44 668 18 00"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.INTERNATIONAL));
// Produces "044 668 18 00"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.NATIONAL));
// Produces "+41446681800"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.E164));

This is particularly useful for anybody working with international phone numbers. This is a common requirement in the world of VoIP where people mix-and-match phones and hosted PBXes in different countries and all their numbers have to be normalized.

About the packages

The new libphonenumber package provides support for C++ and Java users. Upstream also supports JavaScript but that hasn't been packaged yet.

Using libphonenumber from Evolution and other software

Lumicall, the secure SIP/ZRTP client for Android, has had libphonenumber from the beginning. It is essential when converting dialed numbers into E.164 format to make ENUM queries and it is also helpful to normalize all the numbers before passing them to VoIP gateways.

Debian includes the GNOME Evolution suite and it will use libphonenumber to improve handling of phone numbers in contact records if enabled at compile time. Fredrik has submitted a patch for that in Debian.

Many more applications can potentially benefit from this too. libphonenumber is released under an Apache license so it is compatible with the Mozilla license and suitable for use in Thunderbird plugins.

Improving libphonenumber

It is hard to keep up with the changes in dialing codes around the world. Phone companies and sometimes even whole countries come and go from time to time. Numbering plans change to add extra digits. New prefixes are created for new mobile networks. libphonenumber contains metadata for all the countries and telephone numbers that the authors are aware of but they also welcome feedback through their mailing list for anything that is not quite right.

Now that libphonenumber is available as a package, it may be helpful for somebody to try and find a way to split the metadata from the code so that metadata changes could be distributed through the stable updates catalog along with other volatile packages such as anti-virus patterns.

Categories: FLOSS Project Planets
Syndicate content