Re: Livecode SQLite

2022-08-11 Thread Mark Waddingham via use-livecode

On 2022-08-11 16:16, Tom Glod via use-livecode wrote:

I was interested in implementing a relatively new feature where you can
index and query json documents and read the keys directly.

https://dgl.cx/2020/06/sqlite-json-support

I guess, if this is true, is there any documentation about which 
features

of sqlite are implemented and which are not?


The version of SQLite is currently 3.34 built with FTS3, 
FTS3_PARANTHESIS, FTS4, FTS5, RTREE and JSON1 options.


So the JSON features (at least as far as those included in 3.34) should 
be included - perhaps the queries you are trying rely on features 
(perhaps not JSON related) included in more recent versions?


If you file a bug report with what examples of what isn't working, then 
we'll look into updating to the latest version of the library.


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: Tree Widget: hilitedValue?

2022-07-11 Thread Mark Waddingham via use-livecode

On 2022-07-10 21:33, Richard Gaskin via use-livecode wrote:

Brian Milby wrote:


You could also turn the path into an array (but lose the error
checking above):

function getValue pArray, pPath
  split pPath by comma
  return pArray[pPath]
end getValue


Thanks, Brian. I keep forgetting we can use an array as an element 
specifier.


Has that been around the whole time, or was it added in recent years?


I added it before 6.0 - probably in 4.5 or 5.

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


On API keys...

2022-06-24 Thread Mark Waddingham via use-livecode
So this is mainly aimed at Tom Glod due to a question he asked in this 
afternoon's Feature Focus session which I perhaps did not answer 
particularly well (and given that it is security related, I figured I 
should expand on what I said).


The question was whether putting an API Key as a LiveCode 'constant', 
rather than anything else, made it 'more secure' - the answer is 'no 
more than putting it anywhere else in a password protected script'.


However, what I should have probably expanded on is what my 
understanding on the best practice for API keys in general is...


I have come across three kinds of API key in practice:

  1) API keys intended to be used from web pages (in client-side code)

  2) API keys intended to be used in deployed apps

  3) API keys intended to be used for doing secure things

How I would advise using them (based on my current understanding, at 
least) is:


TYPE 1

In (1) above you have things like Google Analytics 'product ids' (which 
aren't strictly API keys I guess, but are similar enough to warrant 
inclusion) and Google Maps JS keys.


As these are intended to be used in client side JavaScript - there is 
very little, if anything, you can do to protect them directly.


For Analytics, since the worse that can happen is that someone can 
generate fake analytics it doesn't really matter - and the data can be 
relatively easily filtered and processed to eliminate any dodgy looking 
submissions.


For Maps, it can cost you money if someone else tries to use yours - 
however, you can restrict the key by the referring website and IP 
addresses, as well as what the key can do.


TYPE 2

In (2) you have things like Google Maps App keys (for Android/iOS) - and 
all manner of other 'cloud type' services which have (native) app 
bindings for mobile (and desktop).


Many services offer restrictions for these keys too - for example Google 
Services API keys can be restricted by Android app signing hashes and 
ids, and iOS app bundle ids.


However, in general, these services generally suggest that you ensure 
that the API key is not extractable directly from the app bundle (after 
decompressing in general) - i.e. that the key be obfuscated in some 
fashion and does not appear in plaintext.


It is important to note that they do not require any more than this 
because, at the end of the day, any API key has to be in memory at some 
point, and indeed has to be transmitted 'over the wire'. If someone has 
enough access to access memory, then they have enough access to 
intercept the HTTP requests (even if encrypted - if they really know 
what they are doing) so obfuscating in the on-disk files of the app is 
as good as you can get.


If these keys are compromised then it is a pain - it might cost you 
money (as all these services which have them tend to charge by use) - 
and, if embedded in an app, will require an app update to replace.


TYPE 3

Certain services require (sometimes in the TOS!) that their API keys 
*never* leave a secure bubble which you control - this means they must 
never appear in deployed apps or in files transmitted to the browser. 
Payment gateway API keys will pretty much always fall into this category 
- Stripe is a good example.


The only way to use these keys is from server scripts running on a 
server which you do your best to maintain the security of. Ideally these 
keys should be stored in files which are only readable by specific users 
- usually the web-server user which is running the backend scripts which 
needs to make the requests.


Indeed, services which require this tend to design their APIs for the 
intention of being used on a server.


WHAT TO DO IN LIVECODE

If you are dealing with a type 1 key then you really don't have to worry 
- they are designed to be used in a context which offers zero ability to 
protect them, so including them in a deployed app (in particular) is 
more secure out of the gate than in their intended use in a webpage.


[ Of course, whether you are actually *allowed* to use their services 
from anything other than websites is another matter - and entirely 
defined by their TOS - but I digress! ]


If you are dealing with a type 2 key then the requirements put on their 
use in deployed (native) apps is more than catered for by having the key 
in script, in a password protected stack - for example, as a constant 
return value of a function, or indeed as a constant defined in the 
script which is talking to the API. With this, the key will not appear 
in plaintext in any of the files included in the built app (even after 
the container is unzipped).


[ I should note here that custom properties values also do not appear in 
plaintext in any of the files of a built app - however, having them in a 
password protected script offers an extra level of protection ].


If you are dealing with a type 3 key then you must only use that key via 
a server - this means you need to set up server side scripts which your 
app then talks 

Re: {OT} Are there any ffmpeg "experts" on this list?

2022-06-24 Thread Mark Waddingham via use-livecode

On 2022-06-24 17:05, Paul Dupuis via use-livecode wrote:

I was unaware of the mediaFoundation library - I had thought that we'd
not see support under LiveCode 10 switches from DirectShow to
MediaFoundation.


Its actually been buried in the product (business/pro features) for a 
long time - I had forgotten about it until relatively recently...



That said, our application is macOS and Windows and the appeal of
ffmpeg via shell is that the same code will work across platforms for
us.


FWIW, I *think* mergAV can do similar things on macOS* to the 
mediafoundation external on Windows - although the APIs, while similar, 
do require different code.


However, if you are using ffmpeg for things other than concatenating 
tracks/movies (i.e. the features those libraries provide) then the 
separate code needed wouldn't be worth it to save inclusion of ffmpeg.


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: How to color a "cell"?

2022-06-23 Thread Mark Waddingham via use-livecode

On 2022-06-23 23:54, Richard Gaskin via use-livecode wrote:

Thanks Mark - works. I could have sworn I'd tried "line" earlier when
attempting to set the backgroundColor, and when it failed was when I
switched to trying "paragraph". But it works now so I don't mind being
mistaken.

Oddly, "paragraph" appears to be synonymous with "line" for the
borderWidth, borderColor, firstIndent, leftIndent, textAlign,
spaceAbove, hGrid, vGrid, and tabs paragraph properties.


I suspect you have dontWrap set and possibly 'table-mode'.


Near as I can tell backgroundColor is the only paragraph properties
where the "paragraph" chunk type isn't synonymous.


If you check the htmlText you can easily see the difference between
using 'paragraph' and 'line' to set the aforementioned properties.

When set on 'line' - the properties appear on the 'p' tags, and they
have an effect on a per (wrapped) paragraph basis.

When set on *all other string chunks* (which reduce to char chunks) -
the properties appear as runs in the 'p' tags, and they have an effect
on runs of text.

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: How to color a "cell"?

2022-06-23 Thread Mark Waddingham via use-livecode
IIRC you need to use ‘line’ to set ‘paragraph‘ properties of fields…

Sent from my iPhone

> On 23 Jun 2022, at 19:29, Richard Gaskin via use-livecode 
>  wrote:
> 
> Craig wrote:
> 
> > Richard wrote:
> >> I had hoped the paragraph-level formatting options introduced in
> >> v5.x would help, but alas as far as I can tell I can only set the
> >> backgroundColor of a run of text, not the full cell.
> >
> > I think this was discussed on the forum a while back. I do not believe
> > you can do what you want without another control overlying the “rect”
> > of the “cell”.
> 
> Thanks. I could get away with setting the backgroundColor of the whole line, 
> but that does the same as setting the backgroundColor of a "cell": it draws 
> the color only beneath the portion of the line that contains text, leaving 
> the rest blank.
> 
> The borderWidth and borderColor paragraph properties work as expected, 
> affecting the full line whether it's filled with text or has no text at all.
> 
> But backgroundColor as a paragraph setting feels broken, as it works the same 
> as setting that property for a chunk rather than for the field.
> 
> From the v5.5.4 Release Notes:
> 
> - The backgroundColor property allows the color of the content area
>  (inside any paragraph border) to be filled (note that strictly
>  speaking this property is not inherited, but the effect is the same
>  as if it was as the background of the field is rendered before the
>  paragraphs are so the background color at the field level will
>  ‘show through’ to the paragraph if the paragraph has no background
>  color).
> 
> - The borderWidth property determines the width of the border to draw
>  around the paragraph.
> 
> Pretty much all the other paragraph-level formatting options work just their 
> their field-level counterparts, but of course limited to the specified 
> paragraph.
> 
> So I'm surprised the backgroundColor was added in such a way that it appears 
> to do nothing we didn't already have with setting backgroundColor of chunks.
> 
> I was hoping I was just using it wrong.
> 
> Here's how I set it in my tests:
> 
>set the backgroundcolor of paragraph 2 of fld 1 to yellow
> 
> Unless there's a different syntax I should be using, it would appear the 
> paragraph-level implementation of backgroundColor is unfinished, no?
> 
> 
> -- 
> 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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs

2022-06-21 Thread Mark Waddingham via use-livecode

On 2022-06-21 12:18, matthias rebbe via use-livecode wrote:
Am 21.06.2022 um 11:56 schrieb Mark Waddingham via use-livecode 
:

Why?



First, it's more convenient for the developer.


I think the end user is more important (in this case) ;)


The Intel only and Apple only builds are smaller ins size than the
universal build.


True - universal builds are double the size essentially (well, resources 
in copy files are *not* duplicated) - however how important is that 
really?


There's a high chance a user might download an app twice from a page 
offering two architectures - because they aren't necessarily sure which 
one they need - at which point, you've lost any advantage in splitting 
them (and just caused user consternation). [ Similar argument holds when 
users upgrade their machines, and restore from a full backup - which is 
what the majority of users do ].


Besides, if size is a real concern here then there are a couple of 
tweaks we could do to reduce the size of universal binaries (and indeed, 
Android APKs) which would see the size difference between universal and 
non-universal drop to maybe 3-4Mb (and probably only 1-2Mb when 
compressed - i.e. transmission size). [ This would be a *much* better 
use of time, than adding an edge-case option to the S/B, IMHO ].



So if i want to build those single platform apps to offer the smaller
sized apps  i have to run the standalone building process twice,
right? And before i run the 2nd build process i even have to switch
the settings, right?
That's not very convenient.


Offering two separate downloads to users is not very convenient to them 
;)



And btw why did this option exist in previous LC versions for an
Universal app with PPC and Intel support?


Well that was getting on for a decade ago - so can't really remember 
what the exact rationale was back then. However, I dimly recall that 
universal PPC+Intel binaries would not run on some earlier versions of 
'MacOS X' which we still supported (and people still had!) at the time - 
so you actually *needed* to offer a separate PPC download if you still 
needed to support those really old 'MacOS X' versions.


These days that's not a problem as there's been a 32-bit -> 64-bit 
architecture switch since then which means all the macOS versions we 
currently support work correctly with universal binaries containing 
slices the OS does not understand.


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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs

2022-06-21 Thread Mark Waddingham via use-livecode

On 2022-06-20 20:55, matthias rebbe via use-livecode wrote:

Anyway, the macOS Apple support is currently experimental, i am pretty
sure there will be such an option in future. At least i hope so. ;)


Why?

The idea of universal binaries is to ensure that a single app/installer 
can be shipped to users and that will then use the 'best' it can for 
their machine. They provide a much better end-user experience than 
Windows or Linux provide in this regard.


Whilst you might not have many users using Apple architecture machines 
right now, you don't know when they might upgrade, so universal binaries 
mean that when a user upgrades their machine, their apps they already 
have (backed up, more than likely, and re-imaged on the new machine) 
will continue to take advantage of their hardware.


Warmest Regards,

Mark.

P.S. I should point out that Apple architecture support *is* 
experimental, so its fine to include and seed to users for testing 
purposes, but I wouldn't include one in final shipping releases just 
yet.


P.P.S. That being said, the only Apple architecture related bug we have 
had reported recently is related to standalone building itself (and is 
related to macOS High Sierra - 10.13 - and below *not* supported arm64 
slices in some of the command-line tools the S/B uses) - and I fully 
expect the experimental tag to be removed by final release of 10 (and 
the corresponding 9.6.x maintenance release just after that).


--
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: M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs

2022-06-20 Thread Mark Waddingham via use-livecode

On 2022-06-18 21:27, matthias rebbe via use-livecode wrote:

So, the question now is, is this a macOS problem or is it possible
that a standalone could show the wrong setting due to a wrong
configuration or so when it is created.


It is a macOS (Finder) bug - I think it was the same when they added 
32-bit vs 64-bit, and probably Intel vs PowerPC.


There's a plist entry 'LSArchitecturePriority' which is the order in 
which the different slices should be used - currently we have x86-64 
then arm64 and it seems the Finder doesn't use this to determine whether 
to show the Rosetta box as checked or not when the user hasn't 
explicitly prodded it in the past (which obviously they won't have done 
for new apps / those which didn't have the option before!).


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: char as word boundary

2022-06-13 Thread Mark Waddingham via use-livecode

Hi Jean-Jacques,

On 2022-06-03 14:56, Jean-Jacques Wagner via use-livecode wrote:

Hi,
Version 6.7word boudary are char number 09,10,11,12,13,32
version 9.67  word boudary are char number 09,10,11,12,13,32,202

Hypercard and livecode 6.7:  the number of chars (numtochar(32)&
numtochar(202)(32)& numtochar(202)(32)) = 2
livecode 9.67  :   the number of chars
(numtochar(32)& numtochar(202)(32)&
numtochar(202)(32)) = 0

Is it a change or a bug considering now numtochar(202) as word
boundary, as it is with numtochar(32)


This is something we will need to consider - please do file a bug about 
it at quality.livecode.com (so you can track any further discussion 
about it).


I can see how this change occurred, and it is perhaps more a 
'side-effect of implementation' rather than an intended change.


Prior to 7.0 - the word chunk used the C library 'ctype' isspace 
function - which returns true if a character is 'whitespace'. However, 
the engine *also* tweaked the C library character tables to make it so 
that NBSP (202 on MacRoman - something else on Windows/Linux - 160 
maybe?) was *not* a space character. This was primarily a very dirty 
hack (which was done before my time!) to allow non-breaking spaces to 
prevent word breaks in fields (I strongly suspect the effect on the word 
chunk was never considered!).


When we moved to Unicode - we changed the word-breaking detection in 
fields to use a simplified version of the Unicode algorithm and Unicode 
character properties (NBSP has the, unsurprisingly, no-break property!). 
Similarly, we changed the word chunk to use the Unicode 'whitespace' 
property. In the unicode world - being whitespace, and non-breaking are 
two separate properties... Hence the difference in behavior since 7.


The reason this is 'of interest' is that the word chunk has had quite a 
hefty performance regression since 7.0 due to the switch to Unicode, so 
re-looking at what it should *actually* do (taking into account what it 
would be most useful in the widest possible circumstances) is definitely 
on the cards.


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: Would anyone miss convertOctals?

2022-06-10 Thread Mark Waddingham via use-livecode

On 2022-06-09 20:54, Craig Newman via use-livecode wrote:

Mark.

Gong the other way, is your task made much simpler by losing
“converOctals”? I assume so, or the issue would never have come up.
Are there other similar language elements that also are on the block?


I'm not sure it makes things 'much simpler' - but it does remove one 
thing to have to think about. Further it removes a case where script is 
ambiguous at parse-time - i.e. the token 0123 could mean one of two 
different things depending on a runtime property.


Given the responses so far, it looks to me like convertOctals is an 
exceptionally rarely used feature (the number of years of LC experience 
amongst those who have responded is in excess of two centuries, and >80% 
of the respondents didn't know what the property was).


Thus any added complexity caused by having this feature seems a waste of 
time/effort/mind-space - particularly as there is a more-than-adequate 
replacement which has none of its problems (i.e. 0o123) - and moreover 
one which other languages (e.g. JS) adopted a long time ago.


In terms of other things which are 'on the block' - then no explicit 
features per-se but there are a couple of extreme 'edge cases' which 
will likely be removed.


For example, the ability to use 'msg' (which is aliased to the content 
of the message box) and '$' implicit variables as referenced 
parameters in handlers. Currently you can do:


  on mouseUp
fillVars msg, $FOOBAR
  end mouseUp

  on fillVars @pA, @pB
put "foo" into pA
put "bar" into pB
  end fillVars

The ability to pass these 'quasi-variables' as references will 
potentially reduce the potential performance gains of moving to a 
bytecode-based VM when referenced parameters are used in general, and 
thus (like convertOctals) their existence seems too high a price to pay 
for what is almost certainly a rarely used (if used at all) feature.


Note: I should stress that the above is *just* removing the ability to 
pass 'msg' and environment variable globals as reference parameters to 
handlers *not* removing 'msg' or environment variables in general!


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: Would anyone miss convertOctals?

2022-06-09 Thread Mark Waddingham via use-livecode

On 2022-06-09 16:33, Devin Asay via use-livecode wrote:

Wait, you said three questions. But no.


What are those two hard problems of computer science again? ;)

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


Would anyone miss convertOctals?

2022-06-09 Thread Mark Waddingham via use-livecode
So I'm currently sitting here about to embark on fixing 
 (which is the final 
thing to sort out before being able to merge my constant expression 
patch) and I was reminded of 'convertOctals'.


Now, generally, I am somewhat averse to actually removing any language 
feature (even those we have deprecated, unless we absolutely have to!) - 
however, I would really like to make convertOctals have no effect at all 
in 10.0+ as it adds a disproportionate amount of complexity compared to 
(what I think, at least) its utility is (particularly in the context of 
things 'coming next' like the script compiler).


So three questions:

  1) Do you know what convertOctals is, and what it does?

  2) If you do, have you ever actually used it in any scripts which are 
