Re: Button icons

[Richmond]

On 30/05/15 00:10, Klaus major-k wrote:

Hi Richmond,


Am 29.05.2015 um 22:09 schrieb Richmond :

On 29/05/15 17:33, Klaus major-k wrote:

Hi RIchmond,


Am 29.05.2015 um 16:28 schrieb Richmond :

So, I have a stack with one button and an image "Blob.png",

But none of these scripts inside the button work:
on mouseUp
  set the icon of me to img 1003
end mouseUp
on mouseUp
  set the icon of me to img ID 1003
end mouseUp
on mouseUp
  set the icon of me to img "Blob.png"
end mouseUp

the correct syntax:
…
set the icon of me to 1003
…
or:
…
set the icon of me to „Blob.png"
…
For how long did you say you are using MetaCard/Revolution/Livecode now?
And is your dictionary broken? :-D

That's a stupid remark.

oh, come on, where is your sense of humor? :-)


I don't have a sense of 'humor'.

Geen gevoel voor humor!

I do have a sense of humour; but, last night it was buried under the 
remains of a real f**ker of a week.


Somebody had been "pressing my buttons" in a nasty way!




As I am sure you know, anyone only learns the features of a system they need.
I have never needed to set the icon of a but via script [always used the Prefs 
palette].
My dictionary is not broken, but it is ambiguous.

I was just kidding, sorry if I've hurt your feelings!


No, don't worry, you didn't :)

However: my remark about only learning the bits you need still stands.

Richmond.




Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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: How do you handle the poor performance of LC 7?

[Richmond]

How do I handle the poor performance of LC 7?

Make sure I deploy my standalones on computers that are over 7 years 
old; then one doesn't notice the difference!


Seriously; most of my computers are a bit like me: "of a certain age" 
and I haven't really noticed a difference.


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

Re: How do you handle the poor performance of LC 7?

[Pierre Sahores]

> Le 30 mai 2015 à 01:17, Richard Gaskin  a écrit :
> 
> The ability to deliver a single compact binary file that contains both 
> objects and code contributes strongly to LiveCode's uncommon productivity,

Not only…

Nobody seems to care around about something possibly more important about the 
LiveCode uncommon productivity…

...

« Can programming be liberated from the von Neumann style? : a functional style 
and its algebra of programs »

John Backus (Fortran Lead Designer, IBM researcher, inventor of the Functional 
Programming paradigm).

http://www.columbia.edu/cu/computinghistory/backus.html

…

http://en.wikipedia.org/wiki/Functional_programming

The main superiority of the Functional Programming Paradigm over the Object 
Oriented Programming Paradigm is very simple :

- FP permits to software designers to describe and implement the software 
complexity trough 2D representation’s plans of what has to be done. This is not 
possible in the OOP world where UML is intended to suits the same needs.
- The Stack’s model is a lots more productive way to go than the Decision Tree 
will ever been.

…

Scala and LiveCode are today two of the most productive functional programming 
languages available around but :

- LiveCode is not intended to be incredibly productive because it’s a 
functional language but because it’s an XTalk.

http://en.wikipedia.org/wiki/LiveCode

- Scala is intended to be incredibly productive because it’s a functional 
language.

http://en.wikipedia.org/wiki/Scala_%28programming_language%29

…

Apple (Hypercard, Swift), Oracle (Oracle Media Object), IBM (Rexx), NASA, EADS, 
and, probably, even Microsoft and Google, are using functional programming 
languages for their own internal development needs.

Why ? 

- Because what can be implemented in one line of code in FP will in average 
need 20 to 50 lines of code in OOP.

Why FP is not intended to be used by the most important companies selling 
development services to (beside their now internal needs) to the outside world ?

- Because they are selling days, months and years of developments, not 
development performance.

…

LiveCode will probably never be pushed up and being seen as a first class 
professional grade programming language as long as it will not assume pliantly 
is FP roots.

A bon entendeur, Salut !
--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.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

AW: How do you handle the poor performance of LC 7?

[Tiemo Hollmann TB]

Hi Richard,

the scenario is a field to enter a search term. With each entered character
(keyUp) or each backspace (rawKeyUp) correcting the search term I call the
following selecting routine to get a "live selection" of my 20,000 record
list of words. In LC 6 I can enter the chars as fast as I want and this
handler is always "on time" to show me the result list. In LC 7.0.5 it
swallows the entered chars, can't catch up until it stucks completely. I am
not talking of a slow down of 10 or 50%. I am talking about a slow down of
some x100%, which makes the complete handling unacceptable. Maybe my code
isn't very professional, so feel free to show up better style. I have send
Hanson my original real live stack.
Tiemo

Here is the relevant piece of code:

   repeat for each key tKey in garrVideos -- alle Begriffe und Sätze
durchgehen
  if gAktRubrik <> 99 and gAktRubrik is not item 2 of garrVideos[tKey]
then next repeat -- falsche Rubrik
  if tBegriffFlag is not item 6 of garrVideos[tKey] then next repeat --
falsche Kategorie Begriffe
  if gMenuAktuell is "Bearbeiten" and tKey is in tLernlistenInhalt then
next repeat -- Begriff schon in Lernliste
  if tSuchbegriff is empty then -- kein Suchbegriff, Begriff/Satz
übernehmen
 put tKey & cr after tListe
  else -- nach Suchbegriff selektieren
 if tSuchenBeliebig is true then -- an beliebiger Stelle im Wort
suchen
if tKey contains tSuchbegriff then -- Wort/Satz enthält
Suchbegriff
   put tKey & cr after tListe
end if
 else -- Suchbegriff nur am Anfang des Wortes
if tKey begins with tSuchbegriff then -- Wort/Satz beginnt mit
Suchbegriff
   put tKey & cr after tListe
end if
 end if
  end if
   end repeat   
   if tListe is not empty then delete last char of tListe   -- letzten CR
löschen
   put xSortListe(tListe) into fld "Liste" -- Text ins Anzeigefeld kopieren

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Richard Gaskin
Gesendet: Freitag, 29. Mai 2015 20:12
An: use-livecode@lists.runrev.com
Betreff: Re: How do you handle the poor performance of LC 7?

Tiemo Hollmann wrote:

 > Testing my stacks in LC 7.0.5 , they show such a poor performance.
 > E.g. plain repeat loops with 20,000 records which take a fraction  > of a
second in LC 6, last up to 10 seconds in LC 7, which is more  > than
unacceptable for me / my clients on old poor machines.

Can you post the code for that loop, and tell us a bit about the data it
works on?

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

AW: How do you handle the poor performance of LC 7?

[Tiemo Hollmann TB]

