Re: Leo Node Move Error

2020-09-03 Thread k-hen
As a follow up:

I figured out the grey box, it's just the unsaved/dirty nodes, so it's not 
that.

Regarding the file size for the DB, I assume this is because the version I 
sent you doesn't have any content. 
So I think this is a legitimate size for the doc, but it probably needs to 
be vacuumed/cleaned up to reduce it back.
https://sqlite.org/lang_vacuum.html

The Leo version is 16MB which is a bit smaller but not quite as dramatic.

Kevin


On Thursday, September 3, 2020 at 4:54:51 PM UTC-4 k-hen wrote:

> Hmm ... well at least it seems reproduceable.  I did run across at least 
> one set of nodse after filing this that were behaving as clones but not 
> flagged as clones, and it's probably the same ones. Not sure if it matters 
> but the box icon was grey instead of black, I thought that was unusual as 
> well, but not sure what that indicates 
>
> I'm using the sqlite version because I assumed it could offer better 
> performance for very large outlines (e.g. potentially 50K+ nodes). 
> Also, because I like SQL and can connect to it with DBVisualizer/alternate 
> tools and write queries (read only ones for now) and/or use ETL workflows 
> with it. 
>
> One thing that _might_ be happening is that I have a 'code' top-level tree 
> that syncs with other developers using Git.
> It's using @file's and so there are now comments scattered throughout the 
> code base. 
> Then subnodes within this tree are cloned into @nosent  'documentation' 
> trees which contains other notes/commentary outputs.
> This is mostly doing what I want, but importing the nodes sometimes 
> results in errors/broken outlines/etc, which I have to repair.
> I close Leo, do the pull, then open Leo again and let it import. 
> Then I fix any issues (mostly nodes losing their parents and appearing at 
> the root).
> I also keep an eye on Git to ensure that I'm not making any unwanted 
> changes after doing this and can revert if necessary.
> It's possible that other developers are copying/moving blocks of code that 
> include the Leo comments (I've asked them not to do this).
> We're making a lot of structural changes now too as we're refactoring so 
> this should settle down later.
>
> For now, perhaps I can save as .leo and then save back as .leo.db to 
> potentially repair any issues.
>
> Is it perhaps possible to detect and/or repair these broken clones using a 
> script?
>
> Thanks so much for all your help.
>
> Kevin
>
>
>
>
> On Thu, 2020-09-03 at 11:52 -0700, Edward K. Ream wrote:
>
> On Wednesday, September 2, 2020 at 3:24:45 PM UTC-5, k-hen wrote:
>
> Ok, got it, will need a bit of time, but will get back to you soon.
>
>
> Something strange is going on.  Here is what I think I know:
>
> The unpacked original file is leo_error_test_01 - cleared - Copy.db. It is 
> about 28.1 MB in size.
>
> Opening the file with Leo does work, but the two "node 5660" are not *shown 
> as *clones of each other. Yet they have the same gnx and id(v) is the 
> same for each. Imo, this is likely the ultimate cause of the crash.
>
> Saving this .db as a .leo file creates a valid .leo file in which the two 
> "node 5660" are indeed true clones. The bug never appears in the .leo file.
>
> Saving the .leo file as a .leo.db file creates a much smaller file, about 
> 1.2 MB. However, in all other respects it appears to be identical to the 
> original .db file. The two "node 5660" are not *shown as *clones of each 
> other, and the bug does manifest itself.
>
> My *tentative* conclusion is that there may be a bug in 
> fc.retrieveVnodesFromDb. However, there are no special cases in this code, 
> so what the bug could possibly be is a big mystery. Iirc, Vitalije wrote 
> this code. Any insights would be appreciated.
>
> Finally, I note that the .leo files are smaller than the corresponding .db 
> files, so one workaround would be to use the .leo files instead.  
> Presumably, however, there are reasons for using the .db files.
>
> Edward
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "leo-editor" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/leo-editor/sANduRjZDVI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> leo-editor+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/leo-editor/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.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/8a91e782-93a9-45d1-b18b-33abe83239a5n%40googlegroups.com.


Re: Leo Node Move Error

2020-09-03 Thread perceptiblelogic
Hmm ... well at least it seems reproduceable.  I did run across at
least one set of nodse after filing this that were behaving as clones
but not flagged as clones, and it's probably the same ones. Not sure if
it matters but the box icon was grey instead of black, I thought that
was unusual as well, but not sure what that indicates 
I'm using the sqlite version because I assumed it could offer better
performance for very large outlines (e.g. potentially 50K+
nodes). Also, because I like SQL and can connect to it with
DBVisualizer/alternate tools and write queries (read only ones for now)
and/or use ETL workflows with it. 
One thing that _might_ be happening is that I have a 'code' top-level
tree that syncs with other developers using Git.It's using @file's and
so there are now comments scattered throughout the code base. Then
subnodes within this tree are cloned into @nosent  'documentation'
trees which contains other notes/commentary outputs.This is mostly
doing what I want, but importing the nodes sometimes results in
errors/broken outlines/etc, which I have to repair.I close Leo, do the
pull, then open Leo again and let it import. Then I fix any issues
(mostly nodes losing their parents and appearing at the root).I also
keep an eye on Git to ensure that I'm not making any unwanted changes
after doing this and can revert if necessary.It's possible that other
developers are copying/moving blocks of code that include the Leo
comments (I've asked them not to do this).We're making a lot of
structural changes now too as we're refactoring so this should settle
down later.
For now, perhaps I can save as .leo and then save back as .leo.db to
potentially repair any issues.
Is it perhaps possible to detect and/or repair these broken clones
using a script?
Thanks so much for all your help.
Kevin



On Thu, 2020-09-03 at 11:52 -0700, Edward K. Ream wrote:
> On Wednesday, September 2, 2020 at 3:24:45 PM UTC-5, k-hen wrote:
> 
> > Ok, got it, will need a bit of time, but will get back to you soon.
> 
> Something strange is going on.  Here is what I think I know:
> 
> The unpacked original file is leo_error_test_01 - cleared - Copy.db.
> It is about 28.1 MB in size.
> 
> Opening the file with Leo does work, but the two "node 5660" are not
> shown as clones of each other. Yet they have the same gnx and id(v)
> is the same for each. Imo, this is likely the ultimate cause of the
> crash.
> 
> Saving this .db as a .leo file creates a valid .leo file in which the
> two "node 5660" are indeed true clones. The bug never appears in the
> .leo file.
> 
> Saving the .leo file as a .leo.db file creates a much smaller file,
> about 1.2 MB. However, in all other respects it appears to be
> identical to the original .db file. The two "node 5660" are not shown
> as clones of each other, and the bug does manifest itself.
> 
> My tentative conclusion is that there may be a bug in
> fc.retrieveVnodesFromDb. However, there are no special cases in this
> code, so what the bug could possibly be is a big mystery. Iirc,
> Vitalije wrote this code. Any insights would be appreciated.
> 
> Finally, I note that the .leo files are smaller than the
> corresponding .db files, so one workaround would be to use the .leo
> files instead.  Presumably, however, there are reasons for using the
> .db files.
> 
> Edward
> 
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to a topic in
> the Google Groups "leo-editor" group.
> 
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/leo-editor/sANduRjZDVI/unsubscribe.
> 
> To unsubscribe from this group and all its topics, 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/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.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/2c4906311bc48e909c60b3d7bb4fc0446b87bb78.camel%40gmail.com.


Re: New Version of Viewrendered3 Updates Asciidoc Handling.

2020-09-03 Thread Thomas Passin
The pylint message about an undefined variable was mistaken because that 
variable can only be used after the condition has been met.  Tested to 
confirm.

I have created a PR for this updated version.

Unless someone reports anything seriously wrong or trivial to fix in the 
next few days, I will release it as a non-beta release.  In the meantime, 
this version is V3.0b15.

On Thursday, September 3, 2020 at 11:08:04 AM UTC-4, Thomas Passin wrote:
>
>
> On Thursday, September 3, 2020 at 10:59:41 AM UTC-4, Edward K. Ream wrote:
>>
>>
>>> Actually, I knew about it.  I'm not sure if it's real or something that 
>>> pylint doesn't understand (I think it's this). 
>>>
>>
>> If it's a pylint mistake, please disable the message.
>>
>
>  I will once I'm sure.  I purposely have not disabled the message until 
> I'm convinced it's spurious.
>
>>

-- 
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/d7c1cd03-a40a-4ef1-bfb7-4731bfd9100eo%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread Edward K. Ream
On Thursday, September 3, 2020 at 11:00:38 AM UTC-5, vitalije wrote:

> By definition wasm code can't do anything that ordinary javascript in the 
browser can't do...

> Concerning user tracking, all major social networks use it all the time, 
regardless of wasm...

> Comparison with the Flash technology is a bit stretched (IMHO).

Thanks for these comments. As I said earlier, I am not qualified to comment 
in detail about security issues. However, I find it hard to believe that 
wasm code is part of some nefarious plot :-)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3fe18614-0239-4f20-ae19-dd053600bd10o%40googlegroups.com.


