Re: Impressive ChatGPT responses

[ne1uno]

I feel bad cheating on eliza.  it is what it is

On Saturday, May 27, 2023 at 5:08:39 PM UTC-4 Félix wrote:

> I now use it somewhat daily to help translate little snippets and small 
> methods here and there to help finish leojs, i only used chatGpt which is 
> gpt3 under the hood. it often makes mistakes and you've really got to be a 
> programmer to revise the code it gives out before using it...  but i've 
> heard that gpt4 is much better! 
>
> Anyways, just a little detail I thought I'd mention :)
>  
> Félix
>
> p.s. the fun part is asking to get answers in the way of a particular 
> character, like snoop dog, or shakespeare, etc... :)
>
> On Fri, May 26, 2023 at 8:04 PM Edward K. Ream  wrote:
>
>>
>>
>> On Wed, May 24, 2023 at 11:11 AM Thomas Passin  wrote:
>>
>>> This is an interesting account of someone doing real programming - 
>>> refactoring and simplifying version 1 - with the help of not one but two 
>>> LLM bots.  He wanted to compare how the two differed and how useful each 
>>> would be - When the rubber duck talks back 
>>> . 
>>> It's especially interesting that - if you are using VSCode, anyway - the 
>>> bot can index your entire repo and use that to give much better results.
>>
>>
>> Thanks Thomas. I'll give it a close look.
>>
>> Edward
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "leo-editor" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to leo-editor+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS3OcqWdLy2JJbrT%2B5D0M1xgm0vgAtKs5L2e8ahoEnNzbg%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/246550e6-0e3e-4f4b-811a-93e13f060845n%40googlegroups.com.

GAOTD] Giveaway of the Day. ModusDoc 7.2.310 - Systematization and cataloging of any information. https://www.giveawayoftheday.com/modusdoc-7-2-3/

[ne1uno]

Giveaway of the Day. usually windows/wine only
ModusDoc 7.2.310 - Systematization and cataloging of any information.
https://www.giveawayoftheday.com/modusdoc-7-2-3/

some interesting program description & comments

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3a050031-e333-49e1-b7dc-d2167f75efcf%40googlegroups.com.

Re: Leo in 2019

[ne1uno]

can I suggest https://www.red-lang.org

code is data/data is code.
 code style agnostic 
an open-source fork of rebol.org with some forth and logo roots.
interesting funding approach, tokenomics.
under 2 meg executable cross platform build no additional tools!
2019 is going to be a very big year, 
hopefully more progress on Android and Linux GUI branch.



Also, thanks all for all the work on installs from everyone over the years. 
(nubees especially)
I installed portable python, unzipped the Leo 5.8 current from github into 
site-packages,
created a shortcut to python launchLeo and was up in running in a few minutes.
 it didn't find my leoID from any other install but wasn't a deal-breaker. 
that's a big deal.
I don't understand how developers don't get the fact you really only get one 
chance 
and likely under 5 minutes with most potential new users. even the desirable 
ones.

as well, no other missing packages prevented the initial windows with 
reasonable fonts and GUI.
portable python has quite a few packages including some version of Qt4 so was 
fairly painless.

I think the Leo menu could use modes. 
an expert the works, pythonic the works plus python, new users shortened 
setting for the basics.
maybe it does? likely some plugin or other does as much.
not every expert will want or care about python and likely first time users 
will be less overwhelmed.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Windows defender is flagging LeoApp.exe as carrying a trojan

[ne1uno]

red-lang is having some of the same false positives as python exe packagers
not every AV program is tripped up. 
something as simple as calling up the commandline using the win32 api can do 
it. 

it's likely some huristic as Terry says 
so companies are loathe to change scan results even when presented with 
evidence.

this is something that the language foundation and developers have to respond 
to.
users and random people complaining won't change anything.
changing hosting obviously won't change anything

need a button to press to get details on the OS, the version of AV and Leo 
package
to simplify making a bug report and don't forget, 
most people just move on to the next editor they wanted to try on the list
or revert to an earlier version


via Matt Wilkie
 """I've read that downloads from SourceForge often have this problem, any SF 
project not just Leo. It's got something to do with a feature that SF has for 
creating easy installers automatically, """

the company at the time that bought out sourceforge offered an opt in program 
so it was mostly the developers themselves
or their lack of attention to detail that got them repackaged

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Windows defender is flagging LeoApp.exe as carrying a trojan

[ne1uno]

I think the included adware problem is an old one. if so, little unfair to 
bring it up again
anything more recent?
sourceforge is under new management

a simple way to verify is publish a hash for any executable
it's extremely unlikely they are repackaging your exe or tampering with Leo in 
any way
it could hardly be kept a secret very long these days though websites are 
hacked all the time
so even a hash published is not 100% foolproof


from the link, QQQ
Update: Since the writing of this article, SourceForge has been sold to a new 
company that stopped the DevShare program discussed in this article. We’re 
leaving this article here for historical reference, but it has since stopped 
these shady practices.
QQQ


*none the less, I have heard others who will never use soureforge since then.
it might be a good idea to distribute alternatively on github in a distribution 
branch or repo

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Leo 5.7b1 released

[ne1uno]

QQQ
Leo 5.7b1 is now available on SourceForge and on GitHub. As always, many thanks 
to all 
...
Links
Leo's home page
Documentation
Tutorials
Video tutorials
Forum
Download
Leo on GitHub
LeoVue
What people are saying about Leo
A web page that displays .leo files
More links
QQQ

a plain text copy of parts of your post.
notice there is nothing resembling a link

this forces anyone to bookmark or use right now the google redirect link
in some applications the links might travel?
I know I often will copy text in a note, more annoying also copy links extra 
step
but usually don't bookmark google redirect links or save them with a note
too long, no guarentee they will work in the future, 
don't want to share them for various reasons, it's no longer a plain link

google you may not have noticed tricks you into thinking the link is plain
by showing only the link in the status bar or on mouseover using the title=

a few in the forum make a point of showing at least a few plain links in their 
posts
maybe you could add one or two links to the announcements 
github and leoeditor maybe?


posted/edited with a mobil browser useragent on desktop,
no idea how the quoted text is going to show
there is no option but to top quote

google never misses an opportunity to show you only what it wants to
not that they're evil or anything, just a little too quick to take liberties 
and shortcuts
notice no forward button or tooltips in android. improving by removing? who 
knows for sure

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: [OT-GAOTD] Aml Pages 9.78 - Aml Pages keeps all your information in a form of tree.

[ne1uno]

I should have mentioned, there is a portable versions available
and, also, a menu item to make a portable version.
I assume this just creates local ini file or whatever else it needs
pulled from far flung directories 
nobody but the program would know how to find.

I often look for and would try or use a portable version.
these days, many will want to know if there is an app version.
ePIM does have one, not sure about AML Pages.
there is a python android app creator
has anyone tried to build Leo for phone or tablet?

just tried the mobile version of groups on desktop
so much quicker and less busy, but doesn't seem to have a reply button.

On Monday, February 27, 2017 at 7:34:05 PM UTC-5, ne1uno wrote:
>
> https://www.giveawayoftheday.com/aml-pages-9-78/
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[OT-GAOTD] Aml Pages 9.78 - Aml Pages keeps all your information in a form of tree.

[ne1uno]

sh
Spoiler Alert













Giveaway of the Day. 
they give away various outliners. editors and others windows programs daily
just to try or to keep. registered versions, usually pro or better
free till 4am eastern 

https://www.giveawayoftheday.com/aml-pages-9-78/

Aml Pages 9.78 - 
keeps all your information in a form of tree.Key Features 
   
   - Tree-structured form of notes
   - Text and paragraph formatting
   - Images, screenshots capture, tables
   - Easily text and web grabbing
   - Instant search, filters and tags
   - Bookmarks and hyperlinks
   - Security and auto-backup
   - Integration with Dropbox, Evernote, LeaderTask.
   - Export to CHM-format (Microsoft Windows Help).
   - Export to OPML for viewing on mobile devices.
   - Free plugins and portable version
   - Unicode support

as usual, the comments are mostly about installation problems with the 
GAOTD wrapper
this one has an unusually overstocked menu and somewhat cluttered interface.
not opensource or scriptable but has a plugin interface
haven't looked into their forum
just for the FYI

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo in 2017

[ne1uno]

I had opportunity to use the mercurial shelf in TortoiseHG today.
say you want to revert the working tip but don't want to commit.
you have a patch for a file or a few files and shelve them
revert update then un-shelve the patches and back in business.

I see clamoring for multiple body's in Leo
what about multiple outlines? or is that already being done?

obviously lots of work comparing two revisions and then somehow applying
the patches. even for the one file I was working on with 3 minor changes
I managed to lose 2 of the edits by the time I got to apply the patch.
you can get the diffs but files can radically change as you go back in time.
maybe if such a tool existed you would find ways to use it?

is code coverage checking a done deal in python? any language?
a test outline on the left and source outline on the right
uncovered code highlighted. maybe more tests generated.
https://wiki.python.org/moin/CodeCoverage

don't forget the substantial non programmer Leo user population!
there might be a use for test driven writing? create an outline
then analyze the nodes, do they make sense.
going the other way, take a bunch of text and generate
headlines. is a free form text importer possible? useful?


On Saturday, December 24, 2016 at 6:16:41 AM UTC-5, Edward K. Ream 
wrote:The last two years have seen @clean and the clone-find commands.  
Both are game changers. My *goal *for the new year is create something 
similar.

The *strategy *will be to focus on problems that we have learning or using 
Leo.  Some possibilities:



*Learning about Leo*The Programming with Leo 
 tutorial must be 
rewritten, following the "less said the better" principle. I'll start with 
motivating @file and @others.  Everything else is details.

I am considering a series of "Looking over Edward's shoulder" tutorials.  
Instead of slideshows or videos, it may be more effective to throw out a 
few haiku-like invitations for discovery, following the how to learn Leo 
post . 
Yes, Leo has a gazillion features, but the basics of Leo are simple, and 
there aren't many of them.