Hi Malte,
I've send Hanson my "real live stack"
Waiting what they will tell me
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Freitag, 29. Mai 2015 17:53
An: use-livecode@lists.runrev.com
Betreff: Re: How do you handle the poor performance of LC 7?

I set up a couple of benchmark stacks a while back:

http://forums.livecode.com/viewtopic.php?f=67&t=22072 


Bad thing was that the team wanted to see „real live scenarios“ (which most of 
my benchmark stacks are, just boiled down to the core of the problems as I 
found them). I was able to fly over to Edinburgh and discuss many of the 
problematic areas with the team. I guess the more „real live“ scenarios they 
see, the better as it might help find optimisations. Until the speed issues are 
resolved I am stuck with 6.7 for productive work, which is a shame because for 
one project I would urgently need to be able to support arabic RTL input. But I 
guess the old rule applies: First you make it work, then you make it fast. 
Impatiently waiting for the latter. :-)

Best,

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


___
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: Button icons

[Martin Koob]

Richmond Mathewson-2 wrote
> 
> I do have a sense of humour; but, last night it was buried under the 
> remains of a real f**ker of a week.
> 
> Somebody had been "pressing my buttons" in a nasty way!

And none of his buttons had icons which didn't help. :-)

Sorry couldn't resist.

Martin



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Button-icons-tp4692680p4692730.html
Sent from the Revolution - User mailing list archive at Nabble.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

help with timecode

[Tim Selander]

Dear Listers,

I am trying to convert the currenttime of a player showing video 
into standard video timecode -- hours:minutes:seconds:frames -- 
in both drop and non-drop timecode. I'm not being too successful 
at it. As I struggled with it, it occured to me I may be trying 
to re-invent the wheel.


Does anyone of a solution for turning the current time of an LC 
player into time code that they could share?


Thanks,

Tim Selander
Tokyo, Japan


___
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: How do you handle the poor performance of LC 7?

[Malte Brill]

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer engine, without 
(many) other benefits. ROI isn’t that appealing / existent for them there.

That said, I guess we need more real life things where the 7 and 8 engine is 
slower to hand over to the team, so many thanks you sent your stacks. As Mark 
said, the „laboratory“ benchmark tests do not appear to help as much as I would 
have thought in the first place. On the other hand it is rather difficult to 
send over complete projects if they require additional requisites (like a 
Database, or even worse a complete server) to demonstrate the issues. I must 
say the team has been most helpful there, so I really hope for the best.

Cheers,

Malte



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

Re: help with timecode

[Walt Brown]

You are using timescale? My assumption is that "interval" = "frame".

"Use the timeScale property  to convert internal movie
or sound times into seconds. The timeScale is the number of intervals per
second of a movie or sound. These intervals are used for the player's
 startTime , endTime
, duration , and currentTime
properties , and you can use the
timeScale property  to convert from the time scale used
by the movie or sound to seconds."

On Sat, May 30, 2015 at 9:38 AM, Tim Selander 
wrote:

> Dear Listers,
>
> I am trying to convert the currenttime of a player showing video into
> standard video timecode -- hours:minutes:seconds:frames -- in both drop and
> non-drop timecode. I'm not being too successful at it. As I struggled with
> it, it occured to me I may be trying to re-invent the wheel.
>
> Does anyone of a solution for turning the current time of an LC player
> into time code that they could share?
>
> Thanks,
>
> Tim Selander
> Tokyo, Japan
>
>
> ___
> 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: help with timecode

[Mike Bonner]

Be aware I have no clue about drop, no drop etc so I am probably way off
base here but..

It seems to me that first you need to make sure you're working in seconds,
so you need to divide the currenttime by the timescale to get the total
seconds.
Then its just a matter of math.

Having said that, I may have an easy way to do the conversion.  The first
thing to do would be to grab a padding number when your app starts up like
so:

put 0 into tSeconds
convert tSeconds to dateitems
put (24 - (item -4 of tSeconds)) * 3600 into myAdjustment --the adjustment
allows for timezone differences

gives an adjustment number of seconds that will be used later.

Then, it should be easy.

put ((the currenttime of player "yourplayer"  / the timescale of player
"yourPlayer" ) + myAdjustment) into tCurrentTime
convert tCurrentTime  to dateitems

At this point the hours of tCurrentTime should be item 4, minutes is 5, and
seconds is 6.
When displaying them, look at numberformat in the dictionary.


On Sat, May 30, 2015 at 7:38 AM, Tim Selander 
wrote:

> Dear Listers,
>
> I am trying to convert the currenttime of a player showing video into
> standard video timecode -- hours:minutes:seconds:frames -- in both drop and
> non-drop timecode. I'm not being too successful at it. As I struggled with
> it, it occured to me I may be trying to re-invent the wheel.
>
> Does anyone of a solution for turning the current time of an LC player
> into time code that they could share?
>
> Thanks,
>
> Tim Selander
> Tokyo, Japan
>
>
> ___
> 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: AW: How do you handle the poor performance of LC 7?

[Mike Bonner]

Malte, it might help if you don't sort the keys on each keystroke, instead
put the keys into a list and sort them once, then keep referring to that
same list as you do your filtering. Its faster to pop the full sorted list
into a working variable on each keystroke and filter than it is to get the
keys, sort the keys, then filter.


To optimize further, you can do a comparison on each keystroke by keeping
track of the previous search.

if char 1 to -2 of the current search string is the same as the previous
search string,.  you've just added a single char to the end of the search
string.  In this case you can do your filter on the most recently filtered
list rather than doing the full list filter each time. Otherwise, pull in
the full sorted list from wherever you're hiding it and do the filter on
that.

On Sat, May 30, 2015 at 7:50 AM, Malte Brill  wrote:

> Hey Tiemo,
>
> what does the xSortListe function do? What is rather funny that my real
> life problem childs are also revolving around a live search feature. It
> might well be that your speed issues (as mine) are related to the sorting
> part (if you do a sort). My approach is a little diffrent than yours, as I
> do have numeric keys in the array (and as numeric keys are not in stable
> order in an array I have (had) to sort those on each keystroke).
>
> To be fair towards 7, I have refactored quite a bit of my own code over
> the past weeks and now have scenarios where the performance impact is far
> less dramatic than it used to be. I just got around to test this yesterday
> and now see a speed loss of the 7 engine of 7 to 15% which is somewhat
> acceptable (not good, but acceptable). I had to jump through quite some
> hoops to get there though. The only upside is that stuff got significantly
> faster also in 6.7 so my users would see a general performance boost
> regardless the engine. That is something I can sell. This is speaking for
> my own software though. If I am in control of the budget all it costs is my
> time to refactor existing stuff and most of the times refactoring is my
> friend, as generally the code base gets better. If I am on the other side
> of my programming life, namely coding for other customers, it gets a lot
> harder to sell them on refactoring a couple of 100 stacks, just to get them
> to the same speed with the newer engine, without (many) other benefits. ROI
> isn’t that appealing / existent for them there.
>
> That said, I guess we need more real life things where the 7 and 8 engine
> is slower to hand over to the team, so many thanks you sent your stacks. As
> Mark said, the „laboratory“ benchmark tests do not appear to help as much
> as I would have thought in the first place. On the other hand it is rather
> difficult to send over complete projects if they require additional
> requisites (like a Database, or even worse a complete server) to
> demonstrate the issues. I must say the team has been most helpful there, so
> I really hope for the best.
>
> Cheers,
>
> Malte
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
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: How do you handle the poor performance of LC 7?

[Dr. Hawkins]

On Sat, May 30, 2015 at 7:16 AM, Mike Bonner  wrote:

> Malte, it might help if you don't sort the keys on each keystroke, instead
> put the keys into a list and sort them once, then keep referring to that
> same list as you do your filtering. Its faster to pop the full sorted list
> into a working variable on each keystroke and filter than it is to get the
> keys, sort the keys, then filter.
>

That's also what mine does.  Pulled once from the database already sorted,
stashed,then copied on use to a working set.  Working set is further
filtered for added characters, and recopied then filtered if a char is
deleted.

Now that I think of it in this context, a FILTER SORTED that assumes sorted
data might be faster (but I suppose only faster if filtering from first
character, rather than arbitrary position).

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Button icons

[Dr. Hawkins]

On Sat, May 30, 2015 at 6:13 AM, Martin Koob  wrote:

> And none of his buttons had icons which didn't help. :-)
>

Not needed; he's an iconic figure in his own right.

:)


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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 do you handle the poor performance of LC 7?

[Richard Gaskin]

Richmond wrote:

> How do I handle the poor performance of LC 7?
>
> Make sure I deploy my standalones on computers that are over 7 years
> old; then one doesn't notice the difference!
>
> Seriously; most of my computers are a bit like me: "of a certain age"
> and I haven't really noticed a difference.

Me neither.  That is, once I stepped away from the benchmarks and the 
vague complaints and actually ran my software in v7.


Some of my friends poke fun at my choice of modest hardware, but the 
reasons I prefer the components I work with extends far beyond being 
able to spend the cost difference on a weekend at a seaside resort:


Many years ago I was a Beta tester for a product which shall remain 
nameless, shortly after it was acquired by another company also unnamed 
here.  Prior to the acquisition it was a Mac-only app that ran 
beautifully, but that summer the acquiring team folded the code into 
their cross-platform framework, and the app size exploded while 
performance dropped about proportionately.  With some features the 
performance loss was significant enough to impair usability.


So I submitted a couple of performance-related bugs, feeling that was a 
reasonable thing to do since back in those days my hardware habit was to 
buy Apple's second-best machine every three years at the outside, so I 
never worked on the latest and greatest (that is, after the clone I 
bought from PowerComputing, but that's another story), but somewhat 
ahead of what the average computer user would have.


My reports came back "UTR" - Unable to Reproduce.

We went back and forth and ultimately I asked for a machine profile so I 
could compare what the devs were working with to what I was working with.


It turned out that the acquiring company is very generous with their 
developers, outfitting them with the very latest and fastest Macs loaded 
with maximum RAM and the fastest HDDs on the market.


In short, the developers were completely insulated from any 
understanding of the average user experience.  It simply wasn't possible 
for them to know how slow their code had become in the eyes of their market.


I can't really blame them, but I did find it curious that the product 
manager didn't notice this performance disparity while managing the 
testing pool.


Ever since then my hardware choices have become increasingly lean, 
buying only the CPU power I truly need while keeping an eye on what 
average customers are using.


And I'll admit I have a simpler life than those devs: as a scripter 
using LiveCode, I never have to wait for a compile cycle. :)


So all hail cheap hardware!  It keeps our code honest.

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

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

Re: AW: How do you handle the poor performance of LC 7?

[Richard Gaskin]

Thanks for sending your stack to the team.  Please let us know the outcome.

And thanks for posting that handler.  Mike and Richard already hit on 
the only two items that come to mind (sorting and filtering), but I'm 
curious:  How does performance look if you comment out the call to 
xSortListe?


I wish I had time this morning to run some benchmarking between a loop 
through an array as you have here and a filter on a pre-sorted list, but 
my hunch is the latter would take care of a lot of that performance for you.


If you have time to run a quick benchmark on that handler with and 
without the xSortListe call commented, I would be very interested in the 
results.


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


Tiemo Hollmann wrote:

> Hi Richard,
>
> the scenario is a field to enter a search term. With each entered
> character (keyUp) or each backspace (rawKeyUp) correcting the search
> term I call the following selecting routine to get a "live selection"
> of my 20,000 record list of words. In LC 6 I can enter the chars as
> fast as I want and this handler is always "on time" to show me the
> result list. In LC 7.0.5 it swallows the entered chars, can't catch
> up until it stucks completely. I am not talking of a slow down of 10
> or 50%. I am talking about a slow down of some x100%, which makes the
> complete handling unacceptable. Maybe my code isn't very
> professional, so feel free to show up better style. I have send
> Hanson my original real live stack.
> Tiemo
>
> Here is the relevant piece of code:
>
>repeat for each key tKey in garrVideos -- alle Begriffe und Sätze
> durchgehen
>   if gAktRubrik <> 99 and gAktRubrik is not item 2 of 
garrVideos[tKey]

> then next repeat -- falsche Rubrik
>   if tBegriffFlag is not item 6 of garrVideos[tKey] then next 
repeat --

> falsche Kategorie Begriffe
>   if gMenuAktuell is "Bearbeiten" and tKey is in 
tLernlistenInhalt then

> next repeat -- Begriff schon in Lernliste
>   if tSuchbegriff is empty then -- kein Suchbegriff, Begriff/Satz
> übernehmen
>  put tKey & cr after tListe
>   else -- nach Suchbegriff selektieren
>  if tSuchenBeliebig is true then -- an beliebiger Stelle im Wort
> suchen
> if tKey contains tSuchbegriff then -- Wort/Satz enthält
> Suchbegriff
>put tKey & cr after tListe
> end if
>  else -- Suchbegriff nur am Anfang des Wortes
> if tKey begins with tSuchbegriff then -- Wort/Satz 
beginnt mit

> Suchbegriff
>put tKey & cr after tListe
> end if
>  end if
>   end if
>end repeat
>if tListe is not empty then delete last char of tListe   -- letzten CR
> löschen
>put xSortListe(tListe) into fld "Liste" -- Text ins Anzeigefeld 
kopieren




___
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: Button icons

[Richmond]

On 30/05/15 16:13, Martin Koob wrote:

Richmond Mathewson-2 wrote

I do have a sense of humour; but, last night it was buried under the
remains of a real f**ker of a week.

Somebody had been "pressing my buttons" in a nasty way!

And none of his buttons had icons which didn't help. :-)


Exactly!



Sorry couldn't resist.

Martin



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Button-icons-tp4692680p4692730.html
Sent from the Revolution - User mailing list archive at Nabble.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: How do you handle the poor performance of LC 7?

[Dr. Hawkins]

On Sat, May 30, 2015 at 8:07 AM, Richard Gaskin 
wrote:

> It turned out that the acquiring company is very generous with their
> developers, outfitting them with the very latest and fastest Macs loaded
> with maximum RAM and the fastest HDDs on the market.


I hit the opposite of this during my dissertation.

The Fortran compiler I was using (absoft?) was based on the Cray compiler
(yes, an odd adaptation).  Anyway, I was working with huge matrices on a
mathematically intractable problem.  This was probably in '07 o '98.

The source of the crashes finally turned out to be my allocation of a
dynamic array.

I had more memory (512mb, iirc) than any of the developers so they had
never tried an array that was larger than 256mb.  Turns out that such
arrays were bit addressed, and I had surpassed 2^31 bits . . .  I was
bemused by accidentally tripping over a situation where 32 bit addressing
was not enough . . .

Fixed dimension arrays were faster, anyway . . .


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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

AW: AW: How do you handle the poor performance of LC 7?

[Tiemo Hollmann TB]

Hi Malte, you and Richard are on the right trace - and I was blind :)
The time cruncher is not the repeat loop, but my "special" sorting routine. I 
have a mixed alpha-numerical list. It is perhaps a little bit strange, but I 
want the numbers to be sorted at the end of the list. "A-Z-1-9-10-99-100-x" 
Because I didn't found a "build-in" function to realize this, that’s why I 
created this "Tiemo-Sort" (xSortListe). Perhaps there is a much straight 
forward way to do this. Because I never had performance issues with this I 
completely forgot this handler, I think I have to rethink this special sort:


---
function xSortListe pListe
   -
   -- Sortierung einer einfachen Liste, Zahlen am Ende
   local tZeile, tLine, tArt, tOben, tAlphaSort
   sort lines of pListe numeric -- gesamte Liste numerisch sortieren, damit 
stehen alle Alphazeilen vorne und numerische hinten, Zahlen in richtiger Folge.
   put the number of lines of pListe into tOben
   
   put "mixed" into tArt
   if not isNumber(first char of line tOben of pListe) then -- Letztes Zeichen 
ist ein Alpha, also ganze Liste Alpha
  put "alpha" into tArt
   else if isNumber(first char of line 1 of pListe) then -- Letztes Zeichen ist 
Zahl und 1. Zeichen auch Zahl
  put "numeric" into tArt
   end if
   switch tArt
  case "alpha" -- reine Alphaliste einfach international sortieren
 sort lines of pListe international
 break
  case "mixed" -- bei gemischter Alpha + Zahlenliste nur den Alphateil 
international sortieren
 put 1 into tZeile
 repeat for each line tLine in pListe
if the first character of tLine is a number then -- erste Zeile, 
die mit einer Zahl beginnt
   exit repeat
end if
add 1 to tZeile
 end repeat
 put line 1 to (tZeile - 1) of pListe into tAlphaSort -- den Alpha-Teil 
herausnehmen und international sortieren
 sort lines of tAlphaSort international
 put tAlphaSort into line 1 to (tZeile - 1) of pListe -- den Alphateil 
wieder zurück in die Gesamtliste setzen.
 break
 -- rein numerische Liste ist am Anfang schon sortiert
   end switch
   return pListe
end xSortListe

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Samstag, 30. Mai 2015 15:51
An: use-livecode@lists.runrev.com
Betreff: Re: AW: How do you handle the poor performance of LC 7? 

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer engine, without 
(many) other benefits. ROI isn’t that appealing / existent for them there.

That said, I guess we need more real life things where the 7 and 8 engine is 
slower to hand over to the team, so many thanks you sent your stacks. As Mark 
said, the „laboratory“ benchmark tests do not appear to help as much as I would 
have thought in the first place. On the other hand it is rather difficult to 
send over complete projects if they require additional requisites (like a 
Database, or even worse a complete server) to demonstrate the issues. I must 
say the team has been most helpful there, so I really hope for the best.

Cheers,

Malte



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


___
use-livecode mailing list
use-livecode@lists.run

Re: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 08:07 AM, Richard Gaskin wrote:


In short, the developers were completely insulated from any
understanding of the average user experience.  It simply wasn't possible
for them to know how slow their code had become in the eyes of their
market.


I had a similar experience doing QA work at Apple. I refused on 
principle to do what the other developers were doing: using the latest 
bleeding-edge computers off the line, instead verifying that things 
worked across the range of systems. This led to filing some interesting 
bug reports...


My favorite was finding what turned out to be a bug in the way the MPW C 
compiler created its stack frames. It would have been completely missed 
and shipped if I had been using the latest and greatest CPU set, and at 
first the bug report was dismissed as unreproducible because of course 
it worked fine on the newest machines.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/29/2015 09:27 PM, Andrew Kluthe wrote:


Most of our c# stuff is still .Net ;)


Yeah, C# isn't really as bad as it might be. The language itself is 
reasonable, if only it could be separated from the .NET stuff.



nodejs debugging suite, built in git client, great js intellisense while


Speaking of NodeJS, have you checked out famo.us yet? I went to their 
new api launch last week, and I think they're going to make a big splash 
at the conference next month. This is what I'll be doing instead of the 
LiveCode/HTML5 thing.


http://famo.us
http://famous.org

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: AW: AW: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 09:58 AM, Tiemo Hollmann TB wrote:


Hi Malte, you and Richard are on the right trace - and I was blind :)


Nonetheless, if there's a significant performance hit in *the same code* 
running on different LC versions, then it's something to worry about.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

AW: AW: How do you handle the poor performance of LC 7?

[Tiemo Hollmann TB]

I made some more performance benchmarks with my real life data
I deactivated my "special sort" xSortListe handler and replaced it just by: 
1. sort lines of tListe numeric
2. sort lines of tListe international
(though it is not a solution for my sorting feature, but just to drill it down)

LC 6.5.2, average times:
My repeat loop: 14 millisecs
plain Sort numeric: 3 millisecs
plain Sort international: 128 millisecs

LC 7.0.5, average times:
My repeat loop: 55 millisecs (+393%)
plain Sort numeric: 8 millisecs (+267%)
plain Sort international: 4100 millisecs (+3203%)

for my real life app just unacceptable
Tiemo



-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Tiemo Hollmann TB
Gesendet: Samstag, 30. Mai 2015 18:59
An: 'How to use LiveCode'
Betreff: AW: AW: How do you handle the poor performance of LC 7? 

Hi Malte, you and Richard are on the right trace - and I was blind :) The time 
cruncher is not the repeat loop, but my "special" sorting routine. I have a 
mixed alpha-numerical list. It is perhaps a little bit strange, but I want the 
numbers to be sorted at the end of the list. "A-Z-1-9-10-99-100-x" Because I 
didn't found a "build-in" function to realize this, that’s why I created this 
"Tiemo-Sort" (xSortListe). Perhaps there is a much straight forward way to do 
this. Because I never had performance issues with this I completely forgot this 
handler, I think I have to rethink this special sort:


---
function xSortListe pListe
   -
   -- Sortierung einer einfachen Liste, Zahlen am Ende
   local tZeile, tLine, tArt, tOben, tAlphaSort
   sort lines of pListe numeric -- gesamte Liste numerisch sortieren, damit 
stehen alle Alphazeilen vorne und numerische hinten, Zahlen in richtiger Folge.
   put the number of lines of pListe into tOben
   
   put "mixed" into tArt
   if not isNumber(first char of line tOben of pListe) then -- Letztes Zeichen 
ist ein Alpha, also ganze Liste Alpha
  put "alpha" into tArt
   else if isNumber(first char of line 1 of pListe) then -- Letztes Zeichen ist 
Zahl und 1. Zeichen auch Zahl
  put "numeric" into tArt
   end if
   switch tArt
  case "alpha" -- reine Alphaliste einfach international sortieren
 sort lines of pListe international
 break
  case "mixed" -- bei gemischter Alpha + Zahlenliste nur den Alphateil 
international sortieren
 put 1 into tZeile
 repeat for each line tLine in pListe
if the first character of tLine is a number then -- erste Zeile, 
die mit einer Zahl beginnt
   exit repeat
end if
add 1 to tZeile
 end repeat
 put line 1 to (tZeile - 1) of pListe into tAlphaSort -- den Alpha-Teil 
herausnehmen und international sortieren
 sort lines of tAlphaSort international
 put tAlphaSort into line 1 to (tZeile - 1) of pListe -- den Alphateil 
wieder zurück in die Gesamtliste setzen.
 break
 -- rein numerische Liste ist am Anfang schon sortiert
   end switch
   return pListe
end xSortListe

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Samstag, 30. Mai 2015 15:51
An: use-livecode@lists.runrev.com
Betreff: Re: AW: How do you handle the poor performance of LC 7? 

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer engine, without 
(many) other benefits. ROI isn’t that appealing / existent for them there.

That said, I guess we ne

Re: AW: AW: How do you handle the poor performance of LC 7?

[Richard Gaskin]

Mark Wieder wrote:
> Nonetheless, if there's a significant performance hit in *the same
> code* running on different LC versions, then it's something to worry
> about.

If we were in a more optimistic mood, we could say:

  LiveCode 7 is very good at exposing suboptimal algorithms.

;)

Of course it would be more convenient for everyone if LiveCode could 
have undertaken the most significant rewrite of any xTalk ever and 
pulled it off with only performance gains and not a single downside.


But in the imperfect world we live in, desirable as that might be I 
don't think it's a realistic goal.


Some areas of the v7 engine are faster, some slower, and now and then 
the slower parts will be slow enough that it'll prompt us to consider 
revising our code as it would have been faster all along.


It's worth noting that the scope of Tiemo's slowdown is far beyond 
anything I've been able to measure in v7 myself, and well outside of 
just about anything I've even read about.


That most stuff works without any noticeable difference at all is pretty 
good, even if we can expect to find a handful of edge cases where 
optimizing the algorithm may be needed.


If moving into the present with LiveCode 7 seems like a lot of work, 
talk to Python 2 fans migrating their code to Python 3. ;)


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


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

Re: AW: AW: How do you handle the poor performance of LC 7?

[Peter TB Brett]

On 2015-05-30 19:33, Tiemo Hollmann TB wrote:

I made some more performance benchmarks with my real life data
I deactivated my "special sort" xSortListe handler and replaced it just 
by:

1. sort lines of tListe numeric
2. sort lines of tListe international
(though it is not a solution for my sorting feature, but just to drill 
it down)


LC 6.5.2, average times:
My repeat loop: 14 millisecs
plain Sort numeric: 3 millisecs
plain Sort international: 128 millisecs

LC 7.0.5, average times:
My repeat loop: 55 millisecs (+393%)
plain Sort numeric: 8 millisecs (+267%)
plain Sort international: 4100 millisecs (+3203%)


Oh dear. That "sort international" performance is really not very good 
at all, is it?  I think we will need to address this soon!


I was going to suggest trying the following but perhaps it will not make 
much difference because it still uses "sort international"



function TiemoSort pList
   local tSorted, tLine, tNumeric, tAlpha

   repeat for each line tLine in pList
  if isNumber(first char of  tLine) then
 put tLine & return after tNumeric
  else
 put tLine & return  after tAlpha
  end if
   end repeat

   sort tNumeric numeric
   sort tAlpha international

   return tAlpha & tNumeric
end TiemoSort


Thank you for sending your stack.  I hope it will enable us to deal with 
your problem promptly.  :-)



  Peter

--
Dr Peter Brett 
LiveCode Engine Development Team


___
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: How do you handle the poor performance of LC 7?

[Dr. Hawkins]

On Sat, May 30, 2015 at 10:33 AM, Tiemo Hollmann TB 
wrote:

> I made some more performance benchmarks with my real life data
> I deactivated my "special sort" xSortListe handler and replaced it just by:
> 1. sort lines of tListe numeric
> 2. sort lines of tListe international
> (though it is not a solution for my sorting feature, but just to drill it
> down)
>

I don't think you need to go this far.

Just call it once and for all before editing; no need to do so at each
character, as filtering will preserve order.



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: help with timecode

[Peter Bogdanoff]

This is what I use for minutes & seconds. You can extend it to include hours & 
frames.

You’ll want to do the send command at the frame interval (1/30) of a second.

on updateCurrTime
 put round(the currentTime of player “thePlayer" 1005 / 600) into theTime
  put theTime div 60 into theMin
  put theTime mod 60 into theSec
  if len(theSec) = 1 then put "0" & theSec into theSec
  put theMin & ":" & theSec into field "CurrTime"
  send "updateCurrTime" to me in 1 seconds
end updateCurrTime

Peter Bogdanoff
UCLA

On May 30, 2015, at 7:07 AM, Mike Bonner  wrote:

> Be aware I have no clue about drop, no drop etc so I am probably way off
> base here but..
> 
> It seems to me that first you need to make sure you're working in seconds,
> so you need to divide the currenttime by the timescale to get the total
> seconds.
> Then its just a matter of math.
> 
> Having said that, I may have an easy way to do the conversion.  The first
> thing to do would be to grab a padding number when your app starts up like
> so:
> 
> put 0 into tSeconds
> convert tSeconds to dateitems
> put (24 - (item -4 of tSeconds)) * 3600 into myAdjustment --the adjustment
> allows for timezone differences
> 
> gives an adjustment number of seconds that will be used later.
> 
> Then, it should be easy.
> 
> put ((the currenttime of player "yourplayer"  / the timescale of player
> "yourPlayer" ) + myAdjustment) into tCurrentTime
> convert tCurrentTime  to dateitems
> 
> At this point the hours of tCurrentTime should be item 4, minutes is 5, and
> seconds is 6.
> When displaying them, look at numberformat in the dictionary.
> 
> 
> On Sat, May 30, 2015 at 7:38 AM, Tim Selander 
> wrote:
> 
>> Dear Listers,
>> 
>> I am trying to convert the currenttime of a player showing video into
>> standard video timecode -- hours:minutes:seconds:frames -- in both drop and
>> non-drop timecode. I'm not being too successful at it. As I struggled with
>> it, it occured to me I may be trying to re-invent the wheel.
>> 
>> Does anyone of a solution for turning the current time of an LC player
>> into time code that they could share?
>> 
>> Thanks,
>> 
>> Tim Selander
>> Tokyo, Japan
>> 
>> 
>> ___
>> 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: How do you handle the poor performance of LC 7?

[Brahmanathaswami]

And then there is the rest of us... how many I don't know.

I'm not  "Programmer" per se... I did some PHP, kinda grok JS... and 
they make me very edgy if I start thinking about useing them to getting 
work done. ...


Mostly   I just "need to get stuff done today!"

I can hack up a stack for some volunteer to load .epubs, extract the 
xhtml files and then dig out pull quotes for me into an on-board 
database, dump those to a  pipe delimited file and then on the server 
using the same language read that file and upload all that data into a 
MySQL date base and then use RevIgniter to run the web site.


I can take visual assets from our designers here and in less then 30 
minutes throw them into an app. open it in Xcode and pop it onto my 
iPhone and say "See I told you so.. the type is really way too small."


I can load 1000 images in space (loc -1000,-1000) get their rects and 
save this and post to the online database.


I can create an interface in a few hours for some 14 year old girls to 
go thru and fix titles and description to art work.


If I need to process some horrible mass of text.. .I can just whip open 
my "text processor stack" which has 100 cards all load with an 
incredible mess of buttons that I' developed over 20 years of doing 
xTalk, pick a card tweak a script  process .ics calendars, put them to 
html... on and on


But... I'm not a programmer...

So I get it that there may be a lot of weeping and wailing if you are 
doing industrial systems. In that world perhaps "the time has passed for 
Livecode to be considered a serious development tool."  But I think this 
misses the point about the vision of the future context(s) where 
software that is this incredibly easy to use and for such an amazing 
array of jobs... has incredible value for the masses of would be geeks 
who will never, ever worry about 20,000 of anything and who would like 
to code but not have it be so "painful"  and, as they mature, have a 
toolbox they can use to get serious work to done.


So "the rest of us" I really believe that there really *nothing* out 
there like LiveCode that can give me this kind of freedom and create 
power to do this kind of diverse tool generation in such short time 
frames across all these usage contexts -- desktop, standalone, server, 
mobile, all working seamlessly together.


I suppose someone will try to convince me that some other language X can 
do all these things if I took the time to learn it... But, I'm familiar 
with enough of them... I've hever hired people who are "experts" in 
those languages and they time frames for getting stuff done just drive 
me nuts after years of doing xTalk.


I built a complete revision control system for Indesign documents here 
in house in under 20 hours... we have been using it for 5 years (since 
EOL adobe version control) with zero problems... )  I did this crazy 
wizard for the local desktops here on the LAN that sends search strings 
to a CGI on the big server (400,000 plus images) in house tha calls a 
shell command to use the locate database and returns results that the 
user can filter as he sees fit... way better than spotlight!


total lines of code in the app and the cgi on the server: less than 300.

I just don't think I'm going to get that anywhere else.

That said.. 7.0.5 is frustrating. Crashed 5 times on me to today... and 
I didn't have time to send in any bug reports... I saved one crash log.. 
will send later.. So, yeah, if I were in a corporate environment and 
some software manager were looking over my shoulder, I can understand 
the he might not take LC seriously.


Swasti Astu, Be Well!
Brahmanathaswami

Kauai's Hindu Monastery
www.HimalayanAcademy.com



Trevor DeVore wrote:

Hi Andrew,

I've been reading the responses to this thread and wanted to add some
additional thoughts. I understand where you are coming from and I don't
mean to argue against what you are saying. Each developer has different
needs and has different resources to allocate. Rather, I just want to add a
different perspective as the perspective most often shared on the mailing
list is from those experiencing problems with LC 7.


___
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: SQLite and Android "Database Error:Unable to open the database file"

[Ralph DiMola]

Thanks Peter. Both checked OK. I think this might be a bug unless there is
some data inconsistency that could creep into some data type that the other
platforms ignore. Maybe?? I've seen this using MS Access via ODBC to MYSQL
DBs with invalid data in data types. I'm going to plod along and see what I
can find.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Peter Haworth
Sent: Saturday, May 30, 2015 2:26 AM
To: How to use LiveCode
Subject: Re: SQLite and Android "Database Error:Unable to open the database
file"

Try PRAGMA integrity_check and PRAGMA foreign_key_check.

Pete
lcSQL Software
On May 29, 2015 11:20 PM, "Ralph DiMola"  wrote:

> I am getting the dreaded and extremely unhelpful "Database 
> Error:Unable to open the database file". This only happens on Android. 
> Works in the IDE on either Mac or PC. Works on iOS. Fails only with 
> some queries. Other queries work just fine. This started after I added 
> some data. If I just add additional criteria to a select query 
> encompassing new data that failed then query will work? Or if the 
> first item in the WHERE clause does not reference any of the new data 
> it works. You can select ALL the data and it works. I'm guessing that 
> there is some data inconsistency that only the Android library cares 
> about. Any ideas how to run this down? Are there any utilities to 
> verify the integrity of an SQLite DB? I load the db from an LC utility 
> that shells to export a .xls to a .txt tab delimited file and then reads
in the text file and adds records to the DB.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
> ___
> 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

Subject: Re: How do you handle the poor performance of LC 7?

[Mark Rauterkus]

Hi All,

Everyone won't ever always be happy, but when do "the rest of us" turn
those frowns upside down? In what month or year?

Tell us about the timing of the arrival of the light at the end of the
tunnel.

What is your guess as to WHEN? Wondering.

Of course, this asks for total speculation. Of course, skeptics are friends
too.

So, one possible answer as to how to handle the poor performance of LC 7 is
to wait. But how long is that waiting?

--
Ta.


Mark Rauterkus   mark.rauter...@gmail.com
412 298 3432 = cell
___
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: Subject: Re: How do you handle the poor performance of LC 7?

[Richard Gaskin]

Mark Rauterkus wrote:

So, one possible answer as to how to handle the poor performance of LC 7 is
to wait. But how long is that waiting?


Depends on the specifics of this issue.  What performance issues are 
affecting your apps?


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

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

Re: AW: AW: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 10:54 AM, Richard Gaskin wrote:


If we were in a more optimistic mood, we could say:

   LiveCode 7 is very good at exposing suboptimal algorithms.


Yep. And for dp or rc builds I think that's a good thing.
But not for 'stable' releases.


That most stuff works without any noticeable difference at all is pretty
good, even if we can expect to find a handful of edge cases where
optimizing the algorithm may be needed.


The problem is that "pretty good" isn't good enough for LiveCode 
positioning itself in the marketplace, and that bodes ill for all of us 
who hope for its continued existence. We old-timers are more willing to 
accept some of the flaws, the degradations in performance, the 
long-standing bugs, the lack of features, etc. Folks investigating LC as 
a development platform won't be as forgiving.



If moving into the present with LiveCode 7 seems like a lot of work,
talk to Python 2 fans migrating their code to Python 3. ;)


Heh. Yeah. Python is quite particular about versions. I've had to move 
my code to Python 3.3, not just 3.2 any more, because there were too 
many incompatibilities.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 11:19 AM, Brahmanathaswami wrote:


But... I'm not a programmer...


I''ve seen some of the code you've thrown together, and I beg to differ.



So I get it that there may be a lot of weeping and wailing if you are
doing industrial systems. In that world perhaps "the time has passed for
Livecode to be considered a serious development tool."  But I think this
misses the point about the vision of the future context(s) where
software that is this incredibly easy to use and for such an amazing
array of jobs... has incredible value for the masses of would be geeks
who will never, ever worry about 20,000 of anything and who would like
to code but not have it be so "painful"  and, as they mature, have a
toolbox they can use to get serious work to done.


Yeah, but here's the difference: you're the boss, you can make the 
decisions, you don't have to convince upper management about how new 
development tools fit into the existing set; and you don't have to 
manage a group of half a dozen engineers all trying to make changes to 
parts of the same application in development, and figure out how to 
merge their changes into one stack.




So "the rest of us" I really believe that there really *nothing* out
there like LiveCode that can give me this kind of freedom and create
power to do this kind of diverse tool generation in such short time
frames across all these usage contexts -- desktop, standalone, server,
mobile, all working seamlessly together.


...and I'm certainly not going to argue that point with you, but really 
what you're aguing for is the power of the xtalk environment, not 
LiveCode in particular. And I agree, that's why we're still here today 
whether we started with HyperCard or discovered SuperCard somewhere 
along the way or are new converts to LiceCode. And add to those 
affirmations the fact that I'm four to five times as productive writing 
xtalk code as I am in C or Ruby or Javascript or whatever.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 12:40 PM, Mark Wieder wrote:


along the way or are new converts to LiceCode. And add to those


Oops. Obviously I meant LiveCode.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: AW: AW: How do you handle the poor performance of LC 7?

[Richard Gaskin]

Mark Wieder wrote:
> The problem is that "pretty good" isn't good enough for LiveCode
> positioning itself in the marketplace, and that bodes ill for all
> of us who hope for its continued existence. We old-timers are more
> willing to accept some of the flaws, the degradations in performance,
> the long-standing bugs, the lack of features, etc. Folks
> investigating LC as a development platform won't be as forgiving.

I'd like to live in an ideal world too.  I just recognize the world 
we're in.


And thankfully, warts and all, none of the issues with LiveCode are 
preventing Trevor, myself, and many others from shipping products made 
with it.



>> If moving into the present with LiveCode 7 seems like a lot of work,
>> talk to Python 2 fans migrating their code to Python 3. ;)
>
> Heh. Yeah. Python is quite particular about versions. I've had to
> move my code to Python 3.3, not just 3.2 any more, because there
> were too many incompatibilities.

Exactly - warts and all, that hasn't stopped a good many people from 
using Python.


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

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

Re: How do you handle the poor performance of LC 7?

[Brahmanathaswami]

Mark Wieder wrote:


Yeah, but here's the difference: you're the boss, you can make the 
decisions, you don't have to convince upper management about how new 
development tools fit into the existing set; and you don't have to 
manage a group of half a dozen engineers all trying to make changes to 
parts of the same application in development, and figure out how to 
merge their changes into one stack.


Point well taken... in fact I do ponder now how to move forward on some 
projects where I am ready to pay for an LC "engineer" to help with 
apps... (stay tuned for a call on this in the weeks to come...our 
budgets are very small though...)


The collaborative environment is not looking too facile... We are kind 
of left with the old RCS model, check file out... wait while I work on 
it... check it in... wait while you work on it... making archival copies 
along the way of course, but there is easy way for regression or 
innovative testing of alternative methods along the way without having 
do regress the entire stack.


BR

___
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: How do you handle the poor performance of LC 7?

[Malte Brill]

> And thankfully, warts and all, none of the issues with LiveCode are 
> preventing Trevor, myself, and many others from shipping products made 
> with it.
Out of interest, how many of those have you moved to use the 7 engine?

I have no interest in lamenting here. I do admire the job that has been done 
since the kickstarter and all the new shiny stuff like widgets looks rather 
good. Still there are areas where 7 is just not ready for prime time. I guess 
we will get there, especially seeing how responsive the folks at RR are at the 
moment. The more importance I see in openly discussing the issues we encounter. 
I think it does not help to point out that the current state works for others. 
It is more helpful to try to help identifying the areas where there are issues 
which I believe aren’t that many anymore (sort, filter and maybe rendering 
speed on high density displays), however for a certain amount of apps being 
built that handful of things are real showstoppers.

Best,

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

Re: AW: AW: How do you handle the poor performance of LC 7?

[Richard Gaskin]

Malte Brill wrote:

>> And thankfully, warts and all, none of the issues with LiveCode are
>> preventing Trevor, myself, and many others from shipping products
>> made with it.
>
> Out of interest, how many of those have you moved to use the 7 engine?

Currently everything I do in LiveCode is done in v7.0.5.


> Still there are areas where 7 is just not ready for prime time.

It would be useful to know which ones are affecting your apps.


> The more importance I see in openly discussing the issues we
> encounter. I think it does not help to point out that the current
> state works for others.

I agree that open discussion in a community is helpful, but I don't see 
the value in limiting the discussion only to what doesn't work.


I see no harm in Trevor or others noting that they're doing productive 
work with v7.  Why not allow the full scope of experience to be shared?


In light of the many posts here from folks describing things they've 
heard from others but not actually seen for themselves, any discussion 
of first-hand experience would seem welcome, even if it's as shockingly 
unfashionable as people merely having a good time. :)



> It is more helpful to try to help identifying the areas where there
> are issues which I believe aren’t that many anymore

Yes, despite the ongoing distraction of constant iOS updates, they've 
been working hard to knock off many issues for other platforms as well.



> however for a certain amount of apps being built that handful of
> things are real showstoppers.

I agree that focusing on specific actionable issues experienced 
firsthand is very valuable.


If there are bugs that have been submitted but not acted on and are 
holding up work without a workaround, let's identify those and get them 
resolved.


In addition to review of the current bug DB, Ben recently contacted a 
few developers to solicit such a shortlist, and as Community Manager I'm 
happy to add to that list with anything critical we can identify here.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@fourthworld.com


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

Re: How do you handle the poor performance of LC 7?

[Dr. Hawkins]

On Sat, May 30, 2015 at 2:05 PM, Mark Wieder  wrote:

> On 05/30/2015 12:40 PM, Mark Wieder wrote:
>
>  along the way or are new converts to LiceCode. And add to those
>>
>
> Oops. Obviously I meant LiveCode.


LiceCode:  the hairiest programming experience you will ever have.  The
compiler is truly nit-picking . . .

:)




-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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 do you handle the poor performance of LC 7?

[Peter W A Wood]

Richard 

> On 31 May 2015, at 07:07, Richard Gaskin  wrote:
> 
> If there are bugs that have been submitted but not acted on and are holding 
> up work without a workaround, let's identify those and get them resolved.
> 
> In addition to review of the current bug DB, Ben recently contacted a few 
> developers to solicit such a shortlist, and as Community Manager I'm happy to 
> add to that list with anything critical we can identify here.

I reported a bug - http://quality.runrev.com/show_bug.cgi?id=15173 
 - in the default version of 
LiveCode Server used on On-Rev on 8th April 2015. The bug stopped me using 
LiveCode to develop a small web app used by a client. I had to use Ruby 
instead. When the client asked, “What did you write it in?”. I answered “Ruby” 
not “LiveCode”. 

Nobody at LiveCode has bothered to review the bug report yet.

Peter


___
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

[OT] Google Keynote - forget death by PowerPoint

[Kay C Lan]

A lot of talk about Mobile computing so not completely off topic.

If you ever do a presentation at a conference then the bar has been set
pretty high for the openning splash. As you watch this you need to remember
this is in a conference room and the screens are all around you. It slows
down a bit in the middle but stick with it until the speaker appears on
stage.

If you continue with the actual presentation there is an interesting visual
display of the distribution of mobile phone distribution.

Enjoy:

https://events.google.com/io2015/#
___
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: help with timecode

[Peter Bogdanoff]

Had some odd stuff...once again (600 is the timescale I was working with; you 
can find the timescale() with that function) :

on updateCurrTime
put round(the currentTime of player "thePlayer" / 600) into theTime
 put theTime div 60 into theMin
 put theTime mod 60 into theSec
 if len(theSec) = 1 then put "0" & theSec into theSec
 put theMin & ":" & theSec into field "CurrTime"
 send "updateCurrTime" to me in 1 seconds
end updateCurrTime

> On May 30, 2015, at 11:16 AM, Peter Bogdanoff  wrote:
> 
> on updateCurrTime
> put round(the currentTime of player “thePlayer" 1005 / 600) into theTime
>  put theTime div 60 into theMin
>  put theTime mod 60 into theSec
>  if len(theSec) = 1 then put "0" & theSec into theSec
>  put theMin & ":" & theSec into field "CurrTime"
>  send "updateCurrTime" to me in 1 seconds
> end updateCurrTime

___
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: How do you handle the poor performance of LC 7?

[Alex Tweedly]

On 31/05/2015 00:07, Richard Gaskin wrote:


Currently everything I do in LiveCode is done in v7.0.5.

I too have used only v7 for everything I've done recently for myself (no 
released products - just stuff I do for myself and friends/family). I've 
been still using v6 when I don't control it all myself.


I'm happy to say I've had no crashes, no serious IDE problems and few 
performance issues (which were all already reported or known).


So I've now started to go through some of my older stacks that I think 
might be more performance-dependent to see if I can find and report 
anything. First one I tried did indeed show a graphics performance issue 
(on Mac - so maybe due to different graphic libs rather than the 
engine)- anyway that's 15447.


I agree that focusing on specific actionable issues experienced 
firsthand is very valuable.


If there are bugs that have been submitted but not acted on and are 
holding up work without a workaround, let's identify those and get 
them resolved.


In addition to review of the current bug DB, Ben recently contacted a 
few developers to solicit such a shortlist, and as Community Manager 
I'm happy to add to that list with anything critical we can identify 
here.


I'm no RQCC expert - is there a simple recipe to find all (or most) v7 
performance related bug reports ?


Thanks
-- Alex.

___
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 do you handle the poor performance of LC 7?

[Mark Wieder]

On 05/30/2015 04:45 PM, Dr. Hawkins wrote:


LiceCode:  the hairiest programming experience you will ever have.  The
compiler is truly nit-picking . . .

:)


I should have known I was opening the door to lousy puns.

--
 Mark Wieder
 ahsoftw...@gmail.com

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