News
Analyzed 7 minutes
ago based on code collected 3 days ago.
|
Posted
2 days
ago
by
Peter Grasch
A little while ago, I mentioned that I'll be giving a talk about the current state of open source speech recognition at this years Akademy.
As part of that talk, I want to show off a tech-demo of a moonshot use case of open source speech ... [More] recognition to not only demonstrate what is already possible, but also show off the limits of the current state of the art. So a couple of days ago, I asked what application of speech recognition technology would be most interesting for you, and many of you responded. I extracted the three options that broadly cover all suggestions: Dictation (like Dragon Naturally Speaking), a virtual assistant (like Siri) and simultaneous translation (like Star Trek's universal translator). You now get to pick one of those three from the poll below. After the poll closes (a week from now), I'll take the idea that received the most votes and devote about a week to build a prototype based on currently available open source language processing tools. This prototype will then be demonstrated at this years Akademy. Happy voting! Tags: SimonKDE Poll: Dictation, Assistant or Translator? Wed, 06/12/2013 - 10:45 Choices Dictation Virtual personal assistant Simultaneous translation Leave this field blank [Less] |
||||||
|
Posted
2 days
ago
by
kallecarl
Dot Categories: Community and EventsAre you attending Akademy 2013 in Bilbao? Do you want to get something special out of your Akademy experience?
Be a volunteer. The Akademy Team needs motivated people who are passionate about Free and Open ... [More] Software, especially KDE, one of the foremost communities of any kind in the world. There is a variety of tasks to fit with diverse interests and skills. [Less] |
||||||
|
Posted
3 days
ago
by
Luca Beltrame (einar77)
As a consequence of the recent changes in the repositories, the openSUSE KDE team is happy to announce the availability of packages containing the first beta of the KDE Platform, Workspaces and Applications 4.11.
Packages are ... [More] available in the KDE:Distro:Factory repository. As it is beta software, it may have not-yet-discovered bugs, and its use is recommended only if you are willing to test packaging (reporting bugs to Novell’s bugzilla) or the software (reporting bugs directly to KDE). For specific queries on the 4.11 beta not related to specific openSUSE packaging, use the KDE Community Forums 4.11 Beta/RC area. Have a good test! [Less] |
||||||
|
Posted
3 days
ago
by
Henry de Valence (hdevalence)
This post describes a few of the coordinate systems that KStars uses to keep track of the positions of various astronomical objects, and how they relate to one another.
All of the points used in KStars can be thought of as lying on a sphere ... [More] , because it really makes no difference how far away a sky object like a star is – we only care about the direction. We can then imagine that these points “live” on the celestial sphere, an imaginary sphere surrounding the Earth. The problem of rendering a map of the night sky is then the problem of figuring out how to transform this sphere onto the screen. Horizontal Coordinates Horizontal coordinates are defined strictly relative to the observer. We usually use two angles, the altitude, which measures the angle from the point to the horizon, so that 90° is straight up, 0° is on the horizon, and -90° is straight down, and the azimuth, which measures the angle eastward from the north direction to the direction of the point. Equatorial Coordinates There are two important lines on the celestial sphere that we’ll use to define our coordinate systems. The first is the celestial equator, which is just the Earth’s equator, extended outwards and projected onto the celestial sphere. The second is the ecliptic, which is the intersection of the Earth’s orbital plane with the celestial sphere. Since the Earth’s axis is tilted, these two lines are distinct, and they intersect at two points, as seen in this drawing: From the point of view of the Earth, the Sun travels along the ecliptic. When the ecliptic intersects the equator, it means that the Sun is directly above the equator, so night and day have the same length everywhere on earth. Thus, these points are the spring (vernal) and fall (autumnal) equinoxes. The equatorial coordinate system describes a point p in terms of its relation to the vernal equinox, usually by means of two angles, called right ascension and declination. The right ascension, RA or α, is the angle running eastward from the vernal equinox along the equator, while the declination is the angle from the object to the equator. Wikipedia provides a nice summary in GIF format: J2000 and standard epochs One thing to note about this system is that the Earth does not orbit the Sun perfectly. The Earth has precession and nutation, which are respectively a slow drift in the earth’s rotational axis and a slight, gradual wobbling motion. These motions cause the positions of the equinoxes to shift slightly, which means that the equatorial coordinates of even “fixed” objects vary over time, since they’re defined in reference to a moving point! To solve this problem, astronomers agree on particular times (“epochs”) to reference their coordinates. The most common is the J2000 epoch, which is defined to be the equatorial coordinates of a point in reference to the vernal equinox at noon on January 1, 2000. These coordinates have the time already specified, so we’re not missing any information, and we can use them in catalogs and databases. As an example, the Andromeda galaxy currently has equatorial coordinates of RA = 00h 43m 29s, Dec = 41° 20’ 22“, but the catalog coordinates are RA = 00h 42m 44s, Dec = 41° 16’ 08”. Ecliptic coordinates Ecliptic coordinates are pretty similar to equatorial coordinates, but they’re defined in terms of the ecliptic plane, instead of the equatorial plane. We describe a point in terms of its ecliptic longitude, which is measured eastward from the vernal equinox, and its ecliptic latitude, which is the angle from the point to the ecliptic plane. The same points about time dependence hold for ecliptic coordinates as well as equatorial coordinates, but in KStars we don’t store any data in ecliptic coordinates, so it’s not as important to define reference epochs for ecliptic coordinates. Galactic coordinates Finally, there’s the galactic coordinate system. This system places the Sun at the centre and uses the disk of the Milky Way to define the galactic equator. It describes a point in terms of its galactic longitude, measured eastward from the centre of the galaxy, and its galactic latitude, which is the angle to the galactic plane. KStars doesn’t actually make use of these, but we have the ability to calculate them, and this is exposed to the user as part of KStars’ tools collection. Converting between coordinate systems A lot of the work that KStars does goes into converting between these coordinate systems. We have a lot of different types of objects, which are grouped into SkyComponents. Currently, KStars deals with the problem of different objects needing different calculations by making each sky object have its own class, with its own object-oriented code for computation. This is really, really, bad for performance in a lot of ways, because it has fragmented memory access patterns, a virtual function call for each point, and a lot of duplicated work. Simplfying this requires carefully laying out what kinds of computation we do for each kind of sky object, which I’ll do in a future post. For now, I’ll just give a brief description of what goes into the conversion from one coordinate system to another. To convert from horizontal coordinates to equatorial coordinates, we need to know the time and location of the observer. Going back to the description we had of the equatorial coordinate system, we have a (relatively) fixed sphere, with the earth rotating around inside. All we need to do is compute the rotation of the earth, and apply that rotation to all of the points we want to convert. (Interestingly enough, at the moment KStars computes this rotation for each point we want to compute, because we never compute multiple conversions at the same time). If we want to be very precise, however, we need to compute the effects of atmospheric refraction, which makes our points appear higher in the sky then they actually are. As we noted, equatorial coordinates change over time due to the effects of precession and nutation. Converting equatorial coordinates in one epoch to another epoch requires computing the effects of precession and nutation. But there’s an extra complication there, too: we also need to compute the effects of aberration, which is caused by relativistic effects: the earth is moving around the sun, and this movement causes the apparent position of the stars to shift depending on the relative velocity of the earth to the star. Converting from equatorial to ecliptic coordinates is a simple rotation, and we just need to know the angle between the Earth’s equator and the ecliptic plane. This varies over time, so we need to compute precession and nutation as before. However, this isn’t the full story: some objects have extra calculations that need to be done, and we also want to be able to do these computations in a way that avoids trigonometry as much as possible. To be continued… [Less] |
||||||
|
Posted
3 days
ago
by
Alex Fiestas (afiestas)
A few days back I attended the first freedesktop summit/sprint where a few hackers from different free desktops met with the objective of working together. We were people from Razord-qt, GNOME, Unity and of course KDE.
Even though we did not ... [More] had the chance to discuss all the topics I was specially interested in like Notifications or Session Inhibition I did had the chance to get involved in other topics that are equally interesting like the shared Desktop Files cache or the “Trash size cache” that will enable a cross desktop way of caching the size of the Trash folder getting better performance across desktops. The social part of these kind of events is important as well, even though I already knew Ryan and David a week of working together makes the collaboration more smooth, and of course I also met new people as well like Lars, or Jeft. I’m quite happy to have pushed together with Ryan this event, we definitively moved forward the collaboration between desktops and even though freedesktop is still far from being perfect I do believe we did a step into the right direction. Can’t wait for the next Fd.o Summit. [Less] |
||||||
|
Posted
3 days
ago
by
mrybczyn
Dot Categories: DeveloperIn this week's KDE Commit-Digest:
|
||||||
|
Posted
3 days
ago
by
Mehrdad Momeny (mtux)
I’m pleased to announce that choqok development mailing list is up and ready (thanks to KDE sysadmins)
and from now on, we will talk about development stuff there. So I invite anyone who is interested to involve in Choqok development ... [More] and contribute code, subscribe to choqok-devel mailing list. Filed under: Choqok, PlanetKDE [Less] |
||||||
|
Posted
4 days
ago
by
Konrad Zemek (konradzemek)
Hey! My name is Konrad Zemek, I’m a student at AGH University of Science and Technology, Kraków, Poland. I study Computer Science, currently finishing my second year. I’m a programmer. Mainly a C++ programmer, but that’s just
... [More]
because I write in C++ professionally – I know a few other languages and I’m fast to pick up new ones. I could write about this a lot more, but I guess it all just comes to that: I’m a programmer, and a good one.
And I have other traits, too! I love gaming, particularly video gaming. I eat through books, mostly of the fantasy kind. I ride a bicycle almost every single day, and I’m learning to play the electric guitar, dreaming that I could someday justify buying a Stratocaster. I’ll get to placing my photo, not made hastily with a cellphone, somewhere around here – in the meantime I redirect you to my Google+ page. The blog I really tried not to commit too much time to deploy this blog, as I’m behind my schedule already. And believe me, it was hard – I’m the type of person who spends weeks reading about color theory and typography before deploying a website. This time, at least from the visual side, everything is pretty generic – still, I see great many hours of tweaking and customizing this blog in my future. Just not now. It’s a bit more interesting from the technical side. I deployed the WordPress application on the Amazon cloud, AWS; its code (the “application” part) resides in a git repository, which I push to “Elastic Beanstalk” (a Platform-as-a-Service) after every update, which in turn spins up a generic instance of GNU/Linux and deploys the application there. Nothing on this instance is persistent, so no actual content can be stored there. The blog connects to a SQL database, which is provided by another part of AWS. Then there’s persistent content that is neither a part of the application nor it belongs in the database, like uploaded images and other post attachments – these are stored by Amazon S3 service. CloudFlare provides DNS, caching, and some anti-bot screening. There are a lot of things on the technical side that I’m itching to talk about, but I’ve got more important thing to write about, that being… Google Summer of Code The main purpose of this blog, or rather the reason it came into existence, is to write about Google Summer of Code, more specifically about my own GSoC project. The title of this proposal is Reimplement Amarok 1.4 (FastForward) & iTunes importers on top of Statistics Synchronization framework, and add Amarok 2.x and Rhythmbox as synchronization targets. Amarok is a legendary music player, part of the KDE software suite (I’d say it’s a Linux music player, but that’s not entirely true). Every but the most basic music player collects data about music being played – it’s called personal metadata, and includes information like number of times a given track has been played, or user’s rating of the track. For users who use those features, it’s quite a big deal – it allows for playing favorite tracks, or maybe the tracks which were not listened to enough, all without any need to spend time setting up custom playlist. Or perhaps you like to share your most-loved tracks through a service like Last.fm? None of that would be achievable without personal metadata. Currently, if you’re using iTunes or an old Amarok version, you are able to share this metadata with Amarok, although there’s no easy way to keep it synchronized. At a basic level, my project aims to add that very capability – to easily resynchronize Amarok with iTunes, previous Amarok versions, and Rhythmbox, Ubuntu’s default music player. There are also some stretch goals, like being able to do a two-way synchronization (update metadata on the other player), and I’m also quite confident of reaching those. I will post my weekly progress updates here during the course of next three months, and I think my planned schedule will end up in a widget somewhere on this site. There also will be more details coming. I’ll get to it, I promise! So that’s me done for this post, before I run out of things to say in the next one. Thanks for reading. :) [Less] |
||||||
|
Posted
4 days
ago
by
Denis Steckelmacher (steckdenis)
The coding period of this year’s Google Summer of Code starts this Monday, and I have just finished my exams. It is a good time to start working on my project, a Nepomuk query parser.
When I learned that I was accepted as a GSoC ... [More] student, I began defining a grammar that will be used to parse Nepomuk search queries. I sent several mails to the nepomuk mailing list, and received very good feedback. Formality and User-Friendliness My first mail described a very formal grammar, very much like the one used by the current parser, that uses a key:value syntax (for instance, reservation house hasTag:holidays). The first comments said that this was not user-friendly enough, and pointed me to alternative syntaxes. In fact, I had only a small idea of what would be user-friendly, so these examples greatly helped me. I then proposed a small modification of my syntax. The first version was purely key:value based, and relied heavily on special characters, parenthesis, colons, operators, etc. The second version made most of these special characters optional, and allowed keys to span multiples words. sent_by:Me could then be replaced by sent by Me, a far more user-friendly syntax. Simplifying the Parser The problem with my second syntax is that it is fairly complex. It is a full formal grammar, with nested queries, and even with that the parser is unable to parse something that is not a sequence of key with spaces value statements. In English, nearly everything can be expressed with these kinds of sequences, but other languages in the world need to split the key around the value (if they have detached postfixes for instance), and even “sent last week to Jimmy” cannot be parsed, even if it is a simple rewording of “sent to Jimmy, sent last week”. After having discussed a bit with Vishesh Handa, my mentor, I began thinking about how a parser could handle these kinds of weird queries. Vishesh also told me that I do not need to keep the new syntax compatible with the old one, so I can simplify my reflection. Before being accepted as a GSoC student, I developed a small library that parses human-entered date-times. “first Monday of next month” will be parsed to the date of the first Monday of next month. This “parser” is not really one following the strict definition of the term. The date-time is not parsed from left to right (from start to finish), but information is cherry-picked. Rules say for instance that “first X”, where X is a day, sets the day of the current period to 0. “next X” is also a rules, and here is responsible for incrementing the month number. This approach is not very formal, but allows rules to be written independently of the parser. The parser ceases to be a parser and becomes a scripting environment. In fact, the human date-time parser used per-locale XML files and relied on KDE’s KCalendarSystem class. For the Nepomuk query parser, I plan to use an approach like this, but a bit enhanced. The idea of rules is kept, but rules become more powerful and less painful to translate. Architecture of the Parser I will explain the general architecture of the parser using an example query made of words, English-specific constructs and key/value pairs: 1e-mails sent by Jimmy, containing "hot dogs", and received before June 13 Don’t be afraid of this query, the plain list of keywords is also recognized by the parser. The first step is the splitting of the query into words. The split is operated at every character for which QChar::isSpace returns true. Normally, this covers every spacing character for every language handled by the Unicode character set. When the words are split, the parser uses them to build a list of Nepomuk2::Query::LiteralTerms. This list can be used to search for documents by keywords. The next passes are only here in order to improve the search results, and also to change the simple literal values into something more precise, that can be used for auto-completion when needed. 1(e-mails) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (13) The first pass transforms string constants into constants of a more suitable type. For instance, “13” is converted to 13 (the integer), “3.14” becomes a double, “2MB” becomes 2.000.000, and finally “2MiB” is converted to 2.097.152. 1(e-mails) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13) Another pass that I have already implemented is what I call type hints. If you have a generic search interface (like KRunner or the equivalent in Plasma Active), the queries entered in them can concern any data indexed on the computer, like files, e-mails, photos, etc. Even if we only think about Dolphin, Nepomuk knows that a file is not only a file, but a document, a picture, a movie, etc. This second pass recognizes type hints in the query and transforms them into filters on the document type. 1(ResourceType=nmo:Email) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13) The third pass already implemented matches “sent by X” and “from X” and adds a filter on the sender of an e-mail 1(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13) Currently, my small experiment does not get the list of known contacts from Nepomuk, but instead tries to directly compare the nmo:messageFrom property with a string. I is not correct and will not work, but I first wanted to have a working parser before being able to generate real queries. The next passes are not already implemented but will be in the coming days or weeks. One of them could match “containing X” and change the query like this (bif:contains is what the current parser seems to use to match documents containing something, but there may be a better way of doing this): 1(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (received) (before) (June) (int:13) The next one matches a day of a month. In English, the month name comes before the day number, but other languages do things differently. This kind of pattern matching can be done using a small pattern language developed for the parser. Each word in the pattern is either an immediate value (it matches a literal value having exactly this value) or a constraint on the term to be matched. For instance, June <integer0> matches “June 13”. The 0 after integer allows the translators to move placeholders around in the pattern, everything will be kept ordered on the C++ side. So, a day-of-month rule could be <string0> <integer1> in English. The C++ handler for this pattern will first check that string0 is a month name and integer1 is comprised between 1 and 31. Then, the according filter can be output. This rule can be translated in French to <integer1> <string0> as month names and day numbers are inverted in French (we say “13 Juin”). In fact, even in English the phrase can be “13th of June”. No problem, the parser accepts multiple patterns for a rule: 1 2 3 4d->runPass(d->pass_dayofmonth, i18nc( "Day number of a month", "<string0> <integer1>|<integer1> (?:th|rd|nd) of <string0>|<integer1> <string0>" ), 2); // 2 = there are two arguments in the pattern Translators are free to add as many rules as they want. Notice that regular expressions will be allowed (currently, they are not yet implemented). Another modification to the current parser that has to be done is to split “3rd” into “3” and “rd”. This could also be used to split “3GB” into “3” and “GB”, thus simplifying the handling of file sizes. With that said, the query is now: 1(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (received) (before) (date:2013-06-13) The last thing that would be nice to have parsed is the “received before” thing. Here, the parser needs to parse “before ” to produce a new date, but with a hint that the comparison to be done with this date is not the equality, but an ordered relation. Then, the parser has to match “received ” and do the actual comparison: 1(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (nmo:receivedDate<=2013-06-13) Now, there is nothing more to do. The parser stops trying rules (it does so in a loop, like optimization passes of a compiler, each rule being able to possibly alter the query and to expose further refinements), and proceeds to the final step: literal values smaller than a minimum size are removed. This removes the comma and the and. We get the final query: 1(ResourceType=nmo:Email) AND (nmo:messageFrom=contact:Jimmy) AND (bif:contains=string:"hot dogs") AND (nmo:receivedDate<=date:2013-06-13) If there was a literal value bigger than the threshold and not matched to anything, it would have been matched against its default property. If the literal value is a string, its default property is bif:contains. For a date, it is a set of properties like the date of creation/receiving, modification, etc. Current state and future plans Source code : nepomukqueryparser on GitHub, LGPLv2.1+ Currently, the parser is completely experimental and cannot be used to do anything even remotely useful. I blog about it in order to have comments about the current implementation direction, and to present how I see the parser. I like to communicate regularly on my blog, my average for my GSoC two years ago was one blog post per day or two. Feel free to comment and to find examples of difficult to parse queries, I will try to organize and architecture the parser in order to have it able to parse your query (if it is user-friendly enough). Another point is that my GSoC project is also about implementing an auto-completed input field. I currently have thought of two strategies that can be used to present auto-completion propositions to the user: Patterns are matched from left to right. If the start of a pattern matches (say, more than 50%, or anything containing an immediate value like a keyword), the end of the pattern can be presented to the user. For instance, if I enter “sent by”, the parser knows that the last part of the pattern is a contact, and the auto-complete box can show the list of my contacts. Terms are typed. When the user edits the query, his or her cursor is not at the end of the input field, and the parser must be more careful (the user may be breaking already-parsed statements or inserting things between them). The already-parsed terms can be used to know what the user is editing. If the user places its cursor on something that was found to be a date-time, a calendar can be shown. The current implementation is able to parse things like “mails sent by Jimmy”, and gives the following result: 1 2 3 4 5 6 7<?xml version="1.0"?> <type uri="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#Email"/> <?xml version="1.0"?> <comparison property="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageFrom" comparator="=" inverted="false"> <literal datatype="http://www.w3.org/2001/XMLSchema#string">Jimmy</literal> </comparison> I will post more details in the coming days, as I advance in the parser and solve different problems. [Less] |
||||||
|
Posted
4 days
ago
by
Marco Martin (notmart)
We saw last week the release of the first beta of KDE Plasma Workspace and applications 4.11
From my side, that’s a very important milestone, because it’s pretty much the coronation of what we intended the 4.x series of the ... [More] workspace to be. It was a long ride, but I think this future release will be pretty stable and “defined” in its own identity. The 4.11 release of the Workspace will be supported for years to come, marking in fact the last big feature release of the 4.x series. This sounds pretty scary, but it indicates a lot of maturity, 4.11 will be a release you can count on being maintained abd bugs fixed for a long time. Nice for home users, utterly awesome for bigger deployments. Just to clarify: this regards only Plasma Workspace so far. Applications will continue feature releases as usual, after all KDE is not a software, is a community that releases a lot of eterogeneous pieces of software. So, were are now? The desktop shell is useful by default. A default setup has all the typical functionality that a typical desktop usage needs, but.. one size does not fit all. The desktop shell is very flexible, trying to not force a paradigm on you, assemmble it at your liking. We have at least 5 different shells: Desktop, Netbook, Plamsa Active, Media center, part for application dashboards. Because one size does not fit all, on different devices we try to give you the best experience given the particular device. QML: It’s very easy to write new components for your desktop/tablet/mediacenter/whatever with an easy scripting language. But of course we never are happy: we want to do new things and have new features in the future.. We are porting to Qt5 and QML2 The whole workspace will be rendered by the GPU: faster and will be possible to have beautiful effects. We will have one shell to rule them all: the actual Plasma Shell becomes just a generic “viewer” with no UI whatsoever by itself. Since all the UI elements will be done by QML, they can be loaded and unloaded, so a different device experience can be dynamically loaded when for instance you plug your tablet to a docking station, the full Desktop shell starts. Even tough it will mean a quite big technology change, since we are quite happy with the overall direction of each one of our shells, there won’t be radical UI changes, except of course the usual incremental upgrades and refinements. I’ll do a talk about Plasma2 at Akademy, going a bit more in deep about the technology, the big picture concept and how to get involved in, so see you there [Less] |
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.