*Editing*

Leo might benefit from a temporary vim mode.  This should be easy to do, 
and it might be useful in some situations.  Leo might also benefit from a 
vim-like "dot" command.

I am having my doubts that a super-duper outline-based diff 
 is going 
to be useful. The only time I ever use git diff is when creating a checkin 
log. Still, I'll investigate a bit further.

As always, I'll be looking for ways to better integrate Leo with vim, 
emacs, jupyter, etc.

*Testing*

The TDD advances 
, have 
stimulated further thoughts. More improvements may follow.

Leo is a uniquely friendly environment for unit testing.  For example, one 
could imagine a short script that would generate unit tests for all 
commands, or all methods in a file or class.

*Design and checking*

After spending considerable time writing the make-stub-files 
 script, I have never used 
mypy . I'll probably play around with checking next 
year.  Programmers have not begun to use big data to validate/improve their 
programs...

*Understanding*

The biggest payoff may come from enhancing Leo's unique strength, namely 
understanding computer programs, or other complex data.  Advances in this 
arena will be difficult (impossible) to duplicate in other programs.

That's all for now.  All comments welcome.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Proper copy / paste for Windows

[ne1uno]

I didn't know it was an option in X11
there is autocopy for browsers firefox and chrome, I use both,
most IRC clients have autocopy turned on. where I first started realizing
you get into the habit of thinking everything you select will be copied.

I also use ditto, clipboard manager and I have that set to ding when clip 
added.
it's just too potentially embarrassing, dangerous to think I might paste 
the clip before last
or fail to paste what I thought was in the copy buffer not to have the 
extra sound effect.
programmable mouse buttons for copy and paste should be mandatory too.
hard to believe users of most programs have so little control over how they 
will act.


*ditto I think is windows only
On Wednesday, February 24, 2016 at 3:05:25 PM UTC-5, Terry Brown wrote:
>
> Hi all - I've been needing to work in Windows quite a bit recently, and 
> the lack of X11's select to copy, middle button to paste has been driving 
> me nuts. Particularly seeing I switch back just often enough to be reminded 
> how it should work.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo.exe: a christmas present for newbies

[ne1uno]

anyone else have problems running leo.exe from the zip file?
I don't have a 64bit system to check it on.
depends says it's a 64bit file and Xp errors when I try to run it.
this appears to be the only 64b file in the distribution.

so, back at the dejavu ranch:
is there a bat file I can create to setup the paths to run leo?
preferably using the existing files in the distribution?
mimic what pyinstaller did to allow the exe to run using ./python27.dll?
probably not so simple if possible at all. 


On Tuesday, December 29, 2015 at 4:13:30 PM UTC-5, Edward K. Ream wrote:
>
> On Monday, December 28, 2015 at 5:39:30 AM UTC-5, Edward K. Ream wrote:
>
> ​I think it would be best to upload both PyInstaller versions of Leo 
>> (single-exe and folder-based) to a folder called something like 
>> "Easy-install Leo".  ​The single-exe version will be best for quick 
>> evaluations of Leo.  The folder-based version will avoid startup overhead 
>> and problems associated with a disappearing temp folder.
>>
>
> Done.  The folder is called Quick Install 
> . It 
> contains leo.exe, Leo.zip and Readme-quick-install.TXT, whose contents is:
>
> Readme-quick-install.TXT
>
> This document describes two ways of running Leo without having to install 
> *anything* else.
>
> Method 1. (Folder-based, Recommended)
>
> Download the Leo folder, unpack it *anywhere* you like, and run leo.exe 
> from within the unpacked folder.
>
> ...   
> Both the folder-based and single-file version were created by PyInstaller:
> http://pythonhosted.org/PyInstaller.
>
> Both leo.exe and Leo.zip work as expected on Windows. Please report any 
> problems immediately.
>
> I plan to add similar files for Linux when I return home.
>
> Edward
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Coming soon: My Last Lecture

[ne1uno]

you will no doubt add a few words about the earlier years? probably
most Leonites have no idea what CUJ is (the C Users Journal), and those
floppy disks you could order with actual source code for neural networks,
AI languages, editors and who knows what would be next.

I can recall one Thanksgiving in the early 80's building a dictionary 
lookup program from one of the disks that took hours and hours to compile 
so I could actually spell check! almost automatically, like magic!
we don't know how good we have it now.
your work on other editors and credit on various projects leading up to Leo.

On Saturday, October 17, 2015 at 12:33:13 PM UTC-4, Edward K. Ream wrote:
>
> From a review 
>  of 
> Randy Pausch's The Last Lecture 
> :
>
> A lot of professors give talks titled "The Last Lecture." Professors are 
> asked to consider their demise and to ruminate on what matters most to 
> them. And while they speak, audiences can't help but mull the same 
> question: What wisdom would we impart to the world if we knew it was our 
> last chance? If we had to vanish tomorrow, what would we want as our legacy?
>
> It's time to give my own "last lecture".  It will have at least two parts:
>
> 1. Leo: a retrospective.  Why I am happy to have spent 25 years on Leo.
>
> 2. What matters most. The wisdom and knowledge that I would like to impart 
> to you, if I knew I would be gone next week.
>
> The lecture will explain why my interest in Leo has been waning for the 
> last six months.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Making Leo easier to install

[ne1uno]

one other option I missed if it was mentioned
similar to the VM solution:
live CD. anyone already running one of many VM programs like virtualbox
can run the ISO directly.
anyone else can burn a CD/DVD or install on a bootable flash drive.
use a self contained small nix distro.
Proteus is one that works well on a flash drive and can persist settings.
preinstalled python, pyQt & Leo with a typical window point & click GUI.
this is a lower barrier to entry as you need not install anything.



-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Making Leo easier to install

[ne1uno]

anyone else find it humorous to start off a post about making
installs easier by saying it's already easy to install?
ya really have to have gotten the memo by now that it ain't,
with respect, I know how many ways this problem has been approached.

just a few weeks ago I need a speedier python program, I don't code
much python these days. I recalled the pypy project and looked in
to my delight they have shippable product now that is promising.
so I tried to start up leo and no shocker, no Tk any more so no dice.
sure, I can figure it out maybe, calling it easy is like an auto mechanic
calling an engine overhaul easy because they can name all the steps.
in no way shape or form is it easy.
now I guess I'll finish reading the thread.


On Wednesday, October 14, 2015 at 12:06:16 PM UTC-4, Edward K. Ream wrote:
>
> I had an enjoyable conversation with Kent Tenney yesterday on this topic.  
> Here are some notes, with some additional thoughts.
>
> tl;dr: Only one-step solutions would seem to be a real improvements.  
> Possibilities include pip install and executable files that create VM's.
>
> I welcome any comments.  Installation is really not my field.
>
> = Background
>
> Leo is already fairly easy to install, which makes significant 
> improvements more challenging. Indeed, the short form of the installation 
> guide is:
>
> A. Install Python.
> B. Install the version of Qt that matches the Python version.
> C. Install Leo using Leo's single-click installer, or using git clone.
>
> = One-step solutions
>
> To do *significantly* better than this would require a one-step solution.
>
> There are at least two possibilities:
>
> Option 1: a do-everything executable file.
>
> In essence, this file would be a VM (Virtual Machine) containing:
>
> A. Some version of Python.
> B. The matching version of Qt.
> C. All files installed by Leo's installer, including documentation, 
> example files, and the entire installed contents of the leo-editor/leo 
> folder.
>
> Yes, this will be a large .exe file, but that can't be helped.
>
> PortableApps is a Windows only solution.  
>
> Option 2: pip install leo-editor full
>
> The effect would presumably be similar to option 1.  This would be more 
> convenient for the user (assuming it can be done) *provided* the user 
> already has pip installed.  Otherwise this is a two-step solution.  On 
> Windows, installing pip is non-trivial.
>
> = Other Possibilities
>
> Kent mentioned the possibility of creating docker containers 
> . But this would require installing docker, 
> unless I am missing something.  Also, the docker subscription service costs 
> $150/month.  It may be possible to using a free hosting service, but I'm 
> not sure about that.
>
> Similarly, VirtualBox can create, (if I 
> understand correctly), self contained VM's.  But like docker, VirtualBox 
> must be installed by the user, making this a two-step solution.
>
> On the Mac, Leo could be delivered as a Homebrew formula (assuming we ever 
> figure out how ;-), but again, Homebrew itself must be installed first.
>
> = Summary
>
> 1. The only true one-step solution is like to be an executable file 
> containing a VM containing everything needed to run Leo.  PortableApps is 
> such, but is Windows only.
>
> 2. pip install (Linux and maybe Windows) and Homebrew formulas are 
> *almost* one-step solutions in the sense that both pip and Homebrew are 
> commonly installed.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

GAOTD maple outliner

[ne1uno]

http://www.giveawayoftheday.com/maple-8-31-pro/

would be interesting to see Leo run their comment gauntlet some day. 
ease of install and getting up to speed without reading the docs would be 
important.
they have given away plenty of pim & outliner software over the years.
does Leo have a bucket list? GAOTD should be on it.

as always giveawayoftheday is windows only though some of the software is 
cross platform or at best cross a few platforms.

ran across a new anygui the other day that claims to work on phones too.
http://unseenu.wikispaces.com/AnyGUI
#c 
there's always a catch

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: android outliners...

[ne1uno]

ePIM has a free android app I am using.
divided into 4 modules
the app and file format isn't open,
but does have import/export from/to csv.
can synch with their pc pro version , 
don't recall if they have *nix version yet

because of the android UI in general I find all apps a chore to use.
no forward button! (maybe newer devices have one?)
 the back button or home button to call up
some other app to copy or paste from so tedious.
keyboards taking up half the screen, all of them error prone.
forced typo corrections that are even worse than the typos.
low battery life, to name just a few annoyances.

and some good things,
can use Qr code image easily generated 
to pass a limited amount of info to the device w/o connection.
cheap GPS & maps that work offline.

