Re: Optimization can be tricky

[Brian Milby via use-livecode]

Do you need the entire list sorted randomly or are you just needing to select N 
random entries from the list (weighted)? How does the speed change if you do a 
simple numeric sort?

You could use a function on a random number to weight things - would need to 
work out the right math to get what you want. Something like random(n)^2/n^2 
possibly. Depending on how heavily you want to prefer one end, you could use 
log or ln.

Your initial code is calculating “item 1 of interestArray[uID][T]” once or 
twice for every line S. I’m guessing that if you evaluate that to a variable 
once per repeat it would provide a small gain.

Depending on how often the if turns out to be true, some additional variables 
could possibly reduce the number of duplicate calculations enough to offset the 
cost of the assignment (what Jerry mentioned).
On Jun 11, 2018, 8:30 PM -0500, Jerry Jensen via use-livecode , wrote:
> At first glance, it looks like you might save some time by grabbing 
> interestArray[uID][T] as soon as you have T, and then use what you grabbed in 
> the 3 later places instead of re-figuring interestArray[uID][T] each time.
>
> As in:
> repeat for each line T in the keys of interestArray[uID]
> put interestArray[uID][T] into AuT —- grab it here
> repeat for each line S in storyArray[T]
> if abs(item 2 of S - item 1 of AuT) < 20 \
> and userSeenArray[uID][item 1 of S] < 4
> then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
> abs(item 2 of S - item 1 of AuT) - \
> item 2 of AuT),T,S & cr after candidateList
> end repeat
> end repeat
> sort lines of candidateList numeric by random(item 1 of each)
>
> It looks like you could do a similar thing with userSeenArray[uID][item 1 of 
> S] to avoid repeating the same calculation.
> Also with item 1 of AuT, and item 2 of S, with lesser gains but while you’re 
> at it…
> That all will make it easier (or harder) to read, depending on if you can 
> find descriptive variable names for the intermediate values.
>
> It won’t help the sort speed, but saves a lot of array un-hashing.
> I haven’t figured out what the algoraithm is doing, or the idea of the 
> randomness in the sort.
>
> All untested, of course!
> Cheers,
> Jerry
>
> > On Jun 11, 2018, at 5:21 PM, Geoff Canyon via use-livecode 
> >  wrote:
> >
> > My first pass at the routine looked roughly like this:
> >
> > repeat for each line T in the keys of interestArray[uID]
> > repeat for each line S in storyArray[T]
> > if abs(item 2 of S - item 1 of interestArray[uID][T]) < 20 \
> > and userSeenArray[uID][item 1 of S] < 4
> > then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
> > abs(item 2 of S - item 1 of interestArray[uID][T]) - \
> > item 2 of interestArray[uID][T]),T,S & cr after candidateList
> > end repeat
> > end repeat
> > sort lines of candidateList numeric by random(item 1 of each)
>
>
> ___
> 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: Optimization can be tricky

[Jerry Jensen via use-livecode]

At first glance, it looks like you might save some time by grabbing 
interestArray[uID][T] as soon as you have T, and then use what you grabbed in 
the 3 later places instead of re-figuring interestArray[uID][T] each time.

As in:
repeat for each line T in the keys of interestArray[uID]
 put interestArray[uID][T] into AuT —- grab it here
 repeat for each line S in storyArray[T]
if abs(item 2 of S - item 1 of AuT) < 20 \
  and userSeenArray[uID][item 1 of S] < 4
then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
  abs(item 2 of S - item 1 of AuT) - \
  item 2 of AuT),T,S & cr after candidateList
 end repeat
  end repeat
  sort lines of candidateList numeric by random(item 1 of each)

It looks like you could do a similar thing with userSeenArray[uID][item 1 of S] 
to avoid repeating the same calculation.
Also with item 1 of AuT, and item 2 of S, with lesser gains but while you’re at 
it…
That all will make it easier (or harder) to read, depending on if you can find 
descriptive variable names for the intermediate values.

It won’t help the sort speed, but saves a lot of array un-hashing.
I haven’t figured out what the algoraithm is doing, or the idea of the 
randomness in the sort.

All untested, of course!
Cheers,
Jerry

> On Jun 11, 2018, at 5:21 PM, Geoff Canyon via use-livecode 
>  wrote:
> 
> My first pass at the routine looked roughly like this:
> 
>   repeat for each line T in the keys of interestArray[uID]
>  repeat for each line S in storyArray[T]
> if abs(item 2 of S - item 1 of interestArray[uID][T]) < 20 \
>   and userSeenArray[uID][item 1 of S] < 4
> then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
>   abs(item 2 of S - item 1 of interestArray[uID][T]) - \
>   item 2 of interestArray[uID][T]),T,S & cr after candidateList
>  end repeat
>   end repeat
>   sort lines of candidateList numeric by random(item 1 of each)


___
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: Optimization can be tricky

[Tom Glod via use-livecode]

please do goeff this subject is very interesting to me.  i have some
problems where i need to optimize in a similar way.  which kind of repeat
look have u found works fastest? have u tried ? repeat for each key
this_key in array? is that slower?

i love saving milliseconds. :) makes a big diff at scale.

On Mon, Jun 11, 2018 at 8:21 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> ​I have a routine that takes about a minute to run for the test case I
> created, and who knows how long for the real use case. Given that I want to
> run it several thousand times for actual work, I need it to run (much)
> faster.
>
> Roughly, the routine gathers together a bunch of data from arrays, sorts
> the data based on its relationship to other arrays, and then returns a
> subset of the result.
>
> My first pass at the routine looked roughly like this:
>
>repeat for each line T in the keys of interestArray[uID]
>   repeat for each line S in storyArray[T]
>  if abs(item 2 of S - item 1 of interestArray[uID][T]) < 20 \
>and userSeenArray[uID][item 1 of S] < 4
>  then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
>abs(item 2 of S - item 1 of interestArray[uID][T]) - \
>item 2 of interestArray[uID][T]),T,S & cr after
> candidateList
>   end repeat
>end repeat
>sort lines of candidateList numeric by random(item 1 of each)
>
> In simple terms: parse through the individual lines of all the entries that
> possibly work, calculating a relevant value for each and appending that
> value and the line to an interim list, which then gets sorted, randomly
> favoring lower values.
>
> I assumed the problem was all the line-by-line parsing, and I thought of a
> clever way to accomplish the same thing. That led to this:
>
>put storyArray into R
>intersect R with interestArray[uID]
>combine R using cr and comma
>sort lines of R by (101 + userSeenArray[uID][item 2 of each] * 30 + 5 *
> \
>  abs(item 3 of each - item 1 of interestArray[uID][item 1 of each])
> \
>  - item 2 of interestArray[uID][item 1 of each])
>
> Much simpler, albeit that's a heck of a "sort by" -- more complex by far
> than any I had previously created, and a testament to the power and
> flexibility of "each". Alas, despite condensing my code and removing
> parsing and loops, that version took ten seconds more than the previous
> version, I'm guessing because the previous version has that "if" statement
> that weeds out undesirable entries before the sort has to deal with them.
>
> (I'm writing this email as I parse through this figuring it out)
>
> So it turns out that the crazy use of "each" is only part of the problem --
> changing that line to:
>
>sort lines of R by random(1)
>
> still takes over 20 seconds -- 3x as fast, but still far too slow. It turns
> out that the source data numbers anywhere from 1,000 to 2,000 lines, so
> sorting it in any way to randomly select the several lines I need is a
> really bad choice. removing the sort step but keeping everything else cuts
> the execution time down to under a second.
>
> Hmm. How to select several lines at weighted random from among a couple
> thousand? I'll think on this and post a follow-up.
> ___
> 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: Anything LiveCode Can Learn From GO

[Tom Glod via use-livecode]

but as i understand it ...changing a single threaded app to multi-threaded
at its core is a huge undertaking aand i'm not sure its even on the drawing
board for v 12 ...but i could be wrongmaybe its coming in v10 :D :D :D

On Mon, Jun 11, 2018 at 9:02 PM, Tom Glod  wrote:

> i see what you mean.  the single threaded aspect of LC is a
> drag... i'm actually trying my hand at some kind of workaround for this
> limitation for the global conference in september i aim to do some
> multi-core processing using LC and measure performance gain over specific
> workloads ...like searchdb query. and i/o.
>
> On Mon, Jun 11, 2018 at 8:08 PM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
>
>> I wasn't thinking about high language per se.   but more from an engine
>> point of view, specifically use of "Goroutines"
>>
>> "But, most of the modern programming languages(like Java, Python etc.)
>> are from the ’90s single threaded environment. Most of those programming
>> languages supports multi-threading. But the real problem comes with
>> concurrent execution, threading-locking, race conditions and deadlocks.
>> Those things make it hard to create a multi-threading application on those
>> languages.
>> {snip]
>> On the other hand, Go was released in 2009 when multi-core processors
>> were already available. That’s why Go is built with keeping concurrency in
>> mind. Go has goroutines instead of threads. They consume almost 2KB memory
>> from the heap. So, you can spin millions of goroutines at any time.
>>
>> How Goroutines work? Reffrance: http://golangtutorials.blogspo
>> t.in/2011/06/goroutines.html
>>
>> Other benefits are :
>>
>> Goroutines have growable segmented stacks. That means they will use
>> more memory only when needed.
>> Goroutines have a faster startup time than threads.
>> Goroutines come with built-in primitives to communicate safely
>> between themselves (channels).
>> Goroutines allow you to avoid having to resort to mutex locking when
>> sharing data structures.
>> Also, goroutines and OS threads do not have 1:1 mapping. A single
>> goroutine can run on multiple threads. Goroutines are multiplexed into
>> small number of OS threads.
>> =
>>
>> And from the reference a "Goroutine" may be not language specific and
>> maybe (I don't know much about the engine) I am dreaming about the rabbit
>> in the moon, but, for Mark's "idea machine" there is this:
>>
>> " Effectively for us goroutines hides many of the internal machine
>> complexities in achieving parallelism. This also means that the language
>> designers could implement changes to how goroutines scale on the machine
>> taking advantage of hardware and CPU improvements."
>>
>> Brahmanathaswami
>>
>>
>> On 6/10/18, 5:01 AM, "use-livecode on behalf of Tom Glod via
>> use-livecode" > use-livecode@lists.runrev.com> wrote:
>>
>> LC and Go have entirely different target marketsbut since you can
>> easily make 1 application talk to another application using sockets
>> .
>> or open process.. the LC and Go make a wonderful partnership if
>> you
>> need to build UI ...but also do High Performance Computing.
>>
>> The 2 can make a great couple indeed.  But neither can replace the
>> other.
>>
>> ___
>> 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: Anything LiveCode Can Learn From GO

[Tom Glod via use-livecode]

i see what you mean.  the single threaded aspect of LC is a drag...
i'm actually trying my hand at some kind of workaround for this limitation
for the global conference in september i aim to do some multi-core
processing using LC and measure performance gain over specific workloads
...like searchdb query. and i/o.

On Mon, Jun 11, 2018 at 8:08 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> I wasn't thinking about high language per se.   but more from an engine
> point of view, specifically use of "Goroutines"
>
> "But, most of the modern programming languages(like Java, Python etc.) are
> from the ’90s single threaded environment. Most of those programming
> languages supports multi-threading. But the real problem comes with
> concurrent execution, threading-locking, race conditions and deadlocks.
> Those things make it hard to create a multi-threading application on those
> languages.
> {snip]
> On the other hand, Go was released in 2009 when multi-core processors were
> already available. That’s why Go is built with keeping concurrency in mind.
> Go has goroutines instead of threads. They consume almost 2KB memory from
> the heap. So, you can spin millions of goroutines at any time.
>
> How Goroutines work? Reffrance: http://golangtutorials.
> blogspot.in/2011/06/goroutines.html
>
> Other benefits are :
>
> Goroutines have growable segmented stacks. That means they will use
> more memory only when needed.
> Goroutines have a faster startup time than threads.
> Goroutines come with built-in primitives to communicate safely between
> themselves (channels).
> Goroutines allow you to avoid having to resort to mutex locking when
> sharing data structures.
> Also, goroutines and OS threads do not have 1:1 mapping. A single
> goroutine can run on multiple threads. Goroutines are multiplexed into
> small number of OS threads.
> =
>
> And from the reference a "Goroutine" may be not language specific and
> maybe (I don't know much about the engine) I am dreaming about the rabbit
> in the moon, but, for Mark's "idea machine" there is this:
>
> " Effectively for us goroutines hides many of the internal machine
> complexities in achieving parallelism. This also means that the language
> designers could implement changes to how goroutines scale on the machine
> taking advantage of hardware and CPU improvements."
>
> Brahmanathaswami
>
>
> On 6/10/18, 5:01 AM, "use-livecode on behalf of Tom Glod via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> LC and Go have entirely different target marketsbut since you can
> easily make 1 application talk to another application using sockets
> .
> or open process.. the LC and Go make a wonderful partnership if you
> need to build UI ...but also do High Performance Computing.
>
> The 2 can make a great couple indeed.  But neither can replace the
> other.
>
> ___
> 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

Optimization can be tricky

[Geoff Canyon via use-livecode]

​I have a routine that takes about a minute to run for the test case I
created, and who knows how long for the real use case. Given that I want to
run it several thousand times for actual work, I need it to run (much)
faster.

Roughly, the routine gathers together a bunch of data from arrays, sorts
the data based on its relationship to other arrays, and then returns a
subset of the result.

My first pass at the routine looked roughly like this:

   repeat for each line T in the keys of interestArray[uID]
  repeat for each line S in storyArray[T]
 if abs(item 2 of S - item 1 of interestArray[uID][T]) < 20 \
   and userSeenArray[uID][item 1 of S] < 4
 then put (101 + userSeenArray[uID][item 1 of S] * 30 + 5 * \
   abs(item 2 of S - item 1 of interestArray[uID][T]) - \
   item 2 of interestArray[uID][T]),T,S & cr after candidateList
  end repeat
   end repeat
   sort lines of candidateList numeric by random(item 1 of each)

In simple terms: parse through the individual lines of all the entries that
possibly work, calculating a relevant value for each and appending that
value and the line to an interim list, which then gets sorted, randomly
favoring lower values.

I assumed the problem was all the line-by-line parsing, and I thought of a
clever way to accomplish the same thing. That led to this:

   put storyArray into R
   intersect R with interestArray[uID]
   combine R using cr and comma
   sort lines of R by (101 + userSeenArray[uID][item 2 of each] * 30 + 5 * \
 abs(item 3 of each - item 1 of interestArray[uID][item 1 of each])
\
 - item 2 of interestArray[uID][item 1 of each])

Much simpler, albeit that's a heck of a "sort by" -- more complex by far
than any I had previously created, and a testament to the power and
flexibility of "each". Alas, despite condensing my code and removing
parsing and loops, that version took ten seconds more than the previous
version, I'm guessing because the previous version has that "if" statement
that weeds out undesirable entries before the sort has to deal with them.

(I'm writing this email as I parse through this figuring it out)

So it turns out that the crazy use of "each" is only part of the problem --
changing that line to:

   sort lines of R by random(1)

still takes over 20 seconds -- 3x as fast, but still far too slow. It turns
out that the source data numbers anywhere from 1,000 to 2,000 lines, so
sorting it in any way to randomly select the several lines I need is a
really bad choice. removing the sort step but keeping everything else cuts
the execution time down to under a second.

Hmm. How to select several lines at weighted random from among a couple
thousand? I'll think on this and post a follow-up.
___
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: Best practise approach for artwork for iOS and Android?

[Sannyasin Brahmanathaswami via use-livecode]

Other replied on resolution. I'll reply as to content. You may not have the 
option, but there is a "safe zone" for landscape and portrait. 

We recently hire an artist to do a kid's story. She was asked to put "sky" the 
top and "grass" and the bottom and significant elements in "safe zone"  

Later we are will set the image to "the loc of this card"   (centered) 

On devices that crop, we lose the top and bottom but significant elements 
remain visible.

Is this helpful?  Probably not... if it is, I have a "safe zone" stack I can 
send you.

Brahmanathaswami
 

On 6/10/18, 10:55 PM, "use-livecode on behalf of Tiemo Hollmann TB via 
use-livecode"  wrote:

Up to now it looks to me as a never ending story, but perhaps I don't see a
good approach

Any experience or pointers to a how to are very welcome.

___
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: Anything LiveCode Can Learn From GO

[Sannyasin Brahmanathaswami via use-livecode]

I wasn't thinking about high language per se.   but more from an engine point 
of view, specifically use of "Goroutines"

"But, most of the modern programming languages(like Java, Python etc.) are from 
the ’90s single threaded environment. Most of those programming languages 
supports multi-threading. But the real problem comes with concurrent execution, 
threading-locking, race conditions and deadlocks. Those things make it hard to 
create a multi-threading application on those languages.
{snip]
On the other hand, Go was released in 2009 when multi-core processors were 
already available. That’s why Go is built with keeping concurrency in mind. Go 
has goroutines instead of threads. They consume almost 2KB memory from the 
heap. So, you can spin millions of goroutines at any time.

How Goroutines work? Reffrance: 
http://golangtutorials.blogspot.in/2011/06/goroutines.html

Other benefits are :

Goroutines have growable segmented stacks. That means they will use more 
memory only when needed.
Goroutines have a faster startup time than threads.
Goroutines come with built-in primitives to communicate safely between 
themselves (channels).
Goroutines allow you to avoid having to resort to mutex locking when 
sharing data structures.
Also, goroutines and OS threads do not have 1:1 mapping. A single goroutine 
can run on multiple threads. Goroutines are multiplexed into small number of OS 
threads.
=

And from the reference a "Goroutine" may be not language specific and maybe (I 
don't know much about the engine) I am dreaming about the rabbit in the moon, 
but, for Mark's "idea machine" there is this:

" Effectively for us goroutines hides many of the internal machine complexities 
in achieving parallelism. This also means that the language designers could 
implement changes to how goroutines scale on the machine taking advantage of 
hardware and CPU improvements."

Brahmanathaswami
 

On 6/10/18, 5:01 AM, "use-livecode on behalf of Tom Glod via use-livecode" 
 wrote:

LC and Go have entirely different target marketsbut since you can
easily make 1 application talk to another application using sockets .
or open process.. the LC and Go make a wonderful partnership if you
need to build UI ...but also do High Performance Computing.

The 2 can make a great couple indeed.  But neither can replace the other.

___
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 USB port

[J. Landman Gay via use-livecode]

On 6/10/18 10:44 AM, Douglas Ruisaard via use-livecode wrote:

Apple, if it isn't known, requires you to sell your first-born, sign a contract in blood 
and then embed a "special" hardware chip in your device in order to ALLOW USB 
connectivity.  I'm good with using BlueTooth for iOS... but Android has me stumped unless 
this community can lend a hand.


You can use Bluetooth with Android as well, but we don't have an 
external for that yet. USB connectivity has always been missing on all 
platforms, and I don't know of any plans to add it.


It sounds like what you need is a custom Android external for BlueTooth.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

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

Re: Best practise approach for artwork for iOS and Android?

[J. Landman Gay via use-livecode]

I would bulk-convert all the images to a higher resolution, perhaps 
144dpi. On Mac, Graphic Converter can batch process these in seconds, 
and I am sure there are other programs that do the same on both Mac and 
Windows. Use these higher-resolution images in your project.


On mobile, use fullScreenMode "showAll", which will automatically adjust 
the display to fit any resolution and screen size on both iOS and 
Android. Depending on the original card size, some edges will either be 
cropped or empty space will be added. There are ways around this, mainly 
by displaying an image at a larger size than the (original) card size.


There was a bug in the showAll fullscreenmode when navigating cards, but 
that has just been fixed and will be in the next 9.0 release. There are 
also workarounds for this right now if you don't want to wait.


This is a quick process that doesn't take much time because you won't 
have to adjust every image.


On 6/11/18 3:54 AM, Tiemo Hollmann TB via use-livecode wrote:

Hi,

I have three old windows program (going back to the 90th), designed for
children, which are based on "full window" image backgrounds (douzends of
cards, each with another background image) and lots of small detail images.
Up to now I have only developed LiveCode for Windows and MacOS, no
experience yet with iOS and Android development. I try to evaluate the work
load to redevelop those old windows programs for mobile and one general
question before I start is the art work. Since the old art work has a size
about 800x600 by 72dpi, I obviously would need to let redesign all art work
for the todays resolutions, which would be a pretty costly part of the
project and probably the go or nogo for the whole project.

  


Since there are so many different screen sizes, resolutions and aspect
ratios on iOS and Android, I wonder how to cover all those variants
technically in LiveCode and basically from the art work side. E.g. which
size and ratio I would have to let create the "master" images by the artist
(to be also on the safe side for the next years)?

Since I can't let design for each ratio a different master image for each
card, I probably would have to distort the "master" image to each different
screen size (app only for tablets in landscape mode)? Could I let make the
OS the distortion of one background image per card in LiveCode, or would I
need to import and assign different images (which I have distored in
photoshop before) for each screen size in each card? Additionally I would
need to create douzends of polygons as clickable objects, above each image
for small parts of it, where I am not sure, if they would keep their exact
target area, when the background image will be distort - probably not.

  


Up to now it looks to me as a never ending story, but perhaps I don't see a
good approach

Any experience or pointers to a how to are very welcome.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

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

Re: scancodes

[Mike Bonner via use-livecode]

Don't think of a key press and key release as if they should be 2 different
can codes, instead think of them as as being state changes.  Like a light.
Send power to the lightbulb, the light is on. Remove power from the bulb,
the light is off.  The bulb is still the same bulb.   Same with the
keyboard and keycodes.. The light is on! (key pressed)  The light is off!
(key released)  The identifier for the key (the scancode) remains the
same.  Or from a livecode perspective.. Click and hold a button and on
mousedown, report the target.  on mouseup, the same target is reported due
to a state change.  Click begun (mousedown)  click completed (mouseup).  So
no, the scancodes shouldn't be different.  (If you play with an arduino,
the same applies there.  Checking and changing pin states, setting a
voltage high, or low, but the pin assignment remains the same, only its
state changes from high to low, IE on to off)


On Mon, Jun 11, 2018 at 12:51 PM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> So . . . messing around, as one does, I started to think about scancodes:
> that is to say, signals sent by USB devices (and others)
> when keys are pressed . . .
>
> The main reason for this is that if I have this sort of code in a LiveCode
> stack:
>
> on rawKeyDown RD
>  put RD
> end rawKeyDown
>
> on rawKeyUp RU
>   put RU
> end rawKeyUp
>
> RD and RU will be the same,
>
> while the actual scancodes sent from the keyboard to the computer should
> be different for
> keyDown and keyUp.
>
> I realise that this is fairly silly unless one wants one's program to do
> different things from a keyDown to a keyUp, and that there are
> comparatively straightforward
> ways to ensure this without accessing the scancodes.
>
> Notwithstanding . . .
>
> Richmond.
> ___
> 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

scancodes

[Richmond Mathewson via use-livecode]

So . . . messing around, as one does, I started to think about scancodes:
that is to say, signals sent by USB devices (and others)
when keys are pressed . . .

The main reason for this is that if I have this sort of code in a 
LiveCode stack:


on rawKeyDown RD
 put RD
end rawKeyDown

on rawKeyUp RU
  put RU
end rawKeyUp

RD and RU will be the same,

while the actual scancodes sent from the keyboard to the computer should 
be different for

keyDown and keyUp.

I realise that this is fairly silly unless one wants one's program to do
different things from a keyDown to a keyUp, and that there are 
comparatively straightforward

ways to ensure this without accessing the scancodes.

Notwithstanding . . .

Richmond.
___
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

[ANN] This Week in LiveCode 132

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #132 here: https://goo.gl/x6H5Ym

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.


-- 
Panagiotis Merakos 
LiveCode Software Developer

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: Best practise approach for artwork for iOS and Android?

[Kee Nethery via use-livecode]

If you use the imagery you have, don’t distort it to fill the screen. That 
always looks bad. Add white space and/or crop but keep the proportions correct.

If you run them through a smoothing filter to up the dpi, you will want to bit 
poke each image to restore sharp corners that should not have been rounded.

Personally, if the app worked well with the images you had, and redoing them is 
your big go/no go, I’d use the images you have. If one app gains traction, 
perhaps v2 has new images.

Toss them all against the wall and see what sticks.

My two cents.

Kee Nethery


On Jun 11, 2018, at 1:54 AM, Tiemo Hollmann TB via use-livecode 
 wrote:

> Hi,
> 
> I have three old windows program (going back to the 90th), designed for
> children, which are based on "full window" image backgrounds (douzends of
> cards, each with another background image) and lots of small detail images.
> Up to now I have only developed LiveCode for Windows and MacOS, no
> experience yet with iOS and Android development. I try to evaluate the work
> load to redevelop those old windows programs for mobile and one general
> question before I start is the art work. Since the old art work has a size
> about 800x600 by 72dpi, I obviously would need to let redesign all art work
> for the todays resolutions, which would be a pretty costly part of the
> project and probably the go or nogo for the whole project.
> 
> 
> 
> Since there are so many different screen sizes, resolutions and aspect
> ratios on iOS and Android, I wonder how to cover all those variants
> technically in LiveCode and basically from the art work side. E.g. which
> size and ratio I would have to let create the "master" images by the artist
> (to be also on the safe side for the next years)?
> 
> Since I can't let design for each ratio a different master image for each
> card, I probably would have to distort the "master" image to each different
> screen size (app only for tablets in landscape mode)? Could I let make the
> OS the distortion of one background image per card in LiveCode, or would I
> need to import and assign different images (which I have distored in
> photoshop before) for each screen size in each card? Additionally I would
> need to create douzends of polygons as clickable objects, above each image
> for small parts of it, where I am not sure, if they would keep their exact
> target area, when the background image will be distort - probably not.
> 
> 
> 
> Up to now it looks to me as a never ending story, but perhaps I don't see a
> good approach
> 
> Any experience or pointers to a how to are very welcome.
> 
> 
> 
> Tiemo
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

Best practise approach for artwork for iOS and Android?

[Tiemo Hollmann TB via use-livecode]

Hi,

I have three old windows program (going back to the 90th), designed for
children, which are based on "full window" image backgrounds (douzends of
cards, each with another background image) and lots of small detail images.
Up to now I have only developed LiveCode for Windows and MacOS, no
experience yet with iOS and Android development. I try to evaluate the work
load to redevelop those old windows programs for mobile and one general
question before I start is the art work. Since the old art work has a size
about 800x600 by 72dpi, I obviously would need to let redesign all art work
for the todays resolutions, which would be a pretty costly part of the
project and probably the go or nogo for the whole project.

 

Since there are so many different screen sizes, resolutions and aspect
ratios on iOS and Android, I wonder how to cover all those variants
technically in LiveCode and basically from the art work side. E.g. which
size and ratio I would have to let create the "master" images by the artist
(to be also on the safe side for the next years)?

Since I can't let design for each ratio a different master image for each
card, I probably would have to distort the "master" image to each different
screen size (app only for tablets in landscape mode)? Could I let make the
OS the distortion of one background image per card in LiveCode, or would I
need to import and assign different images (which I have distored in
photoshop before) for each screen size in each card? Additionally I would
need to create douzends of polygons as clickable objects, above each image
for small parts of it, where I am not sure, if they would keep their exact
target area, when the background image will be distort - probably not.

 

Up to now it looks to me as a never ending story, but perhaps I don't see a
good approach

Any experience or pointers to a how to are very welcome.

 

Tiemo

 

 

 

___
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