Re: Leo Node Move Error

2020-09-03 Thread Edward K. Ream
On Wednesday, September 2, 2020 at 3:24:45 PM UTC-5, k-hen wrote:

Ok, got it, will need a bit of time, but will get back to you soon.
>

Something strange is going on.  Here is what I think I know:

The unpacked original file is leo_error_test_01 - cleared - Copy.db. It is 
about 28.1 MB in size.

Opening the file with Leo does work, but the two "node 5660" are not *shown 
as *clones of each other. Yet they have the same gnx and id(v) is the same 
for each. Imo, this is likely the ultimate cause of the crash.

Saving this .db as a .leo file creates a valid .leo file in which the two 
"node 5660" are indeed true clones. The bug never appears in the .leo file.

Saving the .leo file as a .leo.db file creates a much smaller file, about 
1.2 MB. However, in all other respects it appears to be identical to the 
original .db file. The two "node 5660" are not *shown as *clones of each 
other, and the bug does manifest itself.

My *tentative* conclusion is that there may be a bug in 
fc.retrieveVnodesFromDb. However, there are no special cases in this code, 
so what the bug could possibly be is a big mystery. Iirc, Vitalije wrote 
this code. Any insights would be appreciated.

Finally, I note that the .leo files are smaller than the corresponding .db 
files, so one workaround would be to use the .leo files instead.  
Presumably, however, there are reasons for using the .db files.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread vitalije

