IMAP library, or support via tsNet?

[Ben Rubinstein via use-livecode]

Is there anything in the way of an IMAP library around?

My needs are relatively simple: I want to connect to an iMAP server, 
recursively list folders and fetch the size of each (if necessary by fetching 
the size of each message)


e.g. in JavaScript with this library
https://github.com/emailjs/emailjs-imap-client
I'd be using
connect()
listMailboxes()
listMessages(... ['RFC822.SIZE'])
...

Is there a library that would support this kind of access?

Does tsNet provide anything above the basic network primitives to support 
this?  Some time I ago there was a tantalising hint on this list:


On 24/08/2017 11:05, Charles Warwick via use-livecode wrote:
IMAP and POP3 support in tsNet under Linux is only available in tsNet 1.3.0+ 
which will be bundled with the next LC release.


All other platforms have had support for those protocols for a while.  I hope 
to have some documentation available in the next two weeks.


Did that ever come to fruition?


Many thanks,

Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

It might be that I stand corrected for the behaviour of lock / unlock screen.
But then I also stand puzzled on the effect it has between engines. Same code 
which redrew the screen within 2.5 seconds on the 5.x series took 11 secs in 
8/9. After debugging libraries. Being used to make sure that lock screens no 
longer nested brought this down to 1.5 seconds. Rest of the code left 
unchanged! I really do not get it. That said, I am pretty happy with the fact. 
I only wish I would have found/tried this earlier.

Regarding strictness of the parser, I am actually quite glad that the parser is 
less forgiving nowadays. :-) Have been working in strict compile mode for ages 
and this has saved me from shooting my own foot numerous times.
Thank you all for your input on this. If anyone of you has any more gotchas to 
look out for I am most interested to learn. :-)

Cheers,

Malte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

IMAP library, or support via tsNet?

[Ben Rubinstein via use-livecode]

Is there anything in the way of an IMAP library around?

My needs are relatively simple: I want to connect to an iMAP server, 
recursively list folders and fetch the size of each (if necessary by fetching 
the size of each message)


e.g. in JavaScript with this library
https://github.com/emailjs/emailjs-imap-client
I'd be using
connect()
listMailboxes()
listMessages(... ['RFC822.SIZE'])
...

Is there a library that would support this kind of access?

Does tsNet provide anything above the basic network primitives to support 
this?  Some time I ago there was a tantalising hint on this list:


On 24/08/2017 11:05, Charles Warwick via use-livecode wrote:
IMAP and POP3 support in tsNet under Linux is only available in tsNet 1.3.0+ 
which will be bundled with the next LC release.


All other platforms have had support for those protocols for a while.  I hope 
to have some documentation available in the next two weeks.


Did that ever come to fruition?


Many thanks,

Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[hh via use-livecode]

> Geoff C. wrote:
> Let me know if there's anything still missing.

A reordering in the stacks list that sets the window layering?
(What a simple go to stack from last line down to first line does).


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: IMAP library, or support via tsNet?

[Matthias Rebbe via use-livecode]

Ben,

i just did a quick test with my local test mai server. This script for example 
would output the number of messages in the imap folder to the message box.

put tUSERNAME into pSettings["username"]
put put into pSettings["password"]
put "STATUS INBOX (MESSAGES)" into pRequest
put "imap://192.168.7.25" into pURL
put tsnetCustomSync(pURL,pRequest,xHeaders,rOutHeaders,rResult,rBytes,pSettings)

Did not try ssl, but should work also.


Regards,

Matthias



Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de
https://winsignhelper.dermattes.de

> Am 03.01.2019 um 12:17 schrieb Ben Rubinstein via use-livecode 
> :
> 
> Is there anything in the way of an IMAP library around?
> 
> My needs are relatively simple: I want to connect to an iMAP server, 
> recursively list folders and fetch the size of each (if necessary by fetching 
> the size of each message)
> 
> e.g. in JavaScript with this library
>   https://github.com/emailjs/emailjs-imap-client
> I'd be using
>   connect()
>   listMailboxes()
>   listMessages(... ['RFC822.SIZE'])
>   ...
> 
> Is there a library that would support this kind of access?
> 
> Does tsNet provide anything above the basic network primitives to support 
> this?  Some time I ago there was a tantalising hint on this list:
> 
> On 24/08/2017 11:05, Charles Warwick via use-livecode wrote:
>> IMAP and POP3 support in tsNet under Linux is only available in tsNet 1.3.0+ 
>> which will be bundled with the next LC release.
>> All other platforms have had support for those protocols for a while.  I 
>> hope to have some documentation available in the next two weeks.
> 
> Did that ever come to fruition?
> 
> 
> Many thanks,
> 
> Ben
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Bob Sneidar via use-livecode]