actually still in use?


  3) If you do use it in any scripts which are still in use, would you 
be willing to change them to not use it?


  4) If you do use/have used it, had you ever noticed that it has been 
slightly broken for years?


Now, its always better to offer a carrot when there is a stick (or in 
this case, an axe) being wielded and the carrot in this case would be to 
expand the numeric literal syntax to add both explicit octal and binary 
number literals alongside hexadecimal:


0xabcdef - hex literal
0o777 - octal literal
0b101110101

The key difference between 0o777 and using 0777 (with convertOctals 
true) is that the former is not ambiguous at parse time, it doesn't 
require a runtime property set to true in order for the engine to 
convert the string to a number correctly.


Please let me know your thoughts :)

Warmest Regards,

Mark.

P.S. In the scheme of 'breaking changes' - we've already made a number 
of them for 10 already, and my gut tells me removing convertOctals is 
likely to cause less consternation than those we already have - but I 
could be wrong!


--
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: Generating Random numbers to conform a distribution

2022-06-08 Thread Mark Waddingham via use-livecode

On 2022-06-07 21:51, David V Glasgow via use-livecode wrote:

Quite a lot of stats and maths packages offer a feature whereby the N,
the Mean and the SD are variables specified by the user, and N random
numbers are then generated with the required mean and SD.  I remember
the venerable and excellent Hypercard  HyperStat
 (1993)
by David M Lane doing exactly that.

Or is there an elegant formula?  I have Googled about and can’t see
one, but maybe I don’t know the magic words.  And if someone wanted to
script this in LC what would be the best approach? (just general
guidance here, wouldn’t want anyone to invest their valuable time in
what is at present just vague musings)

Any hints from the stats gurus?


I'm not a stats guru but...

I think all you need to do here is to use some of the intrinsic 
'properties' of the Mean and SD.


Lets say you have a collection X of numbers then the following things 
are always true:


  P1: Mean(c * X) = c * Mean(X)
  P2: Mean(X + k) = k + Mean(X)
  P3: SD(c * X) = abs(c) * SD(X)
  P4: SD(X + k) = SD(X)

In English, scaling a set of numbers scales their mean by the same 
amount, and offsetting a set of numbers offsets their mean by the same 
amount, Similarly, scaling a set of numbers scales their SD by the same 
amount, and offsetting a set of numbers makes no difference to the SD 
(as the SD is a relative quantity - it cares about distance from the 
mean, not magnitude).


Now, hopefully we can agree that if you generate a set of a random 
numbers, then scaling and offsetting them still uniformly does not 
reduce the randomness (randomness means the numbers form a uniform 
distribution over the range of generation, if you scale and offset then 
all you are doing is changing the range - not the distribution).


So with this in mind, let TMean and TSD be the target mean and target 
SD. Then:


  1. Generate N random numbers in the range [0, 1] - S0, ..., SN

  2. Compute SMean := Mean(S0, ..., SN)

  3. Compute SSD := SD(S0, ..., SN)

Now we take a small diversion from a sequence of enumerated steps to ask 
"what offset and scale do we need to apply to the set of numbers so that 
we get TMean and TSD, rather than SMean and SSD?".


The amount we need to scale by is mandated by the SD, specifically:

 c := TSD/SSD

If we scale our source numbers by c and apply SD then we see:

 SD(c * S0, ..., c * SN) = c * SD(S0, ..., SN) [P3 above]
 = c * SSD
 = TSD / SSD * SSD
 = TSD

i.e. Our scaled input numbers give us the desired SD!

So now we just need to play the same 'game' with the Mean. We have:

 Mean(c * S0, ..., c * SN) = c * Mean(S0, ..., SN)
   = c * SMean

However we really want a mean of TMean so define:

 k := TMean - c * SMean

Then if we translate our (scaled!) source numbers by k and apply Mean 
then we see:


Mean(c * S0 + k, ..., c * SN + k) = c * Mean(S0, ..., SN) + k [P1 
and P2 above]

  = c * SMean + k
  = c * SMean + TMean - c * SMean
  = TMean

i.e. Our scaled and offset input numbers give us the desired Mean!

Note that SD is invariant under offsetting (P4) so SD(c * S0 + k, ..., c 
* SN + k) = SD(c * S0, ... c * SN) = TSD!


We can now return to our sequence of steps:

  4. Compute c := TSD/SSD

  5. Compute k := TMean - c * SMean

  6. Compute the target random numbers, Tn := c * Sn + k

So, assuming my maths is correct above T0, ..., TN, will be still be 
'random' (for some suitable definition of random), but have Mean of 
TMean and SD of TSD as desired.


In LiveCode Script, the above is something like:

   function randomNumbers pN, pTMean, pTSD
  local tSource
  repeat pN times
 put random(2^31) & comma after tSource
  end repeat

  local tSMean, tSSD
  put average(tSource) into tSMean
  put stdDev(tSource) into tSSD

  local tC, tK
  put pTSD / pSSD into tC
  put pTMean - tC * tSMean into tK

  local tTarget
  repeat for each item tS in tSource
put tC * tS + tK & comma after tTarget
  end repeat

  return tTarget
   end randomNumbers

Hope this helps!

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: Case sensitivity in Livecode ??

2022-06-07 Thread Mark Waddingham via use-livecode

On 2022-06-07 17:16, Mark Wieder via use-livecode wrote:

1. Because it's a function, not a constant.
  put gkMyMagicValue() into tVar
is cognitively different from
  put gkMyMagicValue into tVar

Something like 17 is a trivial case. Something more like real world
usage would be

constant kRootURL="http://example.com/aUrlThatMightChange/api/v2;


I see and what is kRootURL the Url for? If I were writing a library for 
a web-service and needed (for some reason) to expose the underlying URL 
to callers of the library, then I'd have simply define a function as 
part of its public API:


  function myRestLibraryGetRootUrl
return "http://example.com/aUrlThatMightChange/api/v2;
  end myRestLibraryGetRootUrl

I don't buy the 'cognitively different' argument - different languages 
have different patterns. I really don't see that getting into the habit 
of using 'constant functions' instead of 'constant variables' is any 
different from getting into the habit of doing assignment as 'source 
into target', rather than 'target = source'; or getting your head around 
the message path.


It is definitely *not* unusual for libraries in any language to expose 
*all* that they do via functions - whilst you can use enums and 
preprocessor defines in C/C++ for global constants - they make your 
library unwrappable easily by higher-level languages. Indeed, you tend 
to find that as published low-level (C/C++) libraries have evolved they 
have changed to ensure their interfaces are entirely function based ones 
(indeed, oftentimes C++-based libraries gain a C function wrapper to 
make this easier - as C++ is a nightmare to wrap stuff from due to the 
immensely complicated semantics, these days, of C++ classes).



2. Because the server already build supports the "include" keyword
which would neatly solve the issue, but none of the other platforms
do. Why?


You can't really compare the features of the PHP (C preprocessor) style 
operation of the server engine with the object-based scripting of the 
normal LiveCode engine.


In that PHP-likeness, 'include' makes sense as the server engine is 
essentially doing a continuous 'merge' - emitting interleaved blocks of 
content (text) with content generated from code.


The include which is present there makes sense for that form of coding - 
i.e. for generating text documents from a mixture of prewritten text, 
and evaluated script. I don't think it makes sense when scripts are 
attached to objects where more structure is needed and they exist in a 
dynamic environment.


Critically, the server engine loads and parses files in a linear fashion 
- emitting the text, and executing the interleaved script. Everything is 
completely transient - when the document has finished being emitted, the 
engine terminates.


It raises too many edge-cases and questions as to what should happen in 
various different scenarios (as well as being a very large noose with 
which people could hang themselves) when you try to add its 'include' 
operation to the normal LiveCode environment.


Remember that in the server engine include operates on a file so  what 
would you expect to happen if you change the file? Does the engine have 
to track changes and recompile any object scripts including it when they 
change? (Remember that object scripts are compiled on being set, or when 
first tickled by a handler lookup if already set and loaded from disk).



3. Because every other language I've used has global constants and
makes this easy. It's only xtalk that makes this hard. If an LC goal
is to provide a tool for learning coding then multiple definitions of
the same constant is a paradigm that is not transportable to other
languages, and indeed will probably result in a compiler error.


xTalk does not make it hard - see above - its just different because of 
its model.


Of the languages you've used how many are object-based, where objects 
have scripts which can be dynamically (re-)attached continuously 
throughout the lifetime of a programs execution and, moreover, can be 
dynamically created at runtime; and more specifically, where a script is 
a defined set of handlers and other definitions which are completely 
independent (from the point of view of compiling) of any other script?


For those which you have found which fit that pattern, do any of them 
have global constants?



4. Because it gets tiresome having to explain to new developers that
you have to declare constants in multiple scripts even though it's the
same constant you already declared and the workaround is to use a
getter function as you described.


Then tell new developers that the xTalk way to do global constants is 
constant functions in the message path!


Saying that is a workaround is akin to telling them that:

  "The workaround for not being able use the syntax 'X := Y' is to use 
the syntax 'put X into Y'"


Or telling someone learning Java that:

  "The workaround for defining a global function is to make it a static 

Re: Case sensitivity in Livecode ??

2022-06-07 Thread Mark Waddingham via use-livecode

On 2022-06-01 19:54, Alex Tweedly via use-livecode wrote:

Also, you'll be able to do things like:

    constant kPiBy2 = pi / 2
    constant kPiBy2Squared = kPiBy2 * kPiBy2
    constant kPiBy2String = format("%f", kPiBy2)
    local sPiMap = { "pi-by-2": kPiBy2, "pi-by-2-sq": kPiBy2Squared }


Very good. In fact, great !! Thank you!

Would you be ale to do something like

constant kPiMap = { ... as above ... }


Yes - the initializers in both constant and local keywords are the same 
- both can use arbitrary constant expressions (any local properties are 
assumed to be the default values when evaluating).


And now I'll push my luck and ponder the possibility of 'global' 
constants.


Haha...


OK - 'global constant' is likely counter to the scope concepts. But
perhaps they could be done as "write-once" variables, or as a more
general "write-protected' variable.

   put 17 into gkMyMagicValue
   writeprotect "gkMyMagicValue"

and any *subsequent* attempt to change the value would fail.


How is that any better than putting something like this in a library or 
back script:


function gkMyMagicValue
return 17
end gkMyMagicValue

Including the global declaration its the same number of lines (indeed 
less, as you'd need to put a global declaration in every script which 
wanted to use said global constant...).


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: Reporting Apple Silicon anomalies (Re: [[ ANN ]] Release 9.6.8 RC-1)

2022-06-06 Thread Mark Waddingham via use-livecode

On 2022-06-06 15:50, Ben Rubinstein via use-livecode wrote:

This is very exciting, thank you. If we find anomalies in the Apple
Silicon side, should we raise them in the first instance
 - to you directly?
 - on this list?
 - straight into LQCC?


Just file a bug in the LQCC - indicating that the discrepancy is between 
Apple and Intel architectures :)


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: Case sensitivity in Livecode ??

2022-06-01 Thread Mark Waddingham via use-livecode

On 2022-06-01 17:44, Alex Tweedly via use-livecode wrote:

I was surprised to find that

   constant K = TRUE

produces an error, though

  constant K = true

is fine. In other contexts, you can say

   put TRUE into myVar
   put true into hisVar
   etc.

but in a constant statement, it seems to be case sensitive.

Anyone got an interesting story (or theory) on why ?   :-)


Its a small mitigation of 
https://quality.livecode.com/show_bug.cgi?id=19413 - i.e. where the 
initializer of constants (and locals) is currently treated as a single 
literal.


In explicitVariables mode, unquoted literals are allowed on the RHS only 
if the literal is a (builtin) constant *and* the constants value is 
identical to the token you have provided.


That extra check is there to ensure that the constants (and 
initializers) you have used are actually what you intended.


Currently - the following does not do what you think:

   constant kEmptyString = empty

Indeed, this isn't allowed in explicitVariables mode, as the constant 
empty's value is "" and not "empty" - which is what kEmptyString will 
actually be with explicitVariables turned off.


Anyway, this rather odd and obscure facet of the language will disappear 
in 10 as we've made it so that initializers for constants and locals can 
be constant expressions. Thus:


constant kTrue = TRUE
local sEmptyString = empty

Will do precisely what they look like they should do...

Also, you'll be able to do things like:

constant kPiBy2 = pi / 2
constant kPiBy2Squared = kPiBy2 * kPiBy2
constant kPiBy2String = format("%f", kPiBy2)
local sPiMap = { "pi-by-2": kPiBy2, "pi-by-2-sq": kPiBy2Squared }

Warmest Regards,

Mark.

P.S. Amusingly, your question came up on exactly the same day I 
'finished' my patch for the above - it now awaits review which may 
result in it not being quite finished ;)


--
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: Set HTMLText and Get Effective HTMLText

2022-05-18 Thread Mark Waddingham via use-livecode

On 2022-05-18 17:43, Rick Harrison via use-livecode wrote:

I wish it worked with variables though
because execution would be faster.


If variables could manipulate styled text (aka htmlText) then they 
wouldn't be any faster than fields ;)


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: drawingSvgCompileIcon(pIconName) always BLACK

2022-04-06 Thread Mark Waddingham via use-livecode

On 2022-04-06 18:16, Klaus major-k via use-livecode wrote:

Hi all,

so sorry, looks like I completely f. up here.
Sorry for the confusion, not may day...

See:



Hehe - no worries.

So in answer to your original query about wanting to be able to color 
the icons - the drawing library supports the 'currentColor' attribute in 
SVG - and this is tied to the 'backgroundColor' property of the image 
object the drawing is set on.


It would only take a small tweak to Brian's extension to make this work 
- adding `fill="currentColor"` to the path node it generates.


Brian's extension works by fetching the path data from the IconSVG 
library, wrapping it in the necessary SVG XML, and then compiling it 
with drawingSvgCompile.


Irksomely, there does not seem to be any support for marking colors in 
SVGs as 'currentColor' in any SVG editor we've come across (unless its 
deeply buried in it). So one strategy there is making sure the colors 
you want to be configurable in the SVG are set to a known unlikely 
random color (e.g. #ABCDEF), exporting as SVG XML from the editor and 
then just doing a global find/replace of (e.g.) #ABCDEF with 
currentColor.


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: Weird Standalone Builder issue

2022-03-25 Thread Mark Waddingham via use-livecode

On 2022-03-24 21:07, Paul Dupuis via use-livecode wrote:

I'm on Windows 10, using LC 9.6.6, and building for macOS and Windows
...
This is not a problem form me as I can use revDeleteFolder to remove
Contents\Resources\_MacOS\Utilities\ on the mac build and
revDeleteFile to remove "ffmepeg" from the Utilities folder on Windows
and I am left with the right utility for the right platform. I could
also just copy the utilities from the project folder each build during
the "on standaloneSaved" message handler.

I am mostly curious as to why the Standalone Builder splits the
files/folder for macOS and leaves them together for Windows?


So this is by design although its been so many years since this was done 
my memory is a little hazy!


I think the evolution of this was as follows:
   - originally copy files were put next to the executable (i.e. 
Contents/MacOS on macOS)
   - Apple made that path read-only and things had to be put in 
.app/Contents/Resources
   - the s/b started doing that, but we added internal redirects to the 
low-level file functions in the engine so code wouldn't see a difference
   - Apple then made it so that Apple executables could not be launched 
from anywhere except from Contents/MacOS
   - so we made it so the s/b sniffed the header of all files copied for 
Mach-O files and left those in Contents/MacOS


Basically, we've tried to make changes to Apple's structuring 
requirements transparent to developers all the way along - and its 
worked fine up until now, but admittedly looks a little strange if you 
dig around into things!


I've been pondering whether we should ditch the mechanism soon though:

   - remove the magic redirection
   - require code to use specialFolderPath("resources") to find 
non-executable resources
   - require code to use (a new) specialFolderPath("executable 
resources") to find executable resources (which would only be different 
to the above on macOS systems)
   - keep the magic sniffing of files in the S/B so executables still go 
in Contents/MacOS


This may break some really old code - but would remove some rather 
fiddly code in the engine which does the magical redirection - and mean 
things would be structured as expected (with the new definition of 
expected).


FWIW, even with the above you would still have to branch code to do what 
you want as the macOS exes would be in a different place (because they 
need to be!) so it wouldn't resolve that - but at least you wouldn't 
have been 'surprised' by what you found!


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: debugging javascript in html5

2022-03-18 Thread Mark Waddingham via use-livecode

On 2022-03-18 10:44, Bernard Devlin via use-livecode wrote:
Considering the html5 enhancements might well be the biggest thing in 
LC

10, I can foresee a whole world of pain when it comes to us debugging
Javascript interactions.


Yes - this is somewhat painful at present - and we do hope to make 
debugging web standalones in general less painful in time.


However, if you 'Test' your web standalone in a browser you can then 
open up the Developer Tools for the browser you are testing in - which 
gives you access to the JS console and all the other tools.


In JS you can use `console.log(...);` to have messages emitted to the JS 
console.


Additionally, I *think* you can use `debugger;` to have JS code break 
into the debugger in said browser's developer tools. I must confess I've 
not tried this myself (as our debugging is usually debugging the engine 
running in the browser, rather than debugging JS executed from the 
engine running the browser) - but I can't see why it wouldn't work.


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: debugging javascript in html5

2022-03-18 Thread Mark Waddingham via use-livecode

On 2022-03-18 11:19, Bernard Devlin via use-livecode wrote:
Here's a peculiarity I haven't seen mentioned before.  I am trying to 
test

the viability of the idea of a function to call back to LC and provide
debugging info.

Assume you create a LC function lclog(pmsg,pval) and you put a 
breakpoint
in the IDE inside that function body.  Set the htmltext of a browser 
widget
to the code below, set the javascriptHandlers of the browser to contain 
the

word: lclog . Your browser widget will have a button 'clickme'.
1) On clicking that button the JS alerts ALL trigger first.
2) After they have fired the first call to lclog() runs, and the second
call to lclog() never runs.



