Re: OT: The Monty Hall Problem

[Kent Tenney]

On Tue, Oct 6, 2009 at 5: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.  For example,  China and
>  > India don't want to cut emissions, because they want
>  > to become "the new US".  And the US doesn't want to
>  > cut emissions because we want to retain our status as
>  > "#1".  I can easily see the industrialized world
>  > continuing to make half-assed efforts that fail to
>  > effectively address the underlying sources of
>  > greenhouse gases.  Instead we will come up with
>  > ad-hoc, expensive adaptations to a hotter planet.
>
> Catastrophic Anthropogenic Global warming is a scam.

The science is beyond me, but I'll take the word of 100's of climate
scientists from many countries over several decades over
an economist who says what people want to hear.

see http://tinyurl.com/yag8tpn

> 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.  For a
> relatively easy to understand summary of the latest
> fraud to be exposed, see
> 
> one of many such discoveries of junk science.
>
> The short of the above story is that the evidence that the
> twentieth century has been warmer than the past turns
> out to be an average taken over TEN TREE growing in a
> cold climate, whose growth therefore should reflect the
> length of the warm season, ten trees selected from a
> large population of trees by Briffa, ten trees that have
> appeared again and again in a variety of supposedly
> independent graphs of temperature that supposed confirm
> each other.  Of these ten trees, ONE TREE, Yamal06, showed
> remarkable and unusual growth as compared with fossil
> trees.  However, it turns out these were ten *selected*
> trees, selected without explanation from a much larger
> set of measured trees.
>
> When we average over whole set of similar nearby trees
> their growth patterns are similar to those of fossil
> trees from the same area.  And similarly, if do our own
> selection, by averaging over nine of the ten trees that
> Briffa selected, and exclude Yamal06 as an outlier,
> again the growth patterns of the nine we select of the
> ten Briffa selected are similar to that of the fossil
> tree population.
>
> There is no evidence that temperatures have risen during
> the twentieth century.
>  g.html>
>  raw-surface-temperature-data.html>
>
> Sea ice remains the same as it has been since 1978, when
> satellites first gave us accurate observations of total
> ice area
>  aily.ice.area.withtrend.jpg>
>
> There is no persuasive theoretical reason to expect
> unreasonably strong warming from CO2 emissions, and we
> have not in fact actually observed such warming in
> recent times.  In 2006 the arctic  had unusual melting,
> but not as much as it melted in 1959, and every arctic
> summer since 2006, the ice has been greater than the
> last, despite regular loudly announced predictions of
> the opposite.  In any given year, there is always an
> unusual weather event somewhere, some time, but truly
> global averages, such as world sea ice, world tropical
> storm energy, etc, show no long term pattern, the show
> some warm years and some cold years, some warm decades
> and some cold decades - the tropical storm energy shows
> pretty much the same non pattern as global sea ice.
>
> Twentieth century temperatures are warmer than most of
> the last two thousand years, cooler than the Medieval
> climatic optimum, and cooler than most of the last ten
> thousand years. The climate gets cooler, it gets warmer,
> it gets cooler again.  In recent decades, when most of
> the CO2 was released, there has not been much change.
> 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.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group

Re: Rev 2432 - Crash on startup with Tk GUI

[TL]

> The fix is on the trunk at rev 2440.  All unit tests pass with tk enabled.

Thanks for the quick fix.  Very much appreciated.

TL
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Vim emulation - update

[TL]