link for Leouser if you're still active
Android Studio 1.0 for Windows
http://tools.android.com/download/studio/canary/1-0-1


On Tuesday, January 6, 2015 at 1:30:13 PM UTC-5, Terry Brown wrote:
>
> Hi all, 
>
> Recently started using an android cell phone. 
>
> I'm looking at 
>
>
> http://www.dgtale.ch/index.php?option=com_content&view=article&id=52&Itemid=61
>  
>
> as a possible import / export target for Leo. 
>
> It's very focused on tasks, but has the features needed to contain / 
> display / interact with Leo outlines.  It can sync. its data to a simple 
> JSON format on DropBox or FTP.  It seems to be not open source, but 
> currently free of any need to register anything anywhere, other than 
> perhaps DropBox, but that seems ok. 
>
> And I'm not really interested in it being open source, the point is to 
> use it as a UI for Leo outlines on android, so it's not replicating 
> Leo, just a handy environment for Leo data. 
>
> So, other outliners out there on Android people think might be 
> relevant? 
>
> There's a lot, although a lot seem to require registering with specific 
> services etc. 
>
> Level of interest? 
>
> Cheers -Terry 
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Aml Pages Outliner Free Today GAOTD

[ne1uno]

http://www.giveawayoftheday.com/aml-pages-9-56/

a jam packed (to a fault maybe) outlining note taker with plugins.
like most GAOTD, probably windows only.

worth a look, first opens into a demo outline w/help, faq, website clone, 
tips.
has this ever been tried w/Leo?
it can't be that hard to have a new user see a demo outline, pick from menu 
anytime 
the programming heavy source or settings leo not what most new users crave.

I have no interest in promoting the software beyond
looking/trying out what the competition is doing.
it's not scriptable, can't zoom pages, not open source.
you can create plugins but nobody has done anything for programming.
it's been around for many years so don't hold your breath.

though I will say, it's got a pretty small memory footprint
and seems pretty snappy in use.
probably has a similar steep learning curve to Leo.
like most outliner, you may want to limit data per node and per outline
the devil in the details. I haven't really tried to use it for anything 
serious.

you can download the portable version from their website
which has a few different localized versions.
and use the reg code from the gaotd download
free today till midnight pacific, 3am eastern tomorrow.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: giveawayoftheday inspiration-library

[ne1uno]

forgot to mention, available free till 12pm Pacific today windows only
they probably have a demo on publisher website other times.

On Wednesday, April 2, 2014 5:03:41 PM UTC-4, ne1uno wrote:
>
> http://www.giveawayoftheday.com/inspiration-library-2-0-6/
> free today with upgrades included
> QQQ
> Inspiration Library is a application for curating, collecting, and 
> organizing ideas through photos and designs, allowing you to save files and 
> categorize them according to collections and libraries. Collect ideas that 
> spark your creativity and make you want to create.
> QQQ
> I don't know anything about the program but I do often wish for something 
> similar
> and have tried a few. too bad there is only a chrome plugin as yet.
>
> from the publisher of Zen writer
> the full screen "distraction free" editor
>
> I may find some of the design choices annoying
> but who knows, they may be onto something.
>
> I so hope this doesn't get mangled in the formatting.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

giveawayoftheday inspiration-library

[ne1uno]

http://www.giveawayoftheday.com/inspiration-library-2-0-6/
free today with upgrades included
QQQ
Inspiration Library is a application for curating, collecting, and 
organizing ideas through photos and designs, allowing you to save files and 
categorize them according to collections and libraries. Collect ideas that 
spark your creativity and make you want to create.
QQQ
I don't know anything about the program but I do often wish for something 
similar
and have tried a few. too bad there is only a chrome plugin as yet.

from the publisher of Zen writer
the full screen "distraction free" editor

I may find some of the design choices annoying
but who knows, they may be onto something.

I so hope this doesn't get mangled in the formatting.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

update about Leo google group

[ne1uno]

http://groups.google.com/group/leo-editor/about
still has the old home page
webpages.charter.net
though it also has leoeditor.com/ for discussions. assuming that is
intentional, seems confusing,
since the links point back to google groups.

looks good. remember with the endless refinement, most people don't
want to read first but do first so don't skimp on the usability.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Qt has been sold

[ne1uno]

open  governance the first casualty?

On Sep 27, 9:33 am, "Edward K. Ream"  wrote:
> Here is the announcement:
>
> http://qt.digia.com/About-us/News/Digias-Completion-Of-Acquisition-Pa...
>
> My assumption is that this will not negatively impact Leo for the
> foreseeable future.
>
> Any more informed comments?
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: android/iphone Leo Caution: Suggestion Only

[ne1uno]

just saw this on the qtplanet. probably still a little too much
juggling for any widespread use.

http://blog.rburchell.com/2012/07/qt-5-and-android.html


On Aug 1, 10:18 am, Terry Brown  wrote:
> On Mon, 30 Jul 2012 21:41:52 -0700 (PDT)
>
> Phaze  wrote:
> > It would probably take a bit of work redesigning the interface (which is
> > why the words of caution) but...
>
> > Android and iPhone versions of Leo.  Apparently it is already possible to
> > jack a python interpreter onto Android
>
> Ville has something on this topic, I forget what exactly.
>
> I've gone as far as installing the Android SDK and getting hello world
> running in the Python interpreter thing.  But I don't think you can get
> PyQt for Android, not even sure if Qt is fully available.  Ville would
> know that too I imagine.
>
> But there's the option of a non-Qt interface to Leo files, I would
> imagine still using Python, which was what I was investigating when I
> installed the Android SDK.  That was a while ago and I didn't have time
> to get very far.  Of course a non-Qt interface would not have most of
> the plugins, keybindings, etc.
>
> Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Beyond Leo tweaks

[ne1uno]

 it's a no brainer that you can catch most type errors with static
type checking. assuming people won't actively try and circumvent
the checks like you sometimes must with casts in the c languages.
no surprise that it's much easier to create tools in a static
type checked language when you nearly always know how to allocate.
this usually translates to speed and compile time error checking.

 another thing some functional languages do is identify functions
as "pure", that is no side effects. no global changes,
no I/O of any kind, screen, file etc. no use of impure functions.
 pure functions should be/are easier to test.
given the same parameter values the returns will always be the same.
in a static typed language like haskell the analysis is done.
in python, you have to identify all callers to the function and
infer which types are the parameters and what type the return values.

part of the process of marking a function pure in a hypothetical
dynamic type inference program would be to verify somehow that no
plugins or settings could somehow change the function or one of
the functions in the chain in a way that would change the purity.
seems like a tall task done statically.
I would also mention that pylint faced will similar hard to know types
and most definitely epydoc will revert to active inference!
which makes the whole idea of safety in a static analyzer suspect.

never run a static analyzer on untrusted code with this loophole!
this is my recollection, not having followed pylint for many years.
it's possible they have since made active inference a default off
option.
you wouldn't want to check or re-factor a code snippet and rmv /*
yet another reason not to run tests or edit as root admin.



On May 25, 6:23 am, "Edward K. Ream"  wrote:
> On Thu, May 24, 2012 at 3:17 AM, ne1uno  wrote:
> > python does obviously have type inference, isn't it good enough?
>
> Python's interpreter knows the type of objects at run time, that is,
> just at the time the interpreter is about to execute an opcode.
>
> My goal is to deduce interesting things about programs statically.
> That is, before the program runs.
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Beyond Leo tweaks

[ne1uno]

On May 16, 12:34 pm, "Edward K. Ream"  wrote:

> From time to time, however, I have the desire to use Leo to do
> something else besides develop Leo itself.  Now is such a time.  I
> plan to revisit the leoInspect module.  The idea is to develop a very
> fast inference engine based on what might be called local type
> induction.
>
> The idea is simple: we programmers mostly understand code locally.  We
> don't have to understand very much to determine what a program is
> supposed to do.
>
> For example, most instances of vars called "c" in Leo are (or should
> be) leoCommands objects.  The induction step simply verifies that *if*
> all input vars c, c1, and c2 *are* leoCommands objects, then any
> assignments to other c vars (including via return statements) are
> *also* leoCommands objects.
>
> In other words, mathematical "proofs" that type induction must be slow
> may be valid in a mathematical sense, but they are not valid in an
> engineering sense.  The idea is to "cheat" in such a way that
> inferences become very fast and easy.  That's actually what we humans
> do.  But we need checks to verify that our "intuitions" are correct.
> Those checks are lint-like.  If they fail, they will indicate where
> our programs (and especially their naming conventions) can be
> improved.
>
> That's the idea.  We'll see how leoInspect can be generalized to
> support it.

a worthy goal.  though I may have only vaguely been aware of why
beyond a potential speed improvement a week ago.

it's practically a given that every so many months to reach for an
opportunity or overcome an obstacle you learn a new language. maybe
a new paradigm. maybe it's a one off domain specific language.
every so often you get deeper into the culture of a more substantial
language. I kept bumping into Haskell and won't say what the
obstacle is but recently decided I liked enough of what's available
and jumped in past the feet wet understanding.
it's more a functional language than anything else, pure by default,
there is type inference yet it is strongly and strict typed.
there are some bizarre naming and indentation rules,
maybe rules is too loose a word, could be considered strait jackets.
yet you can, within limits mix various programming styles.
JavaScript it ain't. there are both interpreters and compilers.
darcs RCS is one notable project written in it.

a Haskell motto might be that once a program runs it is more likely
to be correct, at least as far as type errors are concerned.
with many less internal and external tests required.

little of this would apply directly to python,
being part of the specification of the language & tools you
pay for with up front design time vrs a more dynamic language.
2 weeks ago I couldn't spell Haskell.

python does obviously have type inference, isn't it good enough?

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Learning javascript

[ne1uno]