>
> I forgot to include the potential for malware.  Some links:
>
 
According to the research mentioned in your third link that claims half of 
the web sites using wasm use it maliciously, the malicious usage consist in 
obfuscating and mining.

According to the first link, from the figure 4 it is clear that malicious 
site will use users CPU to mine cryptocurrency even if the web browser 
doesn't support wasm. So it is not only wasm's fault.





By definition wasm code can't do anything that ordinary javascript in the 
browser can't do. If obfuscation is malicious then I don't know any serious 
web site today that isn't malicious, because every web page uses minimized 
and very often obfuscated javascript. So, as far as I am concerned, 
obfuscation is not malicious per se.

Concerning user tracking, all major social networks use it all the time, 
regardless of wasm. We are writing on the google forum and google use our 
posts to dig some data from them. Who knows how many of us on this forum 
have gmail accounts, github accounts,... all these platforms collect data 
about us and about the way we use internet. They have done this long before 
wasm technology. Therefore I don't see any special threat in using and 
spreading wasm technology.

Comparison with the Flash technology is a bit stretched (IMHO). Flash was 
used to overcome some deficiencies in browsers, their incompatibilities and 
yes flash had some potential for writing malicious software. But wasm is 
much safer and it relies on the browser safety mechanisms, it doesn't have 
to be enabled or installed by the user. It is an integral part of newer web 
browsers, no less than the javascript is.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8b3961ac-760f-420f-aa48-1a1fa0eb3efbo%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread Edward K. Ream
On Thu, Sep 3, 2020 at 10:23 AM Thomas Passin  wrote:

> I forgot to include the potential for malware.  Some links:

https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/#h4-webassemblys-date-malware
https://medium.com/better-programming/webassembly-is-the-end-of-the-internet-as-we-know-it-9085a49cbc7b
https://it.slashdot.org/story/20/01/08/1421216/half-of-the-websites-using-webassembly-use-it-for-malicious-purposes

Thanks for the links. I'm not qualified to comment on computer security.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0QGJc_3Ddkj2X_aAbJHkTYR7A5S%2B3%3DiBcXD8HLLXQT1w%40mail.gmail.com.


Re: Wow: wasmtime

2020-09-03 Thread Thomas Passin
Yes, that's so, and I understand that web assemblies are basically a Google 
effort to do that.

On Thursday, September 3, 2020 at 11:20:12 AM UTC-4, lun...@gmail.com wrote:
>
> You're giving technology and standards too much credit. Corporations are 
> going to create closed systems and implement data hiding no matter the 
> tools they have at hand and they're going to continue to do it mercilessly 
> unless socially/culturally disincentivized to do so. Web assemblies will 
> not meaningfully alter their plans or the outcome of those plans. 
>
> On Thursday, September 3, 2020 at 8:41:03 AM UTC-4 tbp1...@gmail.com 
> wrote:
>
>> I am so opposed to webassemblies that I don't want to work on them.  Web 
>> assemblies if widespread will encourage the trend towards breaking the web 
>> by making URLs meaningless, and will promote more closed silos and data 
>> hiding.  I do see that they could be very good in non-web use, but that's 
>> not enough for me to want to help it all happen.
>>
>>
>> On Thursday, September 3, 2020 at 7:59:08 AM UTC-4, Edward K. Ream wrote:
>>>
>>> As part of my "what's next for Leo" project, I decided to check in on 
>>> what's new with webassembly. Here is my google trail:
>>>
>>> webAssembly: https://webassembly.org/
>>>
>>> non-web Embeddings (because Leo doesn't run on the web): 
>>> https://webassembly.org/docs/non-web/
>>>
>>> WebAssembly High-level goals: https://webassembly.org/roadmap/ From the 
>>> table I found...
>>>
>>> wasmer: https://docs.wasmer.io/
>>>
>>> wasmtime: https://wasmtime.dev/
>>>
>>> I had heard of neither wasmer nor wasmtime before.
>>>
>>> The last link is the jackpot. Please take a look at Lin Clark's video. 
>>> The video doesn't waste your time. Instead, it pulls you along and invites 
>>> you to study more deeply. There is a ton of stuff I don't know here. 
>>> Following all the breadcrumbs might be a good way to become an experienced 
>>> web developer. I'll be studying her blog posts next. 
>>>
>>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9c4d9390-0c1b-454d-93d6-079d660d2e33o%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread Thomas Passin
On Thursday, September 3, 2020 at 11:00:48 AM UTC-4, Edward K. Ream wrote:
>
>
>
> On Thu, Sep 3, 2020 at 7:41 AM Thomas Passin  > wrote:
>
>> I am so opposed to webassemblies that I don't want to work on them.  Web 
>> assemblies if widespread will encourage the trend towards breaking the web 
>> by making URLs meaningless, and will promote more closed silos and data 
>> hiding.
>>
>
> I haven't heard anything about this. Could you provide some links?
>

I forgot to include the potential for malware.  Some links:

https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/#h4-webassemblys-date-malware
https://medium.com/better-programming/webassembly-is-the-end-of-the-internet-as-we-know-it-9085a49cbc7b
https://it.slashdot.org/story/20/01/08/1421216/half-of-the-websites-using-webassembly-use-it-for-malicious-purposes

Otherwise, I have read about how WA will break the web, but I can't find 
them again so far.  WA is being presented as a way to get better/faster/etc 
programming languages into the browser.  But actually it will be more like 
Flash - it's taken years to flush Flash out of the system, and now we're 
going to get a more advanced rendition.

I suppose it's inevitable, but I don't have to like it.

-- 
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/d6ac47a7-2784-447f-ad9f-7f265faead41o%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread lun...@gmail.com
You're giving technology and standards too much credit. Corporations are 
going to create closed systems and implement data hiding no matter the 
tools they have at hand and they're going to continue to do it mercilessly 
unless socially/culturally disincentivized to do so. Web assemblies will 
not meaningfully alter their plans or the outcome of those plans. 

On Thursday, September 3, 2020 at 8:41:03 AM UTC-4 tbp1...@gmail.com wrote:

> I am so opposed to webassemblies that I don't want to work on them.  Web 
> assemblies if widespread will encourage the trend towards breaking the web 
> by making URLs meaningless, and will promote more closed silos and data 
> hiding.  I do see that they could be very good in non-web use, but that's 
> not enough for me to want to help it all happen.
>
>
> On Thursday, September 3, 2020 at 7:59:08 AM UTC-4, Edward K. Ream wrote:
>>
>> As part of my "what's next for Leo" project, I decided to check in on 
>> what's new with webassembly. Here is my google trail:
>>
>> webAssembly: https://webassembly.org/
>>
>> non-web Embeddings (because Leo doesn't run on the web): 
>> https://webassembly.org/docs/non-web/
>>
>> WebAssembly High-level goals: https://webassembly.org/roadmap/ From the 
>> table I found...
>>
>> wasmer: https://docs.wasmer.io/
>>
>> wasmtime: https://wasmtime.dev/
>>
>> I had heard of neither wasmer nor wasmtime before.
>>
>> The last link is the jackpot. Please take a look at Lin Clark's video. 
>> The video doesn't waste your time. Instead, it pulls you along and invites 
>> you to study more deeply. There is a ton of stuff I don't know here. 
>> Following all the breadcrumbs might be a good way to become an experienced 
>> web developer. I'll be studying her blog posts next. 
>>
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/65fd5511-dbf1-4f5d-80e0-58b1d5e39f19n%40googlegroups.com.


Re: New Version of Viewrendered3 Updates Asciidoc Handling.

2020-09-03 Thread Thomas Passin

On Thursday, September 3, 2020 at 10:59:41 AM UTC-4, Edward K. Ream wrote:
>
>
>> Actually, I knew about it.  I'm not sure if it's real or something that 
>> pylint doesn't understand (I think it's this). 
>>
>
> If it's a pylint mistake, please disable the message.
>

 I will once I'm sure.  I purposely have not disabled the message until I'm 
convinced it's spurious.

>

-- 
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/ecedbee4-c1df-4e2d-8cee-1533cb54b8dao%40googlegroups.com.


Re: Wow: wasmtime

2020-09-03 Thread Edward K. Ream
On Thu, Sep 3, 2020 at 7:41 AM Thomas Passin  wrote:

> I am so opposed to webassemblies that I don't want to work on them.  Web
> assemblies if widespread will encourage the trend towards breaking the web
> by making URLs meaningless, and will promote more closed silos and data
> hiding.
>

I haven't heard anything about this. Could you provide some links?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0t8k_bBmNisgP-zfAHSHkpUXAy3Ej9aeKyp58X7HEEXQ%40mail.gmail.com.


Re: New Version of Viewrendered3 Updates Asciidoc Handling.

2020-09-03 Thread Edward K. Ream
On Thu, Sep 3, 2020 at 7:30 AM Thomas Passin  wrote:

>
> pylint gives this complaint:
>>
>> * Module leo.plugins.viewrendered3
>> leo\plugins\viewrendered3.py:1803:23: E0602: Undefined variable
>> 'AsciiDocError' (undefined-variable)
>>
>> Do you get the same complaint? If so, please attempt to remove it.
>> Thanks.
>>
>
> Actually, I knew about it.  I'm not sure if it's real or something that
> pylint doesn't understand (I think it's this).
>