More like malcontents. :-)

Bob S


> On Jan 2, 2019, at 17:02 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 1/2/19 2:30 PM, Geoff Canyon via use-livecode wrote:
>> Ha, I knew that to a select subset of people this would be the most
>> important feature of the update :-)
> 
> Heh. Yeah, I've backburned for now a talk entitled "Global Variables and 
> Their Discontents"
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Bob Sneidar via use-livecode]

Folding seems to have broken. I cannot fold or unfold but the default folding 
is in effect. 

Bob S


> On Jan 2, 2019, at 14:17 , Geoff Canyon via use-livecode 
>  wrote:
> 
> As usual, you can get Navigator here
> . Or grab it
> from GitHub .

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Geoff Canyon via use-livecode]

So you want drag and drop in the stack list to reorder the windows? What's
the purpose? To bring a particular stack to the foreground?

On Thu, Jan 3, 2019 at 4:38 AM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff C. wrote:
> > Let me know if there's anything still missing.
>
> A reordering in the stacks list that sets the window layering?
> (What a simple go to stack from last line down to first line does).
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

I'm curious if issuing a new screen lock inadvertently and for an instant 
unlocks the screen and a redraw happens? Not the desired effect obviously but 
that would explain things somewhat. 

Bob S


> On Jan 3, 2019, at 03:13 , Malte Pfaff-Brill via use-livecode 
>  wrote:
> 
> It might be that I stand corrected for the behaviour of lock / unlock screen.
> But then I also stand puzzled on the effect it has between engines. Same code 
> which redrew the screen within 2.5 seconds on the 5.x series took 11 secs in 
> 8/9. After debugging libraries. Being used to make sure that lock screens no 
> longer nested brought this down to 1.5 seconds. Rest of the code left 
> unchanged! I really do not get it. That said, I am pretty happy with the 
> fact. I only wish I would have found/tried this earlier.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Howdy LiveCoders,

I'm very happy to see people succeeding, optimizing, and coming back and 
LiveCoding. That's heartwarming.


But I'm making one of my rare appearances here, chiming in lest this 
thread end while consisting only of celebrating extra work that was put 
in to overcome slowdowns. To me putting in double work (or 1.x work) to 
achieve the result is not ideal.


Therefore, while I'm very happy people are back on track and "OK" - 
while I share in their relief and renewed optimism - I don't think it 
rises to the level of celebration. Quite the reverse. That would be 
celebrating a model where requiring more work to produce fewer results 
(or repeated work to achieve the same result) is considered a good 
thing. I consider that a bad thing.


Objective, repeatable testing has showed that LC 9 is considerably 
slower than LC 6 in a number of areas. In 2 years, LC has become twice 
as slow at some basic tasks. This pretty much negates the benefits of 
Moore's Law (and similar advances driving current and future hardware) 
and deprives coders and users of what would otherwise be a trend toward 
(offset a bit by OS flashiness) general 1.x improvement in performance 
over time. And that's passive gain; any work on code improvements would 
yield a multiple of performance.


Likewise, in 2 years LC has required one heck of a lot of refactoring. 
That may be fine and dandy for people who write loose and sloppy code 
the first time and love rewriting everything, but it's not quite so cool 
for responsible, experienced coders who do it right the first time, and 
build reliable and optimized code to last as a smart value for their 
clients and customers. If you love retyping, redoing, and refactoring 
every 2 years, along with multiplied costs, then I totally understand 
the celebration. Personally I don't love that model. My ideal is just 
the opposite - smart code that is built to last and already optimized 
and reasonably well written from the start.


Imagine all the hours, dollars, pounds, and euros spent on refactoring 
for 7/8/9 - multiplied by all the projects and clients. It's staggering. 
I'm confident that a good portion of that was avoidable. And STILL the 9 
engine is slow and has more bugs and arbitrary problematic changes than 
it should.


For my own addons, with VERY few exceptions, it has been due to LC's own 
bugs and arbitrary changes when they have broken or had problems. LC 
breaks it, I have to fix it. That's OK now and then, but it's not OK 
when LC gets sloppy, because when it's one person against a team, it 
becomes faster for a team to make a mess and break things than an 
individual to follow behind for clean up and repair. And one of those 
very few exceptions was a slowdown that another person added to my code 
when I permitted them to tweak the project, something I rarely do; I 
write very few bugs myself and that's how I like it. Don't you?


Sometimes I'm slower than ideal in following and repairing the breaks 
with my own updates, but it's a team vs one situation, updates go 
through a process, and the "one" is not the one doing the breaking. (Hi 
Klaus, old buddy old pal.) More updates are close, BTW - I have a little 
less extra steam for updates after my regular client work during winter, 
but it'll pick up again in the spring.


