Re: Updates to LeoVue

[Chris George]

I guess this would be a question for Joe.

I have gotten Leo Vue to "work" under heroku. The application serves a page 
that is identical to a page served by the local application. But it won't 
display the page.

https://agile-fortress-75552.herokuapp.com/

As you know a lot more about node.js etc. than me I was hoping you might 
have an idea.

A big stumbling block to get this working was the lack of a start script in 
packages.json or a server.js file. I am slowly working towards it working 
as I keep googling and tinkering but I have been stuck here for a while.

Chris

On Sunday, October 14, 2018 at 4:34:17 PM UTC-7, Joe Orr wrote:
>
>
>
>>- clicking on "Feature Introduction" and "Chunking" items in ToC 
>>starts a download of the .md file for that node. The other items seem to 
>> be 
>>okay
>>
>> That's weird, does it on FF in Mac too. But the page does display after 
> you get rid of the download dialog. I'll look into it. For now I'm really 
> only supporting Chrome though. 
>
>
>>- there's no vertical scroll bar in the rendered pane, so without a 
>>mouse wheel I can't see the whole page. PageDn doesn't work at first 
>>because keyboard focus is in the pane that was clicked (ToC).
>>
>> I removed the scrollbars (but not scrolling) scrolling because they 
> looked crappy in Windows. I could put them back as an option... Arrow keys 
> should work, but with mouse wheel or track pad it works better.
>
>>
>>- wow. just wow.
>>
>> Glad you like it! If you have any good sample files, you can try them 
> out. All you need to do is put them online with an index file that points 
> to the CDN.
>
>>
>>- Install too complicated: yeah. I'm going to keep chipping away at 
>>that.
>>- Install and using LeoVue requires a webserver - maybe there's 
>>something in Tiddly Desktop that can be adapted (
>>https://tiddlywiki.com/static/TiddlyDesktop.html)
>>
>> LeoVue depends on Vue, which requires files to be served not from 
> filesystem.
>
> Joe
>  
>

-- 
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 as a web app.

[Terry Brown]

Here's a Dockerfile that let's Leo (The Python3 / PyQt4 version) run in
a web browser.  This is cheating, and I think I demoed this years ago
without Docker, but it might be useful for someone.

Would be interested to hear if anyone tries it / runs in to issues.
Easier to understand if you're familiar with Docker, but I don't think
it needs any special Docker knowledge to get it running.

Almost forgot the link :)

https://github.com/tbnorth/leo-docker

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: About separate processes and threads

[vitalije]

>
> I am enjoying this.  The real reason I wrote the original post was to get 
> some help in understanding processes, thread and servers.
>
> I'll interrupt my study to ask this rhetorical question. Why do I think this 
> hilarious cartoon  applies to Leo's 
> documentation? 
>
> Ha, ha, ha, that cartoon is really great. 

