mobileStoreMakePurchase not working for iOS

[Andrew at MidWest Coast Media via use-livecode]

I have released my first project with in-app purchases but only to 50% platform 
success: Android works but iOS does not. I’m using the directions at 
https://lessons.livecode.com/m/4069/l/186807-how-do-i-implement-in-app-purchases-in-livecode-apple-appstore
 but am getting generic errors. 

I had been receiving the dreaded “Cannot connect to iTunes Store” error, but 
did the test user creation dance a couple times to step past that.
When trying in the simulator with a real user account or registered sandbox 
user I’m getting a mobileStorePurchaseError of “UNKNOWN_ERROR"
When trying on the device (production build from App Store) I’m getting a 
mobileStorePurchaseError of “An unknown error occurred”

These are all submitted and approved consumables registered in App Store 
Connect. Is there anyway to track down a more descriptive error message? Same 
code is working for Google Play. 

Compiled with LiveCode 9.6.2rc3 on macOS 11.0.1 using Xcode 12.1

—Andrew Bell
___
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: name of web page

[scott--- via use-livecode]

Ah, of course!  Thank you, Matthias.
—
Scott

> On Mar 25, 2021, at 1:13 PM, matthias rebbe via use-livecode 
>  wrote:
> 
> Scott,
> 
> do you want to get the filename of the script that is executing?
> Then
>   put the filename of me
> 
> returns the name of the lc script file including the complete path
> e.g./home//public_html//scott/pagename.lc
> 
> 
> 
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
> 
>> Am 25.03.2021 um 21:01 schrieb scott--- via use-livecode 
>> :
>> 
>> is there a way to determine the file name of that .lc web page (using 
>> livecode scripting)?
> 
> ___
> 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

> On Mar 25, 2021, at 1:13 PM, matthias rebbe via use-livecode 
>  wrote:
> 
> Scott,
> 
> do you want to get the filename of the script that is executing?
> Then
>   put the filename of me
> 
> returns the name of the lc script file including the complete path
> e.g./home//public_html//scott/pagename.lc
> 
> 
> 
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
> 
>> Am 25.03.2021 um 21:01 schrieb scott--- via use-livecode 
>> :
>> 
>> is there a way to determine the file name of that .lc web page (using 
>> livecode scripting)?
> 
> ___
> 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: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

Thanks you Lagi, Tore and others.

Looks like this is specific to Mac OS Big Sur.

I have submitted a bug report:

https://quality.livecode.com/show_bug.cgi?id=23139 


Henry

> On Mar 25, 2021, at 4:11 PM, Lagi Pittas via use-livecode 
>  wrote:
> 
> HI Henry,
> 
> Tried it on windows LC 9.6.2 RC2 and it works fine.
> 
> I still have the problem of very laggy text editor  for a machine with 16G
> of Ram and SSD,
> 
>  there is no scrolling problem on a greater than 5000 line script
> 
> so it looks like it's  big Turd this time ;-)
> 
> Lagi
> 
> On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On further investigation this appears to be a problem with any LC
>> scrolling text field, not just the Script Editor.
>> 
>> Please try the following and let me know what you observe:
>> 
>> 1. Create a new stack (e.g. 1024 x 768)
>> 
>> 2. Add a scrolling text field and resize the field to fill the card.
>> 
>> 3. Paste enough text (multiple pastes of the same text will do) into the
>> field so that the vertical scroll bar is activated.
>> 
>> 4. Place in run mode. Click before the first text character in the field
>> 
>> 5. Drag-Select text downwards (hold mouse button down while dragging down
>> over text) towards the bottom of the field until the field begins to
>> auto-scroll
>> 
>> 6. Let go of the mouse - the field continues to autoscroll until it
>> reaches the end of the text
>> 
>> 7. LC is unresponsive during this automatic scrolling
>> 
>> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
>> 
>> 9. This continues for 1-2 minutes then LC unfreezes.
>> 
>> In a large script I am “locked out” of LC for 10-15 mins as the field
>> autoscrolls down.
>> 
>> This may be Mac Big Sur specific, so hopefully someone can test it on that
>> platform.
>> 
>> Looks like a bug to me.
>> 
>> Henry
>> 
>>> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> RichardG,
>>> That was a very long way of not answering the question. Very insightful
>>> regarding the DG though. :)
>>> It also went a long way of assuming the skill levels of the audience.
>> Some
>>> of us are not limited to xTalk level. I understand C++ and why Trevor
>>> likely coded the DG using such.
>>> 
>>> My question, just to reestablish, was what on Earth could possibly
>>> complicate the scrolling of the line-numbers in sync with the main
>> 'field'?
>>> Very occasionally the numbers freeze altogether until a click in the
>> editor
>>> which is an interesting aside and only partly related to the question. I
>>> never notice a lag between the two areas. 32-bit I feel is neither here
>> nor
>>> there in relation to the syncing or imperceivable lag, especially for the
>>> SE.
>>> 
>>> Looking on github reveals that the majority of the code for the SE are
>>> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
>> mostly,
>>> rather than CPP. And, as suspected, really quite simple and unconvoluted
>> as
>>> they can get. Barely anything to become difficult in fixing for Henry's
>>> listed issue. revsecommoneditorbehavior.livecodescript holds the key,
>> lines
>>> 2658-2721 most likely.
>>> 
>>> Sean
>>> 
>>> 
>>> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 Sean Cole wrote:
 
> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
> 
>> I believe it may be related to the complicated way the line
>> number field is kept in sync.
> 
> Quick question. Why would the line number field be complicated? I
> can’t imagine anything that would necessitate making it complicated.
> Numbers and break points. That’s all it handles, right?
 
 
 It's easy to describe anything in terms that make it sound simple, but
 whether a task is *actually* simple depends on many things.
 
 It's equally an oversimplification to arbitrarily divide the world into
 two types of programmers, xTalkers and C coders, but that won't stop me
 from indulging in it here :
 
 
 If we look at text editors made by C coders, they generally only render
 the line numbers visible on screen given the current scroll position.
 But they do everything with lower-level/computer-oriented thinking, with
 lineto and moveto and stringAt (yes, the Inside Macintosh references
 there show my age, but you know what I mean), so for them these types of
 calculations are second-nature and not considered tedious at all, it's
 just how things are done.
 
 xTalkers, by virtue of choosing a language that is not only high-level
 but among the very few that directly incorporate GUI controls as
 inherent language elements, think differently. To us we put text into a
 field and set the scroll as we like and let the engine figure out the

Re: [ANN] This Week in LiveCode 259

[james--- via use-livecode]

I went for a bike ride this morning.

Just thought I would add a post under this subject that is no longer really 
related to the subject anymore.

Didn’t want to feel left out ;-)

James

___
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: Problem with Script Editor in LC 9.6.2 (rc3)

[Lagi Pittas via use-livecode]

HI Henry,

Tried it on windows LC 9.6.2 RC2 and it works fine.

I still have the problem of very laggy text editor  for a machine with 16G
of Ram and SSD,

  there is no scrolling problem on a greater than 5000 line script

so it looks like it's  big Turd this time ;-)

Lagi