If it's a pylint mistake, please disable the message.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0sQKh5Kvk-CREaiw6BEEsGmDkmeVWcT1KNGoO%2BRfE0ew%40mail.gmail.com.


Re: Wow: wasmtime

2020-09-03 Thread Thomas Passin
I am so opposed to webassemblies that I don't want to work on them.  Web 
assemblies if widespread will encourage the trend towards breaking the web 
by making URLs meaningless, and will promote more closed silos and data 
hiding.  I do see that they could be very good in non-web use, but that's 
not enough for me to want to help it all happen.

On Thursday, September 3, 2020 at 7:59:08 AM UTC-4, Edward K. Ream wrote:
>
> As part of my "what's next for Leo" project, I decided to check in on 
> what's new with webassembly. Here is my google trail:
>
> webAssembly: https://webassembly.org/
>
> non-web Embeddings (because Leo doesn't run on the web): 
> https://webassembly.org/docs/non-web/
>
> WebAssembly High-level goals: https://webassembly.org/roadmap/ From the 
> table I found...
>
> wasmer: https://docs.wasmer.io/
>
> wasmtime: https://wasmtime.dev/
>
> I had heard of neither wasmer nor wasmtime before.
>
> The last link is the jackpot. Please take a look at Lin Clark's video. The 
> video doesn't waste your time. Instead, it pulls you along and invites you 
> to study more deeply. There is a ton of stuff I don't know here. Following 
> all the breadcrumbs might be a good way to become an experienced web 
> developer. I'll be studying her blog posts next. 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eddec80e-0237-47ed-8554-53de15a9f60do%40googlegroups.com.


Re: New Version of Viewrendered3 Updates Asciidoc Handling.

2020-09-03 Thread Thomas Passin


On Thursday, September 3, 2020 at 7:20:39 AM UTC-4, Edward K. Ream wrote:
>
>
>
> On Wednesday, September 2, 2020 at 10:30:08 PM UTC-5, Thomas Passin wrote:
>>
>> I've just submitted a pull request for viewsarendered3 v3.0b14 
>>
>
> I've merged the PR. pylint gives this complaint:
>
> * Module leo.plugins.viewrendered3
> leo\plugins\viewrendered3.py:1803:23: E0602: Undefined variable 
> 'AsciiDocError' (undefined-variable)
>
> Do you get the same complaint? If so, please attempt to remove it.  Thanks.
>

Actually, I knew about it.  I'm not sure if it's real or something that 
pylint doesn't understand (I think it's this).  I'll be looking at it.  If 
it's real, it will happen when the asciidoc3 processor raises that type of 
error, which I have seen but not very often. 

