Hey all!
Just a quick note: Niko and me moved PHP & PHP-Docs to kdereview, we hope to move both plugins to extragear/sdk/kdevelop-plugins. So, if I understood things correctly, after a two week period the plugins will get moved there (well, if we pass the review, but I think we can do that).
So for anybody that uses the plugins from SVN, you’ll have to relocate. The new addresses are:
/trunk/kdereview/kdevelop-php/trunk/kdereview/kdevelop-php-docs
See you in two weeks :)
continue reading...
Hey everybody!
If you are a KDevelop and/or Kate/Kwrite developer and do not read the mailing lists: There’s a hack sprint coming up in Berlin in 2010. I think there’ve been enough sprints in Berlin already so that you know it’s a great city for such an event. Though this time it won’t be at KDAB or Nokia offices, but at the Physics Faculty of the FU-Berlin. Since I (currently) work there as an IT admin, it was my first choice and worked out. I hope it will be a good location for the meeting. If you want to attend, vote on doodle:
http://www.doodle.com/vkyh9up9794zr4s8
But you probably also should register either on the KDevelop or KWrite mailing lists so I have some kind of way to contact you.
PS: in unrelated news I’ll do an internship at KDAB next year! yay
continue reading...
Good news everyone :)
Documentation
After years of pretty much no documentation (except looking at the sources… ), The_User aka. Jonathan Schmidt-Dominé started documenting the parser generator that is used for most KDevelop language plugins (java, python, php, …). You can find it here: http://techbase.kde.org/Development/KDevelop-PG-Qt_Introduction
It has to be improved and more examples have to be put in there, but it’s already a huge improvement over the situation before…
In related news I did some profiling on the parsing of the quite big file that includes all internal PHP declarations (i.e. all functions, classes, definitions,…). It drops in at a whopping 1.9M, with ~80k lines. Well, turns out that this showed a pretty easy to fix bottleneck in KDevelop-PG’s LocationTable, which used to use a linear lookup algorithm. Profiling showed that nearly 75% was spent in that function. But I used the past tense for a reason:
I replaced it with an algorithm that combines a relative search (i.e. relative to the last lookup) with a binary search fallback. That’s comparatively blazingly fast. I added some benchmarks to KDevelop-PG-Qt that proofs that (benchmark below run with release mode build):
continue reading...
Quassel is really a cool program. I like how I can use it from everywhere and access the same set of data. Now using IMAP and Quassel I’d really look forward for similar shared access to other IMs, but that’s not the topic of this blog post.
What I want to introduce is a new addition to my set of shell helpers, called quassellog:
$ quassellog -u milian -b "#kdevelop" | tail -n 1
[2009-08-27 13:09:11] milian > hi all
$ quassellog -b "#kdevelop" | tail -n 1
[2009-08-27 16:43:35] Fersis!n=Fersis@190.245.176.231 > yeah i did
$ quassellog
quassellog [-u USER] [-b BUFFER] [PATTERN]
-u USER show only messages from users, who have USER at
the start of their sender name.
-b BUFFER show only messages in this buffer
valid buffers are:
##linux #khtml &IMP ...SNIP...
PATTERN a simple pattern, use * for wildcard matching
NOTE: order of options is not exchangable, i.e. first -u, then -b then pattern...
continue reading...
So, I kinda messed up my desktop right after the upgrade to karmic, because I was too greedy for performance and converted my root file system to ext4. Well, that worked like a charm on my laptop, but it broke my desktop. This is in no way karmic’s fault, it’s my own misbehavior. Thankfully I could rescue most of my data.
Since I’d had to reinstall anyways, I decided to finally try out Archlinux. I find the rolling release mantra very intriguing. Together with a “simpler” packaging, namely no splitting between -dev and -dbg packages like debian/ubuntu does, this is destined to be a good environment for a developer. I always hated it to track down missing -dev packages when compiling software. And don’t get me started on outdated software in repos… I just compiled kdelibs and the only missing build dependency was hspell, that I don’t need anyways. Under Jaunty I had to compile stuff from kdesupport to fulfill updated dependencies. And the list of not-found optional dependencies was huge, since I did not spent time to install all those -dev packages by hand…
continue reading...
Hi there again! I’ve been silent again on my blog, but didn’t rest on development. In the one and a half months since the last digest, I started writing a PHP application This finally made me eat my own dog food :). It resulted in lots of polishing and quite a few bug fixes for the PHP plugin in KDevelop. Here’s a list of what I think are the notably changes since the last digest:
(Note: to view screenshots, go to the bottom of this article.)
- refactoring of parts of the Code Completion code, should already result in faster code under certain situations
- properly mark constants as “Kind: Constant” in the declaration tooltips
- offer argument hints for ctors during code completion in class init statements
- greatly improve the generate inline documentation of built-in PHP functions, classes, properties etc. pp.
- add documentation of public properties
- support aliased functions (thanks to Victor Grischenko for his patch)
- show more/all documentation, and not only the first paragraph
- fix type-lookup
- don’t get confused when a documentation file documents both, a method and a function (greatly improves e.g. MySQLi documentation)
- don’t offer “jump to declaration” for built-in PHP declarations
- add support for
list(...) statement - cleanup code-completion list, esp. show the return type of functions in the prefix field, and not something a la “function ReturnType ($arg1, $arg2, …)”
- improve the code-completion for include/require statements
- add language constructs to code completion (e.g. class, while, foreach, print, …)
- show declaration tooltip for magic constants, showing their current value
- make functions, methods and classes case-insensitive, just like PHP handles them
- some performance improvements, especially in code completion and parsing of the generated file containing php-internal declarations
- lots of bug fixes, don’t want to iterate them all ;-)
continue reading...
Just a quicky: I wrote a little plugin for KTextEditor which supplies you with basic error checking when you save documents. Currently only PHP (via php -l) and JavaScript (via JavaScript Lint) are supported.
Screenshots
Requirements
- usual tools for compiling C++, e.g. gcc.
- cmake
- Qt development packages, i.e. under Ubuntu:
sudo aptitude install libqt4-dev - KDE 4.2 with development packages for kdelibs and kdebase, i.e. under Ubuntu:
sudo aptitude install kdebase-dev kdebase-workspace-dev kdelibs5-dev. Note: You’ll need the experimental KDE 4.2 packages activated as of now, see for example the Kubuntu news on KDE 4.2 RC1 for hints. - proper setup of environment variables, read this techbase article for more information. the
.bashrc linked there should be enough for most people - For PHP support: a PHP executable which supports the
-l switch for linting - For JavaScript support: a JavaScript Lint executable, you could download and compile the sources for example.
continue reading...
Not only KDevelop gets better and better PHP support — the Kate PHP syntax file also got a few new features and fixes over the last weeks. The good thing is of course that all users of KWrite, Kate, Quanta, KDevelop and other editors leveraging the Katepart benefit from these changes.
Improved HereDocs
screenshot of improved highlighting in PHP heredocs
I went over PHP related bugs on bugs.kde.org today and spotted one that was fairly easy to fix:
continue reading...
So, after a period of silence I present you an unsorted list of features and bug fixes I did to the PHP plugin for KDevelop in the last few weeks:
added support for path autocompletion after require / include statements: This shares code with the Cpp plugin and it’s completion after #include. I plan to use this autocompletion eventually also for functions accepting filenames or paths. Think of fopen, file_get_contents etc. pp. So far only URLs that are covered by an open project can be completed. We will need support for custom include paths so we can support e.g. global PEAR or framework installations.
worked around a bug where the “schedule all project files for parsing” had no affect. Apaku is currently working on making some internal changes so I can remove the workaround and fix this properly. With this fixed/worked around you should retry the PHP plugin along with frameworks or similar to see how well it works. Just make sure to have the framework inside your project so it gets parsed.
continue reading...
When I’m messing around with config files on the command line my editor of choice is Nano. It’s simple, fast and pretty much straight forward. You don’t have to learn any commands and can use keyboard shortcuts just like in GUI programs.
Settings
Today I had a look on the project website and saw that there are tons of settings which I really missed before. Just have a look into your /etc/nanorc for a default config file with all settings and their default values. Here are those I like most:
- smooth (scrolling)
- autoindent
- mouse (though I use it rarely)
- smarthome
- tabsize (8 is far to much, I love 4)
Syntax Highlighting
Yes! Nano supports syntax highlighting! And I never knew it, but heck - it’s never to late. Not for neat features like this one, though I really wonder why this is not activated by default…
In the aforementioned /etc/nanorc are already some default languages which just wait to be commented out. You might also want to have a look into /usr/share/nano, there are some languages you can include in your nanorc file with:
continue reading...