On Feb 21, 11:13 am, "Edward K. Ream"  wrote:
> I've got to learn javascript in order to read the MooTools sources :-)
>
> Some first steps.
>
> The MooTools sources are minimized, but not obfuscated.  Googling for
> "reformat JavaScript" took me to:
>
> http://jsbeautifier.org/
> [..]
>
> I'm still amazed that anyone can write software with a language like
> this, but now I have an inkling about how it might happen.
>
execution of javascript in a browser is another limiting factor.
speed, error reporting to just name two problems.
it would be easy to load most javascript into a QScript engine
previously loaded with mootools, prototype or other favorite
wrapper, coffee script or whatever then evaluate any node
or selected text as can now be done with python & execute script.
not sure how completely pyqt wraps QScript. I have been using
jsbn large integer javascript run inside QScript.

there are some things to notice, most javascript, especially
projects started over a few years ago, expect to be run in
a browser so they expect things like alert("") to work.
prime the engine with something like:
function alert(msg){
throw(Error(msg));
}
of course, an actual popup could be done as well.
sometimes they run code to determine which browser and
change their code on the fly these kinds of things would
have to be commented out or made to recognize QScript somehow.

QScript is mostly compatible but not 100%.
all problems that could be worked out if anyone cared.
QScript has/can be given access to all Qt slots & signals.
there are many more potential programmers of javascript looking
for a fun tool in Leo than there are python programmers.

http://altjs.org/ has a bunch of ports, forks and standalone engines
links.
also check out JSHint, a true fork of JSLint.
I can't recommend a test harness project, there are many, I run
tests outside using javascript to provide the answers.



-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Leo standalone exe

[ne1uno]

On Nov 29, 3:46 pm, Matt Wilkie  wrote:
> On Tue, Nov 29, 2011 at 8:26 AM, ne1uno  wrote:
> > get regmon & filemon if they are still available from sysinternals
[]

> regmon and filemon have been superceded by procmon (Process 
> Monitor):http://technet.microsoft.com/en-us/sysinternals/bb896645
>
> ...later: hmmm, this tool locks up my win7 machine solid. Or more
> precisely, it locks up the start menu, task manager, alt-tab switcher
> and other core services
[]
>
> The procmon window was reporting 27,000 of 110,000 events displayed
> before Windows became unresponsive. It seems like an awfully high
> number, but I don't know if that is normal or not.

seems hi, but I have never run win7 or procmon.
I have seen filemon get overloaded when a build is running, something
with many processes opening and closing.
I've been running filemon since it was available as source.

there must be a way in procmon to filter or limit what is reported.
start it up and disable capture, then look at the options.

get process hacker or something to look at what happens at startup
(after a drop dead backup of course)
you may be able to start an app or right click on an icon
and tell it not to run at startup to cut back
the contentions to a few thousand per second.

this was the eye opening part for me, just how many things are running
in the background while your app stumbles around looking for a file,
and I do mean stumble..
I guess there is no other way than to follow the path,
open drive
open directory
is file there, no
open next drive
is file there, no
open next directory
is file there, no
etc
probably good that all that stays in the background.




-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Leo standalone exe

[ne1uno]

get regmon & filemon if they are still available from sysinternals
they shows in realtime what programs are requesting from the
filesystem or registry. a real eye opener.

On Nov 28, 5:07 pm, Matt Wilkie  wrote:
> > - the application thinks the name of the exe is the home directory,
> > therefore things like save leo file fails with "Permission denied
> > u'x:\\testing\\launchLeo'", it should be 'x:\testing'. Using SaveAs
> > works just fine though.
>
> This statement is wrong. launchLeo.exe is contained in a directory
> called launchLeo, so the permission denied is coming from something
> else.  It's still confused about the directory structure though.
>
> --
> -matt

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: talk: differential execution

[ne1uno]

On Nov 17, 4:12 pm, Matt Wilkie  wrote:
> Hi Folks,
>
> I've been doing some reading, trying to expand my basic (very fuzzy)
> understanding of just what programming or software development is.
> This thing[1] led to that thing[2] to the other thing[3], as is normal
> on this infinite distraction machine, and I found myself reading and
> trying to grasp the gist of something called Differential Execution or
> Dynamic Dialogs
> (http://stackoverflow.com/questions/371898/how-does-differential-execu...).
> It's way above my programming level, I don't really know I'm trying,
> except that when I encountered Leo it too was way above my
> understanding (still is actually), yet I've learned something valuable
> and useful things anyway.
>
> Anyway (seems to be an echo here...) reading that I come away with the
> idea DE might might be approximately equivalent to the difference
> between writing a beautiful webpage wholly in html vs html plus
> cascading stylesheets. Is that about it, in broad strokes?
>

more like HTML + Javascript. I would have to vote hype though. the guy
is selling books on the subjects.

not to say the ideas are not interesting. DE appears to me
to be a solution in search of a problem. the idea that you would be
better off, taking less time and lines of code, getting a diff of the
last state of a dialog and sending that to a window manager instead of
using event programming where the wm decides what needs to be updated
seems like fanciful hype.
though I will have to try it to find out.  with todays tools and
hardware, optimizations from the last century often are no longer cost
effective.

not every idea is a simplification though, nor are good ideas always
easy to grasp or put into practice.
the other idea from the same guy in the profiling thread about halting
a program at random and looking at the call stack to get a sense of
where the program is cpu bound is at best surprising if it has any
merit.
that is after all what a profiler does. again, an optimization
technique usually for larger or cpu bound programs.
not something you really need to worry about at the start of a
project.

the ROI thread has some good advice.
to program well you have to program often to get and keep the
experience. reading about it almost doesn't count.

>
> [1]http://programmers.stackexchange.com/questions/35615/what-programming...
> [2]http://programmers.stackexchange.com/questions/35615/what-programming...
> [3]http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c...

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: BZR memory

[ne1uno]

a no cost alternative would be to update sourceforge with all the
history, then convert to hg. though, like bzr, once something gets
into the repo it tends to stick.
by starting a google code project, an import from another repo could
be used to start hg with full history.

bitbucket can be excruciatingly slow, at least on a dialup and there
is a limit to project members for the free repo, but I have no idea if
that is still true or what the cost is to jump to the next number of
developers. they do implement the hg server so anyone can get an
archive of any changeset.
sourceforge and google code don't.

mercurial is also a distributed RCS. I used bzr a little locally but
happily switched to hg when the euphoria project switched from svn to
hg. tortoiseHG on windows is well ahead in usability of anything I
could find available for bzr or git for a GUI solution on windows. the
commandline client will not be terribly different than bzr to
understand or use.

I'm guessing launchpad has been slow enough to make people avoid using
the bug tracker to full advantage. the bitbucket bug tracker uses a
wiki markup, "creole" that will be a bit of a learning curve for
people but worth the effort. it shouldn't be to difficult to translate
from Rst to creole. google code also has a capable wiki and issue
tracker on every project as well as download server.

On Nov 10, 3:53 pm, "Ville M. Vainio"  wrote:
> On Thu, Nov 10, 2011 at 6:26 PM, Terry Brown  wrote:
> > Different IDs for commits is ok - so all comments and tags on commits
> > remain the same, right?
>
> Yes, according to my understanding.
>
> >> Using github has crossed my mind.  What do you think?
>
> > What are the advantages apart from git having more dev-cred :-)
>
> > bzr is written in python, after all...
>
> Mercurial would seem more sensible alternative, it's as easy to use as
> bzr. Github is a great service, but that may not be worth the learning
> curve for using git. Mercurial is also better supported on windows,
> git on windows is a hack.
>
> I use git for all my stuff these days, and like it, but there
> definitely is the learning curve.
>
> Main advantage of both git and hg over bzr is performance. Both do
> almost everything in a blink of an eye, with bzr you have to wait
> around. Popularity could also be a factor in the choice, don't know.
> Mercurial has a quite professional gui tool, 
> Tortoisehg:http://tortoisehg.bitbucket.org/. Mercurial also has very cool 
> extra
> tools / extensions like Mercurial Queues for patch management.
>
> If we were to change over to, say, bitbucket and hg, we should still
> keep the launchpad project as bug tracking area.
>
> The thing to do now would probably be for Edward to play around with
> hg/git/both, and make the call. I could obviously help with the
> repository migration, if a change is deemed necessary / useful.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: An avalanche of improvements

[ne1uno]

shouldn't there be some way to incorporate the sense of levels in unit
tests?
level 5 would be minimal syntax checks down to 0 full blown
reliability.
there is a theory, Jevons paradox, from the 1860's about coal usage,
improving
the efficiency of a resource actually increases the use of the
resource.
http://en.wikipedia.org/w/index.php?title=Jevons_paradox

this seems less obvious for energy use, but for unit tests it could be
the deciding factor for running unittests before commit and running
level 4 or 5 tests at least before a push.

none of this will leave a repo in a usable state by itself.
no real news there. making tests simpler to create & run helps not
only
Leo but all projects created with Leo. to continue with the Jevons
paradox
there could be a "backfire" effect of more people running tests
producing more
bug reports. but, in the long term, will likely only facilitate better
tests
and better compatibility as tests are run on more configurations.


On Nov 7, 2:04 pm, "Edward K. Ream"  wrote:
> Rev 4748 significantly improves Leo's unit-testing framework:
>
> 1. When running unit tests externally, g.app.isExternalUnitTest is
> True.
>
> 2. Running unit tests externally now inits settings from
> leoSettings.leo.
>
> On my machine, this adds about 0.35 sec to the startup time, which is
> about 50% of the total.  Experience shows that this extra time is well
> worthwhile: the extra time is not enough to be annoying (yet) and it
> adds an important capability to external unit tests.
> ...
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: leoSettings.leo about to change

[ne1uno]

forgot to mention, it should be possible as an option to
ignore all default Leo "theme" settings. some users would
just as soon like Leo to grab default colors/styles from their
window manager theme and adhere as much as possible to those.
not to say in any way this would be easier. much the opposite.
this could make Leo look wildly different or even unusable
for those that use Leo on more than one desktop regularly.
 http://www.freedesktop.org/wiki/Specifications


