If your in the greater Salt Lake area and love python swing by the meeting this evening! We’re doing a python editor head-to-head, should be fun!
Tag Archive for 'Linux'
So the more I work with Django the more I long for a solid development environment to work in. I use Wingware for much of my python development, with its rockin debugger and code completion, its more than I could ask for. Until the curse of the Java class. This quarter I’m taking a Java projects course, most of the class uses Eclipse but a few use Netbeans. My problem is, I got spoiled so fast by the incredible templates support, content suggestions, quick fixes and always dead on code completion. Going back to Wing feels like a halfway-there IDE. I know that pythons interpreted nature makes source completion much more difficult, now I would argue that with an interpreter, you could actually step through the code to some extent. However, I respect that dynamic objects are never gonna be easy to support. My beef is with the lack of support for super-popular frameworks (this goes for everybody!) Ruby on Rails has literally dozens of solid IDEs and a few that are just spectacular (see Aptana, or Netbeans). Why can’t I get even basic highlighting support for my Django templates? Why can’t I get any completion options on Models except my own?
Its just frustrating, Django is still a pleasure to develop in, even with just Gedit and a terminal, but is it really out of the question to consider providing a big pretty environment for those of us that like that?
I did dig up this and this. I guess its a step in the right direction, but its almost embarrassing next to the Rails environments.
So I just finalized my registration for PyCon and booked my flight! I can’t even begin to express my excitement! If anyone else plans on attending, I made a wiki page for you to add your name to!
See you there!
Ok, I replaced our original autocomplete system with something a little more reserved, and based on a Gtk.Entry. Stealing heavily from a little-known F-Spot widget, I concocted a simple tagbar. Tab cycles through the completions and Enter selects. To give a rough idea of whats going on I made a quick screencast.
Let me know what you all think, if this is what we want to base our work on, then I’ll clear out the almost 500 lines of commented code from our past revisions. If we need to try something new, we can do that to.
Well be hacking it up tonight at 6:00PM MST at the Novell Open Source Technology Center. The rough TODO for the night seems to be Tags, Tasks and maybe even a backend to query Beagle. ;) Anyways, if your in the greater Salt Lake City area, come on down! If your a little further away but want to join in anyways, join in on #tomboy!
See you tonight!
Ok, so some of you may have noticed I’ve been a little quiet lately, over this time of non-blogging I built up a dozen great ideas for entries, and collected the photos to flesh them out. However, I am far to lazy, so you all get this little summary post instead. Let me apologize upfront, these were all taken with a cruddy phone. I’ll have another post with my technical musings later this week.
- Who knew Utah was so cool! After attending the Ubuntu-Utah group meeting, I was floored at how active the area was! Not only was the user group active, social and plenty fun, but I quickly learned about the Utah Open Source Foundation, which is (for lack of something more elegant) just plain awesome, the guys that run it could not be doing a better job. It was at a Multi-Distro Release Party (graciously hosted by Novell at their Open Source Technologies Center) that I caught this amusing moment, after Ubuntu is Linux for Human Beings, there aren’t age limits
- Some (hopefully legal) shots of the Novell Provo campus, its quite nice:
- Another fun tidbit about Salt Lake City, they have not only the best burrito joint on earth, but random neon orange flags at street crossings…
It happens.. even running on so little sleep, I still find myself waking.
Fortunately, this time I awoke with an awesome realization. I’ve been pounding my brain against the wall for a week now on how to further refine/increase the accuracy of my original relation-based ranking system. My initial results had been less than stellar when unleashed upon the desktop as a whole. In controlled situations (where my defined relationships weight’s were proportionate and scaled) the results were excellent, but I was hoping this ‘lowest common denominator’ of sorts would be the answer. I was mistaken. After being more or less tossed back to square one, I was less than optimistic to say the least.
However, at 2:30 this morning all that seems irrelevant, as I believe I have determined the key to blazingly accurate desktop search results (specifically over large search sets, to the order of shared drives with thousands of documents, images, e-mails and other media files without any real semantic system to start). In my original design I made the mistake of utilizing fixed-proportion weights for my relationships. A similar mistake as seen in many ObjectRank based systems. PDF Alert! By fixed proportion, I mean that an astronomical amount of time has gone into determining how important an ‘author’ relationship is when compared to a ‘creation date’ relationship. I (like many before me) was using a weight x termsimilarityindex type system for each relationship. As a result I was spending tons of time and effort trying to strike the proper balance, and in most cases when I got one situation to work, I completely destroyed another.
I think my < sarcasm > brilliant </sarcasm > revelation is becoming obvious, but bear with me.
We cannot pretend that authorship means the same thing to all users, a simple example is the large number of users who still operate relatively isolated desktops, where they are the only author for most of the content. if someone email’s them a document, it will have a hard time weighing up. However, creation date/modification date would probably serve as a solid indicator of relationship, as one person can really only work on one thing at a time.
I wish I had something better to show than just this (I’m mostly writing this down so I don’t forget it in the morning 
) but I’ve determined that we need a deeper dimension of weight on relationship weighting (when scoring). While one possibility is to just add another variable to our existing weight-determination system, I am leaning towards something more broad. What if the programmer only had to specify a relationship, and through a combination of its occurrence, how closely it paralleled term-based similarity, and how often that relationship type was used to rank a selected result (would require gui integration, but for this proof of concept thats ok in my head) to build an individualized weight for each relationship.
All of a sudden, the massive programmer burden of a relational ranking system is removed! (it takes a lot of specific code to handle each relationship and its weights/different characteristics properly) While there would be a massive front-end cost to tweaking and tuning the system which determines those individual relationship weights, it would be time well spent, as new data types/sources are added, there is no additional work beyond declaring/mapping the relevant relationships.
Once the sun has actually risen, I’ll try to start the process of actually codifying what I’m trying to say. If I’ve actually made enough sense that anyone understands what I’m getting at and has any thoughts/comments/criticisms, please share!
It looks like the monster might finally start to lay itself to rest. After almost 2 years, one of the most basic feature requests for Banshee looks like it will finally be fulfilled. I’m talking about playlist syncing to iPods. While there have been a plethora of patches in varying states of readiness always floating around, it just never got into trunk. I am very pleased to have checked in a working (and building at the moment) patch which enables the management of iPod playlists though banshee.
I know that the patch has been in better shape, there were a dozen different times that a commit might have made sense, but in the end, ipod-sharp is a moving target, and trying to hit it and Banshee with stable API’s at the same time (without a freeze ) has proven to be quite difficult (no hard feelings to the Banshee dev’s they keep new features coming, and fast). Anyways, there are a few known bugs with this patch, most of which (in my super-limited testing) stem from ipod-sharp being in the middle of an API shift, and trunk isn’t working.
Anyways, I wanted to make a list of Features and Bugs, namely so the 2 don’t get confused, since a big part of this patch was trying to determine exactly what ‘expected behavior’ was, theres a lot of room to grow.
Known Bugs
- Major Performance Issues - This just needed to eventually go in, and maybe the new ipod-sharp api will have a better solution, but I started working on this, everything (meaning the entire music library) must be iterated over to find a corresponding track. Some preliminary work was done to get more content sorted/hashed, but theres still a lot of work to do here.
- Double Tracks on IPod - Depending on your version of ipod-sharp, and what random steps you take to get things building against your version, there is a common issue where a Playlist Dragged from the Library onto an iPod will result in duplicates of every song in the playlist on the iPod. This should be easy enough to track down if someone just has the time and patience.
- New ipod-sharp API - As there will eventually be a new ipod-sharp API, someone needs to migrate the current logic to the new API, should be mostly the same except for the device detection logic.
Behavior Issues/Features
- A Playlist from the Library to the iPod with the same name will result in the iPod version being overwritten.
- Dragging a track from the library to a iPod playlist will result in that track being copied to the iPod again
- Click and Drag support for playlist’s on iPod, its recommended that you drag songs from the iPod’s library
- Rename of iPod playlists
- Does not synchronize all library playlists to iPod automatically, only those which are placed onto the iPod
I think thats most of it, once iPod support in Banshee has leveled out a little bit, I plan on adding support for On-The-Go playlists and Smart Playlists. Anyways, I know that its far from a perfect commit, but after porting this patch through so many API changes, design shifts, and general bitrot, I really just wanted to get it out of Bugzilla.
The obligatory screenshot:
Note: I’ve tested this with the latest iPod Firmware, if you run the Hash tool as you normally would, it should work fine.
Today I checked in a few fun changes to Beagle today focused on the idea of emphasizing relationships between entities. It doesn’t sound like a whole lot of fun, but its kinda nifty.
New Query Context Options
- Find Documents by same author.
- Find E-mails from same contact.
- Find Pages from same site.
In addition (building upon Beagle’s new External Metadata system) I have added support for the tracking of Firefox downloads to files. The file downloaded with Firefox has an extra property (beagle:Origin) which denotes the Url it was downloaded from. I haven’t started to integrate anything on the UI side with this new information, as I want to add support for Epiphany, Opera, and Konqeror. Eventually, I would love to see this kind of mapping from downloaded mail attachments, but thats a little more difficult.
Anyways, this is more work towards my eventual goal of a ranking system based upon relationships (among desktop data). Anyways, I know that no feature-centric blog post is complete without screenshots, so I present:
Beagle’s powerful and simple query language makes stuff like this really easy, its just a matter of knowing what properties warrant special treatment like this. I’m open to ideas, what
I’ve been working on and off on a writeup concerning the use of Beagle to build an intelligent ‘rank’ for desktop entities. Or, in short, a Ranking system (not unlike Page Rank or the like) to organize desktop search results by far more than just keyword/date. I know the writing sucks, and its not 100% complete yet. In addition, I don’t have much in terms of code to share (yet).
To summarize (for those lazybones out there) I’m thinking of utilizing fairly universal and constant relationships (Creator, Creation Date, Modification Date(s), Parent/Source, and maybe others) to recurse deep into desktop relationships. By adding relevancy to the root hit for every child it has (logarithmically decreased by recurse iteration) we can have far more accurate desktop search results when querying a simple keyword/phrase. In addition, the children of a hit could often be considered hits themselves, if found in enough ‘root’ hits.
Its a loose and patchy idea, and miles from a realistic implementation, however, thanks to the awesomeness of Lucene, comparing 2 in-index documents for textual relevancy (based on Term Frequency) is not impossible. (I have not considered the performance elements of these comparisons yet, they may be too slow to be realistic without serious optimization)
Anyways, I’m working on it in Google Docs, so you can check out the full document here. I’ll post once I’ve finished my research/planning etc.
Please, share your thoughts! This is in the ‘major brainfart’ stage, so its open to whatever from anyone, I want to hear ideas!
Technorati Tags: beagle, desktop search, lucene, search rank, gnome, mono
Powered by ScribeFire.
Beagle support in Ubuntu has been less than stellar up until this point (across all releases), and unfortunately, the best that we can really hope for in the immediate future is acceptable. This is mostly because only a few of Beagle’s developers are running Ubuntu, and accurately reproducing common errors is difficult. To top this all off, the defacto Ubuntu contact at this point is me, and I haven’t had the available time to really track down some of the more difficult bugs.
However, this problem reached an all time low when the beagle source package stopped building in Gutsy. This spurred us into action (our urgency increasing as we realized how close Gutsy was to shipping) and as a result there exist updated Ubuntu Gutsy packages (based upon the new 0.2.18 bugfix release of Beagle) available for testing. Thanks to Launchpads new super-awesome Personal Package Archive system, you only need to add the following sources, or download from the corresponding link. (NOTE! the versioning of these debs will not force an update if they are accepted into main, you will need to reinstall should they be accepted at their current version number!)
deb http://ppa.launchpad.net/kkubasik/ubuntu gutsy maindeb-src http://ppa.launchpad.net/kkubasik/ubuntu gutsy main
Please report bugs with these packages either to Beagle in launchpad or the dashboard-hackers mailing list. The more feedback we get in the next few days the better the chance that Ubuntu Gutsy will ship a solid Beagle.
I know that the Beryl Project is fading from existence, but I still couldn’t help myself when I saw this enormous chunk of it at the Smithsonian.
Finally! Perhaps one of the last major features that Beagle needs to match Spotlight and Windows Live Search. Integration into every file choice made in the Gnome environment has long been a dream of mine, and a little less than a year ago, this bug was filed with hopes of making that dream a reality. After lots of hard work, a rough cut of the patch has been committed to the gtk+ trunk, with plans to add missing features in time.
While it will still be some time before this code reaches a Gtk+ release (development releases for the next major series start in late April) its great to feel some awesome love from our friends over at Gtk, a special thanks to Federico Mena Quintero for really being the driving force that finally got this done. What great is that plans for using Beagle’s index to help GtkFileChooser already seem underway.
For any budding Gtk+/Gnome/Beagle hackers out their, this feature still needs a lot of love. A list of bugs/todos exists here, and if someone were to get the ball rolling on anything on that list, it would be a huge help!
And last, the obligatory (if unexciting) Screenshots:
Here were searching for a Mail Attachment in Evolution.
And here we search for a file to upload in Epiphany:
Ok, since my recent post on Dashboard there has been scattered interest in helping revive/work on Dashboard, so I wanted to post a list of things Dashboard needs before we can really look at making it usable at all.
- libdashboard
- Or as its better known, a C library that generates valid, parseable clues. This is not only critical since most plugin authors aren’t going to want to spend the time validating that mono can deserialize all their XML. But because we can generate bindings for most every other language once we have them in C.
- This is a huge one, Dashboard is still pre-alpha, and mostly proof of concept. While the code base could be brought up to production level, it needs tons of cleanup. This is where an army of open source dev’s can help the most, compile and install dashboard from SVN, then just play with it, and every time it crashes, track down why, and try to make it sane. This is long, slow, tedious, and thankless work, but it is an absolute necessity if people want to start using dashboard, as even simple race cases will crash dashboard most of the time.
- You have to be a little more familiar with the Beagle/Dashboard code base to help out with this, but we need them for a huge spread of plugins, and almost everything beagle can generate.
Just a note, I posted this list on the Dashboard Wiki.
Technorati Tags: linux, gnome, dashboard, mono, beagle, search
Powered by ScribeFire.
As I find myself getting more involved with the Ubuntu community and specifically the packaging of Beagle, I decided that it might be about time to apply for official Ubuntu Membership. I always feel a little odd in these situations, much the same as when I applied for membership to the Gnome Foundation. It feels weird trying to itemize and quantify my contributions, and moreover, I’m not a very good bragger when it comes to computers.
While the application process isn’t my favorite, once I commit to it, I find that there are plenty of tools that simplify the process, my blog not being the least of these, as its a nice reminder of what I have worked on. The harder part is deciding when its appropriate to apply, most guidelines on such topics are pretty vague, and to compound things, the most visible members tend to be hacker rockstars that are so above and beyond the accepted norm for membership that intimidation is almost impossible to avoid. I don’t mean any of this as a critique or attack, just my personal feelings and observations as someone slowly getting more involved in the community.
But I digress, The purpose of this post was to ask for anyone who was willing to give a quick glance over my wiki page at Ubuntu (its more or less your resume near as I can tell) to do so, and if willing, share their feedback. The next Community Council meeting isn’t until April 17th, so theres plenty of time. I would appreciate any of the following:
- Feedback on if I am applying too early (ie. not enough Ubuntu experience)
- Feedback on wiki page (formatting flukes, missed information, broken links etc)
- Anything I might have worked with you on, but forgot to include
- General Comments on life and/or its meaning
So yeah, I appreciate any feedback I can get!
Technorati Tags: gnome, ubuntu, linux, membership, gnome foundation,
Powered by ScribeFire.
Recent Comments