Idea for SoC propsal

Tue Apr 1 14:45:10 CEST 2008

>
> Anyway, I went through both your proposal and Matej's a few mins ago
> and I'll provide feedback soon. I noticed your latest draft is quite
> different from the first one you posted and as of now it conflicts
> with mine :-S (the first one didn't).

I am not sure if you are talking with me. Anyway, if you are going to make
any work in krunner, I am interested in talk with you. If 3 of us are going
to work on krunner, we'll need quite a bit of talking.  I wait your
comments. Also, I use to be in #plasma and #kde-devel, my nick is
surprisingly jordi.

And in a someone unrelated comment, as expected, multilingualism is a
difficult goal. I've been playing with some ideas in the calculator runner
(this runner may be the most difficult one in term of syntax, that's why I
started testing ideas there).

Right now the CalculatorRunner will run the text input as qscript code. What
make it very simple but confuses users who generally expect some more user
oriented math language (programming languages make its decisions on syntax
knowing they will be used by programmers).

I've tried to write a small parser. Even working for simple cases it gets
crazy easily ( math expresions can be intrincate ...)

And of course multilinguism is a problem even in a "restricted" domain as
maths. In spanish we don't use "sin 30" but "sen 30".  I also wanted to
implement the google command "X% of Y", which is easy but Japanese will find
it really awkward (I don 't think they can get used to it) because they say
"YnoX%".

So the only solution is go to a pure mathematical usage (I'll send a patch
when ready).
The mathematical language has evolved to become universal at least for
signs, operant positions and the like. If someone knows exceptions on this,
please tell me.
The "sen" example of spanish is considered an alternative to "sin" (though
I'm spanish and I didn't know about "sen" not being the standard Spanish
name).

Summary: Defining the language beforehand is a much better idea although
less flexible than letting the task to each application.

> Anyway, I like what you're
> proposing. Intelligence in a launcher program is something I wanted to
> implement. I tried a limited version back in my fork of Katapult but
> focused on multithreading and the infrastructure for KRunner last
> year. But I like what I see so far. :)
>
> Ryan
>
> 2008/3/31 Jordi Polo <mumismo at gmail.com>:
> >
> > Your proposal has striking similarities to mine:
> > http://www.bahasara.org/raw-attachment/wiki/Papers/gsoc.txt
> >
> > It seems that even when both want to push krunner forward, you are more
> > interested in the performance of the future krunner and I am more
> interested
> > in the integration with the rest of KDE and the command input.
> >
> > You wrote that ranking will be the most time consuming operation. I
> really
> > see discovering the type of information or other text manipulation task
> as
> > more consuming than ranking. Keep track of most used runners, add
> > blacklisting and priority and rank according to that should not take a
> lot
> > of time (guess what the kernel does with memory pages...)
> >
> > I do like your idea of the runners being able of somehow present
> themselves
> > and their syntax.
> >
> >
> > On Mon, Mar 31, 2008 at 5:53 AM, Matej Svejda <mata at aw-modell.at> wrote:
> >
> > > Am Sonntag, 30. März 2008 21:48:58 schrieb Aaron J. Seigo:
> > >
> > > > please be sure to file this soon enough on
> > http://code.google.com/soc2008
> > > > so that you don't miss the deadline. now.. feedback:
> > > Already did.
> > >
> > >
> > > > just to be clear, this won't work for all slow runners. i'm not even
> > sure
> > > > this will help at all since these runners should be checking for
> this
> > catch
> > > > word and returning immediately if it doesn't exist anyways. what
> this
> > would
> > > > save is starting them in the thread; i'm not sure that's really a
> > > > bottleneck.
> > > You're right. That's not really a bottleneck. But still if the
> catch-word
> > was
> > > made configurable there is no real reason why a runner that only
> reacts to
> > a
> > > catch-word should be instanciated an do the logic itself. This can be
> done
> > by
> > > the manager-class. While this won't have a (noticable) impact on speed
> it
> > > would at least mean less work for the runner-programmers.
> > > I tried to clear that up a bit in my proposal.
> > >
> > >
> > > > the runner classes will remain part of libplasma. there's no
> material
> > > > benefit to having a second library just for this functionality,
> thought
> > > > having separate libraries to link against will increase the time to
> > > > startup.
> > > Ok. Changed that.
> > >
> > > Thanks for your input!
> > >
> > > Matej
> > >
> > >
> > >
> > > _______________________________________________
> > > Panel-devel mailing list
> > > Panel-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/panel-devel
> > >
> >
> >
> >
> > --
> > Jordi Polo Carres
> > NLP laboratory - NAIST
> > http://www.bahasara.org
> >
> > _______________________________________________
> >  Panel-devel mailing list
> >  Panel-devel at kde.org
> >  https://mail.kde.org/mailman/listinfo/panel-devel
> >
> >
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>

-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080401/d297a475/attachment.html 