Ondrej Riha | 23 Jan 21:54 2015

wrong path when uninstalling trinity on Ubuntu 14.04

When uninstalling on Ubuntu 14.04 there are some errors:

Removing konsole-trinity (4:14.0.0-r1865-0ubuntu14.04.0+pr185) ...
/var/lib/dpkg/info/konsole-trinity.prerm: 22: /var/lib/dpkg/info/konsole-tr=
inity.prerm: /usr/sbin/update-alternatives: not found
dpkg: error processing package konsole-trinity (--purge):
podproces nain=B9talovan=FD skript pre-removal vr=E1til chybov=FD k=F3d 12=
7
Removing ksmserver-trinity (4:14.0.0-r1865-0ubuntu14.04.0+pr185) ...
/var/lib/dpkg/info/ksmserver-trinity.prerm: 22: /var/lib/dpkg/info/ksmserve=
r-trinity.prerm: /usr/sbin/update-alternatives: not found
dpkg: error processing package ksmserver-trinity (--purge):
podproces nain=B9talovan=FD skript pre-removal vr=E1til chybov=FD k=F3d 12=
7
Removing twin-trinity (4:14.0.0-r1865-0ubuntu14.04.0+pr185) ...
/var/lib/dpkg/info/twin-trinity.prerm: 22: /var/lib/dpkg/info/twin-trinity.=
prerm: /usr/sbin/update-alternatives: not found
dpkg: error processing package twin-trinity (--purge):
podproces installed script pre-removal returned error code 127
There are some errors during uninstall:
konsole-trinity
ksmserver-trinity
twin-trinity

There may be some other errors.

update-alternatives is in /usr/bin and not in /usr/sbin
$ whereis update-alternatives
update-alternatives: /usr/bin/update-alternatives /usr/bin/X11/update-alter=
natives /usr/share/man/man8/update-alternatives.8.gz


Thanks.
OR
Michele Calgaro | 21 Jan 08:37 2015
Picon

Protocol section empty in the Help system


If I open the Help system and look inside the "Protocol" section, I see just a message "Information about the
available protocols". I remember that some months ago there used to be a list of the available protocols in
the system.
I see the same problem both on my system (Jessie, local TDE build) and in a VM machine (Wheezy, official R14.0.0).
Is anyone else seeing this? If so I will open a proper bug report.

Thanks
  Michele
Slávek Banko | 17 Jan 20:15 2015
Picon

Removal of tde-packaging branch 'suse'

Hi all,

I propose to remove the branch 'suse' of tde-packaging. This branch is 
unused / unmaintained and is generally incorrect. For each distribution is 
intended folder, not a branch. Exactly as are maintained packages for 
OpenSUSE by François.

Therefore I consider branch 'suse' suitable for disposal.
Any objections?

--

-- 
Slávek

Jean Milot | 15 Jan 21:14 2015
Picon

Trinity Desktop on PowerPC

Hello,

I would like to install tde on PowerPC.

Someone could help me?

Sincerely,

Jean

--
Darrell | 15 Jan 05:08 2015
Picon

git pretty format

I lost git pretty format. Now all I see is a bunch of ESC[m characters. I haven't knowingly changed anything
at my end so what happened to the formatting with the Trinity repo?

Darrell

Slávek Banko | 17 Jan 15:56 2015
Picon

Re: Codebase formatting discussion

On Tuesday 13 of January 2015 00:25:15 Timothy Pearson wrote:
> > Forcing parenthesis everywhere can make code more difficult to read
> > sometimes, as in:
> >
> > if ((a == 3) || (b == 5) || (c == 4))
> > vs
> > if (a == 3 || b == 5 || c == 4)
> >
> > So I also favor the "best legibility" rule. Let's restate it as something
> > like "the minimum number of parenthesis that
> > clearly isolate a conditional logic block. Example:
> >
> > Right: if (a == 3 || (b == 5 && d != 20) || c == 4)
> > Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
>
> The problem with allowing these is that if I need to refactor the code to
> add in a single conditional I need to add parenthesis, which a.) is an
> additional source of error and b.) messes up the difference tracking
> making it hard for other developers to see what the functional change was.
>  I think I'm going to override you on this one and force the parenthesis.
> ;-)

Ok, I understand and accept.

--

-- 
Slávek

Slávek Banko | 17 Jan 15:52 2015
Picon

Re: Codebase formatting discussion

