<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Speaking of stupid mistakes and KDevelop3 bugs</title>
	<atom:link href="http://apaku.wordpress.com/2008/02/28/speaking-of-stupid-mistakes-and-kdevelop3-bugs/feed/" rel="self" type="application/rss+xml" />
	<link>http://apaku.wordpress.com/2008/02/28/speaking-of-stupid-mistakes-and-kdevelop3-bugs/</link>
	<description>Thoughts, Ideas and Comments (mostly about KDE/KDevelop)</description>
	<pubDate>Sun, 27 Jul 2008 08:39:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=MU</generator>
		<item>
		<title>By: apaku</title>
		<link>http://apaku.wordpress.com/2008/02/28/speaking-of-stupid-mistakes-and-kdevelop3-bugs/#comment-625</link>
		<dc:creator>apaku</dc:creator>
		<pubDate>Fri, 29 Feb 2008 11:38:28 +0000</pubDate>
		<guid isPermaLink="false">http://apaku.wordpress.com/?p=52#comment-625</guid>
		<description>No there's no unit test. In fact KDevelop3 has no unit tests at all. (at least none that I'm aware of).

IIRC we recently removed some of the filtering from the make output as it was getting really slow for lots of output. svn log on parts/outputviews/ should show you the commit.

All the filtering logic is in that directory.</description>
		<content:encoded><![CDATA[<p>No there&#8217;s no unit test. In fact KDevelop3 has no unit tests at all. (at least none that I&#8217;m aware of).</p>
<p>IIRC we recently removed some of the filtering from the make output as it was getting really slow for lots of output. svn log on parts/outputviews/ should show you the commit.</p>
<p>All the filtering logic is in that directory.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Fee</title>
		<link>http://apaku.wordpress.com/2008/02/28/speaking-of-stupid-mistakes-and-kdevelop3-bugs/#comment-624</link>
		<dc:creator>Paul Fee</dc:creator>
		<pubDate>Fri, 29 Feb 2008 10:00:06 +0000</pubDate>
		<guid isPermaLink="false">http://apaku.wordpress.com/?p=52#comment-624</guid>
		<description>Hello,

Is there a unit test for the Messages outputview.

I assume KDevelop forks the child make process and then reads in the stdout and stderr which are produced.

Therefore to test this, the make could be replaced with an invocation of a simple script which produces various messages on stdout and stderr.

I often build systems with very noisy output.  KDevelop is great with its "Very short compiler output" mode.

Without this warnings got buried in thousands of lines of informational text.  Therefore it's a strong reason for people to use this IDE instead of the command line.

Some time between KDevelop 3.5.0 and 3.5.1, the behaviour of "Very short compiler output" changed and it no longer condenses the output as efficiently as it did before (for my build at least).

Since "very short" is a matter of opinion, do you have a set of rules against which this feature should operate?

With a set of requirements we could then have tests to ensure we don't get regressions from previous releases.

If these exist already, could you point out where they are.

I'd like to fix this so any help is appreciated.  It's also good to know that KDevelop3 is still open for fixes.

Thanks,
Paul</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>Is there a unit test for the Messages outputview.</p>
<p>I assume KDevelop forks the child make process and then reads in the stdout and stderr which are produced.</p>
<p>Therefore to test this, the make could be replaced with an invocation of a simple script which produces various messages on stdout and stderr.</p>
<p>I often build systems with very noisy output.  KDevelop is great with its &#8220;Very short compiler output&#8221; mode.</p>
<p>Without this warnings got buried in thousands of lines of informational text.  Therefore it&#8217;s a strong reason for people to use this IDE instead of the command line.</p>
<p>Some time between KDevelop 3.5.0 and 3.5.1, the behaviour of &#8220;Very short compiler output&#8221; changed and it no longer condenses the output as efficiently as it did before (for my build at least).</p>
<p>Since &#8220;very short&#8221; is a matter of opinion, do you have a set of rules against which this feature should operate?</p>
<p>With a set of requirements we could then have tests to ensure we don&#8217;t get regressions from previous releases.</p>
<p>If these exist already, could you point out where they are.</p>
<p>I&#8217;d like to fix this so any help is appreciated.  It&#8217;s also good to know that KDevelop3 is still open for fixes.</p>
<p>Thanks,<br />
Paul</p>
]]></content:encoded>
	</item>
</channel>
</rss>