On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On further investigation this appears to be a problem with any LC
> scrolling text field, not just the Script Editor.
>
> Please try the following and let me know what you observe:
>
> 1. Create a new stack (e.g. 1024 x 768)
>
> 2. Add a scrolling text field and resize the field to fill the card.
>
> 3. Paste enough text (multiple pastes of the same text will do) into the
> field so that the vertical scroll bar is activated.
>
> 4. Place in run mode. Click before the first text character in the field
>
> 5. Drag-Select text downwards (hold mouse button down while dragging down
> over text) towards the bottom of the field until the field begins to
> auto-scroll
>
> 6. Let go of the mouse - the field continues to autoscroll until it
> reaches the end of the text
>
> 7. LC is unresponsive during this automatic scrolling
>
> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
>
> 9. This continues for 1-2 minutes then LC unfreezes.
>
> In a large script I am “locked out” of LC for 10-15 mins as the field
> autoscrolls down.
>
> This may be Mac Big Sur specific, so hopefully someone can test it on that
> platform.
>
> Looks like a bug to me.
>
> Henry
>
> > On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > RichardG,
> > That was a very long way of not answering the question. Very insightful
> > regarding the DG though. :)
> > It also went a long way of assuming the skill levels of the audience.
> Some
> > of us are not limited to xTalk level. I understand C++ and why Trevor
> > likely coded the DG using such.
> >
> > My question, just to reestablish, was what on Earth could possibly
> > complicate the scrolling of the line-numbers in sync with the main
> 'field'?
> > Very occasionally the numbers freeze altogether until a click in the
> editor
> > which is an interesting aside and only partly related to the question. I
> > never notice a lag between the two areas. 32-bit I feel is neither here
> nor
> > there in relation to the syncing or imperceivable lag, especially for the
> > SE.
> >
> > Looking on github reveals that the majority of the code for the SE are
> > indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
> mostly,
> > rather than CPP. And, as suspected, really quite simple and unconvoluted
> as
> > they can get. Barely anything to become difficult in fixing for Henry's
> > listed issue. revsecommoneditorbehavior.livecodescript holds the key,
> lines
> > 2658-2721 most likely.
> >
> > Sean
> >
> >
> > On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Sean Cole wrote:
> >>
> >>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
> >>>
>  I believe it may be related to the complicated way the line
>  number field is kept in sync.
> >>>
> >>> Quick question. Why would the line number field be complicated? I
> >>> can’t imagine anything that would necessitate making it complicated.
> >>> Numbers and break points. That’s all it handles, right?
> >>
> >>
> >> It's easy to describe anything in terms that make it sound simple, but
> >> whether a task is *actually* simple depends on many things.
> >>
> >> It's equally an oversimplification to arbitrarily divide the world into
> >> two types of programmers, xTalkers and C coders, but that won't stop me
> >> from indulging in it here :
> >>
> >>
> >> If we look at text editors made by C coders, they generally only render
> >> the line numbers visible on screen given the current scroll position.
> >> But they do everything with lower-level/computer-oriented thinking, with
> >> lineto and moveto and stringAt (yes, the Inside Macintosh references
> >> there show my age, but you know what I mean), so for them these types of
> >> calculations are second-nature and not considered tedious at all, it's
> >> just how things are done.
> >>
> >> xTalkers, by virtue of choosing a language that is not only high-level
> >> but among the very few that directly incorporate GUI controls as
> >> inherent language elements, think differently. To us we put text into a
> >> field and set the scroll as we like and let the engine figure out the
> >> details.
> >>
> >>
> >> Which is "best" is a topic that can be hotly debated, and was here on
> >> this list several years ago in a thread on making text editors in LC.
> >>
> >> One of the participants in that thread was Jeff Massung, who'd made a
> >> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
> >> the engine to render thousands of lines of line numbers if the script
> 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Tore Nilsen via use-livecode]

I have followed your recipe and I can confirm that this is a problem also with 
ordinary scrolling fields in LC 9.6.2 (rc3). It does not seem to be a problem 
in LC 9.6.2 (rc1).

Best regards
Tore Nilsen

> 25. mar. 2021 kl. 22:07 skrev HENRY LOWE via use-livecode 
> :
> 
> On further investigation this appears to be a problem with any LC scrolling 
> text field, not just the Script Editor.
> 
> Please try the following and let me know what you observe:
> 
> 1. Create a new stack (e.g. 1024 x 768)
> 
> 2. Add a scrolling text field and resize the field to fill the card.
> 
> 3. Paste enough text (multiple pastes of the same text will do) into the 
> field so that the vertical scroll bar is activated.
> 
> 4. Place in run mode. Click before the first text character in the field
> 
> 5. Drag-Select text downwards (hold mouse button down while dragging down 
> over text) towards the bottom of the field until the field begins to 
> auto-scroll
> 
> 6. Let go of the mouse - the field continues to autoscroll until it reaches 
> the end of the text
> 
> 7. LC is unresponsive during this automatic scrolling
> 
> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
> 
> 9. This continues for 1-2 minutes then LC unfreezes.
> 
> In a large script I am “locked out” of LC for 10-15 mins as the field 
> autoscrolls down.
> 
> This may be Mac Big Sur specific, so hopefully someone can test it on that 
> platform.
> 
> Looks like a bug to me.
> 
> Henry
> 
>> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode 
>>  wrote:
>> 
>> RichardG,
>> That was a very long way of not answering the question. Very insightful
>> regarding the DG though. :)
>> It also went a long way of assuming the skill levels of the audience. Some
>> of us are not limited to xTalk level. I understand C++ and why Trevor
>> likely coded the DG using such.
>> 
>> My question, just to reestablish, was what on Earth could possibly
>> complicate the scrolling of the line-numbers in sync with the main 'field'?
>> Very occasionally the numbers freeze altogether until a click in the editor
>> which is an interesting aside and only partly related to the question. I
>> never notice a lag between the two areas. 32-bit I feel is neither here nor
>> there in relation to the syncing or imperceivable lag, especially for the
>> SE.
>> 
>> Looking on github reveals that the majority of the code for the SE are
>> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
>> rather than CPP. And, as suspected, really quite simple and unconvoluted as
>> they can get. Barely anything to become difficult in fixing for Henry's
>> listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
>> 2658-2721 most likely.
>> 
>> Sean
>> 
>> 
>> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Sean Cole wrote:
>>> 
 On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
 
> I believe it may be related to the complicated way the line
> number field is kept in sync.
 
 Quick question. Why would the line number field be complicated? I
 can’t imagine anything that would necessitate making it complicated.
 Numbers and break points. That’s all it handles, right?
>>> 
>>> 
>>> It's easy to describe anything in terms that make it sound simple, but
>>> whether a task is *actually* simple depends on many things.
>>> 
>>> It's equally an oversimplification to arbitrarily divide the world into
>>> two types of programmers, xTalkers and C coders, but that won't stop me
>>> from indulging in it here :
>>> 
>>> 
>>> If we look at text editors made by C coders, they generally only render
>>> the line numbers visible on screen given the current scroll position.
>>> But they do everything with lower-level/computer-oriented thinking, with
>>> lineto and moveto and stringAt (yes, the Inside Macintosh references
>>> there show my age, but you know what I mean), so for them these types of
>>> calculations are second-nature and not considered tedious at all, it's
>>> just how things are done.
>>> 
>>> xTalkers, by virtue of choosing a language that is not only high-level
>>> but among the very few that directly incorporate GUI controls as
>>> inherent language elements, think differently. To us we put text into a
>>> field and set the scroll as we like and let the engine figure out the
>>> details.
>>> 
>>> 
>>> Which is "best" is a topic that can be hotly debated, and was here on
>>> this list several years ago in a thread on making text editors in LC.
>>> 
>>> One of the participants in that thread was Jeff Massung, who'd made a
>>> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
>>> the engine to render thousands of lines of line numbers if the script
>>> being displayed was much shorter.  He felt that the "right" approach
>>> would be to do as C programmers do, to dynamically calculate which line
>>> numbers should be visible 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