I don't have much time to write right now, but here is a list of (IMHO) 
essential facts one should keep in mind when dealing with concurrency:

   - in terms of required computer resources most expensive are processes, 
   then threads, and then micro-threads (where by micro-threads I understand 
   both doing several tasks simultaneously on different CPU cores and some 
   clever concepts implemented in frameworks like Actors in Akka, or something 
   similar in Twisted). It is not so cheap to spawn 10 processes, or 100 
   threads. But you can easily run 1 Actors on modest hardware. 
   - One should not communicate by sharing state between concurrent 
   threads/processes. Instead it is much better to share the state by 
   communicating (like you used queue in Leo debugger)
   - Pure functions (functions that do not produce any side effect) are 
   best friends when dealing with concurrency. These functions return the same 
   result for the same input arguments no matter when and in which order they 
   are called. That helps by letting programmer free to call them in any order 
   and from any thread, or to call them even more than once if necessary. For 
   example in Clojure and ClojureScript there is a kind of variable called 
   atom. Atoms contain some data that can be safely read at any time from any 
   thread. If one want to change the data contained in atom, it isn't possible 
   to write new data directly to atom. Instead one should provide a pure 
   function and perhaps some additional arguments to it. This function will be 
   called with the current data from atom and the rest arguments and its 
   result will be written in atom. If two or more threads try to change atom 
   at the same time, then right before writing result to atom,  atom will 
   check if it currently holds the same data that was passed as an argument to 
   pure function. In case it was changed sometimes between the call and the 
   returning result (by some other thread), then its result is dropped and 
   function is called again using fresh data. This is done automatically by 
   system, so programmer doesn't have to think about it all the time. The only 
   thing programmer must obey is that function must be pure and it may be 
   called more than once.
   - server usually try to serve more than one client simultaneously, it 
   can't be sure at what time client will send request. Clients often don't 
   know about each other. So servers are usually implemented using some kind 
   of concurrency. Sometimes they use several processes, sometime they use 
   several threads, and sometimes they use both several processes and several 
   threads. Most common thing is to dedicate one thread for each incoming 
   request. However that limits how many simultaneous requests can server 
   accept. If you wish to allow more requests then it is usually achieved by 
   using small number of threads from the pool of threads and using some kind 
   of micro-threads like Promises, Actors, ... 
   - Server and client may be on different machines so they usually can't 
   share state. To have same data on the server and in the client they need to 
   encode data in some format acceptable for both parties and to agree on some 
   kind of protocol how and in which order will they exchange encoded 
   messages. Upon receiving encoded messages both client and server decode 
   them and use data to adjust their own internal state to match the state of 
   the other side (server/client, client/server). Even if both server and 
   client are on the same machine, they may be in different processes.
   - Its always easier if you have same language on both sides server and 
   client, but this is not required and very often is not the case. OTOH it 
   allows you to completely replace one of them with totally different 
   implementation and only to keep same protocol and same data encoding and 
   other side won't notice the difference. For example if we have Leo server 
   implemented in Python, and client implemented in JavaScript, then it would 
   be possible (not necessarily easy) to re-implement Leo server in some other 
   language (say Clojure for example), and its JavaScript won't know. Or it 
   would be possible to implement client using python and some other gui 
   library, and server will work without change. 
   - Go language has very nice way to make spawning new tasks to several 
   CPU cores on micro level and re-synchronizing them very cheaply and very 
   easily. Rust prevents sharing mutable state, code won't compile if you try 
   to share mutable variable. 

Re: Unit Testing Nodes

[Chris George]

> I'm using 5.7 - perhaps I'll upgrade. I assume myLeoSettings file will be 
> picked up?
>

Just as an aside, I have been running Leo via a git pull every time for 
three or four years now and have had to step back to an older commit only 
once or twice.

Chris

-- 
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: About separate processes and threads

['tfer' via leo-editor]

Their was a book on Ada I bought a few decades ago that dealt with locks 
and other interprocess stuff.  The author explained things by diagrams that 
had button, (push and pull), hatches and other things that illustrated how 
the various concepts worked in a graphical mechanistic fashion, (apparently 
Ada has a lot of this stuff).

Not really what I was suppose to be learning at the time, but it was 
interesting so I thought I'd get back to it someday, and it matched the way 
I think about those things.  Lost the book in a move, anybody here know the 
title/author?

Tom



On Tuesday, October 16, 2018 at 9:55:35 AM UTC-4, Terry Brown wrote:
>
> On Tue, 16 Oct 2018 04:36:31 -0700 (PDT) 
> "Edward K. Ream" > wrote: 
>
> > The original Dreaming Big Dreams thread suggested reorganizing Leo 
> > into more separable pieces, perhaps using a client/server 
> > architecture or other forms of interprocess communication (IPC). 
>
> Here's a presentation I just gave: 
> https://tbnorth.github.io/multiproc/ 
>
> So processes *can* share memory, although the sharing is managed with 
> IPC calls.  My presentation's for distributed processing of data in 
> NumPy, CPU intensive, not necessarily relevant to whatever it is you're 
> considering for Leo. 
>
> Cheers -Terry 
>
> > Here I'd like to present what little I know about IPC, servers and 
> > threads.  The purpose is continue the conversation, and to expose my 
> > own misconceptions.  Please comment. 
> > 
> > *Separate processes share no data* 
> > 
> > Some kind of IPC is required. There seems to be no end of such 
> > mechanisms: 
> > 
> > - pyzo uses yoton . 
> > - neovim uses msgpack plus 
> > vim-related wrappers. 
> > - LeoVue uses node.js client-server architecture. 
> > - Jupyter uses another client-server 
> > architecture. 
> > - All other client/server architectures have/are their own forms of 
> > IPC. 
> > 
> > I have no idea what would be best for a more "distributed" version of 
> > Leo. Does anyone have any organizing principles or ideas they would 
> > like to share? 
> > 
> > *Separate threads share (almost?) all data* 
> > 
> > Debuggers need access to the program under test, so must run in a 
> > separate *thread* rather than a separate process.  Otoh, both the 
> > debugger and the program under test could run in a separate process 
> > from the IDE.  In that case, the processes would have to communicate 
> > via IPC. 
> > 
> > The shared data between threads causes well-known problems.  Race 
> > conditions can result.  Python's queue.Queue is one (low performance) 
> > way of avoiding some, but not all, of the problems. 
> > 
> > Leo's new debugger contains a listener, in the main thread, that 
> > receives requests from the debugger thread.  The debugger thread is 
> > driven by commands from the main thread.  None of the code could be 
> > called elegant. It has a chance of working because *only *the 
> > g.app.xdb ivar is set by both threads. It must be set/cleared very 
> > carefully. As I write this, I suspect that the present code, while 
> > not *necessarily* wrong, would likely benefit from a lock 
> > on 
> > this ivar. 
> > 
> > *Summary* 
> > 
> > There seems to be too many choices for IPC.  Your comments, please. 
> > Please correct me if I have said something dubious. 
> > 
> > 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: About separate processes and threads

[Edward K. Ream]

On Tue, Oct 16, 2018 at 8:55 AM Terry Brown  wrote:

> On Tue, 16 Oct 2018 04:36:31 -0700 (PDT)
> "Edward K. Ream"  wrote:
>
> > The original Dreaming Big Dreams thread suggested reorganizing Leo
> > into more separable pieces, perhaps using a client/server
> > architecture or other forms of interprocess communication (IPC).
>
> Here's a presentation I just gave:
> https://tbnorth.github.io/multiproc/


I am enjoying this.  The real reason I wrote the original post was to get
some help in understanding processes, thread and servers.

I'll interrupt my study to ask this rhetorical question. Why do I think this
hilarious cartoon  applies to Leo's
documentation?

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: Unit Testing Nodes

[anlifer]

I'm using 5.7 - perhaps I'll upgrade. I assume myLeoSettings file will be 
picked up?

(At home right now and the issue is on my work machine - will send you the 
info when I go to work).

Thanks Vitalije for checking if the test works. At least now I know my 
approach will work.

On Tuesday, October 16, 2018 at 3:30:22 AM UTC-7, Edward K. Ream wrote:
>
>
>
> On Tue, Oct 16, 2018 at 4:55 AM vitalije > 
> wrote:
>
>> How very strange. 
>>
>
> Yes, it's a mystery.  anlifer, what appears in your log window when you 
> start Leo?  This may be an installation-related problem.
>
>> I recall that Edward recently has added some code to make output from the 
>> console to appear in the Log pane. 
>>
>
> I don't recall doing that :-)  That code is certainly not active in 
> general.
>
> 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: About separate processes and threads

[Terry Brown]

On Tue, 16 Oct 2018 04:36:31 -0700 (PDT)
"Edward K. Ream"  wrote:

> The original Dreaming Big Dreams thread suggested reorganizing Leo
> into more separable pieces, perhaps using a client/server
> architecture or other forms of interprocess communication (IPC).

Here's a presentation I just gave:
https://tbnorth.github.io/multiproc/

So processes *can* share memory, although the sharing is managed with
IPC calls.  My presentation's for distributed processing of data in
NumPy, CPU intensive, not necessarily relevant to whatever it is you're
considering for Leo.

Cheers -Terry

> Here I'd like to present what little I know about IPC, servers and 
> threads.  The purpose is continue the conversation, and to expose my
> own misconceptions.  Please comment.
> 
> *Separate processes share no data*
> 
> Some kind of IPC is required. There seems to be no end of such
> mechanisms:
> 
> - pyzo uses yoton .
> - neovim uses msgpack plus
> vim-related wrappers.
> - LeoVue uses node.js client-server architecture.
> - Jupyter uses another client-server
> architecture.
> - All other client/server architectures have/are their own forms of
> IPC.
> 
> I have no idea what would be best for a more "distributed" version of
> Leo. Does anyone have any organizing principles or ideas they would
> like to share?
> 
> *Separate threads share (almost?) all data*
> 
> Debuggers need access to the program under test, so must run in a
> separate *thread* rather than a separate process.  Otoh, both the
> debugger and the program under test could run in a separate process
> from the IDE.  In that case, the processes would have to communicate
> via IPC.
> 
> The shared data between threads causes well-known problems.  Race 
> conditions can result.  Python's queue.Queue is one (low performance)
> way of avoiding some, but not all, of the problems.
> 
> Leo's new debugger contains a listener, in the main thread, that
> receives requests from the debugger thread.  The debugger thread is
> driven by commands from the main thread.  None of the code could be
> called elegant. It has a chance of working because *only *the
> g.app.xdb ivar is set by both threads. It must be set/cleared very
> carefully. As I write this, I suspect that the present code, while
> not *necessarily* wrong, would likely benefit from a lock
> on
> this ivar.
> 
> *Summary*
> 
> There seems to be too many choices for IPC.  Your comments, please.
> Please correct me if I have said something dubious.
> 
> 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: Docker for LeoVue etc.

[Terry Brown]

On Tue, 16 Oct 2018 05:46:00 -0500
"Edward K. Ream"  wrote:

> On Mon, Oct 15, 2018 at 3:23 PM Terry Brown 
> wrote:
> 
> > Responding to Chris's comments re cPanel / LeoVue etc., just a PSA,
> > Docker is easier and more useful than you think ;-)
> >
> 
> Thanks for this.  Despite the work I did on #735 (how to install and
> run LeoVue)  I
> don't remember much about node.js.
> 
> It would be best to make a Docker image for Leo, but running GUI
> apps. is

I'm not sure why I wrote "best", I probably meant to say "easy".

> > really only straightforward in unix/X11, much more trouble in
> > Windows.
> 
> Really?  Iirc, LeoVue runs on Windows.  What are the specific
> problems?

Sloppy writing on my part.  I was talking about Leo, not LeoVue.
container / host network connections are easy in Docker, and because
X11 runs over a network (kind of) it's easy to open GUI apps. from a
container on the host desktop.

Also Docker's just less convenient on Windows, passing paths, finding a
decent terminal, that kind of thing.

I'm wondering though if I can add Leo to a container running Apache
Guacamole, making Leo a containerized web app., probably more of a
novelty than anything.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

About separate processes and threads

[Edward K. Ream]

The original Dreaming Big Dreams thread suggested reorganizing Leo into 
more separable pieces, perhaps using a client/server architecture or other 
forms of interprocess communication (IPC).

Here I'd like to present what little I know about IPC, servers and 
threads.  The purpose is continue the conversation, and to expose my own 
misconceptions.  Please comment.


*Separate processes share no data*

Some kind of IPC is required. There seems to be no end of such mechanisms:

- pyzo uses yoton .
- neovim uses msgpack plus vim-related 
wrappers.
- LeoVue uses node.js client-server architecture.
- Jupyter uses another client-server architecture.
- All other client/server architectures have/are their own forms of IPC.

I have no idea what would be best for a more "distributed" version of Leo.  
Does anyone have any organizing principles or ideas they would like to 
share?

*Separate threads share (almost?) all data*

Debuggers need access to the program under test, so must run in a separate 
*thread* rather than a separate process.  Otoh, both the debugger and the 
program under test could run in a separate process from the IDE.  In that 
case, the processes would have to communicate via IPC.

The shared data between threads causes well-known problems.  Race 
conditions can result.  Python's queue.Queue is one (low performance) way 
of avoiding some, but not all, of the problems.

Leo's new debugger contains a listener, in the main thread, that receives 
requests from the debugger thread.  The debugger thread is driven by 
commands from the main thread.  None of the code could be called elegant.  
It has a chance of working because *only *the g.app.xdb ivar is set by both 
threads. It must be set/cleared very carefully. As I write this, I suspect 
that the present code, while not *necessarily* wrong, would likely benefit 
from a lock on 
this ivar.