How much time and money have you put into your own 7-9 refactoring and 
debugging? Minus your bad code, of course. (If you're thinking "it all 
needed refactoring anyway" that's not proving your point, it's proving 
you were very naughty when coding.) :) For any code riding on top of 
another layer, as ours does, it makes sense to minimize engine and 
syntax breaks as much as reasonably possible. Otherwise some of the 
advantages of the layered environment are lost. There will be some 
breaks over time with generational improvements, but we're way over the 
ideal. And a steady loss of performance over time is just not a good 
thing in any possible universe. (Well, maybe a universe with inverse 
physics.)


Can we survive with this model? Heck yeah. Here we are, at least a good 
number of us. Was it ideal? Not in your wildest dreams. Here I must note 
that we have a lot of bad examples from the big industry players. They 
are taking planned obsolescence to extremes to make big bucks, in 
software as well as hardware. They don't mind if you have to pay N times 
(or work a reasonable amount of hours multipled by N extra times) to 
achieve the same results. They love your money more than they love YOU 
the person. I'm the opposite. I care about YOU - all of you, LC Ltd and 
the entire community.


So when people are frustrated and depressed and give up and then come 
back and try again and put in some renewed time and energy, I get it. 
I'm happy too. But I'm locally happy, for them as an individual, not 
globally happy for us as a community. Because this is inefficient. I'm 
not a very emotional person. I don't get depressed and give up and t

Re: Refactoring is your friend / moving from 6.x to 9.x

[Mark Waddingham via use-livecode]

On 2019-01-03 12:13, Malte Pfaff-Brill via use-livecode wrote:
It might be that I stand corrected for the behaviour of lock / unlock 
screen.

But then I also stand puzzled on the effect it has between engines.
Same code which redrew the screen within 2.5 seconds on the 5.x series
took 11 secs in 8/9. After debugging libraries. Being used to make
sure that lock screens no longer nested brought this down to 1.5
seconds. Rest of the code left unchanged! I really do not get it. That
said, I am pretty happy with the fact. I only wish I would have
found/tried this earlier.


I wonder if this is combination of one too many unlock screens (so the 
screen wasn't actually locked for the whole process you timed); and 
having a Retina screen...


If so, in 5.x the screen was probably being redrawn when you didn't 
intend also, but it was rendering 1/4 of the number of pixels so took 
1/4 of the time or thereabouts (5.x would have been rendering to a 1/4 
size buffer which was then upscaled by the OS to full-resolution Retina; 
it was only 6.x+ which started to render to a full-retina resolution 
window buffer on retina displays).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Whoops: Getting the name of the script only stack an handler is in

[Martin Koob via use-livecode]

Hi

Another way to approach it is to use the 'get the executionContext'.   You
can get the filename of the script only stack from this

I tried this in a button with a behaviour script on a new stack with three
fields to see the different results.

on mouseUp pButtonNumber
   set the itemdelimiter to comma
   put item 4 of the executionContexts into tStackPath
   set the itemDelimiter to "/"
   put the last item of tStackPath into tStackFileName
   delete the last character of tStackFileName
   put tStackFileName into field 1 -- file name of script only stack with
extension
   put the name of me into field 2 -- name of control that has the behavior
   put the name of this me into field 3 -- name of script only stack
end mouseUp

Using the executionContexts you get the actual filename,  not sure if that
is what you want or the stack name.  Either way both options are there.

Martin



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LiveCode Server Mojave

[Rick Harrison via use-livecode]

Happy New Year's Greetings to all LiveCoders!

Has anyone upgraded their LiveCode Server
to Mojave yet?

I am in the process and finding it to be
quite the problem as Apple decided
to get rid of their front-end server.

Everything that used to be in the Server
folder now has to be moved to the
Webserver folder.

They published a document in June 2018
https://developer.apple.com/support/macos-server/macOS-Server-Service-Migration-Guide.pdf
 


I find their documentation to be sadly lacking in proper instruction examples 
etc.
You would have thought they could have been kind enough to provide a nice
video or two on the subject before yanking everything away from loyal users.

This problem also involves how LiveCode Server should be installed.
Those instructions should also be update as soon as possible.

If some expert LiveCode developer came up with a good solution I would
bet that many people would be willing to pay for such a utility.

Let me know of your experiences or what other solutions you think of.

Thanks,

Rick
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Whoops: Getting the name of the script only stack an handler is in

[Bob Sneidar via use-livecode]

Apple Mail does indeed support threading, but somehow certain emails or rather 
replies to emails "unthread" and start a new thread. Part of the problem is 
that some simply subscribe to the list as individual emails, while others 
employ the digest, and still others use the forum (I think). The only solution 
would be a list service that sent and received in all these modes using the 
same process, which I am not even sure is possible. :-(

Bob S


> On Jan 2, 2019, at 14:23 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 1/2/19 8:01 AM, Bob Sneidar via use-livecode wrote:
>> And I replied before checking all my other emails. Seriously, at some point 
>> we need to develop a list system where emails remain threaded. I have over 
>> 40 from this list this morning, and reading through every one, then trying 
>> to go back and respond is a little more brainwork than I am used to before 
>> my 3rd cup of coffee. :-)
> 
> Whoa! There are email clients that don't support threading?
> Here ya go:
> 
> https://www.thunderbird.net/en-US/
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

This is largely due to unicode support in everything, as I understand it. This 
performance hit is, I think, completely understandable. But there definitely 
is/was something else going on when developing under Windows. As other threads 
have amply demonstrated, V9 introduced a massive performance hit, and it's my 
understanding that those issues have been somewhat or wholly addressed in 
9.0.2. 

I will be corrected if inaccurate. 

Bob S


> On Jan 3, 2019, at 10:12 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Objective, repeatable testing has showed that LC 9 is considerably slower 
> than LC 6 in a number of areas. In 2 years, LC has become twice as slow at 
> some basic tasks. This pretty much negates the benefits of Moore's Law (and 
> similar advances driving current and future hardware) and deprives coders and 
> users of what would otherwise be a trend toward (offset a bit by OS 
> flashiness) general 1.x improvement in performance over time. And that's 
> passive gain; any work on code improvements would yield a multiple of 
> performance.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Whoops: Getting the name of the script only stack an handler is in