On further investigation this appears to be a problem with any LC scrolling 
text field, not just the Script Editor.

Please try the following and let me know what you observe:

1. Create a new stack (e.g. 1024 x 768)

2. Add a scrolling text field and resize the field to fill the card.

3. Paste enough text (multiple pastes of the same text will do) into the field 
so that the vertical scroll bar is activated.

4. Place in run mode. Click before the first text character in the field

5. Drag-Select text downwards (hold mouse button down while dragging down over 
text) towards the bottom of the field until the field begins to auto-scroll

6. Let go of the mouse - the field continues to autoscroll until it reaches the 
end of the text

7. LC is unresponsive during this automatic scrolling

8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU

9. This continues for 1-2 minutes then LC unfreezes.

In a large script I am “locked out” of LC for 10-15 mins as the field 
autoscrolls down.

This may be Mac Big Sur specific, so hopefully someone can test it on that 
platform.

Looks like a bug to me.

Henry

> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> RichardG,
> That was a very long way of not answering the question. Very insightful
> regarding the DG though. :)
> It also went a long way of assuming the skill levels of the audience. Some
> of us are not limited to xTalk level. I understand C++ and why Trevor
> likely coded the DG using such.
> 
> My question, just to reestablish, was what on Earth could possibly
> complicate the scrolling of the line-numbers in sync with the main 'field'?
> Very occasionally the numbers freeze altogether until a click in the editor
> which is an interesting aside and only partly related to the question. I
> never notice a lag between the two areas. 32-bit I feel is neither here nor
> there in relation to the syncing or imperceivable lag, especially for the
> SE.
> 
> Looking on github reveals that the majority of the code for the SE are
> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
> rather than CPP. And, as suspected, really quite simple and unconvoluted as
> they can get. Barely anything to become difficult in fixing for Henry's
> listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
> 2658-2721 most likely.
> 
> Sean
> 
> 
> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Sean Cole wrote:
>> 
>>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>>> 
 I believe it may be related to the complicated way the line
 number field is kept in sync.
>>> 
>>> Quick question. Why would the line number field be complicated? I
>>> can’t imagine anything that would necessitate making it complicated.
>>> Numbers and break points. That’s all it handles, right?
>> 
>> 
>> It's easy to describe anything in terms that make it sound simple, but
>> whether a task is *actually* simple depends on many things.
>> 
>> It's equally an oversimplification to arbitrarily divide the world into
>> two types of programmers, xTalkers and C coders, but that won't stop me
>> from indulging in it here :
>> 
>> 
>> If we look at text editors made by C coders, they generally only render
>> the line numbers visible on screen given the current scroll position.
>> But they do everything with lower-level/computer-oriented thinking, with
>> lineto and moveto and stringAt (yes, the Inside Macintosh references
>> there show my age, but you know what I mean), so for them these types of
>> calculations are second-nature and not considered tedious at all, it's
>> just how things are done.
>> 
>> xTalkers, by virtue of choosing a language that is not only high-level
>> but among the very few that directly incorporate GUI controls as
>> inherent language elements, think differently. To us we put text into a
>> field and set the scroll as we like and let the engine figure out the
>> details.
>> 
>> 
>> Which is "best" is a topic that can be hotly debated, and was here on
>> this list several years ago in a thread on making text editors in LC.
>> 
>> One of the participants in that thread was Jeff Massung, who'd made a
>> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
>> the engine to render thousands of lines of line numbers if the script
>> being displayed was much shorter.  He felt that the "right" approach
>> would be to do as C programmers do, to dynamically calculate which line
>> numbers should be visible and dynamically populate the line number list
>> with only those on each scrollBarDrag.
>> 
>> Others, including myself, felt that using xTalk objects as xTalkers are
>> accustomed to using them was not a mistake at all, but actually quite
>> with-the-grain for xTalk work. Even if we're asking the engine to work
>> harder, we're doing it only once up front, relying on the engine's good
>> buffering to make scrolling 

Re: name of web page

[matthias rebbe via use-livecode]

Scott,

do you want to get the filename of the script that is executing?
Then
put the filename of me

returns the name of the lc script file including the complete path
e.g./home//public_html//scott/pagename.lc



-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 25.03.2021 um 21:01 schrieb scott--- via use-livecode 
> :
> 
> is there a way to determine the file name of that .lc web page (using 
> livecode scripting)?

___
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: Android commissions (JeeJeeStudio)

[JeeJeeStudio via use-livecode]

Thank you.

Done!

Op 20-3-2021 om 04:46 schreef Andrew at MidWest Coast Media via 
use-livecode:

Note that this can take a long while, perhaps a very long while

I’m just excited to increase my earning potential by 15% in 6 months at the 2 
app stores, all by doing absolutely nothing myself (thanks Epic Games for 
scaring big tech!).

After having a paid app in the stores for a few years I just released my first 
mobile project with In-app purchases this month so I plan on nudging this along 
through Bugzilla. Feel free to add yourself as a CC to the bug!
[shameless plug]
https://quality.livecode.com/show_bug.cgi?id=23116 


—Andrew Bell
___
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

name of web page

[scott--- via use-livecode]

When using livecode server scripting inside the html of a web page, is there a 
way to determine the file name of that .lc web page (using livecode scripting)?
--
Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth1-360-734-4701
--








___
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: [ANN] This Week in LiveCode 259

[matthias rebbe via use-livecode]

Jacque,
if you use ftps:// and enable use_ssl then the mode is 'FTP over SSL implicit'. 
If your FTP Server does not support this mode, then you get an error. So it 
seems your server does only support FTPS explicit and not implicit
FTPS implicit is not very common. Most shared hosts support ftp/sftp and ftps 
explicit. 

Maybe you missed my comment yesterday. tsNet decides which FTP mode is used 
just by the url prefix. There is no need to change any port. This is 
automatically handled by tsNET

URL prefixuse_sslMode 
ftp://   false  FTP
ftp://.  true  FTPeS (ftp over SSL 
explicit) sometimes also called FTPS explicit
ftps:// true   FTPS (ftp over SSL 
implicit) FTPS implicit