Rev 2447 of the Trunk has restored the Scroll functionality in the Tk
GUI (still doesn't actually scroll [see previous post]) and updates
the Vim emulation to use it.  See the Vim History node in the
leoSettings.leo file for a list of the changes.

Let me know if there are problems/questions/suggestions.

Regards,
TL
--~--~-~--~~~---~--~~
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

[James A. Donald]

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.  For example,  China and
 > India don't want to cut emissions, because they want
 > to become "the new US".  And the US doesn't want to
 > cut emissions because we want to retain our status as
 > "#1".  I can easily see the industrialized world
 > continuing to make half-assed efforts that fail to
 > effectively address the underlying sources of
 > greenhouse gases.  Instead we will come up with
 > ad-hoc, expensive adaptations to a hotter planet.

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.  For a
relatively easy to understand summary of the latest
fraud to be exposed, see

one of many such discoveries of junk science.

The short of the above story is that the evidence that the
twentieth century has been warmer than the past turns
out to be an average taken over TEN TREE growing in a
cold climate, whose growth therefore should reflect the
length of the warm season, ten trees selected from a
large population of trees by Briffa, ten trees that have
appeared again and again in a variety of supposedly
independent graphs of temperature that supposed confirm
each other.  Of these ten trees, ONE TREE, Yamal06, showed
remarkable and unusual growth as compared with fossil
trees.  However, it turns out these were ten *selected*
trees, selected without explanation from a much larger
set of measured trees.

When we average over whole set of similar nearby trees
their growth patterns are similar to those of fossil
trees from the same area.  And similarly, if do our own
selection, by averaging over nine of the ten trees that
Briffa selected, and exclude Yamal06 as an outlier,
again the growth patterns of the nine we select of the
ten Briffa selected are similar to that of the fossil
tree population.

There is no evidence that temperatures have risen during
the twentieth century.



Sea ice remains the same as it has been since 1978, when
satellites first gave us accurate observations of total
ice area


There is no persuasive theoretical reason to expect
unreasonably strong warming from CO2 emissions, and we
have not in fact actually observed such warming in
recent times.  In 2006 the arctic  had unusual melting,
but not as much as it melted in 1959, and every arctic
summer since 2006, the ice has been greater than the
last, despite regular loudly announced predictions of
the opposite.  In any given year, there is always an
unusual weather event somewhere, some time, but truly
global averages, such as world sea ice, world tropical
storm energy, etc, show no long term pattern, the show
some warm years and some cold years, some warm decades
and some cold decades - the tropical storm energy shows
pretty much the same non pattern as global sea ice.

Twentieth century temperatures are warmer than most of
the last two thousand years, cooler than the Medieval
climatic optimum, and cooler than most of the last ten
thousand years. The climate gets cooler, it gets warmer,
it gets cooler again.  In recent decades, when most of
the CO2 was released, there has not been much change.
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.

--~--~-~--~~~---~--~~
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

[Jesse Aldridge]

> At first glance, I don't see how the video relates exactly, but I can
> tell you I would not have invested :-)

I would have invested.  I would have felt it was the morally
imperative thing to do.  And I would have gotten shafted.  I found it
shocking and outrageous that so many could take an action that made
the group as a whole worse off.

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.  For example,  China and India don't
want to cut emissions, because they want to become "the new US".  And
the US doesn't want to cut emissions because we want to retain our
status as "#1".  I can easily see the industrialized world continuing
to make half-assed efforts that fail to effectively address the
underlying sources of greenhouse gases.  Instead we will come up with
ad-hoc, expensive adaptations to a hotter planet.  And of course in
this scenario the third world is fucked.  ...but what else is new?
--~--~-~--~~~---~--~~
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: more issues - losing data in files

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 9:33 PM, Casey (kc)  wrote:
>
> May they all be this easy.
>
> This is one of those RTFM situations where I'm going to have to
> contribute all my pocket change to the kitty.
>
> That document had some text I imported from a report file that had
> form feed characters in each header.  I had to delete the Ctrl-L
> characters and it was then okay.

New versions of leo should strip those characters on write, it was
probably saved with old version of leo.

Cases like this make me lose my faith in xml bit by bit.

I have some preliminary sketches in my head for using either sqlite or
zip files as tnode storage. This would also help small memory systems
(read: phones), where only visited tnodes would be actually loaded to
memory. It would also speed up saving of big files, as only changed
nodes (and the outline xml) would need to be written.

There are some use cases for this, like slurping in a gigantic source
tree in one huge .leo file (possibly as @@auto nodes) for later study
on-the-road. Saving and loading the whole tree every time is a big
drag.

