Mark de Wever | 1 Jan 2009 15:43
Picon
Picon
Favicon

Scrollbar behaviour

Hi all, 

First of all best wishes.

Second a question about the listboxes. In the old language selection
dialog the listbox scrolled down in steps of a language at the time. My
current implementation scrolls fluently. (The version in 1.5.7 contains
some redraw glitches, which are fixed in trunk.)

For the addons we'll get items with different heights [1] so it won't be
possible to do a 'stepped' scrolling in that dialog.

So I want to make all lists to scroll fluently and no longer stepped.
Anybody who thinks the stepped version looks better? If we implement the
stepped version it will cause some listboxes to scroll fluent and some
that scroll stepped, which IMO is a bad idea. (Of course 1.6 will have a
mixture, but I hope we manage to convert all dialogs before 1.8)

[1] http://www.wesnoth.org/wiki/GUI#Campaign_download_Dialog

--

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew
Eric S. Raymond | 2 Jan 2009 16:19
Picon

1.7 design direction and the great Python shift

We have been presented with what I think is a very important
opportunity.  

A potential contributor, Ivan Illarionov, reports that he has
translated a substantial portion of Wesnoth into Python and has a
version running with several key framework classes in Python.  In his
words: "It replaces parts of WML and parts of C++, and yes, game
controller, play controller are all implemented in Python, only core
game engine is C++"

This cracks open a problem I've been thinking about for months but
have not been able to make headway on because I've been too busy
fighting fires: Moving as much as possible of the Wesnoth codebase
out of C++ to Python.

== Pros and Cons of Python ==

Sirp agreed in principle on IRC with moving the Wesnoth codebase
towards Python many months ago, basically in order to attract a larger
population of developers - because, even though Sirp doesn't
particularly *like* Python, he knows it's more accessible than C++.

I will note for the record that though I personally *like* Python and
have come to dislike C++ intensely since learning it for Wesnoth,
these are not actually the reasons uppermost in my mind for wanting to
merge Illarionov's code. Nor is Sirp's reason. Here is how I view the
tradeoffs:

The main reason to hesitate before moving core code to Python is that
it will require Wesnoth developers to know two languages before
(Continue reading)

jeremy rosen | 2 Jan 2009 17:03
Picon
Picon

Re: 1.7 design direction and the great Python shift

I don't have an opinion on the subject yet, but here are a few ideas
that crossed my mind while reading...

1) I don't know python. I know ~20 programming languages last time I
counted so I'm not worried about that

2) interpreted languages are not inherently slower, however I disagree
with ESR in that machine are getting faster... not for wesnoth. We do
have a handheld community with pentium-class machines, and we should
take them into account

3) portability of python is ok, we already have it since the python AI

4) btw, how does it integrate with the python AI ?

5) I'm not very clear on what was implemented and what wasn't, the
kind of job porting require what parts are impacted, what kind of job
we're going into... remember I don't know python

6) what about gettext ? do we need to worry about it, or will it work the same ?

please try to be objective (esp about point 5) I'm ready to do the
move if I'm convinced, but I don't want to regret it...

On Fri, Jan 2, 2009 at 4:19 PM, Eric S. Raymond <esr <at> snark.thyrsus.com> wrote:
> We have been presented with what I think is a very important
> opportunity.
>
> A potential contributor, Ivan Illarionov, reports that he has
> translated a substantial portion of Wesnoth into Python and has a
(Continue reading)

Ivan Illarionov | 2 Jan 2009 17:16
Picon

Re: 1.7 design direction and the great Python shift

High everybody!

Let me introduce myself, my name is Ivan, I live in Russia.

I work hard on that python thing Eric is talking about
It's work-in-progress -- it's far from complete

Bye, see my code at http://github.com/ii/wesnoth/tree/wespython
Mark de Wever | 2 Jan 2009 17:25
Picon
Picon
Favicon

Re: 1.7 design direction and the great Python shift

A short word ahead, since I'm quite busy to get things done for 1.6 I
won't review the code Ivan wrote until after 1.6 has been shipped. The
current code is >15.000 lines, which is huge to review. Which also means
if we change to python most core devs need to relearn the code.

On Fri, Jan 02, 2009 at 10:19:26AM -0500, Eric S. Raymond wrote:
> Sirp agreed in principle on IRC with moving the Wesnoth codebase
> towards Python many months ago, basically in order to attract a larger
> population of developers - because, even though Sirp doesn't
> particularly *like* Python, he knows it's more accessible than C++.

I think such a big move should be agreed by all current core devs and
should be considered carefully. Why do you think Wesnoth will attract
more developers if it's a Python project?

> I will note for the record that though I personally *like* Python and
> have come to dislike C++ intensely since learning it for Wesnoth,
> these are not actually the reasons uppermost in my mind for wanting to
> merge Illarionov's code. Nor is Sirp's reason. Here is how I view the
> tradeoffs:

I have worked with Python and to be honest I'm not really thrilled. My
biggest problem with Python is the type safety. I had some code that
'compiled' without problem but at runtime it had a hard crash due to
invalid types. This kind of problem doesn't happen in C++ since it won't
compile.

> The main reason to hesitate before moving core code to Python is that
> it will require Wesnoth developers to know two languages before
> working on the code.  I do not view this as a major problem, as Python
(Continue reading)

Eric S. Raymond | 2 Jan 2009 17:45
Picon
Gravatar

Re: 1.7 design direction and the great Python shift