function lcxhr(method, url) {

alert('lcxhr called');

var json = JSON.stringify({ name: "John", surname: "Smith"});

liveCode.lclog('json created', json);

alert('you see this alert before the above call to lclog()');

liveCode.lclog('exit js function','');

}


So this is quite separate from what happens in the web engine which 
works very differently.


Embeddable browsers are inherently asynchronous in their execution (not 
necessarily in a multi-thready way, although that does play a part) - 
but more in the sense that you can't get an embedded browser to do 
anything and have it 'block' until it is done.


The converse is also true - the request to call an LC handler from the 
browser widget is basically a post - not a send - which means that 
(really) you can only call LC handlers as tail calls - i.e. as the last 
thing on a handler.


Warmest Regards,

Mark.

P.S. The web engine is (essentially) the running the LC script 'as 
JavaScript' so the same limitation does not apply - calling LC handlers 
from JS in the web engine is synchronous.


--
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: 10.0.0-dp-2 html5 and liburlLastRHHeaders()

2022-03-18 Thread Mark Waddingham via use-livecode

On 2022-03-17 13:07, Bernard Devlin via use-livecode wrote:
So there is something else going on between LC's libUrlLastRHHeaders() 
and
LC's interaction with the JS XMLHttpRequest().  This something is 
stripping

out most of the headers.


As I said, LC is not stripping anything - we are returning what JS 
returns.


However, the difference is that (currently) we use the synchronous mode 
of XMLHttpRequests (as prior to 10, due to the lack of wait using async 
wasn't viable apart from for `load url`). I wonder if that might be the 
difference.


Your sample code and example is useful - if you could post to a bug 
report, then we will look into whether that is the case, or there is 
something else going on.


Warmest Regards,

Mark.

P.S. We are hoping to move to the async version of XMLHttpRequest now 
that we can wait - so that might well be the solution.


--
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: :MEMORY: databases and Windows

2022-03-17 Thread Mark Waddingham via use-livecode

On 2022-03-16 22:07, Bob Sneidar via use-livecode wrote:

Once again you nailed it. Still, this is a bug, minor though it may
be. In the past I was told that it MUST be capitalized. Now it seems
capitalized only works on the mac while all lowercase works on both
platforms.  squared.


FWIW I don't think this is a bug.

In the SQLite documentation it explicitly states ':memory:' lowercase.

We don't process the filename we pass to the SQLite library, so I can't 
explain the difference between macOS and Windows.


Looking at the sqlite sourcecode - it does a case-sensitive comparison 
between the filename passed and ':memory:'.


So, I suggest using ':memory:' as stated by SQLite and all will be well 
:)


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: 10.0.0-dp-2 html5 and liburlLastRHHeaders()

2022-03-17 Thread Mark Waddingham via use-livecode

On 2022-03-16 14:15, Bernard Devlin via use-livecode wrote:
If one could get hold in Livecodescript of the Javascript Request 
object

that was sent to the server, then one might be able to get hold of the
Response headers.

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/getAllResponseHeaders

My guess is that the shim is getting hold of this information but for 
some

strange reason it is stripping out most of the headers.


We already use that JS API to implement lastRHHeaders - we just return 
the value it returns verbatim.


Therefore, I'm guessing this is something the API is doing. The only 
thing which may give a hint is (in that doc):


  'For multipart requests, this returns the headers from the current 
part of the request, not from the original channel.'


Not sure whether that applies in this case or not (except that POST is 
generally used in multipart requests I think...)


Anyway, file a bug with an example if you can and we'll take a look.

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: Speed up a slow loop

2022-03-02 Thread Mark Waddingham via use-livecode

On 2022-03-02 21:57, J. Landman Gay via use-livecode wrote:

The loop takes forever. Here it is (sDictFile is a script local):

  repeat for each line l in pList -- pList is the user word list
if sDictFile[l] = true then put l & cr after tCheckedList
else put l & cr after tNonWords
wait 0 with messages  -- prevent ANRs
  end repeat

I added the wait because my Android phone was putting up an "app not
responding" warning while the loop was running (or just after, hard to
tell.) The loop should be much faster than that. When I added some
timing checks though, the timer says the loop takes between 0 and 1
millisecond, and yet the wait on screen remains.


If the difference between `the milliseconds` before the loop, and then 
after is 0 or 1 millisecond - then that is how long it is taking. This 
means the issue is somewhere else. Are you sure there isn't anything you 
are doing either before that loop or after that loop which doesn't wait 
for ages (due to the ANRs you mentioned).



With a 3-word user list, the loop takes 4 seconds. With an 8 word user
list the loop takes 6 seconds. The more user words, the longer the
wait.


If there are only 3 reasonable length words in pList (I.e. 3 lines) then 
there's no way that loop can take 4 seconds. Of course if the words are 
multiple megabytes long then it might be possible (however the timing 
you already stated above suggests the loop isn't actually taking 4 
seconds!).



Even stranger: on my cheapo Android tablet with 4 megs of RAM running
Android 9 the response is nearly instantaneous, even if the user list
has 200+ words. On my Pixel phone with 8 megs of RAM and Android 12
the response is slow enough to trigger the ANR with only 3 words. I'm
building for ARM 64.


This strongly suggests it is something else either on your phone, or in 
your code which your phone doesn't like I think.


Warmst 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: Have we lost the Oracle driver?

2022-03-01 Thread Mark Waddingham via use-livecode

On 2022-03-01 15:51, Ben Rubinstein via use-livecode wrote:

Hi Matthias,

Good spot! Thanks for checking.

I wonder whether this is an accidental omission, in that Oracle was at
one time only available at a certain higher level of license; maybe
now that there is only level, perhaps someone forgot to tweak whatever
bit of code checked that the 'correct' license was in place?


All business-only features were moved to be part of the pro features 
pack - the oracle driver included.


If it isn't working in your current version of LC, check that the 
license you have licensed LC with does have the pro features pack in 
it...


If you do `put the revLicenseInfo` it should say professional, rather 
than commercial.


If it doesn't say professional, Relicense your IDE using the menu item 
in Help and flick through the licenses you have available until one says 
'pro' in the title.


If the revLicenseInfo does say professional then something odd has 
happened somewhere which will need to look into more deeply!


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: resetall?

2022-02-22 Thread Mark Waddingham via use-livecode

On 2022-02-21 20:17, Mark Wieder via use-livecode wrote:

On 2/21/22 10:37, Mark Waddingham via use-livecode wrote:

Put another way - if you have done 'close socket i', then it is then 
it should be logically impossible for i to be in the openSockets 
immediately afterwards.


Ah. Sorry - after issuing a closeSocket call the socket does *not*
appear in the opensockets. But the socket seems not to be responding
until a reboot. And I'm thinking that I may have a blocking read still
in play at that point, and the close socket command doesn't affect it.


Can you clarify what you mean by the 'socket seems to not be 
responding'?


When you 'close socket', the engine immediately cancels all pending 
reads, but will not actually close the file descriptor until all pending 
writes have finished.


I'm puzzled by the idea of 'blocking writes' - write to socket without 
message will block script execution (and messages) until the timeout or 
the data is sent; so you can't close socket while that is happening (as 
script will not be executing).


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: Loading a LONG list with images

2022-02-22 Thread Mark Waddingham via use-livecode

On 2022-02-21 23:47, Tom Glod via use-livecode wrote:

This is how i did it .  I hope this helps.

First to use the "numberofrecords" way of setting the datagrid data.
This is key, that way you only ever trigger loading of visible rows.


So I've not got much to add to Tom's method

i.e. make sure the datagrid is only creating rows on demand, rather than 
up front, and then requesting images and updating them when they arrive


Beyond a suggestion to ensure the images which are being downloaded are 
already suitably sized/thumbnailed for display.


Decompressing images is a relatively expensive operation - decompressing 
and then downsizing them (thumbnailing) even more so.


So, if you control the webservice that is providing the images it would 
probably be worth making it so that the server can send you images at 
the size needed and do the thumbnailing on the server (caching the 
results alongside the original image on the server).


For maximum fidelity you want the width/height * the device pixel scale 
(which can vary from 1 to 3 these days).


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: resetall?

2022-02-21 Thread Mark Waddingham via use-livecode

On 2022-02-21 18:09, Mark Wieder via use-livecode wrote:

On 2/21/22 08:57, Mark Waddingham via use-livecode wrote:


If you want to brute force close all sockets then I suggest:


     repeat for each line i in the openSockets
   close socket i
     end repeat

:)


Yeah, that's what I'm doing now since resetall doesn't do anything
useful. Displaying the opensockets after a resetall still shows the
same sockets as before issuing the command.

And the repeat loop works maybe 50% of the time. It seems that maybe
if I have an active blocking read on a socket it doesn't get closed.
Could that be the case?


So I think there's something else going on in your scripts (or in the 
environment!) as from what I can see...


When `close socket` is performed, the socket is marked as `closing`, and 
`the openSockets` never includes sockets which are marked as `closing`.


The closing flag on a socket is only ever changed in two places - on 
socket creation/open, when it is set to false, and then on `close 
socket` where it is set to true.


Put another way - if you have done 'close socket i', then it is then it 
should be logically impossible for i to be in the openSockets 
immediately afterwards.


i.e. Based on my reading of the engine code:

  get line 1 of the openSockets
  close socket it
  put it is among the line of the openSockets

Will always put false.

Of course, it is possible after closing a socket, and if the event loop 
has run for a handler to have opened the same socket again (bearing in 
mind sockets are named for their address and port; unless an explicit 
tag is provided)...


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: resetall?

2022-02-21 Thread Mark Waddingham via use-livecode

On 2022-02-21 16:51, Mark Wieder via use-livecode wrote:

Before I report this one...

I thought resetall was supposed to close open sockets. There's even a
warning in the docs about it being a brute force close. But it doesn't
seem to do anything useful. Am I missing something?


Its a synonym for libUrlResetAll - and was only really intended to reset 
libUrl state I think (so its not clear to me why it didn't only ever 
touch the sockets libUrl was using).


These days if tsNet is loaded then it will just reset tsNet's state:

on libUrlResetAll
  local i

  -- CW-2016-06-11: [[ External driver support ]] Call driver specific 
reset command if external driver is in use.

  if lvExtDriver is not empty then
ulDeleteLocals
ulExtResetDriver
  else
if there is a stack "libUrl" then put empty into fld "log1" of stack 
"libURL"

repeat for each line i in the openSockets
  close socket i
end repeat

ulDeleteLocals
put true into lvJumpOut
send "ulDeleteLocals" to me in 5 milliseconds
  end if
end libUrlResetAll

If you want to brute force close all sockets then I suggest:


repeat for each line i in the openSockets
  close socket i
end repeat

:)

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: Encrypting long text

2021-12-16 Thread Mark Waddingham via use-livecode

On 2021-12-16 17:09, Sean Cole via use-livecode wrote:

Thanks Mark,

New problem. Trying to use aes-256-ctr instead. I'm following the 
syntax in

the dictionary but it throws a red cross on it:

encrypt tData using "aes-256-ctr" with key tMyKey and salt tMySalt


I think you can either specify a key, or a password with an optional 
salt.


If you specify a password it uses the provided salt (or a random one if 
one is not provided) to generate a key of the correct length (the bit 
length of the cipher).


If you provide a key then it uses that verbatim to encrypt the data (in 
this case the key must be the correct number of bits as defined by the 
chosen cipher - 256 in this case).


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: Encrypting long text

2021-12-16 Thread Mark Waddingham via use-livecode

On 2021-12-16 16:23, Sean Cole via use-livecode wrote:

Hi all,
I'm trying to use RSA to encrypt data from a text field like an address 
or
notes. When I try to use the encrypt command I get a result 'message 
too

long'. What is the method for encrypting long or large data?

My current line of code:
   encrypt tData using rsa with public key tMyKey and
passphrase tMyPass


RSA encryption can only encrypt data up to a certain length (I can't 
remember off the top of my head the exact relation, but it is related to 
the size of the key) so it isn't designed to be used on arbitrary length 
messages.


Encrypting arbitrary length messages is the domain of symmetric 
encryption functions - like AES and friends.


The solution, therefore, is to combine the two:

  1) Generate a random (using randomBytes()) fixed length encryption key 
FixedKey


  2) Encrypt the actual data using a symmetric algorithm with FixedKey 
as password


  2) Use RSA to encrypt the (fixed length!) key FixedKey

  4) Make you message the RSA-encrypted FixedKey followed by the 
encrypted data


The RSA encrypted FixedKey will be a constant length, and thus you can 
just split that off of the combined data, decrypt it using RSA and then 
use the result to decrypt the payload.


Hope this helps!

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: [ANN] Release 10.0.0 DP-1

2021-12-14 Thread Mark Waddingham via use-livecode

On 2021-12-14 13:50, Rolf Kocherhans via use-livecode wrote:

First of all thanks for the WebAssembly HTML5 implementation. This is
really great stuff !

For instance all my URL stuff (loading a stack on same domain) is
unfortunately not working anymore.

Also, all the PHP scripts which I used to access, which downloaded
stuff from other domains and then displayed
the result in the Browser don't work anymore.


Is this just me - or is it just not implemented yet ?


I don't think it is only you - at least one other person has mentioned 
on the forums that their URL operations are not working either.


What url operations are you using?

The reason I ask is because the engine only has built-in support for 
`load url` currently - the other syntax is implemented by a libURL 
'driver' and I have a suspicion that the latter may be currently broken.


Warmest Regards,

Mark.

P.S. And yes, this is high on the list to investigate in more depth and 
fix!


--
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: How to paste into a form element in the browser widget

2021-12-14 Thread Mark Waddingham via use-livecode

On 2021-12-14 11:41, Tore Nilsen via use-livecode wrote:

I have a problem pasting into a form element on a web page in the
browser widget. This works well in the IDE, but not in a standalone
application. The application has no menus, but I have included a
pasteKey script to handle paste shortcuts. This does not seem to do
the trick in the browser widget. I have tried to put the script in the
stack script, the card script and even in the widget itself, although
I wouldn’t expect the latter to work. Are there anyone who has run
across this problem before and may offer a solution?