-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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: setup issue - cannot run Leo past 4.5.x

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 7:51 PM, Casey (kc)  wrote:

> Just now I reverted back to 4.5.1 final and got leo back again.  So I
> no longer am totally screwed on my project.  But I'm puzzled about
> this.  I see some other posts so other people are having troubles.  I
> tried running just python instead of pythonw and it replied with a
> string of errors about being unable to load QtGui.  But when I went
> back to pythonw, nothing.  I'm not a python programmer so I don't know
> how to debug this.  Is there something else I should install now?  I
> don't have Qt installed - should I try that?

Your problem should be resolved by getting the latest bzr trunk. It
should (propely) revert to Tk ui when Qt is not available.

However, probably the best solution for you is to install PyQt from:

http://www.riverbankcomputing.co.uk/static/Downloads/PyQt4/PyQt-Py2.6-gpl-4.6-1.exe

-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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: more issues - losing data in files

[Casey (kc)]

May they all be this easy.

This is one of those RTFM situations where I'm going to have to
contribute all my pocket change to the kitty.

That document had some text I imported from a report file that had
form feed characters in each header.  I had to delete the Ctrl-L
characters and it was then okay.

Thanks a lot Ed.

--KC

On Oct 6, 3:03 pm, "Edward K. Ream"  wrote:
> On Tue, Oct 6, 2009 at 1:52 PM, Casey (kc)  wrote:
>
> > In another post I described how I reverted back to 4.5.1 in order to
> > get Leo to run again.
>
> > Now I'm having issues that seem peculiar.
> > SAXParseException saying "not well-formed (invalid token)".
>
> See:http://webpages.charter.net/edreamleo/FAQ.html#trouble-shooting
>
> Scroll down until you see
>
> SAXParseException: :123:25: not well-formed (invalid token)
>
> Follow the directions.
>
> 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: more issues - losing data in files

[Edward K. Ream]

On Tue, Oct 6, 2009 at 1:52 PM, Casey (kc)  wrote:

>
> In another post I described how I reverted back to 4.5.1 in order to
> get Leo to run again.
>
> Now I'm having issues that seem peculiar.




> SAXParseException saying "not well-formed (invalid token)".
>

See: http://webpages.charter.net/edreamleo/FAQ.html#trouble-shooting

Scroll down until you see

SAXParseException: :123:25: not well-formed (invalid token)

Follow the directions.

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
-~--~~~~--~~--~--~---

more issues - losing data in files

[Casey (kc)]

In another post I described how I reverted back to 4.5.1 in order to
get Leo to run again.

Now I'm having issues that seem peculiar.  If this were my project I'd
be very interested in them; but it may all be due to something stupid
that I did in configuring the program.  Perhaps I could upload a few
problem files, but I'm reluctant since I can't risk exposing anything
that someone might consider sensitive.  I'll describe what's happening
first.

When I double-click on a leo-associated document file, some smaller
files run all right.  There are several larger files however that
result in a tk window with a load of trace text describing exceptions
in Tk callback functions.  In the main leo client window, the outline
has only a single node, called "created root node".   In the log pane
there's a lot of traceback text ending with a SAXParseException saying
"not well-formed (invalid token)".  After this when I kill leo it asks
me if I want to save my changes, so leo at least knows the contents
have changed but doesn't know it has made a mess.

This happens on several leo files.  When I open the leo files in gvim
I get what looks like a normal leo xml file with all my text and
such.  Does this smell like something I did wrong in the setup?
Smells to me as though I've got conflicting versions of some subsystem
(s) or other that leo uses, but I'm not sure how to figure that out.

Do you have any advice for me?

--KC

--~--~-~--~~~---~--~~
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: setup issue - cannot run Leo past 4.5.x

[Edward K. Ream]

On Tue, Oct 6, 2009 at 12:51 PM, Casey (kc)  wrote:

>
> Is there something else I should install now?  I
> don't have Qt installed - should I try that?
>

That's probably the easiest way in the long run.  Be sure to use the binary
installer on Windows for qt.

However, you can try running Leo from the console with tk enabled. From the
directory containing launchLeo.py, do

python launchLeo.py --gui=tk

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
-~--~~~~--~~--~--~---

setup issue - cannot run Leo past 4.5.x

[Casey (kc)]

I'm in trouble with leo setup again.  Before I went away for 3 weeks I
upgraded to 4.6.2 and suddenly leo wouldn't run.  I poked at it for a
few hours and gave up as I was leaving for South Africa.

When I came back last week I had forgotten everything I might have
tried.  I installed the 4.7.1 beta and got no results. (As in No
Results - no error messages, just nothing happens when I run the
command line.)

Just now I reverted back to 4.5.1 final and got leo back again.  So I
no longer am totally screwed on my project.  But I'm puzzled about
this.  I see some other posts so other people are having troubles.  I
tried running just python instead of pythonw and it replied with a
string of errors about being unable to load QtGui.  But when I went
back to pythonw, nothing.  I'm not a python programmer so I don't know
how to debug this.  Is there something else I should install now?  I
don't have Qt installed - should I try that?

I'm running Windows XP 64 bit, SP2, Python 2.6.1 64 bit,

Thanks for your help, you guys.  I really like using this software.

--KC
--~--~-~--~~~---~--~~
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: Rev 2432 - Crash on startup with Tk GUI

[Edward K. Ream]

On Tue, Oct 6, 2009 at 11:50 AM, Edward K. Ream  wrote:

>
>
> On Tue, Oct 6, 2009 at 7:27 AM, TL  wrote:
>
>>
>>  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7547, in
>> drawUserIcons
>>h,w = 0,0 ; t = p.v.t
>> AttributeError: 'vnode' object has no attribute 't'
>>
>
> Oops!  I'll fix this immediately, and run all unit test with tk enabled.
>

The fix is on the trunk at rev 2440.  All unit tests pass with tk enabled.

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: Rev 2432 - Crash on startup with Tk GUI

[Edward K. Ream]

On Tue, Oct 6, 2009 at 7:27 AM, TL  wrote:

>
>  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7547, in
> drawUserIcons
>h,w = 0,0 ; t = p.v.t
> AttributeError: 'vnode' object has no attribute 't'
>

Oops!  I'll fix this immediately, and run all unit test with tk enabled.

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: Removing v.t and cleaning plugins

[Edward K. Ream]

On Tue, Oct 6, 2009 at 9:29 AM, Terry Brown  wrote:

>
> Select node A
>
> Outline -> Copy Node
> Outline -> Paste Node
>
> Now there is a copy of node A  :-)
>

Ah.  This is a much easier case.

>
> So if there was a node B linked to A then after the rescan B would be
> linked to both the original A and the copy.  I think this is neat, but
> not worth the complexity it introduces vs. just using gnx for id.
>

Just to be clear, plugins *must not* change the gnx (v.fileIndex) data of
any node.  Your plugins probably don't do this, but it would be chaos if
they did.

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: Simpler File:Read/Write menu now on the trunk

[Edward K. Ream]

On Tue, Oct 6, 2009 at 9:54 AM, Ville M. Vainio  wrote:

>
> On Tue, Oct 6, 2009 at 5:27 PM, Edward K. Ream 
> wrote:
>
> > Rev 2435 simplifies and clarifies the Read/Write menu.  Very little
> > code actually changed, except that the Read @ command now
> > disables caching, thereby forcing a read.
>
> Why does it need to disable caching? For debugging purposes?
>

Presumably the user has a reason for forcing a re-read.  True, caching is
very likely to be benign, but the effect of not caching is to issue a
"reading" message, the absence of which would be confusing.

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: First draft of the first words of the intro

[Edward K. Ream]

On Sep 9, 9:33 am, "Edward K. Ream"  wrote:

> > No difference.  Same error appears.