-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 25.03.2021 um 20:22 schrieb J. Landman Gay via use-livecode 
> :
> 
> On 3/25/21 12:52 PM, J. Landman Gay via use-livecode wrote:
>> If I continue to use only "ftp" and "use_ssl" then it works but I am not 
>> sure whether the connection is actually encrypted or not.
> 
> Just to complete this little journey, I think I'm in business. I use "ftp" in 
> the URL which defaults to port 21, and tsnet "use_ssl". The server response 
> says: AUTH TLS OK. It also says an unidentified security scheme is not 
> implemented but then goes ahead and uses SSL anyway. This is what came back:
> 
> Transfer complete with server response code 226
> 220-- Welcome to Pure-FTPd [privsep] [TLS] --
> 220-You are user number 5 of 50 allowed.
> 220-Local time is now 14:57. Server port: 21.
> 220-This is a private system - No anonymous login
> 220-IPv6 connections are also welcome on this server.
> 220 You will be disconnected after 15 minutes of inactivity.
> 500 This security scheme is not implemented
> 234 AUTH TLS OK.
> 331 User  OK. Password required
> 230 OK. Current restricted directory is /
> 200 PBSZ=0
> 200 Data protection level set to "private"
> 257 "/" is your current location
> 250 OK. Current directory is /public_html
> 250 OK. Current directory is /public_html/
> 250 OK. Current directory is /public_html//
> 229 Extended Passive mode OK (|||44775|)
> 200 TYPE is now 8-bit binary
> 150 Accepted data connection
> 226-File successfully transferred
> 226 0.140 seconds (measured here), 345.46 Kbytes per second
> 
> So my little upload tool, inspired by Andre's book, is now working and will 
> save me maybe 5 seconds and three clicks about once a month. :) But there is 
> some satisfaction in that.
> 
> As for using AppleScript, Fetch has removed AppleScript support in its latest 
> release. The docs say it hopes to bring it back in the future. I suspect 
> conflicts with Big Sur or something similar. But that's why I wasn't 
> "authorized."
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: [ANN] This Week in LiveCode 259

[J. Landman Gay via use-livecode]

On 3/25/21 12:52 PM, J. Landman Gay via use-livecode wrote:
If I continue to use only "ftp" and "use_ssl" then it works but I am not sure whether the 
connection is actually encrypted or not.


Just to complete this little journey, I think I'm in business. I use "ftp" in the URL which 
defaults to port 21, and tsnet "use_ssl". The server response says: AUTH TLS OK. It also says 
an unidentified security scheme is not implemented but then goes ahead and uses SSL anyway. 
This is what came back:


Transfer complete with server response code 226
220-- Welcome to Pure-FTPd [privsep] [TLS] --
220-You are user number 5 of 50 allowed.
220-Local time is now 14:57. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
500 This security scheme is not implemented
234 AUTH TLS OK.
331 User  OK. Password required
230 OK. Current restricted directory is /
200 PBSZ=0
200 Data protection level set to "private"
257 "/" is your current location
250 OK. Current directory is /public_html
250 OK. Current directory is /public_html/
250 OK. Current directory is /public_html//
229 Extended Passive mode OK (|||44775|)
200 TYPE is now 8-bit binary
150 Accepted data connection
226-File successfully transferred
226 0.140 seconds (measured here), 345.46 Kbytes per second

So my little upload tool, inspired by Andre's book, is now working and will save me maybe 5 
seconds and three clicks about once a month. :) But there is some satisfaction in that.


As for using AppleScript, Fetch has removed AppleScript support in its latest release. The docs 
say it hopes to bring it back in the future. I suspect conflicts with Big Sur or something 
similar. But that's why I wasn't "authorized."


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> RichardG,

Feel free to use simply "Richard" if you like.


> That was a very long way of not answering the question. Very
> insightful regarding the DG though. :)
> It also went a long way of assuming the skill levels of the audience.
> Some of us are not limited to xTalk level.

Where I wrote that it's "an oversimplification to arbitrarily divide the 
world into two types of programmers, xTalkers and C coders", what I 
meant to say is that it's an oversimplification to arbitrarily divide 
the world into two types of programmers, xTalkers and C coders.


Sorry I was unable to make that clearer.


> I understand C++ and why Trevor likely coded the DG using such.

My writing was even worse than I'd thought. Having once hired Trevor to 
write some C++ for a project many years ago, I'm well aware of the 
breadth of his skillset.


What I had attempted to illustrate there had nothing to do with coding 
styles, but with a merely pragmatic tradeoff necessary for certain uses 
of LC group objects.




> My question, just to reestablish, was what on Earth could possibly
> complicate the scrolling of the line-numbers in sync with the main
> 'field'?

Gave it my best shot.

TL/DL:

1. I don't specifically know what the LC SE is doing there.

2. I don't generally believe it makes sense to describe anything as 
simple until we take the time, however much patience that requires, to 
understand the goals of the design.




> Very occasionally the numbers freeze altogether until a click in
> the editor which is an interesting aside and only partly related
> to the question. I never notice a lag between the two areas.

That lag you just described awaiting the click?  That. That's one of the 
observable lags I'm referring to.




> 32-bit I feel is neither here nor there in relation to the syncing
> or imperceivable lag, especially for the SE.

Agreed, which is why I wrote "the 32-bit coordinate space only applies 
to controls, not the contents within text fields".


Coordinate space was only relevant in exploring why the DG uses dynamic 
scroll updates, contrasting the DGs architectural decisions with those 
used to populate line number fields, where such a choice is not 
necessary but may reflect styles of habit.



> Looking on github reveals that the majority of the code for the SE are
> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
> mostly, rather than CPP. And, as suspected, really quite simple and
> unconvoluted as they can get. Barely anything to become difficult in
> fixing for Henry's listed issue.
> revsecommoneditorbehavior.livecodescript holds the key, lines
> 2658-2721 most likely.

Looks like you've found your answer.

--
Richard Gaskin
Fourth World Systems


___
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: Set and get dgData and dgText delay

[Sean Cole (Pi) via use-livecode]

Thanks Bob, but the columns are defined, both in my test stack and the
project stack. It gets filled once the scripts have finished running, so it
can't be that which is the issue in this instance. But thanks once again
for your input.

Sean

On Thu, 25 Mar 2021 at 17:55, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> DGText will only contain data for the columns you have defined in the
> Datagrid properties. If your dgData array keys have no matching columns it
> will still populate the dgData but dgText will return empty. This is why I
> avoid using dgText at all anymore.
>
> I have also noticed that if one of the row arrays in the dgData is empty
> then that can bork the data grid. You have to set the dgData to empty to
> get rid of it.
>
> Bob S
>
>
> On Mar 25, 2021, at 5:44 AM, Craig Newman via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
>
> I have seen this here and there for years, and having nothing to do with
> dataGrids per se.
>
> A handler will fail to run, but will step through in the debugger without
> issue. This usually resolves, and I never know why.
>
> Craig
>
> ___
> 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: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

RichardG,
That was a very long way of not answering the question. Very insightful
regarding the DG though. :)
It also went a long way of assuming the skill levels of the audience. Some
of us are not limited to xTalk level. I understand C++ and why Trevor
likely coded the DG using such.

My question, just to reestablish, was what on Earth could possibly
complicate the scrolling of the line-numbers in sync with the main 'field'?
Very occasionally the numbers freeze altogether until a click in the editor
which is an interesting aside and only partly related to the question. I
never notice a lag between the two areas. 32-bit I feel is neither here nor
there in relation to the syncing or imperceivable lag, especially for the
SE.

Looking on github reveals that the majority of the code for the SE are
indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
rather than CPP. And, as suspected, really quite simple and unconvoluted as
they can get. Barely anything to become difficult in fixing for Henry's
listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
2658-2721 most likely.

Sean