[Martin Koob via use-livecode]

To view the messages in threaded form I use:
http://lists.runrev.com/pipermail/use-livecode/

I can't reply thru that so when I do want to reply I use:
http://runtime-revolution.278305.n4.nabble.com/

I can't imagine trying to manage all the email from the lists in my mail.  I
have enough to sort thru there as it is.

Martin



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Bob:

> This is largely due to unicode support in everything,
> as I understand it.

Nope, I think that was more of a prior assumption going in, and held 
onto despite test results to the contrary, than a conclusion derived 
from testing. :)


Some tests were designed to rule out the effects of text to the maximum 
extent possible, so slowdowns were almost certainly (or if so, should 
not be) the result of unicode. And some text features maintained or 
gained speed despite unicode. So whatever part it played, there's much 
more to the story.


As I say, tests are repeatable; there will be nothing left to difference 
of opinion or chance. I tested an RC of 902 with the same old slow 
results. Soon when I have a chance, I will test 902 final. Whenever an 
LC version comes along with significant improvements, I'll be all over 
it and make the tests extremely public. Not the case so far, we're still 
in the speed limit zone AFAIK!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

Not to put too fine a point on this, but ALL development environments suffer 
from this. Even if everything is done "right", future OS enhancements, new and 
improved plugins, LC feature enhancements and even developer enhancements can 
all lend themselves to the necessity for refactoring. 

It also begs the question what is meant by doing things right. With a fairly 
forgiving scripting environment like LC, right simply means, "compiles and runs 
without any errors." I moved projects from LC6 to LC9 with little difficulty. 
My problems revolved around app building, and I got through that fairly simply. 

What is missing here I think is what is great about developing in LC. The time 
it takes you to build an app is a fraction of the time it would have taken you 
in C variants or even Java, and the manpower needed is also dramatically 
reduced (and dare I say more cost effective to employ). It's a little like my 
boss telling me that I need to make more money getting customers to pay for IT 
services if I expect a raise. 

The elephant in the room however is that I have been saving them a boatload of 
money these 4 years, ever since I took over managing all their internal IT 
support allowing them to can their prior contractor (who was expensive and not 
nearly as responsive as we would have liked them to be). Not only that, but I 
have produced an in-house application used by all the IT technicians for 
generating professional looking customer forms onsite, as well as revamping all 
our internal forms and standardizing them. 

I could go on singing my own praises, but my point is, the assessment of 
profitability often depends largely on where you decide to plant your flag. I 
think from reading you email, that you might want to consider planting the flag 
a bit further back into your own territory. 

Bob S


