On Fri, May 23, 2008 at 12:44 AM, mini [EMAIL PROTECTED] wrote:
does leo support large project (like linux kernel)? open LeoPyRef.leo,
it seems slow.
I've been hoping somebody would ask this :-) Before discussing various
possibilities, let me ask a few questions:
1. My assumption is that
Leo 4.4.8 is slower than Leo 4.4.2.1 at expanding/contracting nodes.
This is obvious from the following stress tests.
Open LeoDocs.leo for from 4.4.8 final distribution with Leo 4.4.8
final and with Leo 4.4.2.1 final. Expand all nodes (from menu outline-
expand/contact-expand all).
Leo 4.4.8:
On Sat, May 24, 2008 at 2:16 AM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote:
So I cloned just the segment I wanted to profile and pulled it under a new
section:
+ Main module
-- [clone] Generate cryptographic key
-- Hashing algorithm
+ Profiling Experiment
-- [clone] Generate
On Tue, May 27, 2008 at 8:45 AM, vpe [EMAIL PROTECTED] wrote:
Leo 4.4.8 is slower than Leo 4.4.2.1 at expanding/contracting nodes.
This is obvious from the following stress tests.
Open LeoDocs.leo for from 4.4.8 final distribution with Leo 4.4.8
final and with Leo 4.4.2.1 final. Expand all
On May 27, 9:44 am, Edward K. Ream [EMAIL PROTECTED] wrote:
On Tue, May 27, 2008 at 8:45 AM, vpe [EMAIL PROTECTED] wrote:
Leo 4.4.8 is slower than Leo 4.4.2.1 at expanding/contracting nodes.
The culprit is leoTkinterTree.recycleWidgets. The change is old enough
that I don't remember it in
On Tuesday 27 May 2008 09:12 am, Edward K. Ream wrote:
On Fri, May 23, 2008 at 12:44 AM, mini [EMAIL PROTECTED] wrote:
does leo support large project (like linux kernel)? open LeoPyRef.leo,
it seems slow.
Thanks for asking this! I was toying with the idea of importing the nedit
source
On May 27, 10:28 am, Edward K. Ream [EMAIL PROTECTED] wrote:
This list.in operator can be very slow when the list has many
elements. I'll look into the history of the code before attempting a
solution. Presumably the fix will involve using dictionaries instead
of lists.
The new code is
On Tue, May 27, 2008 at 11:29 AM, Randy Kramer [EMAIL PROTECTED] wrote:
On Tuesday 27 May 2008 09:12 am, Edward K. Ream wrote:
On Fri, May 23, 2008 at 12:44 AM, mini [EMAIL PROTECTED] wrote:
does leo support large project (like linux kernel)? open LeoPyRef.leo,
it seems slow.
Thanks
On Wed, May 21, 2008 at 9:34 AM, hairui [EMAIL PROTECTED] wrote:
I have fixed the problem by removing the ImageTk module from official
PIL website and re-installig it by apt-get.
Now LEO can load icon files properly.
It seems all the problems were caused by the version of ImageTk
moudle.
On Tue, May 27, 2008 at 4:12 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
There are various possible ways to speed up loading a large number of
files. The most effective ways might take a *lot* of work:
- Rewrite the read code in pyrex to get C-like speed.
- Represent the Leo outline as a
Yes. I'd tell you the size (in nodes, and characters) of my project
but It's too big to do manually and I can't find any Leo commands that
do it.
Of course, what I think is a big project you may consider to be small.
TL
--~--~-~--~~~---~--~~
You received this
On Tue, May 27, 2008 at 1:22 PM, Ville M. Vainio [EMAIL PROTECTED] wrote:
On Tue, May 27, 2008 at 4:12 PM, Edward K. Ream [EMAIL PROTECTED]
wrote:
Since it's most probably an I/O bound operation, I think the biggest
win would still be lazy nodes (which, as said before, is not easy).
I've
On Tue, May 27, 2008 at 12:56 PM, Kayvan A. Sylvan [EMAIL PROTECTED]
wrote:
As the only further improvement, I would love to figure out some way to
solve Sudoku puzzles that did not involve a brute force search at
some point in the process, but the puzzles I put up on on that link both
need
On Tue, May 27, 2008 at 03:08:51PM -0500, Kent Tenney wrote:
As such, adding sentinels or any type of workflow specific to Leo will
not gain acceptance.
I disagree, sort of. Most of the time, when I slurp a big bunch of files
into LEO for study and annotation, I am doing it only for myself.
On Tue, May 27, 2008 at 02:52:33PM -0500, Edward K. Ream wrote:
On Tue, May 27, 2008 at 12:56 PM, Kayvan A. Sylvan [EMAIL PROTECTED]
My sudoku solver uses only one clever technique: what I call row or column
conflicts. The idea is that an assignment of one value to a cell may make
it
The vim bindings work is great, but a seasoned vim user will just be
frustrated by a subset, and opt for the plugin to open a node in vim.
Concerning opt for the plugin, perhaps in theory but in practice I
open many nodes in Vim when there is a lot of editing to do or I need
some fancy vi/vim
On Tue, May 27, 2008 at 3:08 PM, Kent Tenney [EMAIL PROTECTED] wrote:
I would expect that most projects which are candidates for management by
Leo
which consist of _many_ files will be shared among programmers.
I agree. That's why I have been eagerly waiting for the question about the
A collection of new buzzwords have been circulating about the office:
x-frames (or Bassett's frames), xvcl, cross-cutting concerns,
and aspect oriented programming. Some of the XVCL concepts can be
handled by Leo's clones. But I am not sure about the ability to script
the generation of near
I'm currently confused about leo-as-a-library(?) and leo-as-an-editor,
but I'm pretty sure the installer has not kept up. Using trunk revno
441, if I cd trunk; sudo /bin/sh ./install I get
Password:
Prefix directory set to /usr/local
cp: cannot stat `src': no such file or directory
cp: cannot
19 matches
Mail list logo