On Oct 2> On Oct 25, 10:16 am, "Edward K. Ream" 
wrote:>
> > Leo will soon do more than what you are
> > asking directly.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: leoSettings.leo about to change

[ne1uno]

> Leo will soon do more than what you are
> asking directly.

rue the day.


On Oct 25, 10:16 am, "Edward K. Ream"  wrote:
> On Mon, Oct 24, 2011 at 9:14 AM, ne1uno  wrote:
> > is there any way extra options could be passed onto QApplication(sys.args)?
>
the optparse docs effectively hid from me any hint of extra options or
turning off errors on non existent options.
so I wasn't able to actually try --style or --stylesheet

I was prepared to give up on -stylesheet, after hearing the argument
in another thread, about exposing too much of the implementation.
though you only really care about the base widgets.
flip a coin.
@data stylesheet solorize  contrast+=3 works for me too.

I see now that --stylesheet would have to be intercepted,
I doubt the one given on the commandline would override
any stylesheet set programmaticly by Leo.
I also thought stylesheets were cumulative.
--stylesheet-replace could be the default
--stylesheet-append would be another good option

a script to output the current widgets and style would be nice to
have.
anything from a simple brace check to a full syntax check on the qss/
css probably should be done.
I haven't seen any code for that.

void setStyleSheet() apparently is no error on bad stylesheet. so no
help.
dejavu on Tk Tiles & Tix without the install & setup problems.

you can also set style. not every OS will have every style.
unknown styles are ignored.
Plastique & Cleanlooks set a small radius on widgets. either might
easily be the default without offending anyone.
it's a subtle change.

you can create custom styles but I never looked into exactly how.
maybe with QML or QScript you can script a new style.

""" setStyle()
"""
from PyQt4 import Qt
#these are usually active in Windows
styles = "Windows,WindowsXP,Motif,CDE,Plastique,Cleanlooks".split(',')
#get styles
styles= list(Qt.QStyleFactory.keys())

#pick one
i = 4
g.es( styles[i] )
Qt.QApplication.setStyle(styles[i])
#e


> 1. Imo, it is time to consider adding a typical "startup" file to Leo,

~/leo_config.py and  cmdline --config=workflow_config.py
would be especially nice to change a few runtime options for
the workaday Leo allowing subsequent clicks on a shortcut to
open another leo using the default out of the box config.
though there are numerous ways around that already.

config files are a little problematic. when they error, Leo will
print an error message and exit python taking the command
prompt down with it unless you start Leo from a command prompt
directly. but, any additional capability will be appreciated.

not limited to problems in a config file,
some python errors before Leo gets rolling will pause the display if
started with python -i launchLeo,
but disappear as well if using pythonw.

it would be nice if python would trap all errors.
maybe Leo returning a known error code would do it?
unless in batch mode, a pause would give some time
to actually read the error message.
could bring back a real live popup error message too.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: leoSettings.leo about to change

[ne1uno]

Qt lets you set -style= and -stylesheet= from the commandline, but
optparse errors on unknown options. on X11 you can set quite a few
more options for debug and window controls.

is there any way extra options could be passed onto
QApplication(sys.args)?
maybe with a short informational pseudo --help display for unknown (to
optparse) options?
does seem like a bug not to allow this typical Qt usage.

it's possible if you would be consulting an @data stylesheet node to
deternine what was active, that would no longer be valid, so I guess
you would have to update the internal stylesheet in that case?


On Oct 23, 5:08 pm, "Edward K. Ream"  wrote:
> Now that there is a clear indication of which pane has focus, Leo's
> pastel backgrounds seem truly dubious, especially for the body pane.
>
> I plan to change various colors in leoSettings.leo. If you like the
> existing colors now would be a good time to copy the following
> settings to myLeoSettings.leo::
>
> @data qt-gui-plugin-style-sheet
> Body pane colors
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Leo: munging and analyzing text

[ne1uno]

On Sep 26, 3:38 pm, "Edward K. Ream"  wrote:
> On Sat, Sep 24, 2011 at 3:12 PM, ne1uno  wrote:
> > wouldn't it be great to have a first class c importer?
>
> Importing C "perfectly" would require AI.  Furthermore, people may
> have legitimate preferences for various ways of doing the import.  For
> instance, Kent prefers to split nodes whenever possible:  I like, (or
> liked) fewer nodes.
>
> It may be that the simplest, most flexible, approach would be to
> define tools (scripts, @button nodes) that adjust the result of
> imports.  For example,  here is an @button node I created recently:
>
> @button join-below
>
> '''Join p.b to p.next().b. and delete node p.'''
> u = c.undoer
> p2 = p.next()
> if p2:
>     b = p.b.lstrip()
>     if not b.endswith('\n'):
>         b = b + '\n'
>     p2.b = b + p2.b
>     p.doDelete(p2)
>     c.redraw(p2)
>
> This merges the body text of the selected node with the body text of
> the next node, then deletes the first node.  This simple script helps
> a lot, even without the obvious additions: making it undoable and
> joining only the selected text.
>
> > hiding the complexity of platform & compiler/option #defines.
>
> Possible, but it is tricky to generate the proper code (tree).
>
> > invisible (TM) nodes would be fruitful here.
>
> Hmm.
>
[...]
>
> In any event, parsing is really not the problem: Leo's C importer does
> pretty well, and any improvements would come from better recognition
> of higher-level patterns, not recognition of lower-level C (and CPP)
> constructs.
>
> > Maybe a tokenizer is enough.
>
> A C tokenizer is almost identical to a Python tokenizer:  different
> keywords and operators, but otherwise very simple.   Alas, tokenizing
> really does not solve the difficult problems, namely the recognition
> of higher-level patterns.
[]
>
> Any and all bug reports against Leo's C importer are welcome.
>
yea, on second thought, I was really thinking more of the other
language importers. like html. that basically create a flat file
 needing additional manual labor.


http://clang.llvm.org/
I had bookmarked this but forgot to look it up.
should be easy to get it working if you can stomach the toolchain.
uses cmake & msvc to build and python to test.
I gather, clang/llvm is a drop in replacement for gcc. intermediate
file is a c ast. most of the hard work done.

I will probably have to wait for the binaries or a larger primary
drive. the website lists many in process and llvm in use
projects that sound very interesting for code analysis.

most recently, qtcreator added clang support.
that would be the one to beat since nearly the first version.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Ratcheting: kaizen and unit tests

[ne1uno]

pyqt partially wraps QTest
with QTest you can activate buttons, fill in text fields etc.
see an example here:
http://www.voom.net/pyqt-qtest-example

it might also be a simple, although fragile way for users
to instrument Leo dialogs and menus.
a scripted way to get to a specific Leo setup,
 to replicate a bug or start work on a new project.

On Oct 20, 1:32 pm, "Edward K. Ream"  wrote:
> 2. Many (most?) bugs nowadays depend on a specific set of plugins
> being enabled, or a specific set of options being in effect.   But I
> run unit tests from a *particular* script, that runs unitTest.leo with
> a *particular* set of options.  Furthermore, running tests externally
> is *more* restrictive, not less, because at present running tests
> externally uses the leoBridge module, which in turn uses the nullGui.
>
> 3. Gui-related bugs cause particular problems for unitTest.leo,
> because I don't like to pollute the output with the output from
> various work-arounds to code that would otherwise put up dialogs and
> thus pause the unit tests.
>
> In other words, gui-related unit tests often result in added code (in
> the code being tested) that a) are almost pure cruft and b) typically
> actively subvert the intention of the actual test!  This does not seem
> like progress: I would (usually) prefer to endure repeated (failed)
> attempts to fix the bug rather than pollute the code.
>
> In short, a more general testing framework is needed.  Until that
> happens, we will have to muddle through with untested, and thus very-
> likely buggy code.
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: What would lighter programming be like?

[ne1uno]

in the interest of the heavy/light distinction,
there are quite possibly too many menu choices.
Help-
-default menus-
-beginner
-intermediate
-advanced
-publishing
-programming
it should be easy enough to switch menus in real time.
these wouldn't be much in the way of real differences.
it may be difficult to hide some items.
maybe just give them more transparency,
it shouldn't be necessary for a new user to setup their
own menus out of the box. this would be a simple way in.
is the default now full menus except for no right click
menus? this would be something a new user could easily try
without needing to go through the settings shock.

funny you should mention syntax highlighting in the same
vein as calling SciTE light. I can't imagine a heavier way
to implement syntax highlighting than that used in SciTE.
adding new languages requires a recompile. first you have
to decide if to add to one of the family of languages or
create a new one. all the languages have their own styles
and just getting all the comments the same color out of
the box can be an insurmountable problem for a new user.
shared syntax files mean conflicts can happen.

managing setttings is SciTE, looking at it objectively, is
nearly the same as in Leo!  of course, it's a hard problem.
to be fair, SciTE never claims to be more than a demo
for Scintilla, so it's really not fair to pick on SciTE
for not having this or that feature. or even long standing bugs.
it seems like the devs main goal in SciTE is to say no.
much the opposite often happens with Leo.

KWrite, using the kate syntax files and completion is my new favorite
code "light" editor. does many things well. plugins, scriptable. I
have only just used it a few times in the past few
weeks though, from a live backtrack5 KDE dvd,  depending
on KDE it will probably not turn out to be a truly light candidate.
we are not taking technology anyway, but the look & feel.