I'm finally getting around to this.  Could you send me a smallish .leo
file that illustrates the problem.  Without seeing your code, I can't
tell whether this is a bug or a misunderstanding about what Leo wants
to see.

My address is edreamleo (at) gmail.com

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: Simpler File:Read/Write menu now on the trunk

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 5:27 PM, Edward K. Ream  wrote:

> Rev 2435 simplifies and clarifies the Read/Write menu.  Very little
> code actually changed, except that the Read @ command now
> disables caching, thereby forcing a read.

Why does it need to disable caching? For debugging purposes?

Apart from that, this is a great improvement for new and old leo users
alike. It's not fun trying to remember if @edit is "auto" or "file"
node.


-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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: Removing v.t and cleaning plugins

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 5:29 PM, Terry Brown  wrote:

> Select node A
>
> Outline -> Copy Node
> Outline -> Paste Node
>
> Now there is a copy of node A  :-)

Gotcha. Sorry for the confusion.

> So in the new version coming soon when you copy / paste a node which is
> linked to by another node, the other node will be linked only to the
> original, not the copy.

That makes sense. If you want identical copy (as opposed to
"content-copy"), you'll use clones.


-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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: Removing v.t and cleaning plugins

[Terry Brown]

On Tue, 6 Oct 2009 12:20:10 +0300
"Ville M. Vainio"  wrote:

> You forget that in one-node-world, there is no "copy of A".

We're obviously having trouble getting on the same page here (as Edward
concurred with this in another email).

Select node A

Outline -> Copy Node
Outline -> Paste Node

Now there is a copy of node A  :-)

That's what I'm talking about.  This copies the uA as well as the body
and head (as it should).  In the old (current) version of
backlink.py this has the effect of creating two nodes with the same id
(urgh) (remember the id is stored in the ua) which backlink.py
fixes at the next rescan (on reload or whatever).

So if there was a node B linked to A then after the rescan B would be
linked to both the original A and the copy.  I think this is neat, but
not worth the complexity it introduces vs. just using gnx for id.

So in the new version coming soon when you copy / paste a node which is
linked to by another node, the other node will be linked only to the
original, not the copy.

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
-~--~~~~--~~--~--~---

Simpler File:Read/Write menu now on the trunk

[Edward K. Ream]

Rev 2435 simplifies and clarifies the Read/Write menu.  Very little
code actually changed, except that the Read @ command now
disables caching, thereby forcing a read.

The renamed commands are:

Read @ Nodes
Write @ Nodes

The names emphasize that they apply to @auto, @shadow, @thin, etc, not
just @file nodes.

The following commands have been removed from the menu:

Read @auto Nodes
Read @shadow Nodes
Write @auto Nodes
Write @shadow Nodes

You can put them back by defining menus in myLeoSettings.leo, but imo
these commands are almost completely useless.  Indeed, the generic
Read/Write @ Nodes commands apply to the selected outline, so
you can use them to read or write individual files as you please.

Finally, the atFile.readAll and atFile.writeAll commands say @
rather than @file in their various messages, again emphasizing the
generic nature of the commands.

I think these are useful changes, and will help newbies in particular.

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: OT: The Monty Hall Problem

[Edward K. Ream]

On Oct 5, 4:55 am, "Edward K. Ream"  wrote:

> And in contrast, the worst article ever published in Scientific
> American:http://www.scientificamerican.com/article.cfm?id=squeezing-more-oil

Just ran across this site:http://www.badscience.net/

If I were a conspiracy buff, I would say there is a conspiracy to
denigrate everything that is scientifically known that is the least
bit "inconvenient" for various folk :-)  There certainly seems to be
an epidemic of bad-faith efforts to misrepresent the strength of what
is actually known scientifically.

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: OT: The Monty Hall Problem

[Edward K. Ream]

On Oct 6, 4:38 am, Jesse Aldridge  wrote:

> Check out this video:http://www.youtube.com/watch?v=fhrnFGP4zks
> It had quite an effect on me the first time I watched it.