On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sean Cole wrote:
>
>  > On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>  >
>  >>  I believe it may be related to the complicated way the line
>  >> number field is kept in sync.
>  >
>  > Quick question. Why would the line number field be complicated? I
>  > can’t imagine anything that would necessitate making it complicated.
>  > Numbers and break points. That’s all it handles, right?
>
>
> It's easy to describe anything in terms that make it sound simple, but
> whether a task is *actually* simple depends on many things.
>
> It's equally an oversimplification to arbitrarily divide the world into
> two types of programmers, xTalkers and C coders, but that won't stop me
> from indulging in it here :
>
>
> If we look at text editors made by C coders, they generally only render
> the line numbers visible on screen given the current scroll position.
> But they do everything with lower-level/computer-oriented thinking, with
> lineto and moveto and stringAt (yes, the Inside Macintosh references
> there show my age, but you know what I mean), so for them these types of
> calculations are second-nature and not considered tedious at all, it's
> just how things are done.
>
> xTalkers, by virtue of choosing a language that is not only high-level
> but among the very few that directly incorporate GUI controls as
> inherent language elements, think differently. To us we put text into a
> field and set the scroll as we like and let the engine figure out the
> details.
>
>
> Which is "best" is a topic that can be hotly debated, and was here on
> this list several years ago in a thread on making text editors in LC.
>
> One of the participants in that thread was Jeff Massung, who'd made a
> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
> the engine to render thousands of lines of line numbers if the script
> being displayed was much shorter.  He felt that the "right" approach
> would be to do as C programmers do, to dynamically calculate which line
> numbers should be visible and dynamically populate the line number list
> with only those on each scrollBarDrag.
>
> Others, including myself, felt that using xTalk objects as xTalkers are
> accustomed to using them was not a mistake at all, but actually quite
> with-the-grain for xTalk work. Even if we're asking the engine to work
> harder, we're doing it only once up front, relying on the engine's good
> buffering to make scrolling throughout the rest of the session simpler.
>
>
> It's worth noting that the excellent DataGrid relies on
> dynamically-calculated scrolling, but even more worthy to note WHY:
>
> It's not because scrolling the DG is made any faster (observably it isn't).
>
> It's because the performance impact of dynamically-calculated scrolling
> is a NECESSARY tradeoff to cover the sometimes-large number of records
> it's asked to display.  LC uses 32-bit coordinate addressing, which is
> more than adequate for most things we render since it gives us about 30
> feet of drawing space, far bigger than any monitor. But if you try to
> place tens of thousands of groups nested within a scrolling group,
> you'll quickly discover what happens when you exceed 32-bit coordinate
> space. :)
>
> So Trevor did the tedious work of providing a profoundly flexible
> DataGrid, where for the relatively low cost of a modest performance hit
> during scrolls we can effortlessly display even vast numbers of records,
> by only actually rendering those on screen at any given time.
>
> But the 32-bit coordinate space only applies to controls, not the
> contents within text fields, so
>
>
> Back to the LC Script Editor, truth be told it's been so long since I
> donned my pith helmet to dive into its code jungle that I'm not in a
> 

Re: [ANN] This Week in LiveCode 259

[J. Landman Gay via use-livecode]

On 3/25/21 7:19 AM, Andre Garzia via use-livecode wrote:

Not accepting AppleScript from other apps basically defeats the reason to use 
AppleScript IMHO… those devs are crazy.


I reported the wrong error message. I tried it again and it said "You are unauthorized to use 
AppleScript." There must be something I need to set up.


What I was trying to do when ftp failed was use a nice one-liner:
launch  with . The built-in LC command uses AppleScript 
on Mac OS and that's when I got the error.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Set and get dgData and dgText delay

[Bob Sneidar via use-livecode]

DGText will only contain data for the columns you have defined in the Datagrid 
properties. If your dgData array keys have no matching columns it will still 
populate the dgData but dgText will return empty. This is why I avoid using 
dgText at all anymore.

I have also noticed that if one of the row arrays in the dgData is empty then 
that can bork the data grid. You have to set the dgData to empty to get rid of 
it.

Bob S


On Mar 25, 2021, at 5:44 AM, Craig Newman via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I have seen this here and there for years, and having nothing to do with 
dataGrids per se.

A handler will fail to run, but will step through in the debugger without 
issue. This usually resolves, and I never know why.

Craig

___
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: [ANN] This Week in LiveCode 259

[J. Landman Gay via use-livecode]

On 3/24/21 5:44 PM, matthias rebbe via use-livecode wrote:

It seems Fetch usesftps://  for both  FTPeS (FTP over SSL explicit)  and FTPS 
(FTP over SSL implicit). But it depends on the port number you have entered.
If you keep port 21 then FTPS (FTP over SSL implicit) is used.
If you set the port to 990 then Fetch uses FTPS (FTP over SSL implicit).


I tried setting the URL to "ftps" and got "tsneterr: (7) Failed to connect to hyperactivesw.com 
port 990: Operation timed out." So I removed "use_ssl" from the login array but still got the 
same error. Apparently TSNet uses port 990 if the URL is "ftps".


If I continue to use only "ftp" and "use_ssl" then it works but I am not sure whether the 
connection is actually encrypted or not.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:
>> On 25 Mar 2021, at 14:58, Richard Gaskin wrote:
>>
>> Defaulting to HTTP for customer-facing systems simplifies a
>> lot of decision-making, and since most of the rest of the
>> world makes the same choice at least we're in good company. :)
>
> Also, HTTP/HTTPS are usually enabled on firewalls, makes your
> life a lot easier when you don’t need to tell your user that
> they need to fiddle with firewall rules.

Ah yes, I remember the good ol' days when Internet P2P seemed promising, 
shut down once everyone began reconsider the implications of expanding 
the attack surface with open ports...


--
Richard Gaskin
Fourth World Systems


___
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: [ANN] This Week in LiveCode 259

[Andre Garzia via use-livecode]

> On 25 Mar 2021, at 14:58, Richard Gaskin via use-livecode 
>  wrote:
> 
> Defaulting to HTTP for customer-facing systems simplifies a lot of 
> decision-making, and since most of the rest of the world makes the same 
> choice at least we're in good company. :)

Also, HTTP/HTTPS are usually enabled on firewalls, makes your life a lot easier 
when you don’t need to tell your user that they need to fiddle with firewall 
rules.
___
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: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>
>>  I believe it may be related to the complicated way the line
>> number field is kept in sync.
>
> Quick question. Why would the line number field be complicated? I
> can’t imagine anything that would necessitate making it complicated.
> Numbers and break points. That’s all it handles, right?


It's easy to describe anything in terms that make it sound simple, but 
whether a task is *actually* simple depends on many things.


It's equally an oversimplification to arbitrarily divide the world into 
two types of programmers, xTalkers and C coders, but that won't stop me 
from indulging in it here :



If we look at text editors made by C coders, they generally only render 
the line numbers visible on screen given the current scroll position. 
But they do everything with lower-level/computer-oriented thinking, with 
lineto and moveto and stringAt (yes, the Inside Macintosh references 
there show my age, but you know what I mean), so for them these types of 
calculations are second-nature and not considered tedious at all, it's 
just how things are done.


xTalkers, by virtue of choosing a language that is not only high-level 
but among the very few that directly incorporate GUI controls as 
inherent language elements, think differently. To us we put text into a 
field and set the scroll as we like and let the engine figure out the 
details.



Which is "best" is a topic that can be hotly debated, and was here on 
this list several years ago in a thread on making text editors in LC.