On Oct 10, 5:43 pm, "Edward K. Ream"  wrote:
> Code reuse could be called the holy grail of programming.  The
> evidence suggests it will never happen, and for perfectly plausible
> reasons.
>
> Instead, we could hope for *design* reuse.
>
> Still, in the spirit of "lightening everything" it's at least amusing
> to consider the question.
>
> Let's take a concrete example as the base of speculation.  Leo does a
> great job (if I do say so myself) at interfacing with
> QSyntaxHighlighter.  It's tricky, as described in the Post Script.
>
> Otoh, pygments does a great job of describing, in perhaps the simplest
> way possible, how to tokenize and scan lots of modern-day languages.
>
> So here we have a typical situation: two excellent code bases, each of
> which does something related to the other.  Could we merge the best
> parts of each?  Yes.  All it will take is blood sweat and code :-)
>
> In this case, however, we may get a bit lucky: all pygments pattern
> matchers are regex matchers, so perhaps a single, generic, restarter
> would be needed.
>
> Edward
>
> P.S. The aha behind the line-oriented jEdit colorizer is that we can
> define one or more *restarter* methods for each pattern matcher that
> could possibly match across line boundaries. I say "one or more"
> because we need a separate restarter method for all combinations of
> arguments that can be passed to the jEdit pattern matchers. In effect,
> these restarters are lambda bindings for the generic restarter
> methods.
>
> In actuality, very few restarters are needed. For example, for Python,
> we need restarters for continued strings, and both flavors of
> continued triple-quoted strings. For python, these turn out to be
> three separate lambda bindings for restart_match_span.
>
> When a jEdit pattern matcher partially succeeds, it creates the lambda
> binding for its restarter and calls setRestart to set the ending state
> of the present line to an integer representing the bound restarter.
> setRestart calls computeState to create a *string* representing the
> lambda binding of the restarter. setRestart then calls
> stateNameToStateNumber to convert that string to an integer state
> number that then gets passed to Qt's setCurrentBlockState. The string
> is useful for debugging; Qt only uses the corresponding number.
>
> EKR

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Leo: munging and analyzing text

[ne1uno]

wouldn't it be great to have a first class c importer?
hiding the complexity of platform & compiler/option #defines.
invisible (TM) nodes would be fruitful here. switched on by @#define.
with an @#define= collection node or using a bunch of headlines.
and an rclick flipper for true/false, defined/not defined
declarations.

we know c isn't disappearing. quite a few people still regard
any so called scripting language as a nuisance.
maybe ok for prototyping but not for the final product.
pyqt would be near zilch useful w/o Qt, at least currently.
I guess that's as far as I ever got, wouldn't it be great if...

meanwhile I wait for the inspiration or someone else to nail down
a regular expression c language parser. maybe a tokenizer is enough.
I did run c code through AStyle then through your old c2py via
buttons.
for code that would remain in c,
in SciTE through google CPPlint program to point up flaws,
and to get the context sensitive help from various CHM.
running flawfinder good to do now and then old or new code.
post processing and displaying the report in a browser.
but it doesn't go far enough & too many false positives.

there is splint, maybe the only free lint left. the need to inject
"hints" all over the code make it less than ideal for perusing
unknown source and generally a deal breaker for project code.
sometimes all you need is a function/var list to get by.
deeper static analysis is quite the serious business. so, it's
not a surprise those programs are not easily found, or used.
there are a few code flow programs that could be harnessed
to colorize headlines indicating relations.
taking all this in, marking nodes that need work with a popup
or tooltip action event when you view that node with the
details of one or another parser to annotate what needs work.

we have had a few plugins/buttons/attempts at designing an
interface to get a program node compiled. this is also a decent
way to get info on the quality of code by turning all warnings on.
fails for snippits. never quite simple to hookup or modify painless.
perhaps the biggest problem is knowing what is available and where.
more toolbars, no reason they can't dock. drag & dropping buttons.
one of the huge advantages of Qt over Tk so far barely tapped.
you begin to accept the fact that you need to create a temp file
instead of real process control. managing program quirks
& options becomes more trouble than it's worth just to
protect the purity of the operation sans temp files.
QTprocess has more options than the process in pythons libs.
if it ever works as well as it should. but, a little hard to wrap.
not going to venture a guess if pyqt gets it right or not.
not to mention how bungled up OS process control still is.
process control will be essential to any inter-process operations.
that is, unless you backslide into wanting to build everything "in"
and invent everything new again. re: blender, I haven't looked at
blender code in a while, but I would be shocked if there weren't
some well established way to hook into a script.
sounds like noone has found them yet.

not sure how to grab a window handle on other OS but for windows
it's fairly straight forward. blender or GTK could setup blocks.
another great Qt based project is universal indenter, a front end

for many indenters for many languages. this would be a good place
to look for how to manage inter-process communication in Qt.
a first class editor will have to include first class importer for
javascript at the least and probably lua and one or two others.
one could imagine niceties like clickable links on #include files.
right clickable options on them such as import, simple view, htmlize.

also about styles, astyle has the options on the commandline, the
builtin/compiled in defaults and an ~/.astyle.rc for personal style.
some will find an indenter that has no options useless. I know the
indenter created is purely for internal use, as it were, at this
point.
adding selectable options later will complicate the program and for
most use will have little payback. you may as well expect to have some
want a plugable option for style.
exposing a general use tokenizer could have many callers.


On Sep 21, 8:44 am, "Edward K. Ream"  wrote:
> It's finally become clear why I am so interesting in text scanning.
> It's a big part of text editing.
>
> So rather than convert other people's programs, I'll be focusing on
> converting programs in Leo outlines.
>
> This is also the reason I'm interested in the new lint project.  It
> would be good to build program analysis tools into Leo.
>
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

[GAOD] Maple Professional compare & contrast

[ne1uno]

you're probably too late to get the freehe giveaway, but some of the
comments related to the app some will find interesting,
http://www.giveawayoftheday.com/maple-professional/
QQQ
Maple Professional is the flagship of the tree outline managers for
power users. It enables you to create hierarchical trees for storing
information such as documents, notes, and images.
QQQ

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Create Leo as an executable .EXE file?

[ne1uno]

On Aug 13, 9:47 am, Steve Allen  wrote:
> Having the program as an .EXE would allow you to bypass this
> restriction by creating it as a "Portable App", which is able to be
> ran from a USB stick.  Just food for thought.

another route is portableapps.com, I use winmerge and firefox portable
and if anything they start faster than the full install. the advantage
of smaller footprint and not using the registry?

getting Leo accepted by portableapps would not be especially easy,
consider limiting the settings search for one thing. python itself is
not especially portable by design, the size of pyqt is a factor.
probably just needs someone to try to get Leo running as a
portableapp. I came acrost this thread, http://portableapps.com/node/12031

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: @root must disappear

[ne1uno]

On Aug 6, 9:05 pm, "Edward K. Ream"  wrote:
> The great collapse in complexity has taken away almost all the blah,
> blah, blah of LP (Literate programming).
>
> Gone are discussions of noweb, CWEB, LaTeX.  Leo still supports these
> languages, but it does so gracefully, without making a big deal about
> it.

let me hasten to add, I am a strong believer in the insights
that I assume led to the creation of the original  tangle/untangle
concepts, that is
keeping the docs with the code, now seen in a lighter form in doxygen,
javadoc, eudoc and others.
the full extent of untangle, as I understand it, just isn't required
when the docs
are contained in markup in comments. closer to the code, but
still a little removed and so they can get out of sync. another common
problem, hard to
automatically test examples with add hoc extraction of code.

you do have to give credit to the idea. but the tools many projects
now use are lots more practical and ultimately easier to understand.
we know this because there is no significant amount of code using the
superior literate methods. maybe I overlooked them?

Leo has not even kept the docs with the code itself.
which wouldn't necessarily have been an improvement all told.
barely using python doc strings except to the extent of having them so
as not to mess up auto api generating tools last I cared.
docing a moving target is always difficult. so it doesn't hurt to
occasionally run off an API list of available methods. even though you
know they are out of date as soon as a few plugins run.

anyone knows you need more than an API reference for decent docs and
too many projects stop there.
it doesn't matter where the doc source are located only that they get
improved
and stay in synch with the code, how ever that is defined.
worse than bad docs of course is bad code and anything that makes code
more complicated to follow surely is a bug magnet.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: @root must disappear

[ne1uno]

On Aug 6, 9:05 pm, "Edward K. Ream"  wrote:
> On Aug 6, 5:18 pm, "Edward K. Ream"  wrote:
>
> > On my bicycle ride today I had a "road to Damascus" moment:  It is
> > time to kill @root, or at least send to it the attic, there to be quickly 
> > forgotten.
>
> The great collapse in complexity has taken away almost all the blah,
> blah, blah of LP (Literate programming).
>
> Gone are discussions of noweb, CWEB, LaTeX.  Leo still supports these
> languages, but it does so gracefully, without making a big deal about
> it.
>

another page has turned, think of the grand bug report we might have
had when Dr Knuth or possibly his website maintainer
got around to importing one of those original cweb files into Leo...

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: [day job] Qt development on maemo phones video

[ne1uno]

On Jul 26, 2:14 pm, "Ville M. Vainio"  wrote:
>
> N900 can't run new versions of Leo anymore, because it has python 2.5.

as of a few months ago, well after everything worked in py3.0,
there were only 3 or 4 (totally gratuitous IMHO) one line, or two line
very localzed syntactic sugar type changes
that require py2.6
only took a very few minutes to revert them.

I am not sure if any more py2.6 or 3.0 ism's have been used recently,
I decided to stay with that forked version.


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Engelbart's NLS

[ne1uno]

On Mar 24, 12:07 am, June Kim  wrote:
> Hello,
>
> As I embarked on the journey of learning and using Leo, it constantly
> reminded me of Engelbart's NLS[1].
[]
> http://en.wikipedia.org/wiki/NLS_%28computer_system%29
>
> Were orginators of Leo aware of NLS, and did they take any concepts from it?
> Did they see any connections? Are they planning to extend Leo with NLS
> features? Where is Leo heading?

there are no doubt thousands of projects seemingly converging on the
theory of everything. many predating the web. thanks for posting the
link.

I've been studying the classic diff algorithms the past week for a
html tidy front end in euqt and ran into this, yet another project
I'de never heard of. this one seems to have helped define the term
"vaporware". revision control control is not yet a solved problem.
there is still room for improvements in the user interface for sure.
on just a quick read, they were attempting to build an RCS into the
editor. now there are so many competing products it would seem to be
impractical to limit an editor this way.