At first glance, I don't see how the video relates exactly, but I can
tell you I would not have invested :-)

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: Rev 2432 - Crash on startup with Tk GUI

[TL]

Addtional info:
   Trunk rev 2420 works (was the current trunk on 10/2/09)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Rev 2432 - Crash on startup with Tk GUI

[TL]

I just updated my local Trunk branch to the latest trunk (rev 2432)

I get the following error during Leo startup running the Tk GUI on
WinXP:

Traceback (most recent call last):
  File "leo\core\runLeo.py", line 650, in 
run()
  File "leo\core\runLeo.py", line 95, in run
ok = doPostPluginsInit(args,fn,relFn,script)
  File "leo\core\runLeo.py", line 365, in doPostPluginsInit
c,frame = createFrame(fileName,relativeFileName,script)
  File "leo\core\runLeo.py", line 393, in createFrame
ok, frame = g.openWithFileName(relativeFileName or fileName,None)
  File "C:\_Proj\Leo\trunk\leo\core\leoGlobals.py", line 2796, in
openWithFileName
ok = g.handleOpenHooks(c,old_c,gui,fn,f,readAtFileNodesFlag)
  File "C:\_Proj\Leo\trunk\leo\core\leoGlobals.py", line 2859, in
handleOpenHooks
readAtFileNodesFlag=readAtFileNodesFlag) # closes file.
  File "C:\_Proj\Leo\trunk\leo\core\leoFileCommands.py", line 899, in
open
silent=silent)
  File "C:\_Proj\Leo\trunk\leo\core\leoFileCommands.py", line 792, in
getLeoFile
c.redraw()
  File "C:\_Proj\Leo\trunk\leo\core\leoCommands.py", line 6476, in
redraw
c.frame.tree.redraw(p)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7296, in
redraw_now
self.redrawHelper(scroll=scroll,forceDraw=forceDraw)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7321, in
redrawHelper
self.drawTopTree()
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7714, in
drawTopTree
self.drawTree(p,self.root_left,self.root_top,
0,0,hoistFlag=hoistFlag)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7742, in
drawTree
h,indent = self.drawNode(const_p,x,y)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7483, in
drawNode
return self.force_draw_node(p,x,y)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7492, in
force_draw_node
h2,w2 = self.drawUserIcons(p,"beforeBox",x,y)
  File "C:\_Proj\Leo\trunk\leo\plugins\tkGui.py", line 7547, in
drawUserIcons
h,w = 0,0 ; t = p.v.t
AttributeError: 'vnode' object has no attribute 't'

--~--~-~--~~~---~--~~
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: Removing v.t and cleaning plugins

[Edward K. Ream]

On Oct 6, 5:43 am, "Edward K. Ream"  wrote:
> On Tue, Oct 6, 2009 at 4:20 AM, Ville M. Vainio  wrote:

> > You forget that in one-node-world, there is no "copy of A". There is
> > just one node object, which happens to be in "children" list of the
> > parent twice. So, there is nowhere you could store your uA
> > information, unless you implement your own data structure that stores
> > per-position stuff. Not to say that would be impossible, just not
> > nearly as easy as you think ;-).
>
> I was about to say *exactly* the same thing.

Links do a lot of work in the one-node world :-)  It's good to draw
pictures of the node structure, keeping in mind that no node is ever
duplicated.  Try it.

With that in mind, one can imagine "fat" links.  These would be
adjuncts to the v.children array.  An ambitious plugin could override
(monkey-patch) v._addLink and v._cutLink.  We can't easily store per-
link information in the vnodes to which links point, but we could
store per-link information in links themselves, that is, in the vnodes
containing the links.

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: Removing v.t and cleaning plugins

[Edward K. Ream]

On Tue, Oct 6, 2009 at 4:20 AM, Ville M. Vainio  wrote:

>
> You forget that in one-node-world, there is no "copy of A". There is
> just one node object, which happens to be in "children" list of the
> parent twice. So, there is nowhere you could store your uA
> information, unless you implement your own data structure that stores
> per-position stuff. Not to say that would be impossible, just not
> nearly as easy as you think ;-).
>

I was about to say *exactly* the same thing.

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: OT: The Monty Hall Problem

[Jesse Aldridge]

> To be fair, this is what they teach about statistic problems in high
> school. You should not think of what happened before, and only
> consider the situation *right now*.

Ah, yes, that's a good point.
--~--~-~--~~~---~--~~
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

[Jesse Aldridge]

I see global warming as more of an economic, game-theoretical
problem.  Assume that cutting emissions means increasing costs of
production (in the short term).  That means countries that don't cut
emissions will have an economic advantage over countries that do cut
emissions.  In Game Theory, they'd call this a sub-optimal Nash
equilibrium -- no matter what your "opponent" does, you'll be
comparatively better off by not cutting emissions.  So little gets
done.  Check out this video: http://www.youtube.com/watch?v=fhrnFGP4zks
It had quite an effect on me the first time I watched it.

I think problems like global warming ultimately stem from the fact
that individual entities, when forced into competition, will
inevitably behave selfishly in the absence of any overarching
authority.  I think the best solution to this problem is some sort of
global government with the ability to enforce cooperation.  Of course
there are enormous challenges and grave dangers along this path, but
it does seem to be the logical conclusion.
--~--~-~--~~~---~--~~
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: Removing v.t and cleaning plugins

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 4:02 AM, Terry Brown  wrote:

>> We don't have vnode uA's you used to know anymore. The current vnode
>> uA is the same as the old tnode uA - actually, the vnodes we have are
>> more like the old tnodes.
>>
>> So, you really don't have much choice in the issue ;-).
>
> :-) It really doesn't matter where the uA is, it's the storing of the
> id in the uA which allows the id to be duplicated when the node is
> duplicated, and subsequently allows the "B connects to both the
> original A and the copy of A" behavior.

You forget that in one-node-world, there is no "copy of A". There is
just one node object, which happens to be in "children" list of the
parent twice. So, there is nowhere you could store your uA
information, unless you implement your own data structure that stores
per-position stuff. Not to say that would be impossible, just not
nearly as easy as you think ;-).

-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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

[Ville M. Vainio]

On Tue, Oct 6, 2009 at 11:52 AM, Jesse Aldridge  wrote:

> For me the key insight of the Monty Hall problem is that humans, due
> to having limited working memory, collapse a sequence of events down
> to just the current state.  Our brains are wired to disregard the
> initial door and just see the two doors standing in front of us.

To be fair, this is what they teach about statistic problems in high
school. You should not think of what happened before, and only
consider the situation *right now*.

The key insight for me, again was that Monty Hall cannot open the door
you selected.

-- 
Ville M. Vainio
http://tinyurl.com/vainio

--~--~-~--~~~---~--~~
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

[Jesse Aldridge]

Yes.  I love this problem.  I refused to believe the explanation the
first time I heard it.  I ended up writing a script to prove it's
validity to myself:

import random

def monty_hall():
doors = ['car', 'goat', 'goat']
random.shuffle(doors)

# Assume we guess the first door (doors[0])

# "Open" one of the doors that doesn't have a car
if doors[1] == "goat":
del doors[1]
else:
del doors[2]

# Stay with the same door
#return doors[0] == "car"

# Switch to the other door
return doors[1] == "car"
#

num_wins = 0
num_trials = 1
for i in range(num_trials):
if monty_hall():
num_wins += 1

print "win percentage: ", float(num_wins) * 100 / num_trials

---

For fun, try dropping num_trials to a low number like 10 and then
raise it back up to see the variance drop out.  At 100,000 trials,
it's 66 point something percent *every time*.  Probability is amazing.

For me the key insight of the Monty Hall problem is that humans, due
to having limited working memory, collapse a sequence of events down
to just the current state.  Our brains are wired to disregard the
initial door and just see the two doors standing in front of us.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---