I think there's more to it though. Thomas's PR is stuck in "waiting for
status to be reported" mode, and I found a lot of similar threads. Sounds
like a recurring GitHub <-> Travis integration problem. I've asked for help.
>
> Take a look at https://github.com/leo-editor/leo-editor/branches/active.
>
umm, no.
[Later] after some poking around discovered the [Requests] page.
https://travis-ci.org/github/leo-editor/leo-editor/requests
which says "GitHub payload is missing a merge commit (mergeable_state:
>
> Even better that Zoom is Jitsi[1], which doesn't do extensive data and
> metadata collection just to have a simple conference, is open source,
> gratis, multiplatform and just requires a link to start your talk.
>
> [1] meet.jit.si/
>
Thanks Offray. This is useful to me in another context
According to your linked page, deleteLater() can lead to problems that give
the very exception we are seeing. The places it shows up are in code that I
inherited from VR/VR2, and just left in because I didn't really know why we
needed it but supposed that someone before me had.
Most if not all
Edward, if you retrieved this file before about 9:30 PM Eastern, please get
it again. I found a bug where the line h = c.hash() in store_layout had
been removed during my merge. It needs to be there.
On Wednesday, April 1, 2020 at 8:00:27 PM UTC-4, Thomas Passin wrote:
>
> I merged the files.
Thanks, that looks like it could be relevant.
On Wednesday, April 1, 2020 at 6:37:34 PM UTC-4, Edward K. Ream wrote:
>
> Here's the link. I found it while cleaning out my bookmarks :-)
>
> http://enki-editor.org/2014/08/23/Pyqt_mem_mgmt.html
>
> Maybe it will help find the memory problems in
I merged the files. For some reason I couldn't push my changes upstream
to the "fix" branch. Although I was logged in to Github, it said it
couldn't authenticate. So I pushed the changes to the devel branch of my
own fork and sent a PR.
On Wednesday, April 1, 2020 at 6:31:35 PM UTC-4,
It looks pretty cool in fact :-).
Thanks,
On 1/04/20 5:15 p. m., Thomas Passin wrote:
> Hi, I see you found us on another thread. Here is a longer example.
> It's a real one that I did for myself some time ago. It is too long
> to show in a single image, so I exported it to the browser and
Here's the link. I found it while cleaning out my bookmarks :-)
http://enki-editor.org/2014/08/23/Pyqt_mem_mgmt.html
Maybe it will help find the memory problems in vr3.py.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe
Take a look at https://github.com/leo-editor/leo-editor/branches/active.
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
Here is the checkin log for rev 69288fd in the fix branch:
QQQ
Manually remove the git merge conflict markers as follows:
In *all* cases, removed everything between and ===, using the second
version.
Fixed one unmatched docstring delim.
Pylint reports that "h" is undefined in
Hi,
Is good to see the path ahead and the upcoming focus.
On 23/03/20 8:11 a. m., Edward K. Ream wrote:
> 3. Imo, live coding is a dead end. The cool demos are toys which can
> not be scaled up:
>
> A: *Graphics*: Any graphics-based demo could be more easily recreated
> with a slider that
This looks really cool! I was asking for a inspiring screenshot in other
thread, unknowing that I would find them here.
Thanks a lot,
Offray
On 30/03/20 7:34 a. m., Thomas Passin wrote:
> And it turns out that it's just as easy to work with Seaborn,
>
> On Monday, March 30, 2020 at 6:48:29 AM
Hi,
Nice to see this theme become alive again, as Jupyter interactive alike
experiences combining with Leo outiling alike experience have been
discussed before. We could have interactive emergent computing. I have
been a log advocate of them and it was the reason I prototyped
Grafoscopio[1],
Hi,
Even better that Zoom is Jitsi[1], which doesn't do extensive data and
metadata collection just to have a simple conference, is open source,
gratis, multiplatform and just requires a link to start your talk.
[1] meet.jit.si/
Leo is awesome for a lot of other thinks.
Cheers,
Offray
On
Right, and Edward has already asked me to clear this up.
On Wednesday, April 1, 2020 at 11:38:11 AM UTC-4, vitalije wrote:
>
> Title tells everything. While executing unit tests, two are failing: check
> syntax of all files and pluginTestCase for viewrender3.
>
> Vitalije
>
--
You received
Title tells everything. While executing unit tests, two are failing: check
syntax of all files and pluginTestCase for viewrender3.
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
On Wed, Apr 1, 2020 at 9:45 AM Thomas Passin wrote:
> It's really a comprehension vs brevity thing, and a matter of personal
> style.
>
No. It's a pylint bug. Enable the two checks and look at the warnings.
Edward
--
You received this message because you are subscribed to the Google Groups
>
> ...I can certainly imagine using Leo to grab and re-arrange snippets from
>> lectures and so on.
>>
>
> Excellent ideas. Please create an enhancement request.
>
Done! https://github.com/leo-editor/leo-editor/issues/1556
--
You received this message because you are subscribed to the Google
It's really a comprehension vs brevity thing, and a matter of personal
style. Removing the else gives shorter code, which is *usually* more
clear. But without the *else*, you have to *infer* its virtual presence,
and that interferes with comprehension. I'm not consistent about this,
myself.
On Wed, Apr 1, 2020 at 8:52 AM vitalije wrote:
> I doubt that. A few days ago I've run pylint and it reported some
> complains about non necessary else after break, or after return. My first
> reaction was just like yours, but then I looked more closely and those
> complains were correct.
>
>
I doubt that. A few days ago I've run pylint and it reported some complains
about non necessary else after break, or after return. My first reaction
was just like yours, but then I looked more closely and those complains
were correct.
while True:
... # some code here
if condition:
leo/test/pylint-leo-rc-ref.txt now disables the following two new tests:
no-elif-break
no-else-break
Imo, these are just plain wrong. Following the pylint advice would change
the meaning of the program. These look like serious pylint bugs.
Edward
--
You received this message because
On Wednesday, April 1, 2020 at 8:05:28 AM UTC-5, Thomas Passin wrote:
>
> OK, I'll take a run at it. It can be difficult when you have a lot of
> changes that are mostly whitespace and style.
>
Just make sure there are no merge markers like <<, == and >>.
Somebody can beautify the
OK, I'll take a run at it. It can be difficult when you have a lot of
changes that are mostly whitespace and style. I messed one up that way
recently, too.
On Wednesday, April 1, 2020 at 6:34:20 AM UTC-4, Edward K. Ream wrote:
>
> Somehow it contains many conflict markers from a git merge.
>
It's always annoying when there are a lot of whitespace and style changes.
I'll see about it.
(For the benefit of anyone else who is wondering what this is about, this
commit tried to remove a lot of complaints from pylint about whitespace
and other sylistic nits that had build up over the
On Wednesday, April 1, 2020 at 5:34:20 AM UTC-5, Edward K. Ream wrote:
>
> Somehow it contains many conflict markers from a git merge.
>
It should be easy for you. From a branch that contains your desired vr3.py:
- git merge devel (Will likely create a merge conflict).
- git checkout --ours
Somehow it contains many conflict markers from a git merge.
Not sure how this happened. Presumably the PR went awry.
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
On Tue, Mar 31, 2020 at 1:03 PM Thomas Passin wrote:
I don't see the point of working with Jupyter/ipython in Leo unless we can
> actually make use of Leo's strengths.
>
I agree.
Last year we reached consensus that embedding Leo into emacs or vim is a
bad idea. Similar logic applies here.
On Tue, Mar 31, 2020 at 10:44 AM 'tfer' via leo-editor <
leo-editor@googlegroups.com> wrote:
> There is another option we could consider, rather than full juypter stuff,
> just add an Ipython console tab to the log pane. Though not as sexy as
> Juypter, it has most of its guts, is embed-able,
On Tue, Mar 31, 2020 at 7:35 PM Matt Wilkie wrote:
> Imagine Leo turned to this task, headlines would label snippets of audio
>> captured in their body
>
>
> I started a course today called Introduction to Mathematical Thinking
>
On Tue, Mar 31, 2020 at 12:52 PM 'tfer' via leo-editor <
leo-editor@googlegroups.com> wrote:
> Just like the outliner "More" provided inspiration for Leo, Leo provides
> me with inspiration for various thinking, capturing, organizing tools.
> I've mentioned my idea for a presentation plugin for
On Tue, Mar 31, 2020 at 8:00 PM Thomas Passin wrote:
>
> On Tuesday, March 31, 2020 at 6:42:01 PM UTC-4, Edward K. Ream wrote:
>
>> As you say, at present the ipynb.do_cell method (in importers/ipynb.py)
>> doesn't save much. It should be easy to save more, if you would like that.
>>
>
> Easy,
33 matches
Mail list logo