> On Jan 3, 2019, at 10:12 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Likewise, in 2 years LC has required one heck of a lot of refactoring. That 
> may be fine and dandy for people who write loose and sloppy code the first 
> time and love rewriting everything, but it's not quite so cool for 
> responsible, experienced coders who do it right the first time, and build 
> reliable and optimized code to last as a smart value for their clients and 
> customers. If you love retyping, redoing, and refactoring every 2 years, 
> along with multiplied costs, then I totally understand the celebration. 
> Personally I don't love that model. My ideal is just the opposite - smart 
> code that is built to last and already optimized and reasonably well written 
> from the start.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: IMAP library, or support via tsNet?

[Ben Rubinstein via use-livecode]

Aha! I didn't even realise that there was an imap URL protocol.

Thanks Matthias, that's exactly what I needed.

best regards,

Ben

On 03/01/2019 13:57, Matthias Rebbe via use-livecode wrote:

Ben,

i just did a quick test with my local test mai server. This script for example 
would output the number of messages in the imap folder to the message box.

put tUSERNAME into pSettings["username"]
put put into pSettings["password"]
put "STATUS INBOX (MESSAGES)" into pRequest
put "imap://192.168.7.25" into pURL
put tsnetCustomSync(pURL,pRequest,xHeaders,rOutHeaders,rResult,rBytes,pSettings)

Did not try ssl, but should work also.


Regards,

Matthias



Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de
https://winsignhelper.dermattes.de


Am 03.01.2019 um 12:17 schrieb Ben Rubinstein via use-livecode 
:

Is there anything in the way of an IMAP library around?

My needs are relatively simple: I want to connect to an iMAP server, 
recursively list folders and fetch the size of each (if necessary by fetching 
the size of each message)

e.g. in JavaScript with this library
https://github.com/emailjs/emailjs-imap-client
I'd be using
connect()
listMailboxes()
listMessages(... ['RFC822.SIZE'])
...

Is there a library that would support this kind of access?

Does tsNet provide anything above the basic network primitives to support this? 
 Some time I ago there was a tantalising hint on this list:

On 24/08/2017 11:05, Charles Warwick via use-livecode wrote:

IMAP and POP3 support in tsNet under Linux is only available in tsNet 1.3.0+ 
which will be bundled with the next LC release.
All other platforms have had support for those protocols for a while.  I hope 
to have some documentation available in the next two weeks.


Did that ever come to fruition?


Many thanks,

Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Sorry Bob (not to single you out, on the contrary thanks for your reply 
and sharing your experience) but just be aware I never not enter a 
thread lightly, nor were my words hasty. This has been a situation years 
in the making, with plenty of evidence behind it, and I've been many 
years in the LC arena. My list and forum silence may sometimes mask my 
eternal presence and busy contributions. I realize that the human mind 
tends to favor the loudest and most frequent voices (in marketing it's 
recognized that an audience needs to hear a message repeated 3 times to 
even notice it, whereas if you repeat yourself 3 times in code you've 
broken a rule) so when popping up now and then, I will remind the hasty 
of reply that while my points are easy to dismiss on the subjective 
basis of being heard less frequently, they are built on solid ground and 
difficult to overturn by factual or logical approach.


(I don't have spare time to be one of the loudest and most frequent 
voices here, so for better or worse this post must satisfy the 
obligatory 3 times mentioning, and unfortunately that's all I can spare; 
I'll be back in lurk/work mode soon after this because as my clients 
know, they come first; no exceptions. Even addons come second and 
conversation is last. To sum up what years of factual records will show, 
I'm not one of the most frequent posters here on the list, but I am one 
of the most frequently involved consultants in the LC world. So)



Not to put too fine a point on this, but ALL development
environments suffer from this.


Not all to the same extent. And there's the difference, adding to 
personal preference and work needs/range of experience. Without going 
too far down that potentially red herring road, when it could be called 
suffering it's too much. When done right it doesn't cause suffering. 
That will vary per personal preference, bias, and experience, but what 
stays true is that efficiency is better than a lack of it. I'm sure you 
have many examples, but I would have many counter-examples, plus I think 
arguing for quality and efficiency is a stronger position that arguing 
for a lower-quality, lower-efficiency bandwagon. Winning an irrelevant 
contest of examples would not weaken my point, so we can probably save 
that particular trip.



I moved projects from LC6 to LC9 with little difficulty.
My problems revolved around app building, and I got through
that fairly simply.


I'm genuinely happy for you there! I work for a wide variety of client 
projects and my own addons and other projects, so it takes me lots of 
places within LC. Not one platform nor approach nor area of LC 
endeavors. I also have spent a lot of time tracking down issues to 
report, investing my own addon income right back in LC debugging rather 
than own products, to help LC through the transitions, and many of those 
bugs have been fixed. You may have benefited from those and the efforts 
of others who dedicated a lot of time to that. So I applaud your own 
luck and lack of trouble, but perhaps fortunately you were in an area 
that benefited from the most attention to fixes and the least need for 
performance.