*Summary*

There seems to be too many choices for IPC.  Your comments, please.  Please 
correct me if I have said something dubious.

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: Unit Testing Nodes

[vitalije]

On Tuesday, October 16, 2018 at 12:30:22 PM UTC+2, Edward K. Ream wrote:
>
>
>
> On Tue, Oct 16, 2018 at 4:55 AM vitalije > 
> wrote:
>
>> How very strange. 
>>
>
> Yes, it's a mystery.  anlifer, what appears in your log window when you 
> start Leo?  This may be an installation-related problem.
>
>> I recall that Edward recently has added some code to make output from the 
>> console to appear in the Log pane. 
>>
>
> I don't recall doing that :-)  That code is certainly not active in 
> general.
>
> I was referring to this thread 


> Soon, all xdb/pdb output will be sent to an output area in the debug 
> pane.  Once that happens, you will be able to run the debugger without 
> running Leo from a console window.


Done at rev b6cca36b3 in the "pdb" branch.


But now I see it is just about debugger output not all output.

Vitalije

>

-- 
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 options if file on disk gets updated?

[Edward K. Ream]

On Mon, Oct 1, 2018 at 9:37 AM jkn  wrote:

My apologies for the delay in responding.

4) Separately,
> touch mytest.leo
>
> 5) Change back to Leo.
> nothing shown(!)
>

Leo doesn't continually check to see whether a .leo file has been changed.
The workaround is not to do that. You could file an enhancement request,
but I would reject it ;-)

Leo *does* warn you if you try to open two separate of the same .leo file.
If you ignore the warning then you, and only you, are responsible for what
happens.

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: Docker for LeoVue etc.

[Edward K. Ream]

On Mon, Oct 15, 2018 at 3:23 PM Terry Brown  wrote:

> Responding to Chris's comments re cPanel / LeoVue etc., just a PSA,
> Docker is easier and more useful than you think ;-)
>

Thanks for this.  Despite the work I did on #735 (how to install and run
LeoVue)  I don't
remember much about node.js.

It would be best to make a Docker image for Leo, but running GUI apps. is
> really only straightforward in unix/X11, much more trouble in
> Windows.
>

Really?  Iirc, LeoVue runs on Windows.  What are the specific problems?

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: Unit Testing Nodes

[Edward K. Ream]

On Tue, Oct 16, 2018 at 4:55 AM vitalije  wrote:

> How very strange.
>

Yes, it's a mystery.  anlifer, what appears in your log window when you
start Leo?  This may be an installation-related problem.

> I recall that Edward recently has added some code to make output from the
> console to appear in the Log pane.
>

I don't recall doing that :-)  That code is certainly not active in general.

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: Unit Testing Nodes

[vitalije]

Running all unit tests locally on the above Leo file(see previous message), 
on my machine produces following output:
F
==
FAIL: runTest (leo.core.leoTest.GeneralTestCase)
@test factorial

--
Traceback (most recent call last):
  File 
"/media/vitalije/home11/vitalije/programi/leo-editor/trunk-git/leo/core/leoTest.py",
 
line 196, in runTest
exec(compile(script, scriptFile, 'exec'), d)
  File "/home/vitalije/.leo/scriptFile.py", line 14, in 
self.assertEqual(factorial(5), 121)
AssertionError: 120 != 121

--
Ran 1 test in 0.007s

FAILED (failures=1)

when all assertions are uncommented, and when I comment wrong ones, the 
output is as follows:
.
--
Ran 1 test in 0.003s

OK

Vitalije


-- 
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: Unit Testing Nodes

[vitalije]

How very strange. I recall that Edward recently has added some code to make 
output from the console to appear in the Log pane. I don't know if that has 
something to do with your issue.

...

I have just updated my Leo to the latest version and it works as expected.
Attached to this message is Leo file with lib_factorial.py module example 
and some tests.

Please try this file and if it doesn't work for you, file an issue 
attaching some info about your installation and the Leo file that 
reproduces error.

Vitalije

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


test-factorial.leo
Description: Binary data