I think you'll need to include an Edit menu with the normal shortcuts 
(Cut/Copy/Paste) - make sure the tag of the items is correct as the 
engine uses those to map them to the internal (Cocoa) references. e.g.


  (Cu /X|cut
  ( /C|copy
  ( /V|paste

Cocoa-based controls (which the browser widget uses the WebView variant 
of) don't respond to shortcuts directly, but only via menu item 
accelerators - so the browser widget needs the menu items present for 
such shortcuts to work.


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: Android tap location doesn't match visual location

2021-11-20 Thread Mark Waddingham via use-livecode
Hi Scott - the touch coords being wrong sounds like a bug to me - can you file 
a report (with example stack if possible).

Thanks!

Mark.

Sent from my iPhone

> On 20 Nov 2021, at 12:04, scott--- via use-livecode 
>  wrote:
> 
> Just answering my own question in case anyone searches this later. 
> 
> This was kind of a forehead slapper when I finally saw it. There was a native 
> UIScroller over part of the screen. None of the other buttons on the screen 
> were inside the rectangle of the scroller, so they weren’t effected. The 
> scroller was being disabled while the fake dialog was on the screen and this 
> worked fine for iOS but in my case at least, it is problematic for Android. 
> My solution for now is to either leave the scroller active on Android (not a 
> great UI but tolerable) or delete the scroller while the fake dialog is 
> showing and rebuild the scroller after the fake dialog is dismissed… which is 
> probably the better solution. I’m not sure why the disabled Android scroller 
> is offsetting the touch when the iOS scroller is not. Maybe it is a bug and 
> I’m the first person to put a disabled scroller over a button…more likely it 
> is something that I’m doing wrong when I create the scroller.
> — Scott Morrow
> 
>> On Nov 20, 2021, at 1:05 AM, scott--- via use-livecode 
>>  wrote:
>> 
>> Jacque, that is pretty much what I’m doing (except that my semi-transparent 
>> screen graphic is separate from the fake dialog group.) I agree that this 
>> approach normally works well. I don’t have as much experience on Android so 
>> I wondered if it had something to do with the platform. Apparently it is 
>> something I’m doing.
>> 
>> Brian, I will try your suggestion of isolating and breaking the process down 
>> in order to determine where the issue lies. I was just feeling lazy and 
>> hoping to save myself some work.  :-)
>> 
>> 
 On Nov 19, 2021, at 10:45 PM, J. Landman Gay via use-livecode 
  wrote:
>>> 
>>> I've done several fake dialogs. The trick is to group the dialog with a a 
>>> semi-transparent full screen graphic layered behind the dialog group. 
>>> Greying the screen is normal behavior on Android and works on iOS too. The 
>>> graphic has blocker mouse handlers so clicking it does nothing. That way 
>>> you can script the dialog buttons to respond themselves. The user needs to 
>>> click one of the buttons to make the dialog go away, at which point you 
>>> hide the group.
>>> 
>>> The buttons can put the response in the dialogData, which is a built in 
>>> mechanism to transfer custom messages to a script, or else you can put the 
>>> response in a global or a custom property.
>>> 
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software | http://www.hyperactivesw.com
 On November 19, 2021 10:49:57 PM scott--- via use-livecode 
  wrote:
>>> 
 I’m having trouble with an app that up until now has just been for iOS. 
 Most of the changes have been pretty straight forward but I’ve encountered 
 a specific case where touching a button doesn’t pass the touch message to 
 the button being tapped… unless I touch significantly below the button (I 
 also had to switch from mouse messages to touch messages in this 
 particular case.) This is not a general issue. It only happens when I show 
 a group  containing the buttons in question and while this group is 
 displayed there is repeat loop running that includes  “wait with messages” 
 (I’m faking a modal dialog.) I encountered this once before under the same 
 circumstances (a fake modal dialog while moving an iOS app to Android) and 
 simply switched to using the built in dialog. Unfortunately, that won’t 
 work in this case.  Any thoughts?
 
 --
 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
> 
> 
> ___
> 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: The Dreaded tsNet "Error Previous request not completed" iOS app

2021-11-19 Thread Mark Waddingham via use-livecode

On 2021-11-19 17:20, Ralph DiMola via use-livecode wrote:
I just wanted to thank Jacqueline Landman Gay and Charles Warwick for 
this

thread
https://www.mail-archive.com/use-livecode@lists.runrev.com/msg113554.html

I still wonder how more than one synchronous operation can be in play 
at the

same as synchronous operations are blocking. Oh well I works now with
tsNet-Pro. Well worth the price...


So technically 'synchronous' libURL operations are not blocking - they 
use a nested wait. As libURL is a script library, and uses engine 
sockets (and thus messages), they need to get messages and so all 
messages also occur. Indeed, this also means you can handle progress 
notifications, and whatever means you choose to show the UI is currently 
'blocked' because your script is busy.


It does mean you do have to be somewhat careful with `get url` and 
friends - since you can end up in a bit of a recursive mess (i.e. if a 
message fires while a get url is going on, and you do another get url 
etc. etc.).


There is a request in BZ to make tsNet's synchronous calls truly 
blocking - however that would probably need to come with some sort of 
automatic 'busy' indicator over all currently open windows to prevent UI 
events getting queued / lost (and users being confused why things don't 
work at certain points!). The upside of that is that it might prevent 
'mysterious' problems with accidental recursive waits which can happen 
at the moment.


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: Broken: November use-livecode Archive!

2021-11-18 Thread Mark Waddingham via use-livecode

On 2021-11-18 18:13, Curry Kenworthy via use-livecode wrote:

The November use-livecode Archive has been broken
for around 20 hours:




Its a side-effect of deleting a recent post which contained sensitive 
information (obviously we can't get rid any copies elsewhere, but can on 
our server). We are aware of the issue and will endeavour to rectify the 
problem tomorrow.


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: How to restrain impatient tsNet?

2021-11-07 Thread Mark Waddingham via use-livecode
I think tsNetSetTimeouts is what you need :)

Warmest Regards,

Mark

Sent from my iPhone

> On 7 Nov 2021, at 16:51, Ben Rubinstein via use-livecode 
>  wrote:
> 
> 
> I'm finally moving an app from LC 6.7 to LC 9.6.5 (huge thanks to Mark W for 
> fixing the accumulating/sorting delay loops, which has made this possible).
> 
> I've hit what I hope is the last hurdle: at one point in its processing, the 
> app has to load a resource over HTTP, which is s.l.o.w. - it typically takes 
> around 8 minutes at the moment.
> 
> By setting the sockettimeoutinterval to the extreme 1800 (i.e. half an hour) 
> this has been fine.
> 
> But under 9.6.5, in spite of this setting, it craps out within a minute with 
> the message
>tsneterr: (28) Operation too slow. Less than 1000 bytes/sec transferred 
> the last 30 seconds
> 
> Does tsneterr ignore the sockettimeoutinterval? Is there some other property 
> I can set to persuade it to be patient?
> 
> TIA,
> 
> 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: LC 9.6.5 RC 2 Speed Test

2021-11-05 Thread Mark Waddingham via use-livecode

On 2021-11-05 12:32, Curry Kenworthy via use-livecode wrote:

Absolutely; thanks!
I'll do that within the next few days.

(Should I use the old speed bug 21561 or a new one?)


If you just add it as another example stack to Bug 21561 that would be 
fine - there's a good chance its multiple actual issues (just as the 
existing stack is/was) :)


Thanks in advance!

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: LC 9.6.5 RC 2 Speed Test

2021-11-05 Thread Mark Waddingham via use-livecode

On 2021-11-05 11:05, Curry Kenworthy via use-livecode wrote:

My first LC 9.6.5 RC 2 Speed Test -

Results on Windows 10, current WordLib

Ratings:

- LC 9.6.5 RC 2 vs LC 9.6.3: 5 Wins, 0 Losses
- LC 9.6.5 RC 2 vs LC 6.7.11: 2 Wins, 3 Losses

Conclusion:

Good progress; if we follow up on these gains
and locate other areas needing optimization,
LC 10/11 can be pretty fleet of foot!


Well that is pleasing to see.

Is there any chance you can package up the files used to test along with 
the stack and submit as an issue to BZ? That way we can take a look to 
see what is causing the significant differences with C and E, in 
particular?


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: Lemniscate Polygon

2021-11-03 Thread Mark Waddingham via use-livecode

Hi Roger,

On 2021-11-02 22:27, Roger Guay via use-livecode wrote:

Dear List,

Bernd has produced an absolutely beautiful animation using a
Lemniskate polygon that was previously provided by Hermann Hoch. Can
anyone provide some help on how to create this polygon mathematically?
Since the equation for a Lemniskate involves the SqRt of negative
numbers, which is not allowed in LC, I am stumped.

You can find Bernd’s animation here:
https://forums.livecode.com/viewtopic.php?f=10=36412



In general lemniscates are defined as the roots of a specific kind of 
quartic (power four) polynomials of the pattern:


(x^2 + y^2)^2 - cx^2 - dy^2 = 0

So the algorithms for solving them you are probably finding are more 
general 'quartic polynomial' solvers - just like solving quadratic 
equations, the full set of solutions can only be computed if you flip 
into the complex plane (i.e. where sqrt(-1) exists) rather than the real 
plane.


However, there is at least one type of Lemniscate for which there is a 
nice parametric form - Bernoulli's lemniscate, which is a slightly 
simpler equation:


(x^2 + y^2)^2 - 2a^2(x^2 - y^2) = 0

According to https://mathworld.wolfram.com/Lemniscate.html, this can be 
parameterized as:


x = (a * cos(t)) / (1 + sin(t)^2)

y = (a * sin(t) * cos(t)) / (1 + sin(t)^2)

Its not clear what the range of t is from the article, but I suspect it 
will be -pi <= t <= pi (or any 2*pi length range).


So a simple repeat loop where N is the number of steps you want to take, 
and A is the 'scale' of the lemniscate should give you the points you 
want:


repeat with t = -pi to pi step (2*pi / N)
   put A * cos(t) / (1 + sin(t)^2) into X
   put A * sin(t) * cos(t) / (1 + sin(t)^2) into Y
   put X, Y & return after POINTS
end repeat

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: Number of items

2021-10-25 Thread Mark Waddingham via use-livecode

On 2021-10-25 16:22, Paul Dupuis via use-livecode wrote:

Why is it a feature? (I'm sorry, I am sure it has been explained
before in these lists)


Its a fundamental rule in the way xTalk string lists work.

It is neither a bug nor a feature - it is a rule - much like xTalks are 
one-based rather than zero-based for indexing.



I searched the Quality Center and could find no open bug entry for
this. As LC 9.6.3 still gives and item count of ",1" as 2 and an item
count of "1," as 1 that this is indeed the expected behavior?!?


There is no bug about it because it is not a bug.


I would have personally expected them both to be 2, but perhaps these
is a reason trailing empty items are not counted?


Trailing delimiters in LiveCode (xTalk) string lists are ignored. If you 
want to express an empty last item in a string list you have to append 
an extra delimiter. i.e.


  the number of items in "" == 0
  the number of items in "," == 1
  the number of items in ",," == 2

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: Some questions about Command-line argument parser library

2021-10-19 Thread Mark Waddingham via use-livecode

On 2021-10-18 23:04, matthias rebbe via use-livecode wrote:

Mark,

thank you very much for your explanations.

It works now.

Would  you please be so kind to also explain what for the
argumentArray can be used?

GetOpt(grammar [, argumentArray])

Okay, i could use it for testing in the LC IDE, so i do not need to
compile and execute the standalone.
But is there another scenario where it would make sense to include
that array in the call?


It just makes it more flexible - you may need to pre-process the 
argument array before processing it for options - or perhaps some 
commands are just shorthand for others, so it allows you to separate the 
arguments from the thing which uses them e.g. in C, the main function 
passes you argv and argc, so you can in principal substitute at your 
leisure - indeed GetOpt() is based on the 'standard' C function getopt 
which does the same thing with the same grammer... The latter requires 
you pass in the argument array.



The environment function can also return "development command line"
The dictionary says about that : The stack is running in the
development environment with the "-ui" command line option.

So would i be able to run a stack by running the LC IDE with -ui, add
the stack as parameter and add also command line options, which then
could be parsed with getop()?


Heh - I can't remember off the top of my head exactly what does work 
there - the licensed editions of LC were always a bit different from 
community. I did have to make some tweaks for 9.6,4 though to ensure all 
our build systems still run (we use LiveCode for a fair bit of stuff 
which occurs after the engine is built) so perhaps try it and see? :)


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: Some questions about Command-line argument parser library

2021-10-18 Thread Mark Waddingham via use-livecode

On 2021-10-18 15:14, matthias rebbe via use-livecode wrote:

Hello,

is there anyone who uses the Command-line argument parser library?

I am not sure how i can get the value that is attached as parameter
when the programm is started from the command-line

Let's say i call my program like this  ./myprogram -m=SomeParam

So how do i get the value SomeParam?I thought it is in the array after
getop() is called.

My code looks like this

put getopt("m,macadress") into tParams
if "macadress" is among the keys of tParams["options"]
then put tParams["options"]["macadress"] into tValue


You are using it correctly - but I think you've omitted a `=` from the 
end of the option specification:


Each option specification can end with a `=`.  This indicates that
the option expects an argument.  For example, with the grammar
`-o,--output=`, the option can be specified like `-o file`, `-ofile`,
`--output file`, or `--output=file`.

[ FWIW there is a 'typo' in the docs there the grammer being exhibited 
should be `o,output=` I think! ]


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: how to autodetect inclusions in a password protected stack

2021-10-15 Thread Mark Waddingham via use-livecode

On 2021-10-15 08:41, Tiemo via use-livecode wrote:
When you build a standalone, the inclusions can't be detected 
automatically,

when the stack is pw protected.

I am working with pw protected stacks and have copied manually the 
needed
externals in my externals folder on windows or in the app bundle on mac 
from

the beginning of the days.

After years I am asking myself, what the regular approach is. Is there 
is an
automated build including the externals with pw protected stacks? How 
is

this meant to be done correctly?


If your stacks are password protected then the automated detection 
process cannot run as it needs to iterated over all scripts looking for 
keywords to suggest what you are using (a process which is, 
unfortunately, not 100% reliable).


Therefore, in this case you have to select inclusions manually in the 
Standalone Builder and choose the things you use explicitly.


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 20:12, Pi Digital via use-livecode wrote:

Quite right. I make sure it’s the main stack selected and that all
other stacks, inspectors and editors are closed just in case. Then, as
you have it laid out in steps 2 to 4 and 4 and 4 ad infinitum. :)

That’s all there is to it.

There is nothing, as I am aware, that is loading any other external
stacks at all. They only reference to substacks of the main.

What do we check next?


So we need to try and work out what is causing the load of a stack with 
the same name of that in memory (my hunch is that there is a filename 
reference to a stack somewhere, which is being triggered, and reloading 
the stack which has just been saved-as from it original location).


If you:

  edit script of stack "revbackscriptlibrary"

Find the `reloadStack` handler and then add:

  put the executionContexts

At the very top of the handler - then you should get the backtrace of 
what handlers are executing at the point the reloadStack message is sent 
which should help pinpoint the culprit.


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 17:25, Brian Milby via use-livecode wrote:

I would be more of a fan of lowering the engine check to just a
warning vice a hard error/prohibition.  Like you said, if you don’t
use the long name then most of the time you are going to reference the
earliest opened version of the stack (based on the linked list of open
stacks).  But if you reference an object within the same stack (or at
least the visible card), it can reference by short name.  I guess I
should expand my test stack to check that.


I'm not quite sure how the engine would give a warning - the behavior 
being discussed in this thread is the way the IDE deals with how the 
engine deals with a specific case...


In general, the engine will either let something happen or it won't. In 
this specific case, it doesn't let implicit opens of stacks (which is 
what all initial openings of stacks are when you use a 'stack ' 
chunk are - given the potential disconnect between what  is, and 
what stackfile might actually be loaded) proceed if there is already a 
stack with the same name in memory...


However it *does* send a message 'reloadStack' that can be handled so 
script can decide what to do.


Indeed, this handler could happily let things go ahead:

  on reloadStack pStackName, pPath
local tOldFilename
set the name of stack pStackName to (pStackName & "~")
put the filename of stack pStackName into tOldFilename
set the filename of stack pStackName to "this is a unique name"
go stack pPath
set the name of stack "this is a unique name" to pStackName
  end reloadStack

The IDE chooses not to do this to stop the large number of other issues 
which could arise from having multiple stacks in memory with the same 
name (in an environment where it might happen 'by accident', rather than 
for any particularly controlled reason as might be the case in a 
standalone environment written to cope with it).



I can see a couple of ways to implement this where it would not impact
existing code.  First would be a global flag to enable opening of
files with the same name (default to off/false).  The second would be
a “force” parameter to the open command which would bypass the check.


I guess my real question here is what would be the purpose of that? i.e. 
What problem does it solve?


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 17:10, Pi Digital via use-livecode wrote:

The ‘save/purge/cancel’ is only intuitive to you it seems because you
understand the background. It doesn’t seem to make sense to us (and
certainly not a newcomer) because we have only our experience from
other software to go on and how we expect it to work. If we do a
saveAs in any other ware, we would never see a purge option. Maybe
just an ‘are you sure’ or a ‘this will have this kind of effect’
warning. So we would never expect this kind of behaviour from software
and know what to do with it. Hence the immediate initial responses to
my OP (which were hilarious by the way, much needed light relief).


As I said, this isn't anything to do with 'Save As' specifically - 'Save 
As' is doing precisely what you would expect... i.e. Saving the 
stackfile to a different file, and just as when you do that in any other 
application the filename of the stack changes to be the new filename.


What you are seeing is the mechanism which is in place to prevent two 
mainstacks of the same name being loaded into memory at once. That 
mechanism *only* occurs *if* something has attempted to load a stack 
into memory when there is already one with the same name (but a 
different filename).


The question to ask is why, in your case, 'everytime you do a Save As' 
is that mechanism triggered? i.e. There must be some script that is 
running somewhere (whether it be IDE, plugin, or code in one of the 
project's stacks) which is causing it.


So the first thing to ask is, is the recipe as simple as:

  1) Select stack you want to 'Save As'
  2) File > Save As
  3) Give a different name and Save
  4) Duplicate name Save/Purge/Cancel dialog appears?

Or is there any more to the recipe?

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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 15:57, Brian Milby via use-livecode wrote:

Clone stack avoids the check.  It is not that hard to get multiple
stacks with the same short name but different long names in memory (in
a standalone).  The engine makes sane choices when referencing the top
stack in that case.  Any individual stack can be referenced via the
long name.


Yes indeed, you don't actually need to even use clone stack - just 'set 
the name of' will do it.


However, the fact you can do that from script is a different case from 
what the IDE should let you do in the normal course of things (and 
indeed, perhaps we should plug the holes in the engine which let it 
happen) in (a perhaps vain?) attempt to stop people tying themselves 
into too many knots.