One of the participants in that thread was Jeff Massung, who'd made a 
very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask 
the engine to render thousands of lines of line numbers if the script 
being displayed was much shorter.  He felt that the "right" approach 
would be to do as C programmers do, to dynamically calculate which line 
numbers should be visible and dynamically populate the line number list 
with only those on each scrollBarDrag.


Others, including myself, felt that using xTalk objects as xTalkers are 
accustomed to using them was not a mistake at all, but actually quite 
with-the-grain for xTalk work. Even if we're asking the engine to work 
harder, we're doing it only once up front, relying on the engine's good 
buffering to make scrolling throughout the rest of the session simpler.



It's worth noting that the excellent DataGrid relies on 
dynamically-calculated scrolling, but even more worthy to note WHY:


It's not because scrolling the DG is made any faster (observably it isn't).

It's because the performance impact of dynamically-calculated scrolling 
is a NECESSARY tradeoff to cover the sometimes-large number of records 
it's asked to display.  LC uses 32-bit coordinate addressing, which is 
more than adequate for most things we render since it gives us about 30 
feet of drawing space, far bigger than any monitor. But if you try to 
place tens of thousands of groups nested within a scrolling group, 
you'll quickly discover what happens when you exceed 32-bit coordinate 
space. :)


So Trevor did the tedious work of providing a profoundly flexible 
DataGrid, where for the relatively low cost of a modest performance hit 
during scrolls we can effortlessly display even vast numbers of records, 
by only actually rendering those on screen at any given time.


But the 32-bit coordinate space only applies to controls, not the 
contents within text fields, so



Back to the LC Script Editor, truth be told it's been so long since I 
donned my pith helmet to dive into its code jungle that I'm not in a 
position to speak authoritatively on how it's constructed.


But we can observe (sadly, without much effort) a lag between scrolling 
the script field and the subsequent update of the line number list.  In 
some cases, depending on platform and script length, this lag is more 
easily seen than on others.


This suggests that there's a lot more going on with the SE's line number 
update than just setting its scroll to match the editor field's.


Indeed, given the variance of the lag it would seem it's not updated 
directly at all, but perhaps via "send".



It wouldn't be appropriate to say the LC implementation is necessarily 
"wrong" or even "bad".  It's a deeply complicated layout with a lot of 
updates to manage, and given the vast scope of its design ambitions it's 
hard to say what one "should" do there.


But it is safe to observe that it was written by people who cut their 
teeth on languages more lower-level than xTalk. Aside from Monte and 
Kevin, I don't know of anyone there who shipped a product using an xTalk 
before being hired to make an xTalk.


Obviously, that's exactly what we want in an engine team, C++ engineers 
who live and breathe deep computer science.


But from time to time it does lend itself toward designs and 
implementations that look like the work of native C coders rather than 
native 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

I have definitely experienced this in Windows, not Mac. But I had assumed
it was an anomaly from running it in Parallels. I’ve had it for a number of
versions back now. It only happens occasionally and, as you say, only for
large scripts where it has the most impact. I tend to walk away, make a
coffee, come back and it will have stopped and I can scroll using a
different method. The scroll wheel works ok. It’s mostly noticeable when
clicking the scroll area (not the bar itself) to page jump or using the
line up/down buttons.

I hope this helps in your reporting.

Sean

On Wed, 24 Mar 2021 at 22:34, HENRY LOWE via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Matthias. I am not using any 3rd party text tools or plug-ins.
>
> If anyone else can confirm this issue I will submit a bug report.
>
> Henry

-- 
Pi Digital
___
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: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

Quick question. Why would the line number field be complicated? I can’t
imagine anything that would necessitate making it complicated. Numbers and
break points. That’s all it handles, right?

On Wed, 24 Mar 2021 at 21:45, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>  I believe it may be related to
> the complicated way the line number field is kept in sync.
>
-- 
Pi Digital
___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> On 24 Mar 2021, at 23:50, Richard Gaskin wrote:
>>
>> And with Windows 10, Microsoft is now embracing Linux in its Windows
>> Subsystem for Linux, so Win folk can enjoy industry standard tooling
>> on all OSes:
...
> If you have control of the Windows machine, then you can set it up to
> run as you want, but if you’re shipping software for end-users, you
> can’t assume WSL Ubuntu is there so you can run rsync.
>
> I know you didn’t say that but often I see scripts in other
> communities that assume a ton of stuff (even on macOS where
> many scripts assume homebrew is present).

True, I didn't say that. What I said was:

In this discussion of personal plugins run on macOS,
a macOS solution seemed appropriate.

We often see AppleScript presented on this list, as it was in this 
discussion as well.  But it's far less pervasive than bash: it's only 
available on macOS, with no option at all for using it anywhere else. 
And it's only well supported in an ever-smaller percentage of apps (not 
to mention slow, finicky, and hugely unpopular with the Steve Jobs/NeXT 
acolytes running much of Apple's tech divisions).


For most sysadmin tasks, these days Apple nudges us toward shell, with a 
large and growing number of bash examples in their dev docs.  macOS 
being a certified Unix, bash is a good choice for Apple to promote, and 
for developers and sysadmins to use.



Of course for any customer-facing solution we'll want to be mindful of 
dependencies.


But since everyone here is a developer, and this discussion is about 
developers making tools for themselves, appreciating the full scope of 
options available to us doesn't seem a mistake.


Modern macOS development increasingly means being familiar with 
Terminal. Time spent there is not only necessary for many things, but as 
we learn how to integrate the shell with LiveCode the options for 
automation of both local and remote workflows becomes nearly as 
limitless as one's imagination.




As for Windows, Microsoft doesn't pour millions into building out 
subsystems on a whim. Their embrace of the Linux shell for developers is 
as much a part of their well-thought-out strategy as Nadella's embrace 
of open source.


Microsoft understands what we see in the work that comes our own desks: 
in the modern world, software development is usually client-server 
development, with half of most systems we deliver living in the cloud.


Microsoft IIS remains deeply entrenched within the enterprise, but most 
things customer-facing are Linux. Indeed, even on Microsoft's own Azure 
the most popular OS is Ubuntu.


Like Apple, Microsoft is actively encouraging devs to consider adopting 
bash as a prime choice for admin tasks.  It's where the tooling is, and 
on dev systems it's being made ever more available for today's 
interoperable workflows.


We don't have a truly universal admin language, but bash is as close as 
we get right now:  built into every Mac, native to every Linux server we 
work with, and with strong developer support by Microsoft.


--
Richard Gaskin
Fourth World Systems



___
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: Set and get dgData and dgText delay

[Sean Cole (Pi) via use-livecode]

I’ve tried using wait, wait with messages, wait until. No joy.

But in a separate test stack with the same data it works just fine having
them one after the other.

There is no sense to it NOT passing the text one line to the next.

I thought it might be because it was located in a preOpenCard script but
moving it into the openCard or even 0sec after the open card in another
handler made no difference.

The real issue here is that the same stack worked ok before so there is
something we have done that upset it. I’m just going to have to pick my way
through till I find what is preventing the Dg from carrying out its
function. In the background.