But never mind me; for anyone to argue that there was no extra work 
involved, they would have to scrub some messages from the list in 
general and this thread in particular. I'm not sure if you read the 
original post in this thread, but the extra work was acknowledged right 
there when starting this thread, by others. Without that, we wouldn't be 
having this conversation in the first place, no matter whether criticism 
or justification, so I feel no need to say more on that point; 
sufficiently documented although perhaps not a universal condition. But 
remember, not everyone who became frustrated came back. There were other 
discussions, including a somewhat hilarious one that I can't relate here 
due to privacy agreements but where I was the person complaining the 
LEAST of many prominent LC members in that particular conversation.


(Likewise, those separate points of defense argue against themselves to 
a degree; if there was no trouble in your case, then do all environments 
indeed suffer the problem? Separately good defenses, but together, not 
quite as strong.)


Sorry again (and nothing personal, I appreciate your comments) and can 
understand your POV from your particular experience, but no amount of 
talk can disprove (A) repeatable test results and (B) the economics of 
efficiency. Those will stand on their own.



I could go on singing my own praises, but my point is, the
assessment of profitability often depends largely on where you
decide to plant your flag.


As I said, I'm stable here, as are the laws of this universe - no 
running off disappointed or depressed, no coming back and gushing over 
it. No urge to overly defend or rationalize the last two years, nor any 
need to criticize beyond an objective measure.


My work has been consistent and steady, and in fact I've als

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Geoff Canyon via use-livecode]

Can you give me more specifics? Folding is working for me:
https://www.youtube.com/watch?v=x-_nLJNJvpM&feature=youtu.be

On Thu, Jan 3, 2019 at 9:55 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Folding seems to have broken. I cannot fold or unfold but the default
> folding is in effect.
>
> Bob S
>
>
> > On Jan 2, 2019, at 14:17 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > As usual, you can get Navigator here
> > . Or grab
> it
> > from GitHub .
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[hh via use-livecode]

> Geoff C. wrote:
> So you want drag and drop in the stack list to reorder the windows?
> What's the purpose? To bring a particular stack to the foreground?

What others do with the "z-index". Or what we can do with setting the
layer of card controls (no only setting the layer of a control to "top").
Stack windows can be partially transparent. So it makes sense to set
the whole layering of the windows, not only to set the front window...

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: IMAP library, or support via tsNet?

[Charles Warwick via use-livecode]

Hi Ben,

Support for IMAP was added into tsNet a while ago. There are a few lessons that 
I’ve added to LiveCode’s website on IMAP.

Lessons:

http://lessons.livecode.com/m/4071/l/858279-how-to-use-tsnet-to-display-an-e-mail-message-from-an-imap-account

http://lessons.livecode.com/m/4071/l/858974-how-to-use-tsnet-to-display-the-folders-stored-in-an-imap-account

http://lessons.livecode.com/m/4071/l/860779-how-to-use-tsnet-to-delete-an-e-mail-message-from-an-imap-account

Regards,

Charles.

> On 4 Jan 2019, at 5:56 am, Ben Rubinstein via use-livecode 
>  wrote:
> 
> Aha! I didn't even realise that there was an imap URL protocol.
> 
> Thanks Matthias, that's exactly what I needed.
> 
> best regards,
> 
> Ben
> 
>> On 03/01/2019 13:57, Matthias Rebbe via use-livecode wrote:
>> Ben,
>> i just did a quick test with my local test mai server. This script for 
>> example would output the number of messages in the imap folder to the 
>> message box.
>> put tUSERNAME into pSettings["username"]
>> put put into pSettings["password"]
>> put "STATUS INBOX (MESSAGES)" into pRequest
>> put "imap://192.168.7.25" into pURL
>> put 
>> tsnetCustomSync(pURL,pRequest,xHeaders,rOutHeaders,rResult,rBytes,pSettings)
>> Did not try ssl, but should work also.
>> Regards,
>> Matthias
>> Matthias Rebbe
>> free tools for Livecoders:
>> https://instamaker.dermattes.de
>> https://winsignhelper.dermattes.de
>>> Am 03.01.2019 um 12:17 schrieb Ben Rubinstein via use-livecode 
>>> :
>>> 
>>> Is there anything in the way of an IMAP library around?
>>> 
>>> My needs are relatively simple: I want to connect to an iMAP server, 
>>> recursively list folders and fetch the size of each (if necessary by 
>>> fetching the size of each message)
>>> 
>>> e.g. in JavaScript with this library
>>>https://github.com/emailjs/emailjs-imap-client
>>> I'd be using
>>>connect()
>>>listMailboxes()
>>>listMessages(... ['RFC822.SIZE'])
>>>...
>>> 
>>> Is there a library that would support this kind of access?
>>> 
>>> Does tsNet provide anything above the basic network primitives to support 
>>> this?  Some time I ago there was a tantalising hint on this list:
>>> 
 On 24/08/2017 11:05, Charles Warwick via use-livecode wrote:
 IMAP and POP3 support in tsNet under Linux is only available in tsNet 
 1.3.0+ which will be bundled with the next LC release.
 All other platforms have had support for those protocols for a while.  I 
 hope to have some documentation available in the next two weeks.
