Leo 4.7 final is now available here.
Leo 4.7 final fixes all known bugs in Leo.
Leo is a text editor, data organizer, project manager and much more. See:
http://webpages.charter.net/edreamleo/intro.html
The highlights of Leo 4.7:
--------------------------
- Leo now uses the simplest possible internal data model.
This is the so-called "one-node" world.
- Leo supports Python 3.x.
- Leo requires Python 2.6 or above.
- Several important improvements in file handling.
- Leo converts @file nodes to @thin nodes automatically.
- Leo creates a 'Recovered Nodes' node to hold data that
otherwise might be lost due to clone conflicts.
- @auto-rst now works much more reliably reliably.
- Leo no longer supports @noref trees. Such trees are not
reliable in cooperative environments.
- A new Windows installer.
- Many other features, including new command line options and new plugins.
- Dozens of bug fixes.
Links:
------
Leo: http://webpages.charter.net/edreamleo/front.html
Forum: http://groups.google.com/group/leo-editor
Download: http://sourceforge.net/project/showfiles.php?group_id=3458
Bzr: http://code.launchpad.net/leo-editor/
Quotes: http://webpages.charter.net/edreamleo/testimonials.html
Tuesday, February 23, 2010
Monday, February 22, 2010
Collaboration between humans and @test
Here is an exchange from another discussion of this topic
http://groups.google.com/group/leo-editor/browse_thread/thread/47dfb2e1767d2cda
> So, looking from this angle, you came to the heart of programming.
> Unit tests is a reference/control info to incrementally build-up
> a program - 'configure' a programmable material.
I agree. We already have these really cool controllers. They are called human beings :-)
Human controllers have all kinds of ideas and desires, but we aren't real good at maintaining attention, and handling myriad details. So we need help. Unit tests are that help. They are as flexible as their human controllers make them. The collaboration of humans and @test is superb: each can do what it does best.
EKR
http://groups.google.com/group/leo-editor/browse_thread/thread/47dfb2e1767d2cda
> So, looking from this angle, you came to the heart of programming.
> Unit tests is a reference/control info to incrementally build-up
> a program - 'configure' a programmable material.
I agree. We already have these really cool controllers. They are called human beings :-)
Human controllers have all kinds of ideas and desires, but we aren't real good at maintaining attention, and handling myriad details. So we need help. Unit tests are that help. They are as flexible as their human controllers make them. The collaboration of humans and @test is superb: each can do what it does best.
EKR
The stupendous Aha: the haiku version
We have been underestimating the potential of unit tests because of their name.
In fact, unit tests are general-purpose helper scripts that can be run at any time by the UnitTest test runner.
The cruft of having to create subclasses of UnitTest.TestCase usually obscure this simple fact. Leo's @test nodes do away with the blah-blah-blah of unit testing, so this Aha is much easier to see and exploit in Leo.
That's all there is to it.
Edward
In fact, unit tests are general-purpose helper scripts that can be run at any time by the UnitTest test runner.
The cruft of having to create subclasses of UnitTest.TestCase usually obscure this simple fact. Leo's @test nodes do away with the blah-blah-blah of unit testing, so this Aha is much easier to see and exploit in Leo.
That's all there is to it.
Edward
Second try: stupdendous Aha re unit tests
I have gotten zero responses to my 42 post:
I should have remembered that nobody reads long posts. So here is the Aha in a nutshell:
Unit tests are not just for testing! They are the master tool for programming, design, testing, refactoring, studying code, or anything else.
Think of a unit test as the root of a tree. The tree represents any task (including designs).
The unit test formalizes, automates and protects the task or design.
Expanding the notion of unit tests this way is a stupendous Aha. It has totally altered how I approach my work.
For details, read the long post. Print it out, including the lengthy "reply". Study it. Respond. Please.
Edward
P.S. I expect three possible responses to this post, and the longer post:
1. Yeah, I knew that. Welcome to the club of hugely effective programmers.
2. Wow! I didn't know that. This is going to change my life.
3. Huh? I have no idea what you are talking about. Can you do a better job of explaining your ideas?
EKR
I should have remembered that nobody reads long posts. So here is the Aha in a nutshell:
Unit tests are not just for testing! They are the master tool for programming, design, testing, refactoring, studying code, or anything else.
Think of a unit test as the root of a tree. The tree represents any task (including designs).
The unit test formalizes, automates and protects the task or design.
Expanding the notion of unit tests this way is a stupendous Aha. It has totally altered how I approach my work.
For details, read the long post. Print it out, including the lengthy "reply". Study it. Respond. Please.
Edward
P.S. I expect three possible responses to this post, and the longer post:
1. Yeah, I knew that. Welcome to the club of hugely effective programmers.
2. Wow! I didn't know that. This is going to change my life.
3. Huh? I have no idea what you are talking about. Can you do a better job of explaining your ideas?
EKR
Friday, February 19, 2010
Are unit tests the 42 of programming and design?
This is a repost of an entry on my Leo and Pylint blog.
I'm beginning to believe that the answer to this question is 'yes'. (It's certainly not '42' :-)
And I believe I can prove it.
This morning I attempted a rewrite of the complex code that imports Python files into Leo. As I went, it was natural to create unit test as the complexity of the problem became more apparent.
About noon I had to stop for awhile while several (old!) unit tests were failing. During my break, I considered scrapping the approach I was using. So was the effort a failure? Hardly. Amidst the rubble the unit tests stood unscathed.
This isn't an isolated example. Comically, failures create a situation in which unit tests come first the next time around :-)
Now lets consider my recent complaints about packaging. I implied at the end of a recent post that we lacked tools of sufficient power to help us with packaging. Could unit tests be those tools? Yes, they could be.
We need only a slight change in point of view. The typical way of viewing unit tests is to consider them a (permanent!) check of the correctness of a piece of code. This so close to the 42.
Let us instead view unit tests as tools. As tools, they have the following characteristics:
1. Unit tests codify and make explicit desired or expected behavior.
2. Unit tests are a way of "maintaining attention" on a problem. Unit tests don't forget, and they are permanent.
3. Unit tests do whatever we want, and they do it automatically.
What then, is the "effective power" of a unit test? Well, there is no limit to what a unit test can do. A unit test can do whatever we have the wit to require it to do. Unit tests are the master tool for any programmer or designer.
Put it another way, unit tests allow us to focus our attention briefly on a problem, and then, by the nature of a unit test, that attention becomes permanent.
Not convinced? Let's consider the question of packaging.
Suppose I think of unit tests as design tools for packaging issues. What exactly, could not be codified as a unit test? Certainly api's can be codified. Certainly use cases could be codified. Certainly interactions with other packages could be codified.
And so on. As soon as a new concern arises, it becomes possible to create a unit test that addresses that concern! Do you see? Unit test are limited only by our intelligence, commitment and desire.
It seems so clear now. If we wanted a tool of unlimited power, it would have to be limited only by our limitations. But that's exactly what is so about unit tests!
Edward
P.S. Seen in this light, design problems are failures to create proper unit tests. Or rather, design problems arise from a failure to see the need for one or more unit tests.
EKR
I'm beginning to believe that the answer to this question is 'yes'. (It's certainly not '42' :-)
And I believe I can prove it.
This morning I attempted a rewrite of the complex code that imports Python files into Leo. As I went, it was natural to create unit test as the complexity of the problem became more apparent.
About noon I had to stop for awhile while several (old!) unit tests were failing. During my break, I considered scrapping the approach I was using. So was the effort a failure? Hardly. Amidst the rubble the unit tests stood unscathed.
This isn't an isolated example. Comically, failures create a situation in which unit tests come first the next time around :-)
Now lets consider my recent complaints about packaging. I implied at the end of a recent post that we lacked tools of sufficient power to help us with packaging. Could unit tests be those tools? Yes, they could be.
We need only a slight change in point of view. The typical way of viewing unit tests is to consider them a (permanent!) check of the correctness of a piece of code. This so close to the 42.
Let us instead view unit tests as tools. As tools, they have the following characteristics:
1. Unit tests codify and make explicit desired or expected behavior.
2. Unit tests are a way of "maintaining attention" on a problem. Unit tests don't forget, and they are permanent.
3. Unit tests do whatever we want, and they do it automatically.
What then, is the "effective power" of a unit test? Well, there is no limit to what a unit test can do. A unit test can do whatever we have the wit to require it to do. Unit tests are the master tool for any programmer or designer.
Put it another way, unit tests allow us to focus our attention briefly on a problem, and then, by the nature of a unit test, that attention becomes permanent.
Not convinced? Let's consider the question of packaging.
Suppose I think of unit tests as design tools for packaging issues. What exactly, could not be codified as a unit test? Certainly api's can be codified. Certainly use cases could be codified. Certainly interactions with other packages could be codified.
And so on. As soon as a new concern arises, it becomes possible to create a unit test that addresses that concern! Do you see? Unit test are limited only by our intelligence, commitment and desire.
It seems so clear now. If we wanted a tool of unlimited power, it would have to be limited only by our limitations. But that's exactly what is so about unit tests!
Edward
P.S. Seen in this light, design problems are failures to create proper unit tests. Or rather, design problems arise from a failure to see the need for one or more unit tests.
EKR
Thursday, February 18, 2010
Leo and Pylint: a new google group
For the last several days I have been studying pylint and 2to3 intensely. Indeed, 2to3 might be converted into a program, call it pep8.py, that would *fix* deviations from Python's style guidelines, not just warn about stylistic problems.
A new Google Group, called Leo and Pylint, is, in effect, an engineering notebook for my studies. Those who are interested in studying complex programs might be interested in this group. In contrast to the tedious reading of source code, this notebook shows how to make study an active, exciting process.
A new Google Group, called Leo and Pylint, is, in effect, an engineering notebook for my studies. Those who are interested in studying complex programs might be interested in this group. In contrast to the tedious reading of source code, this notebook shows how to make study an active, exciting process.
Saturday, February 13, 2010
Tracking down a pylint bug with a new debugger
The latest version of pylint (0.19.0, with astng 0.19.3, common 0.46.0) produces an unbounded recursion on all of Leo's files.
Pylint is complex code, and several hours of tracing with pdb got me no closer to understanding what was going on. At last I had a better idea: to create a debugger that would warn me when the stack got too big. It is a subclass of pdb, but it overrides two methods in bdb.py.
The original version of this blog listed the code, and the traceback, but the listings got garbled. You can now see them both in the bug report page at
https://bugs.launchpad.net/pylint/+bug/456870
I still don't understand the code, but now I know where the unbounded recursion is.
Edward
Pylint is complex code, and several hours of tracing with pdb got me no closer to understanding what was going on. At last I had a better idea: to create a debugger that would warn me when the stack got too big. It is a subclass of pdb, but it overrides two methods in bdb.py.
The original version of this blog listed the code, and the traceback, but the listings got garbled. You can now see them both in the bug report page at
https://bugs.launchpad.net/pylint/+bug/456870
I still don't understand the code, but now I know where the unbounded recursion is.
Edward
Subscribe to:
Posts (Atom)
Posts