On Thu, 25 Mar 2021 at 14:45, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The difference between the working and non-working examples seems to be
> limited to the introduction of a delay in the working one, between
> setting the dgData array and later obtaining its text.
>
> Since the array form is what the DG uses internally, perhaps something
> during loading of that array or rendering the UI needs the "wait 0", and
> what you're seeing is a side effect of that internal need.
>
> Being scripted in LC, the DG code could be examined for "wait" or "send"
> to see what's up.
>
> But while the exploration may be fun it would likely be inconsequential,
> since given the general quality of Trevor's work the delay is probably
> not a mistake, but a necessity. That is, you'd learn WHY you need the
> delay, but you'd still need it.
>
> If you do go spelunking in the DG source please let us know what you find.
>
> But now that you've found the solution it may be just as well to use it
> and move on with what you're building.
>
> --
> Richard Gaskin
> Fourth World Systems
>
>
>
>
> Sean Cole wrote:
>
> > Thanks Craig
> >
> > This could make some sense. There are a lot of handlers to deal with. I
> > thought I was going a bit mad. I’m just going to have to pick my way
> > through.
> >
> > On Thu, 25 Mar 2021 at 12:44, Craig Newman via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> I have seen this here and there for years, and having nothing to do with
> >> dataGrids per se.
> >>
> >> A handler will fail to run, but will step through in the debugger
> without
> >> issue. This usually resolves, and I never know why.
> >>
> >> Craig
> >>
> >> > On Mar 24, 2021, at 5:09 PM, Pi Digital via use-livecode <
> >> use-livecode at lists.runrev.com> wrote:
> >> >
> >> > Hi All
> >> >
> >> > This has been a bit of a mind bender, mainly because in a test stack
> it
> >> works just fine, but...
> >> >
> >> > Has anyone ever had problems with something like this:
> >> >
> >> > on myHandle
> >> > — ...some code
> >> > Set the dgData of grp “myDG” to tDataA
> >> > Put the dgText of grp “myDG” into tDataS
> >> > — tDataS returns empty
> >> > — process tDataS...
> >> > end myHandle
> >> >
> >> > And this:
> >> >
> >> > on myHandle
> >> > — ...some code
> >> > Set the dgData of grp “myDG” to tDataA
> >> > dispatch “myHandlePt2”
> >> > end myHandle
> >> >
> >> > on myHandlePt2
> >> > Put the dgText of grp “myDG” into tDataS
> >> > — tDataS returns empty
> >> > — process tDataS...
> >> > end myHandlePt2
> >> >
> >> > However, this works:
> >> >
> >> > on myHandle
> >> > — ...some code
> >> > Set the dgData of grp “myDG” to tDataA
> >> > send “myHandlePt2” to me in 0 sec
> >> > end myHandle
> >> >
> >> > on myHandlePt2
> >> > Put the dgText of grp “myDG” into tDataS
> >> > — tDataS returns empty
> >> > — process tDataS...
> >> > end myHandlePt2
> >> >
> >> >
> >> > It seemingly doesn’t have anything to do with data length. I’ve tried
> >> forcing a refresh of the grid using dispatch refreshList to it but that
> >> makes no difference. Stepping through in the debugger allows it to work
> or
> >> setting a breakpoint, but does not when in full run. Both in standalone
> and
> >> ide.
> >> >
> >> > A one have any clues why this might not work sometimes?
> >> >
> >> > Thanks
> >> >
> >> > Sean Cole
> >> > Pi Digital
> >> > eMail Ts & Cs
>
>
> ___
> 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
>
-- 
Pi Digital
___
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: [ANN] This Week in LiveCode 259

[doc hawk via use-livecode]

andre amplified,
>Next time, I’m leaving them in.

Ahh.  The director’s cut . . .

:_)


___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> Devising your own binary file transfer protocol based purely on TCP
> sockets is a very tedious and error prone process that will get you
> no advantages unless you really have some special need that is not
> solved by any of the solutions that already exists.
>
> The easiest way to work around not being able to use FTP and friends,
> is with a simple HTTP server and a CGI on the server machine that has
> logic for receiving file uploads, then you simply use either libURL or
> TSNet to send the files.


When SuperCard introduced socket programming to the Mac xTalk world with 
its companion Marionette add-on, being young folk we got all excited 
about crafting custom protocols for every little thing we needed.


It was a good learning experience, and I came to appreciate the vast 
range of styles in writing clients for NNTP, Gnutella, and FTP, in 
addition to the random protocols I came up with on my own.


But the biggest lesson I learned is not to write custom protocols. :) 
It's a lot of work to get them working well, and far more work to make 
them secure and robust.


These days I rarely think about protocols at all, at least in 
customer-facing code. I've adopted using HTTP as the default solution 
for everything, unless I have a specific reason not to use it.


Most of what we need from a server is to submit a request and get a 
reply, and occasionally have some metadata along for the ride.  HTTP 
does that well, with very slim header requirements that are also vastly 
extensible, so metadata is as simple or rich as you need in the moment. 
 There's more documentation and tooling for HTTP than any other 
protocol, so it's easy to learn to use it well, and if another 
programming joins the team they can work with your code effortlessly.


Defaulting to HTTP for customer-facing systems simplifies a lot of 
decision-making, and since most of the rest of the world makes the same 
choice at least we're in good company. :)


--
Richard Gaskin
Fourth World Systems


___
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: Set and get dgData and dgText delay

[Richard Gaskin via use-livecode]

The difference between the working and non-working examples seems to be 
limited to the introduction of a delay in the working one, between 
setting the dgData array and later obtaining its text.


Since the array form is what the DG uses internally, perhaps something 
during loading of that array or rendering the UI needs the "wait 0", and 
what you're seeing is a side effect of that internal need.


Being scripted in LC, the DG code could be examined for "wait" or "send" 
to see what's up.


But while the exploration may be fun it would likely be inconsequential, 
since given the general quality of Trevor's work the delay is probably 
not a mistake, but a necessity. That is, you'd learn WHY you need the 
delay, but you'd still need it.


If you do go spelunking in the DG source please let us know what you find.

But now that you've found the solution it may be just as well to use it 
and move on with what you're building.


--
Richard Gaskin
Fourth World Systems




Sean Cole wrote:


Thanks Craig

This could make some sense. There are a lot of handlers to deal with. I
thought I was going a bit mad. I’m just going to have to pick my way
through.

On Thu, 25 Mar 2021 at 12:44, Craig Newman via use-livecode <
use-livecode at lists.runrev.com> wrote:


I have seen this here and there for years, and having nothing to do with
dataGrids per se.

A handler will fail to run, but will step through in the debugger without
issue. This usually resolves, and I never know why.

Craig

> On Mar 24, 2021, at 5:09 PM, Pi Digital via use-livecode <
use-livecode at lists.runrev.com> wrote:
>
> Hi All
>
> This has been a bit of a mind bender, mainly because in a test stack it
works just fine, but...
>
> Has anyone ever had problems with something like this:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandle
>
> And this:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> dispatch “myHandlePt2”
> end myHandle
>
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
>
> However, this works:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> send “myHandlePt2” to me in 0 sec
> end myHandle
>
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
>
>
> It seemingly doesn’t have anything to do with data length. I’ve tried
forcing a refresh of the grid using dispatch refreshList to it but that
makes no difference. Stepping through in the debugger allows it to work or
setting a breakpoint, but does not when in full run. Both in standalone and
ide.
>
> A one have any clues why this might not work sometimes?
>
> Thanks
>
> Sean Cole
> Pi Digital
> eMail Ts & Cs



___
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: Set and get dgData and dgText delay

[Sean Cole (Pi) via use-livecode]

Thanks Craig