>>> 
>>> Did that ever come to fruition?
>>> 
>>> 
>>> Many thanks,
>>> 
>>> Ben
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Geoff Canyon via use-livecode]

Okay, that should be easy enough -- I just didn't see the need personally,
and it will require code that is different than the regular
drag/drop/relayering code, so I hadn't bothered.

gc

On Thu, Jan 3, 2019 at 2:55 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff C. wrote:
> > So you want drag and drop in the stack list to reorder the windows?
> > What's the purpose? To bring a particular stack to the foreground?
>
> What others do with the "z-index". Or what we can do with setting the
> layer of card controls (no only setting the layer of a control to "top").
> Stack windows can be partially transparent. So it makes sense to set
> the whole layering of the windows, not only to set the front window...
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

[Geoff Canyon via use-livecode]

This is fixed in 7.0.2 rc1. I had a variable where I was tracking
containers that had already been "default-folded" and I wasn't setting it
properly, so every time the display refreshes, it got the default fold.

As usual, you can get Navigator here
. Or grab it
from GitHub .

On Thu, Jan 3, 2019 at 9:55 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Folding seems to have broken. I cannot fold or unfold but the default
> folding is in effect.
>
> Bob S
>
>
> > On Jan 2, 2019, at 14:17 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > As usual, you can get Navigator here
> > . Or grab
> it
> > from GitHub .
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Musings on Architect, MVC, Nested Behaviors

[Richard Gaskin via use-livecode]

Andre Alves Garzia wrote:

> Be aware that YAML is tricky to parse, there are better formats such
> as TOML which are much easier and tend to be less error prone. It is
> very easy to get some indentation wrong in YAML and move something up
> or down a level. TOML is IMHO a better format for such stuff.
>
>YAML: http://yaml.org
>
>TOML: https://github.com/toml-lang/toml
>
> There is also StrictYAML which removes some problematic features from
> YAML. Anyway, I think that if all you need is something that maps to a
> hashmap that is not too deep (thats important) then TOML is a better
> format.

https://xkcd.com/927/


Story so far:

Assertion: XML will solve everything!
Reality:   bloated

Assertion: JSON will solve everything!
Reality:   If you happen to do everything in JavaScript

Assertion: YAML will solve everything, and be human-writable!
Reality:   Sure, but it's so hard to parse not even robots
   can do it well.

Assertion: TOML will solve everything, and be human-writable,
   and be easily parseable!
Reality:   I'm dizzy, and going to lie down. Wake me when anything
   actually solves all everything, or next Tuesday when
   the next serialization-format-du-jour is premiered as
   the thing that will solve everything, so we can all
   enjoy throwing away this week's code for a week with
   the new kid on the block until next week's kid on the
   block shows up.

:)

The longer I've been in this business the more comfortable I've become 
defining my own purpose-build formats as needed.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Read through this whole thread, optimistic that I'd find the list of 
things that differentiate v6 and v9 so we can hone in on actual solutions.


I learned two things:

 - lock/unlock changed

 - It's apparently easier to write a thousands of words philosophizing
   about how a small team of C++ programmers should provide a uniform
   scripting interface for a nearly unprecedented number of OSes,
   stay on top of ongoing API changes in every one of those OSes,
   multiply features, fix bugs, incorporate Unicode, maintain or improve
   all aspects of performance, and keep the joint running than it is to
   even briefly summarize concerns about any of the above.

Is there an actual list of concrete concerns here that the team may be 
able to take action on or at least explain how/why the change exists, or 
did I just spend an hour reading that I'll never get back?


I feel rickrolled.


I've worked with too many people moving from Drupal 7 to Drupal 8, or 
Python 2 to 3, or any version of Apple's C headers in the '90s that 
broke declarations quarterly, or HyperCard 2 to 3, to get too 
out-of-breath about undoing workarounds in old code to work 
with-the-grain for v9's enhancements and fixes for long-standing 
anomalies.  When I describe LC's high priority for backward 
compatibility to nearly any other experienced dev I know, they look at 
me like I'm high and spouting tales of dancing ponies; many professional 
development systems consider backward compatibility a very minor 
nice-to-have, if they devote time to it at all. Many of us here buy 
computers from a hardware vendor with a similar view.