-- 
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/a44869a7-91ac-460d-8842-899a171cef1fo%40googlegroups.com.


Wow: wasmtime

2020-09-03 Thread Edward K. Ream
As part of my "what's next for Leo" project, I decided to check in on 
what's new with webassembly. Here is my google trail:

webAssembly: https://webassembly.org/

non-web Embeddings (because Leo doesn't run on the web): 
https://webassembly.org/docs/non-web/

WebAssembly High-level goals: https://webassembly.org/roadmap/ From the 
table I found...

wasmer: https://docs.wasmer.io/

wasmtime: https://wasmtime.dev/

I had heard of neither wasmer nor wasmtime before.

The last link is the jackpot. Please take a look at Lin Clark's video. The 
video doesn't waste your time. Instead, it pulls you along and invites you 
to study more deeply. There is a ton of stuff I don't know here. Following 
all the breadcrumbs might be a good way to become an experienced web 
developer. I'll be studying her blog posts next. 

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0d7a1cfa-802e-4678-af35-b935ebc9cd36o%40googlegroups.com.


Re: New Version of Viewrendered3 Updates Asciidoc Handling.

2020-09-03 Thread Edward K. Ream


On Wednesday, September 2, 2020 at 10:30:08 PM UTC-5, Thomas Passin wrote:
>
> I've just submitted a pull request for viewsarendered3 v3.0b14 
>

I've merged the PR. pylint gives this complaint:

* Module leo.plugins.viewrendered3
leo\plugins\viewrendered3.py:1803:23: E0602: Undefined variable 
'AsciiDocError' (undefined-variable)

Do you get the same complaint? If so, please attempt to remove it.  Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/354be6ff-bea9-4198-97a6-f3c5e04cd430o%40googlegroups.com.