http://en.wikipedia.org/wiki/Project_Xanadu
http://xanarama.net/
http://xanadu.com/

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Second try: stupendous Aha re unit tests

[ne1uno]

On Feb 22, 8:21 am, val bykovsky  wrote:
> Hi Edward and All:
> To me your post is very interesting and needs
> time to think it through and respond
[]
> Imagine a 'programmable' (that is, flexible, reconfigurable)
> material.  Each constraint is in fact a control which drives an
> iterative process of reconfiguring the material so that the
> constraint is matched.  Sure, the material can be pre-configured
> ('the art of programming') to make its programming "more efficient"
> (vs. doing it from scratch).
> 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.  To me, this is
> how animals (and some humans) 'effortlessly' program their behavior
> under control of 'environmental challenges'.
> Sure, this line of thinking has a long history, but in the
> programming world i think this is relatively fresh and exciting
> development, and your focus on tools for code exploration and
> understanding seems to me extremely valuable.  Actually, this
> 'probing' technique is applicable to exploration of the whole class of
> 'complex systems'.
> Does this 'angle' make any sense?

this sounds like what I call scaffolding. it prerceeds unittesting and
is the only thing that works in the initial design. stub programs,
print of info, more typical things you do while getting set to
refactor are all scaffolding, support structure removed while cleaning
uo. unittests can be a temporary or permanent part of this. subject to
bit rot like any other code, unittests too early become an unnecessary
hindrance to progress.

have you read any of edwards earlier posts? he has been unittesting
for years, I think the new workflow mentioned where valid unittests
are moved into one or more files/trees helps maintain sanity yet while
with scaffolding  all you do is remove it and on to more progress.
nobody can see the exact process, it leaves little trace beyond
intermediate commits and backups. unittests are heavy scaffolding is
light and infinitely adaptable although not always repeatable in the
way unittests are. it I submit is indispensable while unittests, say
what you will, are still optional.


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Leo 4.7 delayed until critical issues fixed [OT] shuttle

[ne1uno]

On Jan 20, 4:57 am, "Edward K. Ream"  wrote:
> The two space shuttle disasters are a clear warning that schedule
> goals can be the enemy of quality.

while the proximate cause of that shuttle burning up being caused by
tile damage might have been averted by a tighter maintenance schedule
for various components leading to the ultimate tile damage on takeoff.
It appears more to have been a lack of vision, literally. the quote by
the by then rotten head of NASA who somewhat sheepishly said in news
conferences which I happened to catch on the satellite NASA channel
and I don't think widely aired and they have since removed, that we
decided not to look at the tile damage while in orbit because we
couldn't have fixed it anyway. I expected him to resign at that moment
and was dismayed to learn they would allow him to finish out the year
and collect a pension. needless to say, the arm was reconfigured to
contain video and a tile repair kit and provisions for EVA are now
standard equipment. I find it hard to believe that after years of tile
damage on takeoff and intense study by thousands of people over years
that no one could have challenged the conventional wisdom that it
would be better not to know if there were any serious tile damage in
orbit but that's apparently how it was.

time and time again Leo gets broken down and built up again while
adding a feature or fixing a bug and often both at once.
any number of projects suffer from lack of vision at the top and at
the bottom. Leo has been a great example of successful feedback at
both ends of the loop.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Re: Improving Leo's body pane

[ne1uno]

there are also style sheet options possible. somewhere to be included
in the page or in a resource or settings file. global or per body
text.

take a look at this html editor demo. has the source view tabs being
contemplated. also a handy zoom slider for text size. I believe it is
using the webkit widgets but I think the textedit widget can zoom text
size too.
not a whole lot of source there.

http://labs.trolltech.com/blogs/2009/03/12/wysiwyg-html-editor/
http://qt.gitorious.org/qt-labs/graphics-dojo/blobs/master/htmleditor/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: OT: The Monty Hall Problem

[ne1uno]

On Oct 6, 3:56 pm, "James A. Donald"  wrote:
> Jesse Aldridge wrote:
>
>  > The connection to global warming is that there are
>  > situations where cooperation breaks down.  Not because
>  > people don't understand the situation, but because
>  > circumstances compel them to take harmful (though
>  > logically sound) actions.
>
> Catastrophic Anthropogenic Global warming is a scam.
> The direct, scientifically established effects of CO2
> will warm the planet about 0.5 degrees centigrade by
> 2100, which is small compared to the random century to
> century drift of climate.  The sky is falling effects
> are the result of pseudo science, junk science.
[]
> Climate change is indeed real, in that the climate is
> usually changing.  Bur climate change right now is not
> real, or at least not real enough to be measurable, in
> that it is not clear whether over the last few decades
> the world has been getting cooler or warmer, or, as the
> sea ice would suggest, staying quite unusually constant.
> In another hundred years or so, it will be easier to say
> whether things were getting cooler or warmer in our
> time.

so what's your spin on the anti junk science view of glaciers
receding? or continuing to depend on the internal combustion engine?
overreacting to climate change will hardly make the top 100 major
follies of the human race in the last 20 years even if it proves to be
an overreaction. of course, if we were to wait for confirmation, by
then it may be too late to change in any organized manner.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: RC1 observations

[ne1uno]

On Jul 1, 9:38 am, "Edward K. Ream"  wrote:
> On Wed, Jul 1, 2009 at 9:40 AM, tfer  wrote:
>
a
> find/replace.
> Alt-ctrl keys toggle the find checkboxes.
>
> The search tab is for feedback only.
>

rather than chiding people to unplug their mice, would it not be more
leonic to just make the find and change labels clickable?
these non buttons would surely not offend commandline freaks.

after all, isn't input the ultimate user preference.
productivity happens between the ears not the knuckles.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: Understanding @leo.directive

[ne1uno]

On Apr 20, 7:31 am, "Edward K. Ream"  wrote:
> On Mon, Apr 20, 2009 at 12:20 AM, ne1uno  wrote:
>
> > On Apr 16, 7:57 am, "Edward K. Ream"  wrote:
>
>
> Are you 'e'?  If so, it's great to hear from you again.

never gone.

> > and buttons were not at all a revolutionary idea outside Leo!
>
> Maybe, but there is no real DOM outside of Leo,

maybe we should stop talking about it,
other editors may catch on.



>
> > plugins of course can change Leo, and many official pluggins do.
> > so in practice, a decorator, even without specific limits
> > on what kind of things it may do and to what is not too different.
> > IE, you should probably never execute any button, plugin
> > and now maybe ever load any Leo
> > especially concidereing that a leo may contain settings
> > that can virtually wipe out any specific safety setting you have.
>
> Yes, this is exactly correct.  Getting a .leo file from somebody you don't
> know and trust is exactly like opening a spam email.  Or worse.  There is no
> way to scan .leo files for malicious startup code.

with a more careful reading of this thread and AK's docs I
see this topic has not been entirely ignored and would no
doubt be brought up sometime before full implementation.



>
> > beyond the wow factor (plenty of that to spare) of the next big
> > thing, what will they do?
>
> That's the big question.
>
> I'm feeling a bit stuck.  Perhaps the next step is to play with techniques,
> and ignore the actual uses.

could always hammer out the API a little, though they tend get better
by evolution rather than by design. there must be many
things in common between @directive, @command, execute script
@settings @menu and other parts of Leo.
always a good time to check for inconsistencies that complicate the
docs and the scripts confounding anyone off the bleeding edge.
some can use selected text, some need to parse expressions
to get parameters. some parameters can be inferred by context. not
sure I have ever seen a comprehensive list.


> One idea/technique in search of an application if the notion of creating
> (Python) namespaces from Leo outlines.  This will allow a new kind of code
> sharing in outlines.

dyna menu*  has code to turn nodes into modules.
it is how I was able to call doctest without temp files.
you can doctest just a method of a class in a subnode.
you can doctest selected text I believe too. you can
put doctests in subnodes so they get syntax highlighted
which helps to cut down typos and obvious errors.

I never though to play around with other import usage.
this could reduce the amount of non related code
needed to import, while still allowing the py file to
contain a whole series of smaller related classes.
wonder if an optimization technique would simply
remove non needed classes from the global environment.
I always wanted to try to remove the grid & placer methods
from Tk at run time to see if it speeds up rendering.
assuming all the code only used the third remaining packer.


import from nodes might provide a speedup for @command and the future
@directive definition phase which I assume now
is done in some hand crafted parsing of code blocks.
load time is not bad on reasonable sized leo's, probably
file I/O is responsible for a bigger chunk of time than anything.

all you would need to do is register a node url which
could reside in an external file or not. rather than always
scanning the whole document looking for definitions.
I can still see the box I promise. you would obviously still
need to scan for new directives or expressions that change.


OTOH, I spent countless hours researching the techniques
of avoiding importing nodes such as when running
pychecker or epydoc or other doc'ers do especially with untrusted
code.
pylint could turn code into AST but it was not very scriptable.
and it falls back to import if it gets stuck. not too swift.
parsing into AST future proofs you a little since any
secure import would never just import code from a node or file.


* see def importCode used by du_test in dynamenu.py
I haven't updated it to work with current Leo. many
parts now could easily be changed to use @commands.
possibly 1/2 of dyna could be moved into an @setting node.
these days anything I can't eat, wear or pour gets a low priority.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: Understanding @leo.directive

[ne1uno]

On Apr 16, 7:57 am, "Edward K. Ream"  wrote:
[]
> My hunch is that these ideas are important, perhaps extremely
> important.
>
> The present situation reminds me of my first impression of e's
> dynaButtons.  I didn't really understand them at first, but the phrase
> "bring scripts to nodes" eventually lead to @button nodes and the
> mod_scripting plugin.
>
> At present, I am floundering around with these ideas.  But this is the
> kind of floundering I live for.  As I have said many times before, a
> prerequisite for creativity is the ability to live with confusion and
> uncertainty with calm excitement instead of fear.
>