This could make some sense. There are a lot of handlers to deal with. I
thought I was going a bit mad. I’m just going to have to pick my way
through.

On Thu, 25 Mar 2021 at 12:44, Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I have seen this here and there for years, and having nothing to do with
> dataGrids per se.
>
> A handler will fail to run, but will step through in the debugger without
> issue. This usually resolves, and I never know why.
>
> Craig
>
> > On Mar 24, 2021, at 5:09 PM, Pi Digital via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi All
> >
> > This has been a bit of a mind bender, mainly because in a test stack it
> works just fine, but...
> >
> > Has anyone ever had problems with something like this:
> >
> > on myHandle
> > — ...some code
> > Set the dgData of grp “myDG” to tDataA
> > Put the dgText of grp “myDG” into tDataS
> > — tDataS returns empty
> > — process tDataS...
> > end myHandle
> >
> > And this:
> >
> > on myHandle
> > — ...some code
> > Set the dgData of grp “myDG” to tDataA
> > dispatch “myHandlePt2”
> > end myHandle
> >
> > on myHandlePt2
> > Put the dgText of grp “myDG” into tDataS
> > — tDataS returns empty
> > — process tDataS...
> > end myHandlePt2
> >
> > However, this works:
> >
> > on myHandle
> > — ...some code
> > Set the dgData of grp “myDG” to tDataA
> > send “myHandlePt2” to me in 0 sec
> > end myHandle
> >
> > on myHandlePt2
> > Put the dgText of grp “myDG” into tDataS
> > — tDataS returns empty
> > — process tDataS...
> > end myHandlePt2
> >
> >
> > It seemingly doesn’t have anything to do with data length. I’ve tried
> forcing a refresh of the grid using dispatch refreshList to it but that
> makes no difference. Stepping through in the debugger allows it to work or
> setting a breakpoint, but does not when in full run. Both in standalone and
> ide.
> >
> > A one have any clues why this might not work sometimes?
> >
> > Thanks
> >
> > Sean Cole
> > Pi Digital
> > eMail Ts & Cs
> >
> > ___
> > 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
>
-- 
Pi Digital
___
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: Set and get dgData and dgText delay

[Craig Newman via use-livecode]

I have seen this here and there for years, and having nothing to do with 
dataGrids per se.

A handler will fail to run, but will step through in the debugger without 
issue. This usually resolves, and I never know why. 

Craig

> On Mar 24, 2021, at 5:09 PM, Pi Digital via use-livecode 
>  wrote:
> 
> Hi All
> 
> This has been a bit of a mind bender, mainly because in a test stack it works 
> just fine, but...
> 
> Has anyone ever had problems with something like this:
> 
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandle
> 
> And this:
> 
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> dispatch “myHandlePt2”
> end myHandle
> 
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
> 
> However, this works:
> 
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> send “myHandlePt2” to me in 0 sec
> end myHandle
> 
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
> 
> 
> It seemingly doesn’t have anything to do with data length. I’ve tried forcing 
> a refresh of the grid using dispatch refreshList to it but that makes no 
> difference. Stepping through in the debugger allows it to work or setting a 
> breakpoint, but does not when in full run. Both in standalone and ide. 
> 
> A one have any clues why this might not work sometimes?
> 
> Thanks
> 
> Sean Cole
> Pi Digital
> eMail Ts & Cs
> 
> ___
> 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: [ANN] This Week in LiveCode 259

[Andre Garzia via use-livecode]

> On 25 Mar 2021, at 01:14, Bob Sneidar via use-livecode 
>  wrote:
> 
> I suppose everything networking uses sockets, but these are protocols with 
> standardized ways of establishing the connection and securing it. I was 
> thinking of a custom client server file transfer method, but whether or not 
> it could work for Jacque, I don’t know.
> 
> Bob S

Devising your own binary file transfer protocol based purely on TCP sockets is 
a very tedious and error prone process that will get you no advantages unless 
you really have some special need that is not solved by any of the solutions 
that already exists.

The easiest way to work around not being able to use FTP and friends, is with a 
simple HTTP server and a CGI on the server machine that has logic for receiving 
file uploads, then you simply use either libURL or TSNet to send the files.
___
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: [ANN] This Week in LiveCode 259

[Andre Garzia via use-livecode]

> On 24 Mar 2021, at 23:50, Richard Gaskin via use-livecode 
>  wrote:
> 
> And with Windows 10, Microsoft is now embracing Linux in its Windows 
> Subsystem for Linux, so Win folk can enjoy industry standard tooling on all 
> OSes:

Just be aware that WSL is not activated by default, and you can’t assume which 
distro is installed (even though Ubuntu is probably 90% of the installs). There 
are shell commands you can use to probe if WSL is installed, which distros are 
installed, and also execute something on a specific installed distro.

All that is possible but it is not exactly trivial. Windows is quite flexible 
in a way that most systems are not. You might be running on Intel or ARM, you 
might be running 32bits or 64bits, you might be using cmd, powershell 5 or 7, 
bash, who knows what shell is running. Your distros under WSL might be WSL1 
(which is syscall translations) or WSL2 (which is hypervisor emulator). You 
kinda need to take those things into account if you’re running shell() commands 
or trying to bundle binaries.

If you have control of the Windows machine, then you can set it up to run as 
you want, but if you’re shipping software for end-users, you can’t assume WSL 
Ubuntu is there so you can run rsync.

I know you didn’t say that but often I see scripts in other communities that 
assume a ton of stuff (even on macOS where many scripts assume homebrew is 
present).
___
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: [ANN] This Week in LiveCode 259

[Andre Garzia via use-livecode]

> On 24 Mar 2021, at 19:12, J. Landman Gay via use-livecode 
>  wrote:
> 
> Andre: After TSNet failed, I did try to use AppleScript but Fetch put up a 
> dialog that it did not allow AppleScript sent from other apps. And BTW, next 
> time leave in the fun stuff. :)

Not accepting AppleScript from other apps basically defeats the reason to use 
AppleScript IMHO… those devs are crazy. Anyway, that sucks. I know that 
Transmit has a pretty comprehensive AppleScript dictionary as can be seen in:

https://andregarzia.com/img/shots/transmit-dictionary.png 


It is not a cheap software though, but I think it is worthy it.

Next time, I’m leaving the fun bits :-)
___
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: [ANN] This Week in LiveCode 259

[Andre Garzia via use-livecode]

> On 24 Mar 2021, at 17:11, Mark Wieder via use-livecode 
>  wrote:
> 
> I think there may be other questions in play as well.
> Will I learn anything from doing this?
> Will I have fun experimenting with it?
> Are there more pressing things I need to do instead?
> etc.

YES, a thousand times yes!

More than half of what I develop here falls into all these categories. I can 
push the “trying this just for fun” pretty far. The last project I made that 
was a fun experiment was 
https://andregarzia.com/2020/04/starting-project-moon-hermit.html 
 and I still 
love it even though it is not really a project or product.

The book is framed around a mindset for building stuff for business needs, not 
for personal growth and understanding, and not for fun. It is more like: “these 
patterns are good when you’re doing something that we would normally call ‘a 
job’.” That doesn’t mean that every other mode of development is excluded or 
less important. 

I think that the ethos of that book can be summarised as in being a mode of 
thinking that prioritises developer comfort and safety in maintaining a 
business or a long project.

Maybe, the next book will be about having fun while developing. Don’t know...
___
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