Things like the 'topStack' and 'defaultStack' are only sane references 
to the actual underlying stack if they are used as direct syntax (where 
they resolve to the internal pointer). As soon as they are rendered to a 
string (e.g. when passed as an argument) that link is gone - further, if 
a stack has not been saved then there is no way to distinguish one from 
the other with any string-based reference (a stack's long id is only 
different from its name / long name if it has a filename).


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 15:38, Mark Waddingham via use-livecode wrote:

On 2021-10-07 15:26, Pi Digital via use-livecode wrote:

Hi Mark (both :) )

Thanks for your explanation. Very thorough.

What I don’t understand is why the engine needs to delete the old
reference (weak handle) when invoking a ‘save as’. Is it not just a
matter of resaving you a new location and making the pointer to the
storage device for that instance? Why does it need to save it and then
remove from memory at all? Just carry on with what is already in
memory without the need to reload. That’s why we use a ‘save as’
anyway.


This isn't related to 'Save As' - nor is the engine doing anything
here beyond sending a message - which is enforcing the 'only one main
stack with a given (short) name exists in memory at any one time'
invariant.


Sorry Sean this thread had gone on through several things that I missed 
what you said in your original post...


You explicitly said you were getting that dialog when doing a 'Save As' 
(presumably from the file menu)... There must be more to it than that 
though.


The 'Save As' menu item in the IDE uses (with a bit of cruft around it) 
'save stack ... as ' - all that does is serialize the stack 
(as it is in memory) to the new file, and update the filename of the 
stack in memory.


There should be no reloadStack mechanism (as outlined above) going on 
*unless* something is causing a message to fire which is trying to load 
the stack from the previous filename.


Indeed, is this a multi-stack system which you are working on? Is there 
a way your code (which is being triggered somehow after save) is 
referencing the stack you just saved as, by its original filename?


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-07 15:26, Pi Digital via use-livecode wrote:

Hi Mark (both :) )

Thanks for your explanation. Very thorough.

What I don’t understand is why the engine needs to delete the old
reference (weak handle) when invoking a ‘save as’. Is it not just a
matter of resaving you a new location and making the pointer to the
storage device for that instance? Why does it need to save it and then
remove from memory at all? Just carry on with what is already in
memory without the need to reload. That’s why we use a ‘save as’
anyway.


This isn't related to 'Save As' - nor is the engine doing anything here 
beyond sending a message - which is enforcing the 'only one main stack 
with a given (short) name exists in memory at any one time' invariant.


When a stack is deserialized from the on-disk file - before it is 
'hooked up' to anything (i.e. added to the list of things considered for 
any sort of search), it sweeps through all loaded mainStacks and checks 
to see if there is a name conflict (i.e. short name of new stack matches 
that of old).


If there is (and the filenames are different) then it deletes what it 
has just loaded and sends a 'reloadStack' message. Otherwise, it hooks 
the new loaded stack up to the internal list of things considered actual 
stacks.


The IDE handles the reloadStack message - it shows the dialog in 
question.


If you choose 'Cancel' it takes no action - so nothing changes (no new 
stack loaded, no old stack deleted).


If you choose 'Purge' the IDE does its best to remove the current stack 
in memory and *then* trys to load the new stack (from the different 
filepath) - as (in principal) there is no longer any stack in memory 
with the conflicting name, then engine loads it and things carry on.


If you choose 'Save' the IDE does the same as above except that *before* 
it tries to remove the current stack from memory, it saves (save as, if 
the current stack has no filename).


So the looping problem here lies somewhere in the process removing the 
existing stack from memory / saving it.


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: Stack with the same name loop

2021-10-07 Thread Mark Waddingham via use-livecode

On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:

That's what I do as well. Kill, then go do something else for a bit.

Reading the code that invokes this dialog (the reloadstack handler in
revbackscriptlibrary.livecodescript) isn't much help. It's only the
IDE that can't handle this, not the engine.

This would all be moot if the IDE used the long id of the stack
instead of just the short name of the stack, but that would require
work.


That isn't true - the problem is a lot deeper than that.

Most 'stack' related engine syntax works with the short name of stacks 
e.g. defaultStack, topStack, stackFiles.


The IDE is built using the engine, so has to work within the limitations 
the engine has.


Internally the engine references stacks by 'weak handles' (basically 
pointers which 'know' when the thing they are pointing at has been 
deleted) - it does not use names... However the way stacks are 
referenced by script (as mentioned above) do use the short name - to 
keep things simple.


Of course it would be possible to add new syntax and such - and it would 
be possible to update the IDE to use it (and thus the 'irksome' dialog 
could be removed).


However, the reality is that, that endeavour (which would be a very 
large amount of work) would only shift the problem - onto users 
themselves.


If user code did not use the new syntax, then chances are they would end 
up causing really hard to track down issues in their own code due to 
having two stacks with the same name. This is regardless of whatever 
resolution order was chosen to resolve conflicts - unless user code also 
uses unique stack references, there is no choice which would not stop 
problems from happening.


I'd like to point out that this is not me copping out here - it is 
merely pointing out that simplicity does come with restrictions - and as 
it stands, one of these restrictions (with livecode) is uniquely named 
stacks.


I'd further point out that 'critical things having unique name' isn't 
that rare. For example, you can't have two files with the same name in a 
folder for example (even though on UNIX systems, every file has an 
internal unique integer id - the inode number) and you can't have two 
handlers, variables, methods, types (or any named thing) with the same 
name (in the same namespace) in any language that I know of.


So, may I suggest, the problem to solve is to figure out why the dialog 
which spawned this thread does not work correctly in some circumstances?


I say some circumstances, because it does work precisely as advertised 
in a (fresh) IDE after it has been started:


  1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove 
from memory
  2) Create another stack "Foo" - place a button on it and save it as 
"FooButton.livecode"
  3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty 
appears (and FooButton goes)

  4) Add a tab control to FooEmpty.
  5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is 
saved and FooButton appears.
  6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty 
appears (now with tab control) and FooButton has gone.


The correct behavior of that dialog is precisely what you would expect 
from the button names:


  1) Cancel - the loading of the new stack does not happen.
  2) Purge - the existing stack of the same name is removed from memory 
without saving first, and the new stack is loaded.
  3) Save - the existing stack of the same name is saved and then 
removed from memory, and the new stack is loaded.


The effect observed (the looping) could be an interaction with a 
component in the IDE (which somehow causes the stack which should be 
being removed to be reloaded), or it could be some code pattern in user 
stacks which cause much the same problem. In the former case, we need to 
fix the IDE to be 'purge safe in this case', in the latter case we need 
to understand the pattern so that we can change the mechanism to not be 
affected by it.


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: What's in LC 9.6.4?

2021-09-17 Thread Mark Waddingham via use-livecode

On 2021-09-16 11:50, Curry Kenworthy via use-livecode wrote:

What are the big LC 9.6.4 changes versus 9.6.3? Thanks.


The licensing and the fact it is single edition - beyond that 9.6.4 
should be functionally identical to 9.6.3 (hence why the release notes 
do not list any IDE/Engine changes!).


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: PATCH command in tsNetCustom

2021-09-14 Thread Mark Waddingham via use-livecode

On 2021-09-14 12:07, Sean Cole (Pi) via use-livecode wrote:
put tsnetCustomSync(tAddr, "PATCH", tHeaders, tRecvHeaders, 
tResultCode,

tBytes) into tData

Where does tJson get put?


I think you want tsnetCustomUploadSync here - that has an extra 
parameters for the body to upload, and return.


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: Sorting text is *VERY* slow in LC9 on Windows (Re: Accumulating text is *VERY* slow in LC9 on Windows)

2021-09-12 Thread Mark Waddingham via use-livecode

On 2021-09-10 19:10, Ben Rubinstein via use-livecode wrote:

The other was
The only caveat is that it might cause apps mutating lots of 
medium->large strings concurrently to take up more memory in 
general... > ... (and any issue arising from that could be resolved by 
moving to the 64-bit

windows engine).


I have been doing my tests on the 64-bit Windows engine. What am I 
missing?


The change I am making to the buffer extension rules means that mutable 
strings (i.e. those which the last action was modifying them, rather 
than copying them / fetching them) will take up more space than they did 
before to allow for possible extension (previously the maximum 'just in 
case' space which was allocated was 63 bytes).


This means that applications may take up more memory as a result (if 
they happen to have lots of large mutable strings in play at any one 
time).


32-bit windows engines have a maximum address space of 3Gb - so if an 
app was already approaching that limit, this might tip them over to 
start causing out of memory errors.


However, in this case, switching to use the 64-bit windows engine would 
resolve the problem as 64-bit address space is substantially larger.


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: Sorting text is *VERY* slow in LC9 on Windows (Re: Accumulating text is *VERY* slow in LC9 on Windows)

2021-09-10 Thread Mark Waddingham via use-livecode

On 2021-09-10 14:06, Mark Waddingham via use-livecode wrote:

The windows heap is much more prudent than UNIXy counterparts it would
seem - where UNIX heaps will happily leave plenty of free space (which
the heaps know about and thus can re-use), Windows appears to avoid
that like the plague (which I'm sure is the case for lots of
historical reasons and backwards compatibility). [ To give a very
rough analogy, the map of used space in a heap on windows is like a
block of cheddar; whereas on UNIXy systems it will be like a block of
edam ].


I of course meant 'Swiss', not 'Edam'!

--
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: Sorting text is *VERY* slow in LC9 on Windows (Re: Accumulating text is *VERY* slow in LC9 on Windows)

2021-09-10 Thread Mark Waddingham via use-livecode

On 2021-09-02 18:38, Mark Waddingham via use-livecode wrote:

We will endeavour to fix for 9.6.5-rc-1 (due 'real soon now'!).


So I have been prodding the windows 'accumulating large strings' speed 
problem this week (in amongst other things).


It is definitely memory allocation causing the problem.

The rule for extending a string buffer when inserting/appending more 
text is pretty much the same as 6.7 (the amount of 'extra space' it asks 
for each time is a little less - but changing it to the constant used in 
6.7 makes no difference). What is different between 6.7 and 7.0+ is the 
memory allocation patterns of the engine itself and I think it is this 
which is invariably causing a whole new buffer having to be allocated 
when appending to large strings, rather than the existing one being 
extended.


The windows heap is much more prudent than UNIXy counterparts it would 
seem - where UNIX heaps will happily leave plenty of free space (which 
the heaps know about and thus can re-use), Windows appears to avoid that 
like the plague (which I'm sure is the case for lots of historical 
reasons and backwards compatibility). [ To give a very rough analogy, 
the map of used space in a heap on windows is like a block of cheddar; 
whereas on UNIXy systems it will be like a block of edam ].


So anyway, long story short, making a string buffer grow in proportion 
to its size appears to mitigate the problem - I still need to finesse 
things a bit though to ensure that memory starvation doesn't occur when 
you have a couple of large mutating strings but all being well we should 
be able to get something together for 9.6.5-rc-1.


The only caveat is that it might cause apps mutating lots of 
medium->large strings concurrently to take up more memory in general 
(i.e. in that extra unused 'just in case' space at the end of each 
buffer) but no more than the same apps would on any other (UNIX-based) 
platform (and any issue arising from that could be resolved by moving to 
the 64-bit windows engine).


For reference, the bug about the string accumulation problem as posed by 
Ben is https://quality.livecode.com/show_bug.cgi?id=23319 (this will 
also fix the sort speed too - as the final step the sort command 
performs internally is re-accumulating the string in the new order).


Warmest Regards,

Mark.

P.S. I cannot really say whether this will help with the various 'IDE 
can be like treacle' on Windows problems - but it definitely can't hurt!


--
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: LiveCode 10 - what are your thoughts on the new features?

2021-09-09 Thread Mark Waddingham via use-livecode

On 2021-09-09 16:47, Mark Wieder via use-livecode wrote:

On 9/8/21 10:40 PM, Mark Waddingham via use-livecode wrote:


   put [1, 2, 3] into tVar2

is equivalent to:

   put 1 into tVar2[1]
   put 2 into tVar2[2]
   put 3 into tVar2[3]


That's still ambiguous, though. Is

put [4, 5, 6] into tVar2

equivalent to

put 4 into tVar2[1]
put 5 into tVar2[2]
put 6 into tVar2[3]

or

put 4 into tVar2[4]
put 5 into tVar2[5]
put 6 into tVar2[6]


The former.

[ V1, ..., VN ] denotes a sequence which is an array mapping the key i 
to Vi.


{ "K1": V1, ..., "KN": VN } denotes a dictionary which is an array 
mapping Ki to Vi.


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: LiveCode Community - anyone up for maintaining the community edition?

2021-09-09 Thread Mark Waddingham via use-livecode

On 2021-09-08 22:54, Paul McClernan via use-livecode wrote:
I've already fixed a bug that I reported back in April in my fork(s) 
and

added a link to my fix to that bugzilla report.

https://github.com/PaulMcClernan/LiveCodeCommunity-IDE-DontPanicEdition


At this point in any changed relationship, it’s necessary to set out the 
new terms, as amicably as possible. Each side needs to clearly 
understand where they can and cannot go now. As our move away from 
supporting Open Source LiveCode is still very new, it’s likely the 
ramifications are not as yet understood.


I have to ask you (and anyone involved in that project, or any other 
forks) politely not to submit any changes back to bugzilla or anywhere 
else associated with LiveCode Ltd. as it creates a business risk for us.


We (LiveCode Ltd.) cannot take any code changes you make to your 
project's version of the LiveCode source-code and use them in our 
commercial code as (by default) it will be GPLv3 licensed, and the 
copyright of that will be held by the person who authored the changes; 
just as you cannot change the license from GPLv3 nor copyright 
attribution (LiveCode Ltd.) - whether explicit or implicit - of any 
existing line of code in your project's fork of the LiveCode 
repositories, nor take any changes which appear from now onwards in any 
commercial edition to incorporate into your project.


When we were running the open source project, we had in place a 
Contributor's License Agreement which meant that the copyright of any 
code authored by a contributor in any patch submitted to LiveCode Ltd 
was assigned to us. However, this only extended to contributions 
submitted through GitHub, where there was an appropriate immutable 
record of such submissions and it was universally clear what changes 
were being made. For obvious reasons, this no longer exists.


More generally, I must also ask you not to use the LiveCode mailing 
list, bug reporting system or LiveCode forums for discussions 
surrounding your fork - particularly related to plans, ideas, 
developments and changes which are being or have been made.


At no point do I want us to be the target of any sort of public ill-will 
or indeed lawsuit due to assertions of copyright theft, or appropriation 
of other people's ideas that were not clearly (whether implicitly or 
explicitly) proffered to us directly.


The only way to ensure that is for any forks (yours included) to stand 
completely independently and by themselves - with their own 
communication forums, distinctive product name and distinct branding so 
there can be no risk of confusion nor appropriation of anything from 
either side.


I should point out that recent events are actually nothing to do with my 
above words - I would have said the same to any fork maintainer who 
actively sought to advertise their fork within the existing LiveCode 
community - as defined by LiveCode's mailing lists, forums, bug 
reporting system, or any other forum owned and run by LiveCode Ltd. for 
the purposes of public interaction - or posted links to code changes 
from that project or on any such forum/system. Indeed, ensuring complete 
independence really is standard practice when forks are made of open 
source projects - OpenOffice and LibreOffice spring to mind.


We fully respect the legacy we have created in terms of the GPLv3 
source-code, copyrighted to LiveCode Ltd., which is forever preserved in 
the archived GitHub repositories in the LiveCode GitHub account which 
carry the LiveCode name. We have no issue with any or all forks or 
open-source GPLv3-based projects which might arise from that legacy.


All we ask is that any such project ensures that it respects LiveCode 
Ltd.'s intellectual property as embodied within that (through its GPLv3 
licensed, copyrighted source-code) and also respects LiveCode Ltd.'s 
right to assert itself as the only entitled user of the LiveCode name, 
trademarks and brand identity.


With all that said, I wish you, and anyone who joins you, well with your 
endeavour.


Have fun!

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: randomSeed maximum length

2021-09-09 Thread Mark Waddingham via use-livecode

On 2021-09-09 08:25, scott--- via use-livecode wrote:

Does the randomSeed have a maximum length?

Meaning, if the length of the provided number exceeds the maximum
length, does the provided number get truncated or dismissed or… ?


Its a signed 32-bit integer - so range is -2147483648 to 2147483647.

Numbers outside of this appear to end up setting it to -2147483648.

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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-09 00:37, Alex Tweedly via use-livecode wrote:

On 2021-09-08 01:33, Alex Tweedly via use-livecode wrote:


But
 put [1, 2, 3 ] into tVar2
isn't clear to me. If it was in Python it would be a list - but LC
doesn't have 'lists'.

Is it equivalent to
   put true into tVar2[1]
   put true into tVar2[2]
   put true into tVar2[3]    ??



and then On 08/09/2021 08:50, Mark Waddingham via use-livecode wrote:

Yes.


But I'm not sure he meant it :-)


No - 'he' didn't mean that ;)

I failed to look properly at the LHS of the puts in your example :D

  put [1, 2, 3] into tVar2

is equivalent to:

  put 1 into tVar2[1]
  put 2 into tVar2[2]
  put 3 into tVar2[3]

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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode
Heh - I think you are both right in different contexts...

For sure, when used as a noun in isolation (a couple) it refers to two - 
specifically either a pair of parallel but opposing forces (physics) or a pair 
of (usually romantically) involved individuals (some might wryly suggest that 
these two things are much the same ;) ).

I’d say though that when applied to another noun, it generally implies ‘some’ - 
not two specifically, or even three - but a definitely small number.

In fact I think it’s slightly more subtle than that in general usage though...

If applied to something which can be counted discretely (eg facts) - ‘a couple 
of’ implies a likelihood it was almost certainly two, but maybe three (as the 
exact number wasn’t really important). 

However, if applied to something which is continuous (and perhaps more 
importantly something humans are not that great at accurately estimating - eg 
time) it rarely means two exactly... 

After all when was the last time you said to someone - ‘I’ll just be a couple 
of minutes’ and were, indeed, exactly 120 seconds? ;) 

Sent from my iPhone

> On 8 Sep 2021, at 20:55, J. Landman Gay via use-livecode 
>  wrote:
> 
> My husband said the same when I told him about this thread. "Couple" means 
> two. I said yes, but colloquially it can mean "two or three or somewhere in 
> that range." We almost started a longer discussion about it, but I reminded 
> him of our 30+ years of ongoing talk about a "fact" so we both stopped.
> 
> Addendum: he claims there are "true facts." I say that is redundant, that a 
> fact is by definition true, and he's implying there are false facts (or as we 
> say in the US, "alternative facts.") This has been going on for years. It's a 
> friendly, amusing, kind of false disagreement. Then one day we just looked it 
> up in the dictionary and...a fact can either be a true bit of information, or 
> a generic datum.
> 
> And that spoiled all the fun.
> 
> On 9/8/21 6:14 AM, Keith Martin via use-livecode wrote:
 On Sep 7, 2021, at 11:04 PM, Martin Koob via use-livecode 
  wrote:
>>> 
>>> My wife and I have an ongoing disagreement about the term 'couple of’ in 
>>> terms of counting.  I say it means around 2 or 3ish.  She says it means 2. 
>>> Further she says if you wanted to say 3 or 4 you would say ‘a few’.
>> I'm the kind of person that distinguishes between 'like' (exclusive: similar 
>> to but not) and 'such as' (inclusive: similar to and part of the comparison 
>> set), so this is coming from a position of pedantry, but that's because I am 
>> a writer...
>> Strictly speaking, 'a couple' means two, no more and no less. In casual use 
>> (when counting, not when referring to relationship partnerships) it isn't 
>> unusual for it to be used in place of 'a few' and possibly mean three or 
>> even four, but it's not technically *correct.*
>> I too hope your wife's logic is what holds true!
>> :)
>> k
> 
> 
> -- 
> 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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-08 16:48, Ben Rubinstein via use-livecode wrote:

It requires an explicit '...':


Ahah! Not being a javascripter, I completely missed that, and thought
you were just omitting some text for clarity!

[Sidenote: what idiot decided to use ellipsis as an operator?? And not
even the ellipsis character, but three dots???].


Well the heritage of 'triple dots' for such things goes back to C - and 
I think the general idea is that its 'and the rest' (its used to mark 
variadic functions there).


In terms of using it as the operator in this case:

  foo a, b, ... tFoo
 => call foo with parameters a, b, 'and the rest' from tFoo

The reason why it isn't the ellipsis character is because it is 
generally advised to ensure that all core syntax of a language can be 
expressed in ASCII (for the antithesis of this idea - see APL!)


Interesting your missing of the all important operator being required 
reminds
of a mistake I did make way back when I added the ability to use a 
sequence

array as an array index...

   put tArray[tFoo] into tBar -- evaluates as tArray[1][2]


What the... ? [insert joke here - I wrote that without realising what
I'd done...]. I had no idea this facility existed. Is it documented
anywhere?


I'm pretty sure you were one of the people who motivated it (the other 
definitely being Trevor)...


It's definitely come up on the use-list before :D

It has been in the engine for years - maybe since 4.x or 5.x? The 
addition was more than likely buried in the release notes though...



Just to be clear, because the example below is ambiguous, given

  put "a" into tFoo[1]
  put "b" into tFoo[2]

would
  put tArray[tFoo] into tBar

evaluate as
tArray["a"]["b"]
or
tArray[1][2]

?


The former - if an array is encountered in an index, and is a sequence, 
the ordered sequence of values derived from the sequence is used as 
extra components of the path. Indeed, this happens recursively IIRC - 
i.e. if you have ['a', ['b', 'c'], 'd'] then the array path would be 
[a][b][c][d].


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: Send a table in an email.

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-08 11:02, Sean Cole (Pi) via use-livecode wrote:

Hi all

I'm trying to use the MIME encoder to send an email with a table in the
body. I have a field that has both plain text and a few lines that are
displayed as a table in the middle of it. I basically just turn on the 
v

and h lines and set tab stops.

mimeEncodeField... puts the text into the email body but does not seem 
to
format out the table. Is there a way to get it to recognise the table 
or

some other way of getting the table to display correctly in the email?


So the mime library call you are talking about is super simple - it just 
dumps the htmlText of the field into the HTML (so is fine as long as its 
just simple formatting involved), and then looks for inline images and 
attaches them as other parts.


The code is in the mime extension (com.livecode.library.mime) and the 
handler in question (mimeEncodeFieldAsMIMEMultipartDocument) is built 
out of other public mime library APIs... It would be relatively 
straightforward to create your own version and customize the HTML output 
to your needs.


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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-08 13:09, Ben Rubinstein via use-livecode wrote:
I'm also excited by the items in this list, at least the ones that I 
understand.


I am a bit disturbed by the Tail Expressions one, because to the
extent that I do understand it, I don't see how this doesn't break
existing code that passes an array, and will do so in the worst way,
i.e. silently, leaving the developer to figure out what's going on by
the secondary or tertiary effects. Am I wrong?


It requires an explicit '...':

put 1 into tFoo[1]
put 2 into tFoo[2]

myHandler tFoo -- passes a single argument: the array tFoo
myHandler ... tFoo -- passes two arguments: 1, 2 (the elements of 
tFoo)


Interesting your missing of the all important operator being required 
reminds of a mistake I did make way back when I added the ability to use 
a sequence array as an array index...


  put tArray[tFoo] into tBar -- evaluates as tArray[1][2]

I really should have thought to require explicit syntax there. i.e.

  put tArray[... tFoo] into tBar

The reason here is performance - if I had done that it would mean the 
engine would known that in the case of:


  put tArray[tFoo]

That it will only ever generate a path of length 1 to index the array - 
rather than pretty much all array expressions potentially being 
unbounded in length.


You live, you learn.


I'm very pleased about constant expressions. I do wonder whether this
raft of changes might also be the moment to do something about this
nasty little weirdness:
https://quality.livecode.com/show_bug.cgi?id=18390


Well constant expressions do alleviate that problem a bit:

constant kFormatArg = format("\"%s\"")

put format(kFormatArg, "Hello") => "Hello"
put format("\"%s\"", "Hello") => "Hello"

i.e. The use of `\` escapes in format, generates characters which format 
otherwise skips over as content - except `\` itself, so you have to be a 
little careful there. i.e.


   constant kFormatArg = "%s"

   put format(kFormatArg, "Hello") => "\Hello"
   put format("\\%s", "Hello") => "\Hello"

In regards to your comment on that report then yes that is a good idea - 
albeit a breaking change. However, I think that is probably best 
considered as part of a package of changes which improve the expression 
of string constants generally. After all, if tooling is going to be 
updated, it is better to do so 'all in one go', rather than in dribs and 
drabs. Multi-line string literals (as mentioned previously) would go 
into that 'package'.


Another thing we could consider at that point is adding a 'f' prefix to 
literals which imply they are C-style escaped (basically a contraction 
of 'format')... Indeed, we could even make that a way to introduce 
variable interpolation.


Also, at that point I'd probably suggest that we also allow ' or " to 
delimit strings.


So f'...' or f"...", '...\'...', "...\"...", '''...''', """...""".

(Specifically here I'm proposing that there would be no semantic 
difference between ' and " - they would merely enable trivial inclusion 
of the other quote type).




I also wonder whether this might be the moment to introduce another
bit of (completely non-breaking) syntactic sugar:
https://quality.livecode.com/show_bug.cgi?id=8945


Hehe - with integers being unbounded, there are plenty more version 
numbers in the future ;)


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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-08 11:35, Andre Garzia via use-livecode wrote:

I just don't understand this one, so no comment.


As I understand, this is LC version of the “spread operator”.  It
allows you to spread the elements of an array as the arguments to a
handler.

The code:

  put “an...@example.com ” into tDataA[1]
  put “Andre Garzia” into tDataA[2]

  sendEmail …tDataA

Is syntactically equivalent to:


  put “an...@example.com ” into tDataA[1]
  put “Andre Garzia” into tDataA[2]

  sendEmail tDataA[1], tDataA[2]

Which means that you can code the “sendEmail” command to have two
string arguments instead of an array, as shown below:

  command sendEmail pEmail, pFullName
// send your email
  end sendEmail

The spread operator will pass every array element as an argument to
the handler.


Yes - that is precisely what it is :)


It would be beneficial if this feature would also come paired a “rest
operator” that collected extra arguments in an array, so that we could
declare the “sendEmail” handler as

  command sendEmail pEmail, pFullName, …pMoreArgumentsA
// stuff
  end sendEmail

This way, if the call uses an array that contains more than two
elements, the remaining parameters are collected in the final
“pMoreArgumentsA” array. That if what I would like to have, LC didn’t
say anything about this but it is very common in other languages to
implement both operators at the same time.


Indeed.

The key thing here is that doing that adds to the handler signature 
syntax which I'd prefer to do as part of a more substantial improvement 
to the expressibility of that aspect of the language.


Therefore...


In the case of LiveCode there is an alternative though. We can use
“paramCount” and “param()” to grab the extra parameters, but that
requires us coding it while something like a “rest operator” do that
for us automatically.


The feature I omitted from the list and which does pair with the spread 
(or tail) operator is a tweak to the params function... Namely:


   params(N) => returns a sequence or params starting from the Nth

So in the above:

   command sendEmail pEmail, pFullName
 local tMoreArgumentsA
 put params(3) into tMoreArgumentsA
 ...
   end sendEmail

This is a direct evolution / useful addition to the current way existing 
handlers manipulate arguments - and, more importantly, saves a blob of 
code I've seen 100's of times in code which needs to forward arguments:


   command foo
 local tParams
 repeat with i = 1 to the paramCount
put param(i) into tParams[i]
 end repeat
 ...
   end foo

Also this feature is largely orthogonal to any tweak to handler 
signature (i.e. the merge operator, Andre suggests above) as it just 
manipulates the parameters as defined by the signature. For example, in 
the imagined case of a 'merge' clause:


   command merged pFoo, pRestA...
   put the paramCount into tCount -- gives 2
   put param(1) into tFoo -- would give pFoo
   put param(2) into tRestA - would give pRestA
   end merged

Here there are two parameters - pFoo, and an (array) pRestA which 
contains the rest of the parameters passed.


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: LiveCode 10 - what are your thoughts on the new features?

2021-09-08 Thread Mark Waddingham via use-livecode

On 2021-09-08 01:33, Alex Tweedly via use-livecode wrote:

But
 put [1, 2, 3 ] into tVar2
isn't clear to me. If it was in Python it would be a list - but LC
doesn't have 'lists'.

Is it equivalent to
   put true into tVar2[1]
   put true into tVar2[2]
   put true into tVar2[3]    ??


Yes.

A sequence in LC is a numerically-keyed array where the keys range from 
1...the number of elements.


Admittedly they are (currently) still implemented as a 'normal' array 
internally, but they do have different functionality in `repeat for each 
element` which iterates in numeric order, and not hash order.



Why can't I say
    put { myvar: "first", anothervar: tWhatever } into tVar2   ?


So if one treats array literals as an equivalent to an ordered sequence 
of put statements (which is the canonical interpretation really!) then 
there is, in principal, no problem with allowing non-constant 
expressions for both key and value.


Certainly non-constant value expressions are no problem at all, and 
would be included in the initial implementation... I'm not averse to 
non-constant key expressions either really, I'm just a little skittish 
over the resulting reservation of ':' (which is probably fine), and the 
interplay with variables and unquoted-literals (more in terms of 
difference that might occur between what the engine thinks something 
means and what the writer intended).



But I was disappointed to not see my two biggest 'constant' wishes

1. multi-line constants e.g. amongst other ways, Python's

put """line 1

line 2

line 3""" into tVar


I'm not averse to the idea of multi-line literals - although 
constant-folding does go a long way to assuage the problems they solve 
in many cases.


e.g. You can use format("dfsdf\ndfgdfg") for short strings with newlines 
in, and any chained sequence of concatenations of constants will be 
evaluated at compile time.


The main issue here is the effect on tooling really - any code which 
processes LiveCode Script in any way would need to change to take them 
into account. This not only includes syntax highlighters and editors but 
any code which groks script for other reason. This means that what might 
be a relatively simple change to the engine, actually introduces a 
ripple effect where the whole implementation burden is a great deal 
higher.


[ I'd point out that I don't think there is a single piece of tooling in 
existence which actually fully supports the *current* lexical structure 
of LiveCode - which has not actually changed since day dot - including 
the existing Script Editor ]


That being said, in terms of what multiline syntax I'd propose, if it 
were to be added - I'd be in favour of Swift's model. Most other 
languages have added multiline strings with no thought to code 
structure, however the Swift team really have:


   var foo = """
 Line 1 - spaces before stripped
 Line 2 - spaces before stripped
 """

There are two simple rules at play here.

The first is that no string content is present on the lines containing 
""" - i.e. the string content starts on the line after the opening """, 
and the string content ends on the line before the closing """.


The second is that whitespace is stripped from each line of the string 
content based on the whitespace before the final """. i.e. If the """ is 
indented by 3 spaces, then 3 spaces are removed from all lines of the 
content.


This means indenting of such literals is no different from any other 
construct - and is merely predicated on identifying the lines in such a 
literal as continuations (i.e. each line is an extension to the last).



2. global constants. Most compiled languages will allow an 'include'
file which can specify constants, which you can then rely on to be
defined properly (and the same) everywhere. So that's probably too
much at odds with LC's model - but could be handled by 'protect'
global variables (or, I'm sure, another 10 ways that Mark W. could
think of).


So if by 'global constant' you mean being able to define a token which 
means the same thing in all scripts - then yes, that does not really fit 
at all as it breaks the logical independence of all scripts in terms of 
what tokens mean.


Put another way, all scripts would have to be recompiled when a script 
defines such a thing, which would then potentially change the meaning of 
any script if it happens to internally use said token for something else 
(in the worse case scripts which did not have syntax errors before might 
do so after). This is why you have to declare global variables in all 
scripts which use them.


The request for 'global constants' comes up repeatedly, but I don't 
really recall anyone proposing a single use-case which couldn't be 
solved in a 'better' (relative to xTalkiness existing featurs) way :D


Warmest Regards,

Mark.

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

___

Re: Text encoding.

2021-09-02 Thread Mark Waddingham via use-livecode

On 2021-09-02 18:34, Mark Waddingham via use-livecode wrote:

The character itself is the 'undefined/illegal codepoint' which has a
different sequence of bytes for each of the main
(UTF-8/16LE,BE/32LE,BE) encodings. If you do `hexdump -c | less` on
the file, then if it is UTF-8 there will be three bytes before the T,
or 4 if it is UTF-16.


Correcting myself - 4 if it is UTF-32 (which is exceptionally unlikely); 
2 if it is UTF-16.


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: Sorting text is *VERY* slow in LC9 on Windows (Re: Accumulating text is *VERY* slow in LC9 on Windows)

2021-09-02 Thread Mark Waddingham via use-livecode

On 2021-08-30 20:22, Ben Rubinstein via use-livecode wrote:

Thanks to Mark Waddingham's advice about using a buffer var when
accumulating a large text variabel in stages, I've now got a script
that took 8 hours under LC9, and (8 minutes under LC6) down by stages
to just under 1 hour under LC9.

Has anyone else noticed something of this sort? As I said, the effect
varies: e.g. 54 seconds versus 1 second; 22 seconds versus 1 second.
So it may not be so noticeable in all cases.


It will undoubtedly be the same problem as your accumulation slowness - 
as the sort routines use (essentially) `put after` to reconstruct the 
string after sort. So fixing the accumulation slowness will fix sort.


Indeed, there's a further optimization to be had in sort now I come to 
think of it (probably relatively minor after the accumulation problem is 
sorted) - the sorted buffer size (in chars) will be the same as the 
input buffer size as its just a permutation of the lines - so the output 
buffer can be pre-allocated at the right size.


We will endeavour to fix for 9.6.5-rc-1 (due 'real soon now'!).

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: Text encoding.

2021-09-02 Thread Mark Waddingham via use-livecode

On 2021-09-02 12:12, Alex Tweedly via use-livecode wrote:

Sorry to drag us off the interesting topic of licensing :-) into some
Livecode question.

I know little or nothing about Unicode, text encodings, etc. - so my
question is indeed naive.

I have a text file (War & Peace from Project Gutenberg), about 3.4Mb.
The Mac describes it simply as "Plain text".


Do you have a link to the file handy?



When I read that into a variable, and then do
    replace tChar by SPACE in tWholeText
it takes between 1000 and 4000 millisecs - versus the 8-10 msecs I had
expected from other samples.

If I put in
    put textEncode(tWHoleText, "UTF8") into tWholeText
before the replace then it does indeed tae 8-10 msecs.


What exact code are you using in both cases? (including reading in the 
file, char you are replacing etc.)



Additional info - I just discovered that according to 'more' command
line, the file start with :

The Project 


That suggests the file is unicode encoded - it is a 'byte order mark'.

The character itself is the 'undefined/illegal codepoint' which has a 
different sequence of bytes for each of the main (UTF-8/16LE,BE/32LE,BE) 
encodings. If you do `hexdump -c | less` on the file, then if it is 
UTF-8 there will be three bytes before the T, or 4 if it is UTF-16.


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: Accumulating text is *VERY* slow in LC9 on Windows

2021-08-26 Thread Mark Waddingham via use-livecode

On 2021-08-25 18:15, Ben Rubinstein via use-livecode wrote:

I simplified it down to this (pointless) loop which just rebuilds a
table one line at a time:

   local tNewTable
   repeat for each line tRow in tWorkTable
  put tRow & return after tNewTable
   end repeat

with these results:

6.7.11 MacOS  8 seconds
6.7.11 Win32  7 seconds
9.6.3  MacOS  0 seconds
9.6.3  Win32591 seconds


Using a buffer var should workaround the performance issue (which is 
related to the windows heap manager not being very good at continually 
re-extending a buffer):


on mouseUp
   local tLine
   repeat 256 times
  put "*" after tLine
   end repeat

   local tTime
   put the millisecs into tTime

   local tBuffer

   local tText
   repeat 257000 times
  put tLine & return after tBuffer
  if the number of codeunits in tBuffer > 50 then
 put tBuffer after tText
 delete codeunit 1 to -1 of tBuffer
  end if
   end repeat
   put tBuffer after tText
   answer (the number of codeunits in tText) & return & (the millisecs - 
tTime)

end mouseUp

In the original loop, tNewTable is continually extended internally, 
something which appears to cause O(n^2) performance on Windows.


In the revised loop, an intermediate buffer var is used which (after 
first time getting 'full') will have a backing store of 500k ish - 
meaning tText is extended much less often. (Playing with the value of 
50 up or down will affect the resulting speed - there will always be 
a sweet spot).


On my Windows VM - the above loop (which generates about 68mb of text or 
so, takes about 3s.


Hope this helps!

Mark.

P.S. This is an engine issue - we'll need to look into why there's such 
a difference with 6.7 - as, I'm pretty sure I kept the rules about 
extending buffers pretty much the same in string concatenation.


--
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: [iOS] possible console bug

2021-07-12 Thread Mark Waddingham via use-livecode

On 2021-07-12 15:37, Andre Garzia via use-livecode wrote:

Mark,

That’s the problem, I’m looking at the system log on the iOS Simulator
and there is no output for put without a target.


Heh sorry - I didn't actually read the code you posted in your original 
post :D


I believe this should work - `put ...` just gets sent to `NSLog` which 
should emit to the relevant console.


If you run the app on a real iOS device, do you see your log messages in 
the device log for it? Could it be Apple are now funneling simulator 
logs into a pane in Xcode - like they do for devices, rather than have 
them go to the macOS system log?


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: [iOS] possible console bug

2021-07-12 Thread Mark Waddingham via use-livecode

On 2021-07-12 15:01, Andre Garzia via use-livecode wrote:

but it is supposed to work, right? Did this changed in some version?


Apple stopped piping stdout/stderr to 'console' a few years ago I think 
- both on Desktop, and when looking at the device console for iOS.


In version 9.0 though we changed the behavior of `put` without a target. 
e.g.


   put "foo"

In the IDE this will output to the message box.

In -ui mode, this will write to stderr.

Otherwise (which will be the case on iOS / Android!) this will output to 
the system log

   - using NSLog on Desktop/iOS
   - using android.Log class on Android
   - using OutpuDebugString on Win32
   - using syslog on Linux
   - using JS console on html5

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: AW: AW: codesigning FAILS with Umlaute

2021-06-18 Thread Mark Waddingham via use-livecode

On 2021-06-18 11:47, Tiemo via use-livecode wrote:

Strangely enough, codesigning and notarizing a package with umlauts
still works and is verified by Apple.
Since codesigning a package has to be done with "productsign" and not
"codesign" it looks as "codesign" is broken and not the shell.
Tiemo


So Ian dug into this further - we think its the name of the executable 
in the plist which is the problem...


Codesign expects this to be in 'decomposed' unicode form - so instead of 
the (combined) u-umlaut character, it needs to be u,combining-umlaut.


Presumably this is because filenames in Apple FS's are always stored in 
decomposed unicode form, and codesign and friends expect exact byte 
equivalence between the entry in the plist, and that of the executable 
filename.


Anyway, a little bit of a subtle issue, but one which will hopefully be 
fixed by using the normalizeText function appropriately in the S/B where 
it sorts out the plist :)


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: codesigning FAILS with Umlaute

2021-06-16 Thread Mark Waddingham via use-livecode

On 2021-06-16 16:28, Tiemo via use-livecode wrote:

Any idea? please no stories about your doctor experiences .



So I asked Ian to have a look into this - my first thought was that we 
were missing an appropriate textEncode when building the shell command 
in the S/B to do the codesigning...


(The S/B since 9.6.1 does an 'ad-hoc' codesign on standalones as 
otherwise Catalina+ can complain)


However, it would appear that 'codesign' does not like the executable 
name (the bit in Contents/MacOS) having accented chars.


So I think you'll have to tweak the app name in the S/B mac options to 
remove the umlaut - then the internal exe will be fine; then after 
you've built - just rename the app bundle to be the one with the umlaut.


This shouldn't affect verification of the signed app at all as its 
everything *inside* the .app folder which is signed (the internals are - 
the plist contains a ref to the actual executable name, and plist is 
used to generate the code signature, along with the other stuff in the 
app).


Hope this helps!

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: iOS push notifications on Windows

2021-04-23 Thread Mark Waddingham via use-livecode

On 2021-04-23 16:11, panagiotis merakos via use-livecode wrote:

Hello Andrew,

The lesson was written and tested on a Mac. But yeah, on Windows, when
trying to execute "sh /path/to/send.sh" either directly from the
terminal or via the shell command using LC, it is expected to throw an
error. You _might_ be able to work around this by changing the .sh
extension to .bat if you are on Windows, and instead of "sh
/path/to/send.sh" use "/path/to/send.bat".

If I find some time I'll experiment with this and update the lesson 
next

week, unless you get there first :)


Unfortunately bash scripts are incompatible with bat(ch) - they are both 
'shells' but the latter is distinctly tied to Windows - so you'd need to 
translate the script from bash to batch. (There are windows builds of 
Curl that run on windows - they use exactly the same arguments / 
options).


That being said, if you want a quick way to get UNIX style shell scripts 
to work - then you could install Cygwin and the commands used in said 
shell script (is it just curl?) - you can then run the shell script from 
the cygwin terminal.


Cygwin is basically a lot of UNIXy stuff compiled to run on Windows with 
an emulation layer for POSIX system calls mapped to Windows.


You might also want to investigate Microsoft's own relatively new 'UNIX 
on Windows' stuff - although I think that is restricted to recentish 
versions of Windows 10. There, they basically run a custom linux kernel 
on top of Windows to give you a Linux environment which interoperates 
quite well alongside Windows.


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: rant: truewordOffset

2021-04-20 Thread Mark Waddingham via use-livecode

On 2021-04-20 17:04, Mark Wieder via use-livecode wrote:

On 4/20/21 6:00 AM, Niggemann, Bernd via use-livecode wrote:

Mark Wieder wrote
You can't just say

put truewordOffset("font", tText) into tOffset
because it might encounter "fontTable" first.


If I set wholematches to true it works for me


Unfortunately not here. Even with wholematches true


Works fine here too:

set the wholeMatches to true
put trueWordOffset("BT", "foo btn")
  => 0

set the wholeMatches to false
put trueWordOffset("BT", "foo btn")
  => 2

Warmest Regards,

Mark.

P.S. Remember wholeMatches is a handler-local property not global - I 
only mention that because it sounds like it isn't actually the value you 
think when you are calling trueWordOffset.


--
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: [ANN] Release 9.6.2 RC-4

2021-04-13 Thread Mark Waddingham via use-livecode

On 2021-04-13 16:46, Bob Sneidar via use-livecode wrote:

Hi Mark.

I downloaded LC 9.6.2 for Windows and installed it on a Server 2012
VM. It installed in the Program Files (x86) folder. I was under the
impression that only happens when the app is a 32 bit app.


Then you downloaded the 32-bit installer.


Are you implying the standalones are 64 bit but the LC app is 32? If
that were the case, then no benchmarks done in the IDE would be valid.
But it's more likely I am misinformed.


Both 32-bit and 64-bit Windows IDEs can build 32-bit and/or 64-bit 
windows standalones - you can choose in the standalone builder.


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: [ANN] Release 9.6.2 RC-4

2021-04-13 Thread Mark Waddingham via use-livecode

On 2021-04-13 16:15, Mark Wieder via use-livecode wrote:

Do the release notes need updating?


Hah! Yes - we've had a 64-bit windows build (separate installer) 
available since 9.5.


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: [ANN] Release 9.6.2 RC-4

2021-04-13 Thread Mark Waddingham via use-livecode

On 2021-04-09 22:25, Bob Sneidar via use-livecode wrote:

Ya so LC for Windows is basically running in an emulator.


No - its either running as a 32-bit app (if you have installed the 
32-bit version of LC) or as a 64-bit app (if you have installed the 
64-bit version of LC) - there's no emulation going on - the difference 
is the processor mode the executables are run in.


Windows, macOS and Linux all handle 32-bit vs 64-bit exactly the same 
way... The versions of the OS which can run both, have two sets of code 
for everything in the OS - one 32-bit and one 64-bit. The only 
difference is what those OSes call it / how they package it.


On Windows, the 32-bit set of libraries is called WoW 
(Windows-on-Windows), on Linux its called 'multi-arch' or 'multilib' (I 
think at least?), on macOS its called 'universal executables'.


macOS does have the advantage that the Mach-O binary executable format 
allows multiple architectures in the same binary which means it is all 
entirely hidden from the user. Neither PE (Windows) nor ELF (Linux) 
allow that, so user ends up having to choose the appropriate installer / 
run the appropriate installer command.


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: License Activation

2021-04-12 Thread Mark Waddingham via use-livecode

On 2021-04-12 14:58, Ralph DiMola via use-livecode wrote:

When I started LC 9.6.1 this am I got a message that the license is
corrupted. When I entered my username/password to re-activate I got 
this
message "An error occurred while attempting to contact the server" 
Anyone

else having problems?


Hi Ralph,

Are you on Windows by any chance?

If so, then do you have Kaspersky AV?

The revsecurity.dll is being flagged as suspicious and being quarantined 
- we have got Kaspersky to re-evaluate this (several times in fact!) so 
it should be okay now, but you might have to update you Kaspersky virus 
definitions and/or get your local install to un-quarantine it. Indeed, 
you may have to reinstall 9.6.1 :|


Hope this helps!

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: New(?) Idea for Standalones

2021-03-29 Thread Mark Waddingham via use-livecode

On 2021-03-27 22:22, J. Landman Gay via use-livecode wrote:

Also note: The stacks you distribute cannot violate the LC license
agreement. They can't reproduce IDE features or allow users to do
things that only a licensed user can do. Please don't violate the
license agreement; we all want LC to prosper.


Indeed.

I feel I must explicitly point out at this point that, in addition to 
forbidding creation of LiveCode-IDE-like applications, the commercial 
license agreement also explicitly prohibit generic player apps (or 
indeed any player app which allows a non-commercially licensed user to 
access commercial features).


I strongly recommend reviewing section 3 of the (commercial) license 
agreement for full details. The reason these clauses are there is to 
ensure we don't end up in a situation where we only ever sell one LC 
license a year: to a person who creates and distributes a player app and 
an automated build service using a business license to spit out 
standalones for everyone else who is using Community.


In terms of the general thrust behind this thread - I completely agree 
that standalone building has become tortuous over the last few years as 
all platforms add more and more hoops you have to jump through. However, 
this is probably best done by improving the standalone building process 
(i.e. making it as easy as possible) rather than anything else.


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: Unreliable File Deletion

2021-03-29 Thread Mark Waddingham via use-livecode

On 2021-03-28 18:11, R.H. via use-livecode wrote:

@ Peter Reid

Your message found my attention.
Also I am working on Windows 10 and have the same problem using LC 
9.6.1

Indy version.

The similar or same problem as you have: I want to delete the text 
file.

The command I issue is "detele file ". The error it returns:
"Can't delete file".


All cases of people reporting bugs with 'delete file' on Windows that I 
have seen fall into one of two cases:


1) The path they give to 'delete file' is wrong.

2) The file they are trying to delete is open by the app, or by another 
app.


In terms of (1) - its easy to determine - log the path you are using, or 
use 'there is a file ' (but make sure the file you are 
checking for / logging *is* actually the same path as being passed to 
'delete file').


In terms of (2) - Windows and UNIX-derived OSes have a critical 
difference when it comes to filesystems - in UNIX land you can delete a 
file which another process has open, on Windows you can't. (Note: It is 
possible for multiple processes on Windows to open the same file, if 
none have requested exclusive access, but the file cannot be 
deleted/renamed/moved until it is not open by any process).



... // Delete temp file

... delete file ("binfile:")
... put the result into tResult
... if "can't delete that file" is in tResult then

.. myMSG tHInfo & "File could not be deleted." & tFilePath --> 
My

message handler


This script falls into category (1) above - you are giving delete file a 
binfile URL. The 'delete file' command requires a normal file path, not 
a URL of any kind.


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: Resources folder on mac, and the good old days

2021-03-29 Thread Mark Waddingham via use-livecode

On 2021-03-29 03:13, Neville Smythe via use-livecode wrote:

you may already know this, but this will not work in a standalone!
We will surely not have write permissions in that folder!

As a workaround I would probably use -> specialfolderpath("temporary")
Or even write the text to -> the tempname



There is no problem writing to the resources folder. That’s the
logical place to put the user-changeable stack files for a standalone,
making the auxiliary files invisible to external fiddling by the user,
 which a Good Thing (although that does make the app look different on
Windows or Linux).


Unfortunately this has never been true on macOS X.

The Resources folder (which is in the macOS app bundle) should be 
treated as read-only...


This has always been true - the correct (Apple guideline compliant!) 
place to put files that are 'internal' to the app but created/modified 
at runtime and which should persist between restarts of the app is in 
the 'Application Support' folder - in a sub-folder which is named the 
same as the app's id (e.g. com.myapp.mycompany).


[ Apple guidance is here - 
 
]


The read-only ness of resources isn't strictly enforced - especially if 
the standalone is built on the machine it is run (app bundles downloaded 
from the internet, for example, have file attributes added which mark 
them as 'quarantined' - even if unpacked from a zip/archive)... However, 
you will notice some more 'unpleasant' effects, typically, if you move 
the standalone to another machine - these will range from prompt dialogs 
allowing access, to dialogs requesting root permission (if the user has 
put the standalone, say, in /Applications).


In contrast, I do not believe that writing to stuff under 'Application 
Support' ever produces a user-visible prompt dialog on any version of 
macOS.


Additionally, code-signing requirements are becoming more stringent over 
time - off the top of my head I can't remember whether codesign has 
started including non-executable resources in the signature - but as 
soon as it does (if it doesn't already), any signed and notarized app 
will break if any of the files in the app bundle are modified / removed 
/ added to.



As for the Good Old Days of free distribution to other Mac (desktop)
users, they haven’t gone. Apple is making it harder for the
uninitiated to find out how to open “unsafe” files, but they don't
keep it a secret. And while recent rumours abound  about unnotarized
apps not working at all on some future MacOS, it does seem unlikely
that will actually happen, and if they do that’s time for us all to
reboot to Linux.


Indeed, it is unlikely that Apple will ever completely stop unnotarized 
apps from running (although they keep changing what you have to toggle 
to enable right-click Open to open the app!) - but ensuring you use 
appropriate paths for temporary / private writable app files means the 
least friction for the user.


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: Polygon fill algo?

2021-02-15 Thread Mark Waddingham via use-livecode

On 2021-02-16 05:55, Richard Gaskin via use-livecode wrote:

My expectation was almost beyond anything reasonable, but it would
seem useful if there was some way to make it happen:  imagine if each
segment within a list of discontiguous points was rendered as though
it's a separate object, back to front.

It's not going to kill me to use separate graphics to hide the
portions of the vertices I need covered, but it sure would have been
nifty if I'd found a way to have a single poly object render as though
it were many.


So the even-odd fill rule will not give you what you want - overlapping 
regions alternate.


The non-zero fill rule can give you what you want - but you need to make 
sure that all your sub-polygons go 'in the same direction'. (NB: Fixed 
width font ASCII art follows):


These two overlapping rects both go clock-wise so everything is filled.

  |--->---|
  |...|
  |...|--->---|
  ^...|...|...|
  |...|...|...|
  |-- |---|...v
  |...|
  |---|

The left rect goes anti-clockwise and the right rect goes clockwise:

  |---<---|
  |...|
  |...|--->---|
  v...|   |...|
  |...|   |...|
  |-- |---|...v
  |...|
  |---|

Notionally:
   - the non-zero winding rule works by starting on the left of each 
scanline and scanning to the right

   - there is a winding counter which starts at 0.
   - at any pixel, if the winding counter is non-zero the pixel is 
filled.
   - if an edge is crossed which goes 'down', the winding counter is 
decreased
   - if an edge is crossed which goes 'up', the winding counter is 
increased


Hope this helps!

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: Using MySQL on (headless) Linux

2021-02-03 Thread Mark Waddingham via use-livecode

On 2021-02-03 20:07, Richard Gaskin via use-livecode wrote:
LC Server had already been ruled out (for whatever reason) in an 
earlier part of the thread...


That's too bad. LC Server is LiveCode build designed specifically for
command line use.


Interesting - I don't remember that being what I specifically designed 
it for :P


LiveCode Server was *specifically designed* to be used just like PHP - 
allowing you to interpolate code with HTML output for the purposes of 
constructing webpages on the fly, sitting behind a web-server... That's 
why it has unique syntax designed precisely for a CGI environment, and 
operating in that PHP-like manner.


Making it run in command-line mode as well was an obvious thing to do, 
and also made up for the fact (at the time) that bare standalone engines 
would not launch a stack on the command-line (as that was a rather 
gaping licensing hole which was closed between v3 and v4

IIRC). [ It also made it easier to test the general features of it! ]

Since the advent of the community edition, however, and perhaps more 
importantly script-only-stacks - standalone engines running with -ui can 
be just as convenient...


Assuming there isn't a feature-requiring reason to use one over the 
other, then it pretty much comes down to how you want to write your text 
based scripts.


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: Using MySQL on (headless) Linux

2021-02-02 Thread Mark Waddingham via use-livecode

On 2021-02-03 00:31, Richard Gaskin via use-livecode wrote:

As for my post, it was a question in reply to Mark Waddingham's note
about how only standalones can be expected to use externals.  That is,
at least as I read it.


Mark said nothing of the sort :)

LC Server had already been ruled out (for whatever reason) in an earlier 
part of the thread so I was just advising on how to solve Ben's issue of 
wanting a non-server engine that can be run in -ui mode which has 
dependencies.


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: Using MySQL on (headless) Linux

2021-02-02 Thread Mark Waddingham via use-livecode

On 2021-02-01 22:25, Ben Rubinstein via use-livecode wrote:

Undesirable things found:

1. I've not found how to access externals (in this case the database
library) without explicitly setting the 'externals' property of the
stack to a (generally unreliably) full path before the stack is saved.

3. revSetDatabaseDriverPath is required even when the drivers are in
the standard location inside the app 'bundle'.

I'll report (2) and (3) formally when I've done a bit more
investigation. I'd still love to know what I'm doing wrong, in
relation to (1).


Please don't - as neither are bugs :)

The standalone engine inside the runtime folders in the IDE install is 
just a bare engine.


In community you can certainly run the bare engine without building a 
standalone but as you have discovered it is just what it is - a bare 
engine, it knows nothing of externals, database drivers, widgets, script 
libraries or anything else.


If you want a headless (community) engine which has dependencies then 
all you have to do is deploy a standalone with a launcher stack embedded 
into it.


The launcher stack should have the inclusions you want configured for 
it, and it can just run the stack you pass as an argument on the 
command-line.


Doing it this way, it means the standalone builder will take care to 
ensure all the 'inclusions' you set are present and configured correctly 
(including widgets, externals and script libraries).


You only need to rebuild the standalone if your inclusion requirements 
change, or you want to change engine version.


Warmest Regards,

Mark.

P.S. In regards to (1) the trick is to do this:
```
set the externals of the templateStack to 
create invisible stack "Externals" -- or any name you like
inser the script of it into back
reset the templateStack
```
This allows you to compute the external paths at runtime when the engine 
starts (e.g. by using the engine folder, or the filename of the stack 
and computing the paths).


--
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: Server error? SOLVED

2020-12-31 Thread Mark Waddingham via use-livecode

On 2020-12-31 11:08, Klaus major-k via use-livecode wrote:

Hi all,

we could finally solve the problem by copying the revsecurity.dll from
LC 9 to the LC 5.x runtime folder! 8-)

I really had no idea that they were compatible!?

Nevertheless I will write to the mothership next week, just to get to
know why everythings works fine in the IDE but not in a runtime.


The IDE loads different DLLs from those it includes in standalones. So 
there is a revsecurity.dll (near/next to) the IDE engine on Windows, and 
also one in the Runtime/Windows... folder. The latter is copied into 
standalones, the former is only used by the IDE.


It suggests that you have previously copied a newer DLL over the one 
near the IDE engine - so it works in the IDE... Then when you copied the 
same DLL into the runtime folder, it then works in standalones too.


The DLLs from newer versions aren't guaranteed to be compatible with 
older versions - in the specific case of revsecurity it depends on 
whether OpenSSL has changed its API in a way which causes an 
incompatibility but it hasn't done this very often (fortunately in this 
case, it would seem!).


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: Encrypting Stack Breaks Field References

2020-12-13 Thread Mark Waddingham via use-livecode

On 2020-12-14 06:03, J. Landman Gay via use-livecode wrote:

On 12/13/20 6:02 PM, Richard Gaskin via use-livecode wrote:

Copying objects is disallowed in an encrypted stack, since of course 
once an object is copied it could be pasted into an unencrypted stack, 
and thus expose the source.


Except, copying via script using "copy x to y" doesn't involve the
clipboard. I think this could be categorized as a bug, the original
script should work.


Its not the copy that will be failing - but the create. In general you 
can't do anything to an encrypted stack which might cause a script to 
move from where its encrypted to somewhere else or vice-versa. (The 
reason create is disallowed is that you could create a new script via 
setting props of the template object).


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: export snapshot woverwrites variable?

2020-12-10 Thread Mark Waddingham via use-livecode

On 2020-12-10 13:55, Klaus major-k via use-livecode wrote:

Hi friends,

## Doing this again fixes the inconvenience and I can continue:
put dasObjekt() into tObject
...

Funky, funky!?


Nope - not funky.

Container syntax can be either a variable (with array indices or 
without), or an object chunk which has a notion of 'text' (i.e. button, 
field, image).


If it is a variable then the variable gets modified.

If it is an object chunk then the text of the object gets changed.

Variables are only treated as (potential) object chunks when being 
evaluated as a source, and only then if the thing operating on them 
expects an object. e.g. the blendLevel of tObject (property syntax only 
makes sense when targetting an object chunk, so the contents of tObject 
are parsed as a control chunk).


Indeed, if this wasn't the case then you wouldn't ever be able to change 
tObject in the following script:


  local tObject
  put the long id of field 1 into tObject

  -- If variable containers (targets) resolved as objects first:
  put "foo" into tObject -- this would set the text of the field to 
"foo"


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: filter

2020-11-19 Thread Mark Waddingham via use-livecode

So I thought
...
filter fld 1 with "[*"
...
would do the job, but that EMPTIES the field!?
Obviously this [ interferes with some REGEX mechanism of filter?
So what should I use now?


I think:

  filter fld 1 with "[[]*"

Should do the trick...

Basically, you can use '[...]' to 'escape' the operators in the wildcard 
pattern (i.e. *, [ and ?).


Hope this helps,

Mark.

P.S. Wildcard patterns are a lot simpler than general regexes, but 
'filter' can do both "filter ... with regex pattern ..." interprets the 
pattern the same as matchText/replaceText.


--
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: VPN and tsNet

2020-10-27 Thread Mark Waddingham via use-livecode

On 2020-10-27 01:05, Brian Milby via use-livecode wrote:

I have a fairly simple stack that I use to get FedEx tracking data
using tsNetPostSync.  It has worked fine until a new VPN connection
was added.  The only change that I know is that it no longer allows a
split tunnel so everything must go through the VPN.  Assuming that is
the issue, how do I configure tsNet to use the VPN instead of trying
to connect directly?  (I’m pretty sure that proxy is not enabled yet,
but that is probably coming too).  I did try to set the
defaultNetworkInterface but it did not seem to have any impact.  For
now I am just disconnecting the VPN to pull the data.


I *think* the 'interface' setting is what you want:

“interface”: (Introduced in tsNet version 1.4.0) Specify the interface, 
IP address or host name to be used for the outgoing connection.


This should be set to the local ip address of the interface (i.e. VPN) 
you want the socket connection to come from on the local machine.


Warmest Regards,

Mark.

P.S. Hopefully Charles can correct this if I'm wrong!

--
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: First version of LC that supports httpS?

2020-10-19 Thread Mark Waddingham via use-livecode

On 2020-10-19 17:31, Klaus major-k via use-livecode wrote:

Hi all,

see subject, maybe someone happens to know.
Obviously LC 5.02 does not support httpS yet.


HTTPS has been supported since engine version 2.6 judging by the libURL 
source - so that would be LiveCode 2.x (for some 'x' - I can't remember 
the exact version the engine version and the - what was Revolution - 
version synced up).


However, it is unlikely that https will work anymore from those engines 
with any suitably maintained web-server since the SSL protocol version 
they use will likely be judged insecure by the server and thus not allow 
connection. (Although that can be very unwisely changed on the webserver 
side).


Another facet here will be the 'root certificate bundle' which will 
almost certainly be well out of date for older engines (at some point we 
did make collection of SSL certificates from the OS automatic - that was 
before 6.0 by the look of it).


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: SSL cPanel mySql setup

2020-10-16 Thread Mark Waddingham via use-livecode

On 2020-10-16 10:51, matthias rebbe via use-livecode wrote:

Hi Sean,

there was a discussion a few weeks ago with the topic "Strange
behavior between Mysql, MariaDB and SSL."
I am not sure if the information in that discussion will solve your 
problem.


I had a quick look through that thread and I don't think that is 
necessarily relevant here (unless there was a part I missed) - that 
seemed to be mostly about authentication method rather than SSL 
specifically - it sounds like in this case a connection is being made it 
is just that it does not seem to be secured using SSL encryption.


I checked the mysql client library code and it seems that if the MySQL 
server says it does not support SSL then even if you ask for SSL 
connection (which revDB does is the useSSL flag is true) that request 
will be ignored and you will get a plaintext connection.


So this definitely *sounds* like a MySQL server setup problem rather 
than a client one (there's some useful info for at least testing the 
type of connection using the mysql command-line terminal utility here - 
https://docs.cpanel.net/knowledge-base/security/how-to-configure-mysql-ssl-connections/)



Another approach is the following. For security reasons we do not let
communicat our LC apps directly with MySQL Databases, if the Database
is hosted on a public server.

We using a Livecode Server Script on the Webserver for doing the
complete DB communication.
Our standalones (Mobile and Desktop) send the requests (password
encrypted string) either as POST or GET to the LC Server script. The
script encrypts the  request string and executes it. The return from
the DB is then returned to our standalone.


This is most definitely a better solution - and is the only real option 
if client apps are talking to the server from arbitrary networks.


Whilst a secured (via SSL) connection to MySQL directly should mitigate 
security concerns (as all data flowing between client and server is 
encrypted), there is no guarantee that an arbitrary network will *allow* 
connection to the MySQL database port which is required for that to 
function.


In contrast, you'd be hard pressed to find any network which allows 
access to the internet which blocks port 80 (HTTP) or 443 (HTTPS).


Of course, the other advantage of using a 'gateway API' to access your 
server data is that it allows client and server more flexibility in 
changing and optimizing things - i.e. if you change something 
server-side then you can probably make it so you don't necessarily need 
a client update to match (as you can just adjust what the gateway does).


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: DataGrid 2 swipe actions

2020-08-27 Thread Mark Waddingham via use-livecode
Heh - well I said ‘well structured’ not ‘literary’...

Although that being said, the ‘singular’ noun ‘drag’ has a plural and I believe 
it is ‘drags’... 

e.g. ‘It took several drags of her long fingernails down the blackboard to make 
the class pay attention’ ;)

If your fix works for you - great...

Unfortunately it breaks some functionality for others so isn’t mergeable as it 
stands.

Warmest Regards,

Mark.

Sent from my iPhone

> On 27 Aug 2020, at 20:58, Mike Kerner via use-livecode 
>  wrote:
> 
> Don't be telling me about "well structured commit titles".  There is
> nothing clear in that title, unless British is your first language, and
> English is your second, and in British we add an "s" on the ends of every
> singulars nouns, and peoples speak with a lisps.
> In the meantime(s), setting the delayTouches to false(s) on a DG(s) breaks
> scrolling(s), thus my PR(s), from however-long-ago it(s) was. :-P
> Tag.  You(s)'re it(s)
> 
>> On Thu, Aug 27, 2020 at 2:17 PM Mark Waddingham via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> On 2020-08-27 17:07, Mike Kerner via use-livecode wrote:
>>> name's mikey.  y'all can call me...
>>> mikey
>>> 
>>> howdy.
>>> 
>>> i think it was just one line of code, too, right?  it was just a matter
>>> of
>>> setting the delayTouches to true.  i have no idea why it was originally
>>> "false".
>> 
>> Well, the advantage of generally trying to make sure all substantive
>> changes made to the source have well structured commit titles and decent
>> descriptions in the body means its easy to find out by grokking `git
>> log` :D
>> 
>> It was changed precisely because of the issues Andrew pointed out with
>> DG2, specifically in this commit:
>> 
>> commit ac1beee1dd113e203b6715fe472cf2fa88656bd5
>> Author: Michael McCreary 
>> Date:   Thu Dec 21 12:49:26 2017 +
>> 
>> [[ DataGrid 2 ]] Fix drags to cooperate with the mobile scroller.
>> 
>> Previously, a data grid's mobile scroller was getting in the way of
>> reorder and swipe actions.
>> 
>> To fix for reordering, we disable the scroller whenn the user clicks
>> on a reorder control (and re-enable it when the reorder completes).
>> 
>> Swipes are a little trickier. We track dragging on mouse down, but
>> disabling the scroller at this point will prevent all scrolling.
>> Instead we attempt to determine if the user is trying to drag the
>> row before disabling the scroller.
>> 
>> I'd need to do some more digging to see if the highlight on touch has
>> actually been caused by something else since  as I don't recall it being
>> an issue, or noticed when DG2 debuted - but I could be wrong. Especially
>> more since Android has never had a delayTouches mode.
>> 
>> Either this problem also affects Android, which means turning
>> delayTouches on is not really an option (given the negative consequences
>> to DG2 behavior); or it doesn't affect Android in which case something
>> else has changed (potentially in the iOS scroller control itself).
>> 
>> I suspect we will just need a short timer on mouse down so that it only
>> triggers a highlight *if* a scroll message isn't received within the
>> interval of the timer.
>> 
>> 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
>> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> ___
> 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: DataGrid 2 swipe actions

2020-08-27 Thread Mark Waddingham via use-livecode

On 2020-08-27 17:07, Mike Kerner via use-livecode wrote:

name's mikey.  y'all can call me...
mikey

howdy.

i think it was just one line of code, too, right?  it was just a matter 
of

setting the delayTouches to true.  i have no idea why it was originally
"false".


Well, the advantage of generally trying to make sure all substantive 
changes made to the source have well structured commit titles and decent 
descriptions in the body means its easy to find out by grokking `git 
log` :D


It was changed precisely because of the issues Andrew pointed out with 
DG2, specifically in this commit:


commit ac1beee1dd113e203b6715fe472cf2fa88656bd5
Author: Michael McCreary 
Date:   Thu Dec 21 12:49:26 2017 +

[[ DataGrid 2 ]] Fix drags to cooperate with the mobile scroller.

Previously, a data grid's mobile scroller was getting in the way of
reorder and swipe actions.

To fix for reordering, we disable the scroller whenn the user clicks
on a reorder control (and re-enable it when the reorder completes).

Swipes are a little trickier. We track dragging on mouse down, but
disabling the scroller at this point will prevent all scrolling.
Instead we attempt to determine if the user is trying to drag the
row before disabling the scroller.

I'd need to do some more digging to see if the highlight on touch has 
actually been caused by something else since  as I don't recall it being 
an issue, or noticed when DG2 debuted - but I could be wrong. Especially 
more since Android has never had a delayTouches mode.


Either this problem also affects Android, which means turning 
delayTouches on is not really an option (given the negative consequences 
to DG2 behavior); or it doesn't affect Android in which case something 
else has changed (potentially in the iOS scroller control itself).


I suspect we will just need a short timer on mouse down so that it only 
triggers a highlight *if* a scroll message isn't received within the 
interval of the timer.


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: Adding items to a group

2020-08-26 Thread Mark Waddingham via use-livecode

On 2020-08-26 10:06, Jimmieson, Phil via use-livecode wrote:

One thing I’m considering is having a set of dummy hidden items
already in the group and making one of those look like the word the
user just dragged in - thus it’s already a member of the group and can
be scrolled etc with the rest. Can anyone think of any better ways of
doing it?


Take a look at the 'relayer' command in the dictionary. It allows you to 
move controls up and down the layer order and in and out of groups 
easily (without any need to ungroup/regroup).


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


  1   2   3   4   5   6   7   8   9   10   >