On Sunday 11 of January 2015 22:20:50 Timothy Pearson wrote:
> > This is of course subjective and not a big deal for me as well (I have
> > already worked with both style actually).
> > Mostly two reasons:
> > 1) the operator at the end of the line tells me immediately that the
> > conditional expression is not over and I need to
> > continue reading the next line
>
> Wouldn't the lack of a curly brace state the same thing, given our rules
> on curly braces?
>
> > 2) logically easier to read complex statement. For example
> >
> > if (a == 3 &&
> >     (b == 5 || c == 4 ||
> >     (d == 10 && e == 20)))
> >
> > rather than:
> >
> > if (a == 3
> >     && (b == 5 || c == 4
> >
> >
> > I find the second one more prone to misinterpretation, since the || in
> > the 3rd row might look at the same level as the
> > && in the second row at first sight. And in TDE I have seen some rather
> > complex and long ifs :-)
> > Just my 2 cents, let's see what Slavek thinks as well.
>
> Point taken.  However, I think we need to add a rule as well that states
> all conditionals must be enclosed in parenthesis; I have cleaned up so
> many compiler warnings and so much buggy code becase of lazy programmers
> in this respect that I don't want to see another unenclosed conditional.
> ;-)
> If this rule is enforced, your second example becomes:
> if ((a == 3)
>     && ((b == 5) || (c == 4)
>
>
> which is a bit easier to read, but overall this style is still harder to
> read than your first example when more than one condition is present on
> one line.  Perhaps we should allow both styles and simply state that the
> style providing "best legibility" should be used?
>
> The number of long/complex ifs in the codebase are why I am insisting this
> be hammered out properly. :-)  We haven't head from Slavek in a while so I
> guess we'll keep drawing up the specification and he can review it and
> comment when he has time.

For me also are certainly more readable operators at the end of the line, 
rather than at beginning. The only case where I'm used to using the operators 
at the beginning of the line is sql where I use words operators (and, 
or, ...) instead of symbols.

By the way, in my usual style I'm used to indent brackets also in conditions, 
which from my perspective clarifies their nesting. For example:

if (a == 3 &&
    (b == 5 || c == 4 ||
     (d == 10 && e == 20)) &&
    (f == 15 || g == 25)) {
}

if (a == 3 && (b == 5 || c == 4 ||
               (d == 10 && e == 20)) &&
    (f == 15 || g == 25)) {
}

> Forcing parenthesis everywhere can make code more difficult to read
> sometimes, as in:
>
> if ((a == 3) || (b == 5) || (c == 4))
> vs
> if (a == 3 || b == 5 || c == 4)
>
> So I also favor the "best legibility" rule. Let's restate it as something
> like "the minimum number of parenthesis that clearly isolate a conditional
> logic block. Example:
>
> Right: if (a == 3 || (b == 5 && d != 20) || c == 4)
> Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)

In this I agree with Michele.

--

-- 
Slávek

Slávek Banko | 17 Jan 15:30 2015
Picon

Re: Codebase formatting discussion

First of all: I was in earlier days very busy, so I did not manage to follow 
and respond to the debate on coding style. Now I will try gradually respond 
to individual discussed cases.

On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
> Ah, OK, that is a valid complaint.  The case style shown above is fine and
> we'll go with that.
>
> My only remaining question then is should we also be forcing whitespace
> between each case block for legibility, something like this?
>
> do_something();
> switch(foo)  {
>     case bar:
>         a=1;
>         break;
>
>     case baz: {
>         a=2;
>         ...long case block...
>         c=4;
>         break;
>     }
>
>     case asd:
>         a=3;
>         break;
>
>     default:
>         a=0;
> }
> do_something_else();

Here I would like to advocate for the previously mentioned principle braces 
even where they are not required. By this I mean that each 'case' consider as 
block => each case should to have brackets, including 'default':

do_something();
switch(foo)  {
    case bar: {
        a=1;
        break;
    }

    case baz: {
        a=2;
        ...long case block...
        c=4;
        break;
    }

    case asd: {
        a=3;
        break;
    }

    default: {
        a=0;
    }
}
do_something_else();

The advantage is that regardless of the size of the 'case' is easily traceable 
beginning of the block => editor can be used to trace paired brackets. With 
this would also not need white space between each 'case'. By the way, I wont 
give white space anyway. :)

--

-- 
Slávek

Slávek Banko | 17 Jan 15:59 2015
Picon

Re: Codebase formatting discussion

On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
> >> Also on the docket are how to handle simple variable assignments; there
> >> are several ways I've seen: a=2; a = 2; a=
> >> 2; a =2;
> >>
> >> I'm fairly undecided on this.  For consistency with larger statements "a
> >> = 1;" should probably be used but it seems
> >> such a waste of space compared with "a=1;".  Thoughts?
> >
> > Both "a=1" and "a = 1" are fine for me. For long time I used the first
> > way, but in the last couple of years I switched
> > ti the second one: usually more readable for simple expressions but can
> > become confusing with long and complex ones
> > such as:
> > if ((a = 2) && (++b != (c + (x * y) / f(q,w,e))))
> > Choice is up to you and Slavek.
>
> I'm going to lean towards forcing spaces for consistency.  What is your
> opinion Slavek?

Yes, with spaces - in my view certainly readable.

--

-- 
Slávek

Slávek Banko | 17 Jan 16:14 2015
Picon

Re: Codebase formatting discussion

On Friday 09 of January 2015 03:40:45 Timothy Pearson wrote:
> This is the current consensus as far as I can tell:
> 1.) Every conditional uses braces
> 2.) Hard tabs
> 3.) Conditional indentation like so:
>
> if (foo) {
>     a=0;
> }
> else if (bar) {
>     a=1;
> }
> else {
>     a=2;
> }

Incidentally, the 'else' is block like everyone other, so it "should have" 
their own brackets and indentation:

if (foo) {
    a=0;
}
else {
    if (bar) {
        a=1;
    }
    else {
        a=2;
    }
}

I understand that in cases of use strictly as 'elseif' is acceptable to omit 
the brackets. However, only I'm not sure if complicated cases are a source of 
compiler warnings 'ambiguous else'.

--

-- 
Slávek

Darrell | 4 May 19:12 2014
Picon

Taskbar icons

When changing the panel height from 37 to 38 pixels, the taskbar icon buttons start stacking. Is there a way
to stop that stacking behavior?


Gmane