actually, the quote was bring scripts to data.
which later coined the phrase your data your way.
and buttons were not at all a revolutionary idea outside Leo!
if you've used most any microsoft IDE or tool., macro buttons
could be programmed. some editors had the ability, though
most used and still only use menus. which the button is just
a special case of a more limited menu. the dyna button
you may recall uses the rightclick to choose between items.
the advance that Leo brings is the builtin data storage for
the script. although you still have the problem of having
buttons in more than one leo. we accept the small overhead.
the Library plugin was useful here, but still requires too much
fiddling.

so previously we had only thought of how to supply scripts with data
and the scripts lived on a menu and in the scripts directory.
and were probably hardly ever used. some machinery may have
been created to open scripts easily for editing and may have helped.

buttons are like the quote about decorators
they allow you to change the way you think about
how and where they can be used.
decorators after all, do nothing that can't be done in py2.2

the thing that jumps out at me about the decorator idea
is the assumption that it will be fine to execute them
at leo load time. does anyone else recall the angst over allowing
scripts to execute at load time? there are several settings
in mod_scripting to decide if buttons should execute & dissapear.
btw, near or late binding of the script is also an option.

pretty much, the defaults are all that are ever used
I'm not aware of any wiki or forum buttons that don't expect the
defaults.
but locally, it could make sense to have an executable leo.
plugins of course can change Leo, and many official pluggins do.
so in practice, a decorator, even without specific limits
on what kind of things it may do and to what is not too different.
IE, you should probably never execute any button, plugin
and now maybe ever load any Leo
especially concidereing that a leo may contain settings
that can virtually wipe out any specific safety setting you have.
maybe settings should have a level of security attached
that simply loading a leo cannot override.
ignorance is bliss. niche markets are immune to viri aren't they?
lets face it, we throw caution to the wind because it is
not easy to decide which if any plugins or buttons are safe.
should they be tested before and probably during each run?
we could try to limit scope and reject any we don't understand.
that is, any that whatever lint process doesn't understand
because if it isn't automatic, it probably won't happen ever.

I also think it would be sweet revenge that decorators become
the preferred way of defining directives.
maybe revenge isn't quite the word.
eventually IPython and Leo users absorbed the change in stride.
nobody at the time @ was being chosen could have imagined
@whatever() possibly allowing the data owner more control over
the interpretation of their nodes. what a concept.
we still have the problem of where or how to hide the script.
starting to sound more like a buttonless button that executes
to create the definition of a directive that accepts arguments.
beyond the wow factor (plenty of that to spare) of the next big
thing, what will they do?
how can they be made safer, should that be necessary.

<> insert the standard disclaimer about irrelevant tangents.
whatever happens will take a fair bit of coding, user education
doc changes that I probably won't be doing in any case.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: Further IRC improvements to #leo

[ne1uno]

drmike, you should be able to change the topic.
#Leo channel is topic locked so chanserv maintains topic:
/msg ChanServ TOPIC #leo whatever

good job with the bot's & logs.
IRC is just not what people seem to think of first these days.
most channels have too few or too many people active.
not to mention too many channels and networks.
groups/forums are better sometimes for timeshifting.
it is the best for capturing that first time user who will sometimes
temper a forum post and forget or neglect to mention the highlights or
lowlights of their experience.
lifeblood to any project.

On Dec 16, 2:28 pm, Mike Crowe  wrote:
>  At midnight
> each night, conversations, stats, etc will be generated and posted 
> at:http://echelog.matzon.dk?leo
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: The next 20 years? Programs making programs

[ne1uno]

On Dec 3, 11:27 am, "Edward K. Ream"  wrote:

> So this is the Aha: I can continue to do what I've always done, > but
> expand its application to something much more exciting than
> editors.
[...]
> So lib2to3 is just the first baby step towards treating Python
> programs as data in interesting ways.  We won't run out of ideas in
> this area in my lifetime.


a few rambling thoughts. it is always about the editor!
sounds to me like a deeper study of AWK is in order.
I have not needed pythoscope or lib2to3. is it for python3k?
your words evoke more of a data translation construct
than one of a program generator to me. there is a huge
need for easier data visualization to enable more flexible
translation tasks. to broaden the available user base
to enable one with less of a programming skill set to
create the tools needed to accomplish their unique tasks.
by no means new idea but always ripe for picking.
maybe data translation is program generation afterall.
more scriptability, easier to grasp API's, self healing,
are they enabled with better completion and help lookup?
some new combination of libs? we seem to love to invalidate
most of the work already accomplished every few (months,) years
in order to arrive at the need for ever more tricky translation
tasks just to break even. prodigious amounts of hardware and
software upgrades littering the path to there
as well as lost efficiencies of scale when the installed base shrinks.
more concretely, how great would it be to further enhanced the
ability of plugins to troubleshoot themselves instead of the current
situation of waiting for new or renewed users to provide traceback
after a failure. one of the more common frustrations with python.
this is the same old paradigm of try cut paste debug repeat.
we all try, some cut & paste and the debugging separates us.
even if we can make the thing compile and sign-on, does it work?
all test pass as they say, except for the one that counts, real usage.
has anyone succeeded in teaching a computer the intent of a plugin?
so we make better debuggers for more trials and little progress.

 can I suggest a first order of business is to divorce Leo
from python? as good as it has been for Leo it is now a drag.
only half jokingly:
translate pyqt code into c++ and be done with the piecemeal
optimizations. hooking up executescript via QtScript. or not.
as comfortable as python may well be. several orders of
newer versions will still leave us basically where we are.
there I've said it. now all that remains is to wait for the
necessary passage of time and for technology to catch up
till it can reasonably happen. we haven't begun to mine the
archives for data visualization and translation technologies
that have at various times been brought up in connection with
Leo as the bridge if only we could see all the pieces at once
and be there with a grasp of how to get from here to there.
it often takes someone on both sides to meet in the middle.
with suitable wrenches to handle the nitty gritty details.
the fog in this early morning hasn't begun to lift. back when I
could tolerate more python than I now can, I recall similar "the
sky is the limit" feeling. playing with an early version of Logix.
Unfortunately, as you well know, you inevitably get back to the
editor, the visualization, the nuts & bolts, the manufacturing,
the case hardening the testing, the procurement,
the forest the trees the limits the prospective audience
and finally the cost benefit ratios that rarely pan out except in
pure research and experience. you are left with an ever escalating
download upgrade death spiral that thins your target machines
and environments until only you can use the possibly amazing
but fragile thing that barely survives description let alone
widespread use. if we are lucky, we get a plugin and a few demos.
and a whatever.leo, so what can pythoscope do that AWK hasn't
already mapped out as possible 40 years ago?
albeit probably only in bell technical journals gathering dust in
some
university library basement closet and sadly landfill or other
disaster.
although I assume you could pay for the privilege to search & read
too.

awaiting @tab pythoscope and it's @popup API. the devil is in the
details.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Leo bzr snapshot problem

[ne1uno]

note the small size on yesterdays snapshot from
http://www.greygreen.org/leo/

leo-bzr-snapshot-200811200253.zip (1 day old)
Bytes: 435

the zip only contains part of a readme.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: Fatal Python error: GC object already tracked

[ne1uno]

On Nov 14, 12:11 am, zpcspm <[EMAIL PROTECTED]> wrote:
> On Nov 14, 6:52 am, ne1uno <[EMAIL PROTECTED]> wrote:
>
> > py2.5 on win98
>
> Ouch, that's hardcore.
> Why would you use such an ancient and unstable OS?
> Win98 is notorious for being unstable itself, because it doesn't use
> the NT kernel. And Fat32 is not a reliable filesystem as well.

sure, but many older systems and laptops are not upgradable.
I only went to py2.5 because the latest pyqt requires it.
py2.5 is the last that will support win98 so the installer says.
if you have enough memory and apps don't use xp only things it works
fine most times. firefox3 uses cairo so that won't work for ex.

xp is plenty unreliable too and being discontinued.
hopefully I get to skip directly to 64bit. so has Leo been tested
there yet with a 64bit OS and python? we all have problems.
think of win98 like the canary in the coal mine.

with the latest pyqt and qt of last week, some programs on exit hang
python with a threading error on win98 so the writing is on the wall.
plenty of well constructed apps, which python btw is not in a few key
areas, will continue to function.
 the insanity of the DOS/WIN stderr and stdout support is one major
headache and cause of problems. can we agree on that? and continues
with backward compatibility with vista mainly droping support as a
solution. while anyone knows that a unixy console is much more useful
& reliable for some applications.

looking forward to the merge of the qt branch. this surely will put
Leo on the fast track. thanks.






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Fatal Python error: GC object already tracked

[ne1uno]

Fatal Python error: GC object already tracked
This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.


has anyone seen Leo dissapear & python quit with this message?
obviously, any unsaved work is lost.
happened a few times already, at random times while clicking
on something either the mouse or the keyboard. nothing repeatable.
could there be some GC debugging code left in the core somewhere?

py2.5 on win98 using bzr nightly revno1233 week or more ago






RIP. bernhard, you were already missed.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---

Re: no downloadable source distribution weekly? nightly?

[ne1uno]

> > Well, it's on an Ubuntu box that runs 24x7 (it has a lot of other
> > duties), so it's run at 2:53 am every day by the cron task.  Hence the
> > timestamp on the newest snap athttp://www.greygreen.org/leo/
>
> > So on the server there's a line in my crontab that looks like this:
>
> Thanks for these details, and thanks for writing, and running, this script.
>
yes thanks, another possibility would combine a checkout lightweight
with   bundle-revisions   --output=filename but I don't know the exact
syntax. there may be other pitfalls such as not including some
directories or too much history etc.
and would be complicated by needing to change to a more backward
compatible bzr format such as used in 014 or earlier.

just an FYI, not a suggestion or request! the ,bzr files/dirs would
just annoy anyone else and the zip probably can be imported fine.

the nightly/weekly zips will be appreciated, I know the request has
been made before bzr and svn back to cvs.


ne1
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---