jeremy rosen <jeremy.rosen <at> enst-bretagne.fr>:
> 2) interpreted languages are not inherently slower, however I disagree
> with ESR in that machine are getting faster... not for wesnoth. We do
> have a handheld community with pentium-class machines, and we should
> take them into account

We will lose some performance; Python has run-tine overhead that C++
does not.  However, we will gain it back in other ways: (a) smaller
code working set leading to fewer cache misses, (b) higher-level
optimizations in Python, including a load-only-on-demand capability
that is already confirmed by loonycyborg to speed up game
initialization a great deal.

> 4) btw, how does it integrate with the python AI ?

I don't know yet.  Perhaps Ivan will answer.

I do think that the AI is near the top of the list of targets to be
moved to Python.  As opposed, for example, to the display-handling
classes.

> 5) I'm not very clear on what was implemented and what wasn't, the
> kind of job porting require what parts are impacted, what kind of job
> we're going into... remember I don't know python

I'm still exploring this myself.  It looks like Ivan has taken an
outside-in approach, implementing game_controller and play_controller
and the other high-level logic in the main loop first and leaving the
service classes in C++ to be called from the Python.  That is, Python
has taken over the root of the static call tree with most of the
(Continue reading)

Alexander Neundorf | 2 Jan 2009 18:20
Picon
Favicon

Re: 1.7 design direction and the great Python shift

On Friday 02 January 2009, Mark de Wever wrote:
...
> > The main reason to hesitate before moving core code to Python is that
> > it will require Wesnoth developers to know two languages before
> > working on the code.  I do not view this as a major problem, as Python
> > is much easier to pick up than C++; I learned it in four days.
>
> I don't believe somebody can learn a new language and be fluent in it in
> four days. 

Yes, I agree. Four days may be enough to learn the syntax and control 
constructs etc., but surely not to learn the necessary parts from the 
necessary libraries.

...
> Some other concerns I have:
> Is Python available on all platforms we support.

Python is very portable, I think this wouldn't be a problem. What platforms do 
you have in mind ?

Alex
Martin Renold | 2 Jan 2009 18:20
Picon
Picon
Gravatar

Re: 1.7 design direction and the great Python shift

On Fri, Jan 02, 2009 at 05:25:00PM +0100, Mark de Wever wrote:
> I think such a big move should be agreed by all current core devs and
> should be considered carefully. Why do you think Wesnoth will attract
> more developers if it's a Python project?

Speaking only for myself (but as a former contributor), I'd be more excited
to contribute again if most of the codebase is in Python. I especially expect
the STL-intense code to be much more fun to work with in Python.

for(std::vector<std::string>::const_iterator i = items.begin();
    i != items.end(); ++i) {
  ...

for item in items:
  ...

The first version is something I really don't want to type in my spare time.
All my current projects are in Python or mixed Python/C++ these days.

bye,
Martin / maxy
Eric S. Raymond | 2 Jan 2009 18:34
Picon
Gravatar

Re: 1.7 design direction and the great Python shift

Mark de Wever <koraq <at> xs4all.nl>:
> On Fri, Jan 02, 2009 at 10:19:26AM -0500, Eric S. Raymond wrote:
> > Sirp agreed in principle on IRC with moving the Wesnoth codebase
> > towards Python many months ago, basically in order to attract a larger
> > population of developers - because, even though Sirp doesn't
> > particularly *like* Python, he knows it's more accessible than C++.
> 
> I think such a big move should be agreed by all current core devs and
> should be considered carefully. Why do you think Wesnoth will attract
> more developers if it's a Python project?

Because Python is a significantly easier language to write in, there
are more people able and willing to code in Python than in C/C++.  The
intersection of that set with the set of people interested in Wesnoth
can be expected to be larger.

> I have worked with Python and to be honest I'm not really thrilled. My
> biggest problem with Python is the type safety. I had some code that
> 'compiled' without problem but at runtime it had a hard crash due to
> invalid types. This kind of problem doesn't happen in C++ since it won't
> compile.

Instead we have core dumps, which are much more difficult to diagnose
because you can't use C++ itself to do introspection on them.  At
equivalent skill levels, the advantage is all with Python here - that
is, you have to know a great deal about using gdb to read the.
entrails of a core dump before you can accomplish things a person
debugging Python can do with barely a thought.

I have 26 years of experience as a C programmer.  Before that I wrote
(Continue reading)

David White | 2 Jan 2009 18:32

Re: 1.7 design direction and the great Python shift

On Fri, 2009-01-02 at 18:20 +0100, Martin Renold wrote:
> On Fri, Jan 02, 2009 at 05:25:00PM +0100, Mark de Wever wrote:
> > I think such a big move should be agreed by all current core devs and
> > should be considered carefully. Why do you think Wesnoth will attract
> > more developers if it's a Python project?
> 
> Speaking only for myself (but as a former contributor), I'd be more excited
> to contribute again if most of the codebase is in Python. I especially expect
> the STL-intense code to be much more fun to work with in Python.
> 
> for(std::vector<std::string>::const_iterator i = items.begin();
>     i != items.end(); ++i) {
>   ...
> 
> for item in items:
>   ...

Actually in C++ we solved this problem. All you have to do now is,

foreach(const std::string& item, items) {
   ...
}

> 
> The first version is something I really don't want to type in my spare time.
> All my current projects are in Python or mixed Python/C++ these days.
> 
> bye,
> Martin / maxy
> 
(Continue reading)


Gmane