As for performance, in threads with Geoff Canyon, Mark Talutto, and 
others who provided real-world use cases and metrics, we do see some 
performance degradation in v9 from v6 in some cases, a surprising amount 
on par given how relatively little work v6 had to do under the hood with 
encodings and types, a few things a wee bit faster, and overall such a 
strong comeback from the v7 series that it should be clear to those 
earnestly following along that the team has indeed been quite evidently 
working on performance, and delivering improvements over the v9 cycle.


Then again, my work may not touch the items on the concern list.  I 
can't know, because I couldn't find such a list in this long thread.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Geoff Canyon via use-livecode]

I wasn't sure what people were talking about with lock screen performance
issues, so I did a simple test: I set up a button to either lock the screen
once, or twice, and then timed setting the loc of the button while the
screen was locked. I didn't time locking the screen; just the movement
while locked. As I hoped, I didn't find any difference between locking once
or twice, either in 6.7.3, or in 9.0.1 (on an up-to-date Mac).

But...

There was a significant performance difference between 6.7.3 and 9.0.1.
*Maybe* this is Unicode related? In any case, this script takes about 0.04
seconds in 6.7.3, and 0.24 seconds in 9.0.1:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

Then I noticed that I had forgotten one line of code. I changed it to this:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   add 100 to item 1 of L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

...and found that in 6.7.3 that change increased the duration to about 1.25
seconds -- a performance hit of about 30x just because a locked-screen
button is actually moving. In 9.0.1, the time changed to about 0.35
seconds. So if the button *isn't* moving, 6.7.3 is much faster, but in the
more practical and likely case that the button *is* moving, 9.0.1 is
faster. So ¯\_(ツ)_/¯


On Thu, Jan 3, 2019 at 11:03 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Read through this whole thread, optimistic that I'd find the list of
> things that differentiate v6 and v9 so we can hone in on actual solutions.
>
> I learned two things:
>
>   - lock/unlock changed
>
>   - It's apparently easier to write a thousands of words philosophizing
> about how a small team of C++ programmers should provide a uniform
> scripting interface for a nearly unprecedented number of OSes,
> stay on top of ongoing API changes in every one of those OSes,
> multiply features, fix bugs, incorporate Unicode, maintain or improve
> all aspects of performance, and keep the joint running than it is to
> even briefly summarize concerns about any of the above.
>
> Is there an actual list of concrete concerns here that the team may be
> able to take action on or at least explain how/why the change exists, or
> did I just spend an hour reading that I'll never get back?
>
> I feel rickrolled.
>
>
> I've worked with too many people moving from Drupal 7 to Drupal 8, or
> Python 2 to 3, or any version of Apple's C headers in the '90s that
> broke declarations quarterly, or HyperCard 2 to 3, to get too
> out-of-breath about undoing workarounds in old code to work
> with-the-grain for v9's enhancements and fixes for long-standing
> anomalies.  When I describe LC's high priority for backward
> compatibility to nearly any other experienced dev I know, they look at
> me like I'm high and spouting tales of dancing ponies; many professional
> development systems consider backward compatibility a very minor
> nice-to-have, if they devote time to it at all. Many of us here buy
> computers from a hardware vendor with a similar view.
>
> As for performance, in threads with Geoff Canyon, Mark Talutto, and
> others who provided real-world use cases and metrics, we do see some
> performance degradation in v9 from v6 in some cases, a surprising amount
> on par given how relatively little work v6 had to do under the hood with
> encodings and types, a few things a wee bit faster, and overall such a
> strong comeback from the v7 series that it should be clear to those
> earnestly following along that the team has indeed been quite evidently
> working on performance, and delivering improvements over the v9 cycle.
>
> Then again, my work may not touch the items on the concern list.  I
> can't know, because I couldn't find such a list in this long thread.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Geoff Canyon wrote:

> I wasn't sure what people were talking about with lock screen
> performance issues, so I did a simple test
...
> ...and found that in 6.7.3 that change increased the duration to about
> 1.25 seconds -- a performance hit of about 30x just because a locked-
> screen button is actually moving. In 9.0.1, the time changed to about
> 0.35 seconds. So if the button *isn't* moving, 6.7.3 is much faster,
> but in the more practical and likely case that the button *is* moving,
> 9.0.1 is faster. So ¯\_(ツ)_/¯

That seems a good balance of priorities by use case.  After all, when 
nothing's moving the wait time may not even be noticeable, but with 
moving objects performance can be critical.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode