Re: Title Case

[Mike Bonner via use-livecode]

Something like this might work..

put "a create a sentence title" into tTitle
repeat with i = 1 to the number of truewords in tTitle
   put toupper(char 1 of trueword i of tTitle) into char 1 of trueword i of
tTitle
end repeat
put tTitle -- the adjusted case sentence

If you have words that you would rather not uppercase of course, you'll
have to check for those. (like of, the...) and whether or not the word is
the first.


On Fri, Apr 20, 2018 at 9:35 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> What to the simplest way to  "sentence case"
>
> a create a sentence title
>
> in use toUpper to convert to
>
> A Create A Sentence Title…
>
> 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
___
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

Title Case

[Sannyasin Brahmanathaswami via use-livecode]

What to the simplest way to  "sentence case"

a create a sentence title

in use toUpper to convert to

A Create A Sentence Title…

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: OpenLanguage: abstract syntax trees

[David Bovill via use-livecode]

Hmmm. That is problematic.

I think the author must have had some intimate experience of devops.

On 20 April 2018 at 20:35, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 04/20/2018 12:10 PM, David Bovill via use-livecode wrote:
>
>> Yes - I quite distinctly remember having this very discussion with Mark a
>> few years back regarding the Bus Factor. Was clear at that time that a
>> centralised backup was infeasible.
>>
>> I’m glad to say that new additions to the protocol have made possible
>> decentralised solutions to this conundrum.
>>
>> Unfortunately no one so far has been able to discern the meaning of this
>> new architecture. Se we’re building an AI solution to manage the
>> complexity
>> for us.
>>
>
> Long out of print (55 years now), but...
>
> http://folk.uio.no/knuthe/kuriosa/draper.pdf
>
> --
>  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
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: some thoughts on version 9.0.0

[Richmond Mathewson via use-livecode]

As has been pointed out in the Forums: as new LiveCode versions come
out with new capabilities and new features quite a few of the features 
available in previous versions

are removed: this may well be, as has been explained, the necessary cost of
the new features.

About 4 years ago I had to 90% recode my Devawriter Pro because of this 
"feature drift" . . . a time-consuming
and tedious exercise, but the end result was that my App continued to 
function on more recent recensions of

operating systems.

While my recode was a bother, I gained more than I lost.

Richmond.

On 21/4/2018 12:54 am, Douglas Ruisaard via use-livecode wrote:

Maybe, Panos... BUT what if someone (like me!) is using one of those 
"disappearing" inks (sorry for the pun!).  The number of inks which were 
removed is HUGE!  I'm supposed to go back to all of my project and live apps and find 
and replace them???  I don't think so!

  


Doug

  


Hi all,
  


The inks that were removed were legacy inks which were deprecated a long time 
ago, and were not supported in the version of Skia library that LC 9.0 uses.
  


Best,
Panos

--

  


On Fri, Apr 20, 2018 at 11:20 AM, Keith Martin via use-livecode < 
use-livecode@lists.runrev.com> wrote:

  


On 19 Apr 2018, at 17:00, Douglas Ruisaard via use-livecode wrote:
Next is the significant decrease in the "Ink" choices... I've found
(by

process of elimination) the "notSrcOrReverse" ink works for me in
several situations there ain't no such thing in v9.0.0.

Yep, I found that strange and very disappointing too. I cannot see a
reason why this has been changed. Inks are things I sometimes use a
lot in projects for both practical and creative effects. Please
restore the full set!
k

___
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: some thoughts on version 9.0.0

[Monte Goulding via use-livecode]

> On 21 Apr 2018, at 7:54 am, Douglas Ruisaard via use-livecode 
>  wrote:
> 
> Maybe, Panos... BUT what if someone (like me!) is using one of those 
> "disappearing" inks (sorry for the pun!).  The number of inks which were 
> removed is HUGE!  I'm supposed to go back to all of my project and live 
> apps and find and replace them???  I don't think so!


Well of course it’s up to you what you do but these inks were deprecated for a 
long time and were not able to be supported after the skia upgrade. We also had 
to update the IDE to remove/replace their use. It was a while back and I didn’t 
keep the stack unfortunately but I wrote a script that iterated all the open 
stacks and found unsupported inks and then listed the object name so I could go 
and edit to find an equivalent or just remove it.

On the up side you can now use color emoji’s ;-)

Cheers

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

Re: some thoughts on version 9.0.0

[Douglas Ruisaard via use-livecode]

Maybe, Panos... BUT what if someone (like me!) is using one of those 
"disappearing" inks (sorry for the pun!).  The number of inks which were 
removed is HUGE!  I'm supposed to go back to all of my project and live 
apps and find and replace them???  I don't think so!

 

Doug

 

>>>Hi all,

 

>>>The inks that were removed were legacy inks which were deprecated a long 
>>>time ago, and were not supported in the version of Skia library that LC 9.0 
>>>uses.

 

>>>Best,

>>>Panos

--

 

On Fri, Apr 20, 2018 at 11:20 AM, Keith Martin via use-livecode < 
use-livecode@lists.runrev.com> wrote:

 

> On 19 Apr 2018, at 17:00, Douglas Ruisaard via use-livecode wrote:

> 

> Next is the significant decrease in the "Ink" choices... I've found 

> (by

>> process of elimination) the "notSrcOrReverse" ink works for me in 

>> several situations there ain't no such thing in v9.0.0.

>> 

> 

> Yep, I found that strange and very disappointing too. I cannot see a 

> reason why this has been changed. Inks are things I sometimes use a 

> lot in projects for both practical and creative effects. Please 

> restore the full set!

> 

> k

> 

___
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: Search a multidimensional array

[Andrew Bell via use-livecode]

THANK YOU for the recommendation! It took 4 seconds to convert this  
giant array to an SQLlite DB that could be queried in a heartbeat. You  
just took this project from proof of concept to prototype.


My apologies to the list, I vaguely remember seeing that thread but  
didn't recall the title or date. Hopefully THIS thread will make it  
easier for the next n00b to find their solution.


--Andrew Bell



Andrew, you don't peruse this list much, do you? :-)

A recent thread has been going on about just this issue. The upshot  
is that one pass through the array is obviously needed for the  
sqLite conversion, but after that multiple queries can be done much  
more efficiently. I have code already written that converts an array  
to a memory sqLite database. Once you do that, you can index on the  
columns you query most often. Contact me off list and I will send it  
to you.


As an aside, why not just use an sqLite database out of the gate?  
And to the rest of the list, there should probably be a way to  
import a file based sqlite database into a memory database and then  
back again for speed.


Bob S





___
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: Search a multidimensional array

[MWCM via use-livecode]

I tried to be a good developer and search the list before posting: 
multidimensional array search turned up some posts from 2014 but most “sort 
array” searches only returned single dimensional array options. 

I just started using encodedArrays on a recent project and fell in love with 
the simplicity. They have worked for all my previous efforts, but I’ve never 
had more than ~300 keys to deal with so a simple repeat loop always worked fast 
enough. 

I’ve used MySQL database queries in the past with success (thanks to the 
awesome API that HostM has provided), but this particular data set isn’t stored 
in an online database and offline access is required due to client 
circumstances. Before Livecode I’d never dealt with databases at all, so I’m an 
SQLlite virgin. Looks pretty straight forward though. 

--Andrew Bell
--Sent from my iPhone

> On Apr 20, 2018, at 12:10 PM, use-livecode-requ...@lists.runrev.com wrote:
> 
> Andrew, you don't peruse this list much, do you? :-)
> 
> A recent thread has been going on about just this issue. The upshot is that 
> one pass through the array is obviously needed for the sqLite conversion, but 
> after that multiple queries can be done much more efficiently. I have code 
> already written that converts an array to a memory sqLite database. Once you 
> do that, you can index on the columns you query most often. Contact me off 
> list and I will send it to you. 
> 
> As an aside, why not just use an sqLite database out of the gate? And to the 
> rest of the list, there should probably be a way to import a file based 
> sqlite database into a memory database and then back again for speed. 
> 
> Bob S


___
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: Search a multidimensional array

[Alex Tweedly via use-livecode]

On 20/04/2018 20:15, Richard Gaskin via use-livecode wrote:

This is an interesting problem, Andrew.  Thanks for posting it.


Indeed!

One modest performance gain available easily may be to change this:

  repeat for each element tThisItem in tInventoryArray
 if tThisItem["description"] contains tSearchQuery then
    put tThisItem into tSortedInventoryArray[ \
  (the number of elements of tSortedInventoryArray) + 1]
 end if
  end repeat

...to:

  put 0 into i
  repeat for each element tThisItem in tInventoryArray
 if tThisItem["description"] contains tSearchQuery then
    add i to i
    put tThisItem into tSortedInventoryArray[i]
 end if
  end repeat


I'd go for something like
  put tMatchingKeys
  repeat for each line K in the keys of tInventoryArray
 if tInventoryArray [K]["description"] contains tSearchQuery then
    put K & CR after temp
 end if
  end repeat

( or use    repeat for each key K in tInventoryArray
I used that other form because I keep a variable with the set of keys - 
and that can be re-used to subsequently search subsets with the 'repeat 
for each line' style of repeat :-)


and then use the key list for subsequent access. Unless you are changing 
or destroying the 'extracted' elements, it will save you significant 
time to just use it in-place.


Also,  testing with an earlier version of LC (maybe 7.x ??) showed that 
"repeat for each key ..." was faster than "repeat for each element ..." 
- no idea why, and haven't retested in at least a couple of years.


I have a library (announced a couple of days ago - don't use that 
initial version !!) for doing almost exactly this. For a data table 
apparently similar to yours (100 columns, 50,000 rows) this kind of 
simple search takes around 180 millisecs (on an aging Macbook Pro).


NB - the latest version is *much* changed from the version on github - I 
will finish testing tonight and post the new version to Github and put a 
copy on my own website (and announce to this list).


-- Alex.
P.S. I agree with Richard's request for a copy of the data / current 
code if it is not sensitive. Feel free to email directly to me if that 
is possible.



___
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: Contributing to the IDE

[Geoff Canyon via use-livecode]

On Fri, Apr 20, 2018 at 2:46 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> You might make a change to a file which looks identical in 9 and 9.1 - but
> how do you know it will work in 9.1 without running it in 9.1?


​As someone who was, until about four months back, using 6.7.3, you think
I'm that concerned about 9.1? ;-)

But I see your point.

gc​
___
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: OpenLanguage: abstract syntax trees

[Mark Wieder via use-livecode]

On 04/20/2018 12:10 PM, David Bovill via use-livecode wrote:

Yes - I quite distinctly remember having this very discussion with Mark a
few years back regarding the Bus Factor. Was clear at that time that a
centralised backup was infeasible.

I’m glad to say that new additions to the protocol have made possible
decentralised solutions to this conundrum.

Unfortunately no one so far has been able to discern the meaning of this
new architecture. Se we’re building an AI solution to manage the complexity
for us.


Long out of print (55 years now), but...

http://folk.uio.no/knuthe/kuriosa/draper.pdf

--
 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: Search a multidimensional array

[Richard Gaskin via use-livecode]

This is an interesting problem, Andrew.  Thanks for posting it.

One modest performance gain available easily may be to change this:

  repeat for each element tThisItem in tInventoryArray
 if tThisItem["description"] contains tSearchQuery then
put tThisItem into tSortedInventoryArray[ \
  (the number of elements of tSortedInventoryArray) + 1]
 end if
  end repeat

...to:

  put 0 into i
  repeat for each element tThisItem in tInventoryArray
 if tThisItem["description"] contains tSearchQuery then
add i to i
put tThisItem into tSortedInventoryArray[i]
 end if
  end repeat

As originally written it needs to traverse the entire destination array 
each time through the loop just to get a unique ordinal index number; 
maintaining that manually through i should be a little bit faster.


It may be that a much faster optimization may be possible by leaving the 
data as a delimited string.  It's hard to say up front if that will be 
the case, but converting strings to and from arrays is expensive, and 
both "repeat for each line..." and "put  after..." are 
very fast operations.


If these ideas don't yield the performance gain you're looking for, and 
if the data is not sensitive, feel free to email the data and a sample 
stack with your current search scripts and I'll see what I can do.


It's useful for much of the work I do to know which methods of querying 
data will perform better, and I rarely come across good real-world data 
like this, so I'd be happy to give it a shot to see what can be learned 
from it.


My test data no doubt differs from yours, but FWIW most of my testing 
has been done with data containing between 10k and 100k records, and few 
take as long as a second or two for a given query.


Either some of what I've learned may help your situation, or your 
situation will teach me new things to consider.


--
 Richard Gaskin
 Fourth World Systems


Andrew Bell wrote:
Is there a quick way to search a large multidimensional array that I  
am missing? I'm working on an inventory system and trying to figure  
out some more efficient methods.


Currently I'm taking a tab-delimited spreadsheet provided by the  
client and converting it to an array, but there are currently > 48000  
keys in the array so my repeat loop for searching is taking several  
minutes. I quickly figured out by making the barcode (unique value)  
the primary key of the array cut down on a simple SKU search, but I'm  
trying to also search based on other values (like the item description).



A line of sample data looks like this:
66290	PHOTO, Early to Mid 1960's, Womens Hair Style, 27x21"	Blue  
Background w/ White Vine Edging, Gold Frame	1	$200.00



An item in the array looks like this:
tInventoryArray[66290]["barcode"]
tInventoryArray[66290]["description"]
tInventoryArray[66290]["details"]
tInventoryArray[66290]["qty"]
tInventoryArray[66290]["cost"]


My slow, albeit working, search code looks like this:
repeat for each element tThisItem in tInventoryArray
   if tThisItem["description"] contains tSearchQuery then
  put tThisItem into tSortedInventoryArray[(the number of  
elements of tSortedInventoryArray) + 1]

   end if
end repeat


This does work, but is taking almost 2 minutes to search through the  
48000+ item database. Can someone point out a flaw in my process? My  
next experiment is converting this array to a SQLlite database and  
just throwing SELECT * WHERE commands at it.


--Andrew Bell



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

Re: OpenLanguage: abstract syntax trees

[David Bovill via use-livecode]

Yes - I quite distinctly remember having this very discussion with Mark a
few years back regarding the Bus Factor. Was clear at that time that a
centralised backup was infeasible.

I’m glad to say that new additions to the protocol have made possible
decentralised solutions to this conundrum.

Unfortunately no one so far has been able to discern the meaning of this
new architecture. Se we’re building an AI solution to manage the complexity
for us.

On Fri, 20 Apr 2018 at 19:59, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I believe the team tried to get a backup of Mark's brain a while back,
> but they ran out of disk space and the computer crashed. They had to
> settle for copyrighting him and providing an extended health plan.
>
> On 4/20/18 1:06 PM, Bob Sneidar via use-livecode wrote:
> > I was only proposing a possible framework. Obviously, Mark's brain is so
> complex (perhaps convoluted might be a better term) that the project may
> require millions of years and the 2nd most powerful computer ever devised
> in any space time to accomplish this task. Knowing the frustration of those
> who have attempted this before, it may be a good idea to start with asking
> ourselves, what is the question?
> >
> > Bob S
> >
> >
> >> On Apr 20, 2018, at 09:07 , Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> you forgot the most important part of that, the dumbItDownForUsN00bz()
> >> function
> >>
> >> On Fri, Apr 20, 2018 at 10:50 AM, David Bovill via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> Good idea.
> >>>
> >>> Or a podcast. Yes that is what we should do. I’ll  send you an invite
> Mark
> >>> and describe the topic + projects that will go on the show.
> >>>
> >>> On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> >>>
>  What is needed for this is for someone to write a Waddingham Knowledge
>  Extractor API, which would probably involve wtiting an intermediate
>  Waddingham Syntax Distiller (and advanced kind of DSL in it's own
> right)
> >>> as
>  well as a mind wave to digital conversion device. To my mind, the
> latter
>  has not been invented yet, but nothing is stopping you from getting
> >>> started
>  on the first two.
> 
>  Bob S
> >
> > ___
> > 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
> >
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Posting to LiveCode Server

[Richard Gaskin via use-livecode]

Tom Glod wrote:

> I was going to use LC Server until I realized there was a built in
> httpd server library present in LC 9 I ditched LC server
> mainly because it smokes LC server in performance.

I would be interested in the details of that comparison, scripts and 
metrics.


Despite its name, LC Server isn't a server, but a command-line app meant 
to run under a web server such as Apache or LigHTTPd which supports CGI.


The httpd script included with LC is a server, but designed for local 
use.  It may be useful on remote hosts; I haven't tried it.


So it's not so much:

LC's HTTPd  vs LC Server

...as it is:

LC's HTTPd vs Apache + LC Server

Given that all CGIs are launched, run, and quit with each request, and 
that all LC processes (desktop or "Server") currently spend more than 
two thirds of their launch time looking for and initializing fonts which 
are very rarely if ever used (close to zero known uses with LC Server), 
it certainly gives a potential edge to any LC process that runs that 
unnecessarily cumbersome boot process only once and then remains persistent.


But on the flipside, Apache is written in C and despite its vast feature 
set performs as well as we'd expect from compiled object code. My own 
experiments using LC as a scripted HTTPd have managed to achieve only 
half the speed of Apache -  and that was without attempting HTTPS, a 
requirement for any HTTP server to be used outside the local network.


So an apples-to-apples test would pit LC's httpd on a remote server 
bound to one port, with Apache + LC Server on that same system bound to 
another port.


And for the results to be applicable to real-world needs, both would be 
tested with HTTPS.


--
 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: OpenLanguage: abstract syntax trees

[J. Landman Gay via use-livecode]

I believe the team tried to get a backup of Mark's brain a while back, 
but they ran out of disk space and the computer crashed. They had to 
settle for copyrighting him and providing an extended health plan.


On 4/20/18 1:06 PM, Bob Sneidar via use-livecode wrote:

I was only proposing a possible framework. Obviously, Mark's brain is so 
complex (perhaps convoluted might be a better term) that the project may 
require millions of years and the 2nd most powerful computer ever devised in 
any space time to accomplish this task. Knowing the frustration of those who 
have attempted this before, it may be a good idea to start with asking 
ourselves, what is the question?

Bob S



On Apr 20, 2018, at 09:07 , Mike Kerner via use-livecode 
 wrote:

you forgot the most important part of that, the dumbItDownForUsN00bz()
function

On Fri, Apr 20, 2018 at 10:50 AM, David Bovill via use-livecode <
use-livecode@lists.runrev.com> wrote:


Good idea.

Or a podcast. Yes that is what we should do. I’ll  send you an invite Mark
and describe the topic + projects that will go on the show.

On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:


What is needed for this is for someone to write a Waddingham Knowledge
Extractor API, which would probably involve wtiting an intermediate
Waddingham Syntax Distiller (and advanced kind of DSL in it's own right)

as

well as a mind wave to digital conversion device. To my mind, the latter
has not been invented yet, but nothing is stopping you from getting

started

on the first two.

Bob S


___
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




--
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: Has Anyone Got A Directory "Walker" Available

[Richard Gaskin via use-livecode]

You may recall the dreaded recursion errors that have cropped up in 
discussions of directory walkers.  They happen not because anyone has 
directory trees > 40,000 folders deep, but because a permissions 
restriction can prevent going into a subdirectory, causing the current 
directory to be traversed again and again until the recursion error is 
thrown.


The way to avoid this is to add an error check when setting the 
directory, e.g.:


 set the directory to pFolder
 if the result is not empty then
   -- skip or report as needed
 end if


--
 Richard Gaskin
 Fourth World Systems


Sannyasin Brahmanathaswami wrote:

>  I found this in a toolbox. Sent by some ago, by a LiveCode deva
>
> For what it's worth :
>
> # Filters the strings "." and ".." from a list
> function filterDots pList
>local tList
>
>put pList into tList
>filter tList without "."
>filter tList without ".."
>
>return tList
> end filterDots
> # Returns a filtered list of files in the current directory
> function filteredFiles
>return filterDots(the files)
> end filteredFiles
>
> # Returns a filtered list of folders in the current directory
> function filteredFolders
>return filterDots(the folders)
> end filteredFolders
>
> # Returns a list of files in the current directory including
> # each file's full path.
> function filteredFilesWithPaths
>local tFiles, tFilesWithPaths
>
>put filteredFiles() into tFiles
>repeat for each line tFile in tFiles
>   put the directory & slash & tFile & return after \
> tFilesWithPaths
>end repeat
>delete the last char of tFilesWithPaths
>
>return tFilesWithPaths
> end filteredFilesWithPaths
>
>
> # Returns a list of files in a given folder, using recursion to
> # include files in subfolders if desired.
> function listFiles pFolder, pRecurse
>local tTotalFiles, tCurrentFiles, tFolders
>
> set the directory to pFolder
>put filteredFiles() into tCurrentFiles
>if not pRecurse then return tCurrentFiles
>if tCurrentFiles is not empty then
>   put tCurrentFiles & return after tTotalFiles
>end if
>put filteredFolders() into tFolders
>
> repeat for each line tFolder in tFolders
>   put listFiles((pFolder & slash & tFolder), pRecurse) into \
>   tCurrentFiles
>   if tCurrentFiles is not empty then
>  put tCurrentFiles & return after tTotalFiles
>   end if
>end repeat
> delete the last char of tTotalFiles
>
>return tTotalFiles
> end listFiles
>
> # Returns a list of files with their containing folders, using
> # recursion
> # if desired to descend into sub folders.
> function listFilesWithFolders pFolder, pRecurse
>local tTotalFiles, tCurrentFiles, tFolders
>
> set the directory to pFolder
>put filteredFiles() into tCurrentFiles
>if not pRecurse then return pFolder & return & "--" & return \
>& tCurrentFiles
>if tCurrentFiles is not empty then
> put pFolder & return & "--" & return after tTotalFiles
>   put tCurrentFiles & return & return after tTotalFiles
>end if
> put filteredFolders() into tFolders
>repeat for each line tFolder in tFolders
>   put listFilesWithFolders((pFolder & slash & tFolder), \
>   pRecurse) into tCurrentFiles
>   if tCurrentFiles is not empty then put tCurrentFiles & \
>   return after tTotalFiles
> end repeat
>delete the last char of tTotalFiles
>
>return tTotalFiles
> end listFilesWithFolders
>
> # Returns a list of files with the full paths
> function listFilesWithPaths pFolder, pRecurse
>local tTotalFiles, tCurrentFiles, tFolders
>
>set the directory to pFolder
>put filteredFilesWithPaths() into tCurrentFiles
>if not pRecurse then return tCurrentFiles
> if tCurrentFiles is not empty then put tCurrentFiles & \
>return after tTotalFiles
>put filteredFolders() into tFolders
>repeat for each line tFolder in tFolders
>   put listFilesWithPaths((pFolder & slash & tFolder), \
>  pRecurse) into tCurrentFiles
>   if tCurrentFiles is not empty then put tCurrentFiles & \
>   return after tTotalFiles
> end repeat
>delete the last char of tTotalFiles
>
>return tTotalFiles
> end listFilesWithPaths
>
> # Returns a sorted list of the files in pFolder. Again using
> # recursion if
> # required.
> function listSortedFiles pFolder, pRecurse
>local tFiles
>
>put listFiles(pFolder, pRecurse) into tFiles
>sort lines of tFiles by listSortedFilesSortKey(each)
>
>return tFiles
> end listSortedFiles
>
> # Used by the listSortedFiles() function. Returns a sort key
> # from each file's name to
> # allow the sorting to be fully customized.
> function listSortedFilesSortKey pFile
># Use this value for a normal text sort
>return pFile
> end listSortedFilesSortKey
>
>
> on doSomething pFile
>put pFile & return after msg
> end doSomething
>
> --This will achieve similar results to listing the files except that
> it will be slower because text has to be drawn to the 

Re: Search a multidimensional array

[Bob Sneidar via use-livecode]

Andrew, you don't peruse this list much, do you? :-)

A recent thread has been going on about just this issue. The upshot is that one 
pass through the array is obviously needed for the sqLite conversion, but after 
that multiple queries can be done much more efficiently. I have code already 
written that converts an array to a memory sqLite database. Once you do that, 
you can index on the columns you query most often. Contact me off list and I 
will send it to you. 

As an aside, why not just use an sqLite database out of the gate? And to the 
rest of the list, there should probably be a way to import a file based sqlite 
database into a memory database and then back again for speed. 

Bob S


> On Apr 20, 2018, at 11:32 , Andrew Bell via use-livecode 
>  wrote:
> 
> Is there a quick way to search a large multidimensional array that I am 
> missing? I'm working on an inventory system and trying to figure out some 
> more efficient methods.
> 
> Currently I'm taking a tab-delimited spreadsheet provided by the client and 
> converting it to an array, but there are currently > 48000 keys in the array 
> so my repeat loop for searching is taking several minutes. I quickly figured 
> out by making the barcode (unique value) the primary key of the array cut 
> down on a simple SKU search, but I'm trying to also search based on other 
> values (like the item description).
> 
> 
> A line of sample data looks like this:
> 66290 PHOTO, Early to Mid 1960's, Womens Hair Style, 27x21"   Blue Background 
> w/ White Vine Edging, Gold Frame1   $200.00
> 
> 
> An item in the array looks like this:
> tInventoryArray[66290]["barcode"]
> tInventoryArray[66290]["description"]
> tInventoryArray[66290]["details"]
> tInventoryArray[66290]["qty"]
> tInventoryArray[66290]["cost"]
> 
> 
> My slow, albeit working, search code looks like this:
> repeat for each element tThisItem in tInventoryArray
>  if tThisItem["description"] contains tSearchQuery then
> put tThisItem into tSortedInventoryArray[(the number of elements of 
> tSortedInventoryArray) + 1]
>  end if
> end repeat
> 
> 
> This does work, but is taking almost 2 minutes to search through the 48000+ 
> item database. Can someone point out a flaw in my process? My next experiment 
> is converting this array to a SQLlite database and just throwing SELECT * 
> WHERE commands at it.
> 
> --Andrew Bell


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

Search a multidimensional array

[Andrew Bell via use-livecode]

Is there a quick way to search a large multidimensional array that I  
am missing? I'm working on an inventory system and trying to figure  
out some more efficient methods.


Currently I'm taking a tab-delimited spreadsheet provided by the  
client and converting it to an array, but there are currently > 48000  
keys in the array so my repeat loop for searching is taking several  
minutes. I quickly figured out by making the barcode (unique value)  
the primary key of the array cut down on a simple SKU search, but I'm  
trying to also search based on other values (like the item description).



A line of sample data looks like this:
66290	PHOTO, Early to Mid 1960's, Womens Hair Style, 27x21"	Blue  
Background w/ White Vine Edging, Gold Frame	1	$200.00



An item in the array looks like this:
tInventoryArray[66290]["barcode"]
tInventoryArray[66290]["description"]
tInventoryArray[66290]["details"]
tInventoryArray[66290]["qty"]
tInventoryArray[66290]["cost"]


My slow, albeit working, search code looks like this:
repeat for each element tThisItem in tInventoryArray
  if tThisItem["description"] contains tSearchQuery then
 put tThisItem into tSortedInventoryArray[(the number of  
elements of tSortedInventoryArray) + 1]

  end if
end repeat


This does work, but is taking almost 2 minutes to search through the  
48000+ item database. Can someone point out a flaw in my process? My  
next experiment is converting this array to a SQLlite database and  
just throwing SELECT * WHERE commands at it.


--Andrew Bell


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

Re: OpenLanguage: abstract syntax trees

[David Bovill via use-livecode]

Unfortunately I just had a discussion with our CFO. The business model
requires us to sound more impressive than we really are. So we will be
mentioning a lot of buzz words, with casual references to Distributed
Ledger Technology wherever possible.

Marketing has decided it would be good to do in Latin.

On 20 April 2018 at 17:07, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> you forgot the most important part of that, the dumbItDownForUsN00bz()
> function
>
> On Fri, Apr 20, 2018 at 10:50 AM, David Bovill via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Good idea.
> >
> > Or a podcast. Yes that is what we should do. I’ll  send you an invite
> Mark
> > and describe the topic + projects that will go on the show.
> >
> > On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > What is needed for this is for someone to write a Waddingham Knowledge
> > > Extractor API, which would probably involve wtiting an intermediate
> > > Waddingham Syntax Distiller (and advanced kind of DSL in it's own
> right)
> > as
> > > well as a mind wave to digital conversion device. To my mind, the
> latter
> > > has not been invented yet, but nothing is stopping you from getting
> > started
> > > on the first two.
> > >
> > > Bob S
> > >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OpenLanguage: abstract syntax trees

[Bob Sneidar via use-livecode]

I was only proposing a possible framework. Obviously, Mark's brain is so 
complex (perhaps convoluted might be a better term) that the project may 
require millions of years and the 2nd most powerful computer ever devised in 
any space time to accomplish this task. Knowing the frustration of those who 
have attempted this before, it may be a good idea to start with asking 
ourselves, what is the question?

Bob S


> On Apr 20, 2018, at 09:07 , Mike Kerner via use-livecode 
>  wrote:
> 
> you forgot the most important part of that, the dumbItDownForUsN00bz()
> function
> 
> On Fri, Apr 20, 2018 at 10:50 AM, David Bovill via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Good idea.
>> 
>> Or a podcast. Yes that is what we should do. I’ll  send you an invite Mark
>> and describe the topic + projects that will go on the show.
>> 
>> On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> What is needed for this is for someone to write a Waddingham Knowledge
>>> Extractor API, which would probably involve wtiting an intermediate
>>> Waddingham Syntax Distiller (and advanced kind of DSL in it's own right)
>> as
>>> well as a mind wave to digital conversion device. To my mind, the latter
>>> has not been invented yet, but nothing is stopping you from getting
>> started
>>> on the first two.
>>> 
>>> Bob S

___
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: OpenLanguage: abstract syntax trees

[Mike Kerner via use-livecode]

you forgot the most important part of that, the dumbItDownForUsN00bz()
function

On Fri, Apr 20, 2018 at 10:50 AM, David Bovill via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Good idea.
>
> Or a podcast. Yes that is what we should do. I’ll  send you an invite Mark
> and describe the topic + projects that will go on the show.
>
> On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > What is needed for this is for someone to write a Waddingham Knowledge
> > Extractor API, which would probably involve wtiting an intermediate
> > Waddingham Syntax Distiller (and advanced kind of DSL in it's own right)
> as
> > well as a mind wave to digital conversion device. To my mind, the latter
> > has not been invented yet, but nothing is stopping you from getting
> started
> > on the first two.
> >
> > Bob S
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OpenLanguage: abstract syntax trees

[David Bovill via use-livecode]

Good idea.

Or a podcast. Yes that is what we should do. I’ll  send you an invite Mark
and describe the topic + projects that will go on the show.

On Fri, 20 Apr 2018 at 15:46, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> What is needed for this is for someone to write a Waddingham Knowledge
> Extractor API, which would probably involve wtiting an intermediate
> Waddingham Syntax Distiller (and advanced kind of DSL in it's own right) as
> well as a mind wave to digital conversion device. To my mind, the latter
> has not been invented yet, but nothing is stopping you from getting started
> on the first two.
>
> Bob S
>
___
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: OpenLanguage: abstract syntax trees

[Bob Sneidar via use-livecode]

What is needed for this is for someone to write a Waddingham Knowledge 
Extractor API, which would probably involve wtiting an intermediate Waddingham 
Syntax Distiller (and advanced kind of DSL in it's own right) as well as a mind 
wave to digital conversion device. To my mind, the latter has not been invented 
yet, but nothing is stopping you from getting started on the first two. 

Bob S


> On Apr 20, 2018, at 24:50 , Mark Waddingham via use-livecode 
>  wrote:
> 
>> Mark any chance of sending the gift of your knowledge our way?
> 
> I could ramble on at length ( not that I'm prone to that, of course ;) ) 
> about designing programming languages, interpreters, compilers, parsers, 
> tokenisers, name analysis, abstract syntax trees, concrete syntax trees, code 
> generation and a great many other things...
> 
> However, I suspect something more focused would be more helpful and for that 
> I really need a greater idea of what you are wanting to achieve - in 
> particular, what is the DSL you are wanting to create, how do you want it to 
> be used, and what is it intended to do?
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.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: some thoughts on version 9.0.0

[James Hale via use-livecode]

My error.

Yes the first badge takes you to the now empty behavior button.

BUT the second badge does indeed open the script only stack.

no bug, just me not moving further along the chain of badges.

The badges follow along the chain as advertised.



>> On 20 Apr 2018, at 1:41 pm, James At The Hale via use-livecode 
>> > wrote:
>> 
>> One downer I have noticed with the advent of behaviors being in script only 
>> stacks is you lose the ability to edit them when you click on the behavior 
>> badge.
>> 
>> If the behavior resides in a button, as before, all is well.
> 
> That sounds like a bug which we can fix. Could you report it.



James





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

Re: Contributing to the IDE

[Niggemann, Bernd via use-livecode]

>Monte Goulding via 
>use-livecode<https://www.mail-archive.com/search?l=use-livecode@lists.runrev.com=from:%22Monte+Goulding+via+use%5C-livecode%22>
> Fri, 20 Apr 2018 01:49:50 
>-0700<https://www.mail-archive.com/search?l=use-livecode@lists.runrev.com=date:20180420>
> wrote


>I’m fairly sure Bernd implements stuff using his current install of LC locally
>then then makes a patch with that using the github web ui. Am I right Bernd? I
>think the web interface is significantly harder and more confusing to use
>personally but that could be just me. It’s also not possible to do things like
>fix up commit messages.



Yes, I use the github web ui. It is not really straightforward but after a 
while one gets used to it. And some things are not possible but one can always 
close a pull request and do a new one. E.g when doing a pull request against 
the wrong branch.

Kind regards

Bernd

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

Re: some thoughts on version 9.0.0

[panagiotis merakos via use-livecode]

Hi all,

The inks that were removed were legacy inks which were deprecated a long
time ago, and were not supported in the version of Skia library that LC 9.0
uses.

Best,
Panos
--

On Fri, Apr 20, 2018 at 11:20 AM, Keith Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 19 Apr 2018, at 17:00, Douglas Ruisaard via use-livecode wrote:
>
> Next is the significant decrease in the "Ink" choices... I've found (by
>> process of elimination) the "notSrcOrReverse" ink works for me in several
>> situations there ain't no such thing in v9.0.0.
>>
>
> Yep, I found that strange and very disappointing too. I cannot see a
> reason why this has been changed. Inks are things I sometimes use a lot in
> projects for both practical and creative effects. Please restore the full
> set!
>
> k
>
>
> ___
> 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: some thoughts on version 9.0.0

[Keith Martin via use-livecode]

On 19 Apr 2018, at 17:00, Douglas Ruisaard via use-livecode wrote:

Next is the significant decrease in the "Ink" choices... I've found 
(by process of elimination) the "notSrcOrReverse" ink works for me in 
several situations there ain't no such thing in v9.0.0.


Yep, I found that strange and very disappointing too. I cannot see a 
reason why this has been changed. Inks are things I sometimes use a lot 
in projects for both practical and creative effects. Please restore the 
full set!


k

___
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

Lynda.com

[Jacques Hausser via use-livecode]

We just got Lynda.com available free for faculty and students 
in my University (online learning in every possible field). I looked if they 
have something about liveCode… at first view, I didn’t find anything !
Would be a good place to put some material to teach liveCode and make it a bit 
less confidential, if somebody here is interested…

Jacques

**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel:  ++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: jacques.haus...@unil.ch
***

___
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: Contributing to the IDE

[Mark Waddingham via use-livecode]

On 2018-04-20 11:15, Geoff Canyon via use-livecode wrote:

​I get that -- my point is that *many* of the IDE script files are
unchanged from 9.0 release to the current(?) develop branch. So working 
on
files in 9.0, making changes, and then submitting a pull request, 
unless

git somehow makes this a slog, should be perfectly acceptable​. They're
just text files, many of which haven't changed in six months. Or is 
there

something magic (and to me, frustrating) about git that makes it
unacceptable to submit a change made to a file in 9.0 to an identical 
file

in 9.1?


This is nothing to do with git at all - it is to do with actually being 
able to test the change you make and ensure it actually does what you 
want.


Just because a file hasn't changed for months, doesn't mean that its 
action isn't dependent on some code somewhere else in the system.


You might make a change to a file which looks identical in 9 and 9.1 - 
but how do you know it will work in 9.1 without running it in 9.1?


Warmest Regards,

Mark.

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

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

Re: Contributing to the IDE

[Geoff Canyon via use-livecode]

On Fri, Apr 20, 2018 at 1:49 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>>
> Yes - my point about the engine and IDE versions being mutually dependent
> :)


​I get that -- my point is that *many* of the IDE script files are
unchanged from 9.0 release to the current(?) develop branch. So working on
files in 9.0, making changes, and then submitting a pull request, unless
git somehow makes this a slog, should be perfectly acceptable​. They're
just text files, many of which haven't changed in six months. Or is there
something magic (and to me, frustrating) about git that makes it
unacceptable to submit a change made to a file in 9.0 to an identical file
in 9.1?
___
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: Contributing to the IDE

[Monte Goulding via use-livecode]

> ​Sorry, one other point: yes, you are correct, working from a pre-built
> distribution is exactly the question I was asking, and if the only issue is
> syncing the IDE files with the development versions, that seems like a
> small issue: many of the files at
> https://github.com/livecode/livecode-ide/tree/develop/Toolset/libraries are
> months to years from their last update. Ditto for
> https://github.com/livecode/livecode-ide/tree/develop/Toolset/palettes/script%20editor/behaviors.
> That
> makes it seem as though it would absolutely be possible to work on the IDE
> in the current 9.x release, with the caveat that merge conflicts would be
> *slightly* more likely. ​
> 
> Or am I missing something?

I think you are missing that once setup to build then it’s just once click in 
xcode or visual studio or one command on linux and you can rebuild and run the 
correct engine for the IDE so spending any time trying to figure out how to 
avoid such a small amount of work doesn’t seem that helpful. Additionally once 
setup like that you can patch anything from engine, docs, widgets, ide… so it’s 
much less limiting.

Cheers

Monte
___
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: Contributing to the IDE

[Mark Waddingham via use-livecode]

On 2018-04-20 10:39, Geoff Canyon via use-livecode wrote:

​Sorry, one other point: yes, you are correct, working from a pre-built
distribution is exactly the question I was asking, and if the only 
issue is

syncing the IDE files with the development versions, that seems like a
small issue: many of the files at
https://github.com/livecode/livecode-ide/tree/develop/Toolset/libraries 
are

months to years from their last update. Ditto for
https://github.com/livecode/livecode-ide/tree/develop/Toolset/palettes/script%20editor/behaviors.
That
makes it seem as though it would absolutely be possible to work on the 
IDE
in the current 9.x release, with the caveat that merge conflicts would 
be

*slightly* more likely. ​

Or am I missing something?


Yes - my point about the engine and IDE versions being mutually 
dependent :)


There is every chance that the develop-9.0 HEAD IDE *WILL NOT WORK* with 
the release-9.0.0 engine - if you can't run the IDE, you can't edit it, 
or check your changes do what you want.


Warmest Regards,

Mark.

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

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

Re: Contributing to the IDE

[Monte Goulding via use-livecode]

> On 20 Apr 2018, at 6:29 pm, Geoff Canyon via use-livecode 
>  wrote:
> 
> Two questions:
> 
> 1. Are older versions closed to changes? If I find a bug in LC 8.1.8 (or
> some update to it) is it pointless to fix the bug and submit a pull request?

If it is still present on the maintenance release branch (currently 
develop-9.0) then fix against that and it will be in the next maintenance 
release.

> 2. Is it fair to submit IDE pull requests the same way I might for the
> documentation? I.E., GitHub was perfectly happy to fork https://github.com/
> livecode/livecode-ide/edit/develop/Toolset/palettes/menubar/revmenubar.
> livecodescript for me, so it seems that if I update it, I could submit a
> pull request for it, without having built anything. Obviously that beheads
> a significant fraction of git's functionality, but it gets the job done,
> correct?

I’m fairly sure Bernd implements stuff using his current install of LC locally 
then then makes a patch with that using the github web ui. Am I right Bernd? I 
think the web interface is significantly harder and more confusing to use 
personally but that could be just me. It’s also not possible to do things like 
fix up commit messages.

Cheers

Monte

> 
> Thanks,
> 
> gc
> 
> On Fri, Apr 20, 2018 at 1:08 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On 2018-04-17 03:44, Geoff Canyon via use-livecode wrote:
>> 
>>> Are there instructions available somewhere on how to set up the IDE in
>>> GitHub so I can make changes and submit pull requests?
>>> 
>> 
>> Not in the way you are trying to - no.
>> 
>> Pretty much all our documentation is centered around the initial step
>> which is getting the entire LiveCode system (engine and IDE) to build from
>> source first. The main docs for that start in the LiveCode repo README -
>> https://github.com/livecode/livecode/blob/develop/README.md.
>> 
>> What you are asking for is slightly different: "How do I make it so that I
>> can modify the IDE in a pre-built distribution and submit patches/PR from
>> that".
>> 
>> The main issue here (and perhaps the only issue) is that the HEAD versions
>> of the version branches (release-* branches for specific releases,
>> develop-* for the frontier of maintenance releases and develop for the next
>> release) in the three main community repositories are all mutually
>> dependent to a greater or lesser degree. Whilst you can try and use the
>> develop HEAD version of the IDE with an engine built from develop-9.0 or
>> earlier, the reality is that it might not work.
>> 
>> Whilst it would be really really nice to have the IDE completely
>> independent of a given engine version, that is still a dream we are quite a
>> way from realizing.
>> 
>> In order to submit a PR which has any chance of being accepted, you have
>> to make sure it is submitted against the HEAD of the appropriate branch.
>> Whilst you can certainly checkout just the IDE repository, and then
>> redirect the Toolset folder from within a LiveCode distribution to use it -
>> you might find it does not work as the engine version required to run that
>> version of the Toolset (from the HEAD of the branch) might be 'newer' (and
>> as-yet unavailable as a built distribution to download) than that which you
>> have.
>> 
>> To cut a long story short: right now I'd strongly advise against thinking
>> of the engine and IDE as separate things if you want to contribute to the
>> LiveCode project because for the most part they are too mutually dependent.
>> As it stands, you really need to build the LiveCode repo from source on
>> your chosen development platform - as that's the only way you can guarantee
>> that you can submit patches against the current HEAD of any of the branches.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> ___
> 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: Contributing to the IDE

[Mark Waddingham via use-livecode]

On 2018-04-20 10:29, Geoff Canyon via use-livecode wrote:

Thanks for the clear rationale. I'll take a shot at building the whole
thing tomorrow.


I should have mentioned in my post (although I think Monte made it 
clear) that docs can be done entirely on GitHub. Doc entries are a 
special case because they:


  1) Are largely independent of everything else

  2) Are mark-down like structure (and so can be previewed easily 
enough)


  3) Are validated by our CI system when you submit the PR.

And Panos noticed that the version on the contributing to docs guide was 
wrong - I'm sure you'll see that change shortly :)



Two questions:

1. Are older versions closed to changes? If I find a bug in LC 8.1.8 
(or
some update to it) is it pointless to fix the bug and submit a pull 
request?


So the rule is that we only maintain (i.e. will only release builds 
from) two branches at any one time.


Right now 9 is in maintenance mode (develop-9.0) and 9.1 is the next 
development version (develop).


Bug fixes should be applied against the current maintenance branch 
(develop-9.0), additions/features and such should be applied agains the 
current development branch (develop).



2. Is it fair to submit IDE pull requests the same way I might for the
documentation? I.E., GitHub was perfectly happy to fork 
https://github.com/

livecode/livecode-ide/edit/develop/Toolset/palettes/menubar/revmenubar.
livecodescript for me, so it seems that if I update it, I could submit 
a
pull request for it, without having built anything. Obviously that 
beheads
a significant fraction of git's functionality, but it gets the job 
done,

correct?


Yes - you can - although I'd be wary of errors creeping in from doing it 
that way (validating lc-docs is easy, validating code changes is very 
very hard).


I guess for very very very minor tweaks you can copy-paste the code 
you've tried into the github text file editor in the appropriate place, 
and submit a PR. However, if those tweaks then need further work, you 
then have to get that revision onto your machine and then re-tweak.


In the long run, though, that approach is only likely to cause things to 
take longer and cause frustration on both sides.


Warmest Regards,

Mark.

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

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

Re: Contributing to the IDE

[Geoff Canyon via use-livecode]

On Fri, Apr 20, 2018 at 1:08 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> What you are asking for is slightly different: "How do I make it so that I
> can modify the IDE in a pre-built distribution and submit patches/PR from
> that".
>
> The main issue here (and perhaps the only issue) is that the HEAD versions
> of the version branches (release-* branches for specific releases,
> develop-* for the frontier of maintenance releases and develop for the next
> release) in the three main community repositories are all mutually
> dependent to a greater or lesser degree. Whilst you can try and use the
> develop HEAD version of the IDE with an engine built from develop-9.0 or
> earlier, the reality is that it might not work.


​Sorry, one other point: yes, you are correct, working from a pre-built
distribution is exactly the question I was asking, and if the only issue is
syncing the IDE files with the development versions, that seems like a
small issue: many of the files at
https://github.com/livecode/livecode-ide/tree/develop/Toolset/libraries are
months to years from their last update. Ditto for
https://github.com/livecode/livecode-ide/tree/develop/Toolset/palettes/script%20editor/behaviors.
That
makes it seem as though it would absolutely be possible to work on the IDE
in the current 9.x release, with the caveat that merge conflicts would be
*slightly* more likely. ​

Or am I missing something?

Thanks again,

gc
___
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: Contributing to the IDE

[Geoff Canyon via use-livecode]

Thanks, I'm going to give this a shot, probably tomorrow.

gc

On Thu, Apr 19, 2018 at 8:17 PM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I will add that building from source is not that hard for Mac or Linux
> (have not tried Windows). I didn’t know what platform you were using which
> is why I referenced the Readme since it had a section with links for each
> one.
>
> If you run into specific issues getting things set up then we can probably
> help.
> On Thu, Apr 19, 2018 at 9:40 PM Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Hmm… OK Geoff, sorry for being flippant and causing a rant!
> >
> > I must admit I don’t know anything about GitKracken. I used to use
> > SourceTree which I found quite reasonable, however, once working for the
> LC
> > team I found it too slow and hard to do some of the more complicated
> things
> > like interactive rebasing so I moved to command line.
> >
> > > None of it comes close to describing the steps necessary to set up on
> my
> > computer to contribute.
> >
> > The issue I think you are bumping in to is you only really want to
> > contribute to the IDE, however, to do so you really need to build
> livecode
> > from source so you can work on the IDE directly in the respository.
> Because
> > of that the notes linked in the README.md about building LC on different
> > platforms under the section `Detailed instructions` are really what you
> are
> > looking for. https://github.com/livecode/livecode#detailed-instructions
> <
> > https://github.com/livecode/livecode#detailed-instructions>
> > >
> > > it offers nothing useful to figuring out how to set up to contribute.
> >
> > Yes it does. See above ^.
> > >
> > > I ran into this same problem when I started to put Navigator into
> > GitHub: the GitHub documentation is absolutely abysmal. In that instance,
> > the blame lies with literally everyone associated with Git and GitHub,
> but
> > in the case of wanting to contribute to the LC IDE, the buck stops with
> the
> > LC crew. I have asked others who are decades-long LC developers for
> > guidance, and found that they don't understand how to contribute. That
> > holds back development of LC and the IDE.
> >
> > OK, well we’d like to do better in this regard, however, we do tend to
> run
> > into the problem that a large chunk of our experienced LC developers have
> > no interest in reading about git or github. The very best thing you can
> do
> > before anything else is understand git. There is bucket loads of freely
> > available information online. This is a great free book
> > https://git-scm.com/book/en/v2 
> > >
> > > To be clear: reasonable documentation for contributing to the IDE would
> > include a section something like:
> > >
> > > 1. Create an account on GitHub. Follow the guidelines mentioned
> > elsewhere in this documentation.
> >
> > OK, this has presumably been seen as assumed knowledge til now… and/or
> > GitHub’s responsibility do document how to use GitHub. I’m sure we can
> add
> > something though!
> >
> > > 2. (optional) Install the graphic Git client of your choice (a list of
> > possibilities is included at the bottom of this documentation).
> >
> > The problem here is there are lots of graphic git clients. All look
> > different. Ali has spent quite some time documenting how to contribute
> via
> > GitHub’s web interface.
> >
> > > 3. Determine which version of LC you want to contribute to. Note that
> > only contributions to  are being accepted at present.
> >
> > See
> > https://github.com/livecode/livecode/blob/develop/
> CONTRIBUTING.md#branches-in-github
> > <
> > https://github.com/livecode/livecode/blob/develop/
> CONTRIBUTING.md#branches-in-github
> > >
> > > 4. Clone the repository for the LC version you have selected to your
> > local drive.
> >
> > Yes, I agree there’s some missing bits here on forking on github, cloning
> > and setting up the clone. I can give command line instructions and or
> write
> > a script for you to run.
> >
> > Basically we use multiple repositories to build LiveCode. Ignoring the
> > commercial repositories that only the team have access to the structure
> is:
> >
> > livecode
> >ide -> livecode-ide
> >thirdparty -> livecode-thirdparty
> >
> > Most of the ide stacks are in the livecode-ide repository, however, there
> > are some in the ide-support folder of the livecode repository and we are
> > gradually moving as many modular libraries as possible to the
> > extensions/script-libraries folder of the livecode repository.
> >
> > The thirdparty repository is something that anyone outside the team is
> > unlikely to need to patch so we can ignore that for now.
> >
> > So to work on the ide you really need to fork both
> > https://github.com/livecode/livecode  livecode>
> > and https://github.com/livecode/livecode-ide <
> > https://github.com/livecode/livecode-ide>
> >
> > From 

Re: Contributing to the IDE

[Geoff Canyon via use-livecode]

Thanks for the clear rationale. I'll take a shot at building the whole
thing tomorrow.

Two questions:

1. Are older versions closed to changes? If I find a bug in LC 8.1.8 (or
some update to it) is it pointless to fix the bug and submit a pull request?
2. Is it fair to submit IDE pull requests the same way I might for the
documentation? I.E., GitHub was perfectly happy to fork https://github.com/
livecode/livecode-ide/edit/develop/Toolset/palettes/menubar/revmenubar.
livecodescript for me, so it seems that if I update it, I could submit a
pull request for it, without having built anything. Obviously that beheads
a significant fraction of git's functionality, but it gets the job done,
correct?

Thanks,

gc

On Fri, Apr 20, 2018 at 1:08 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-04-17 03:44, Geoff Canyon via use-livecode wrote:
>
>> Are there instructions available somewhere on how to set up the IDE in
>> GitHub so I can make changes and submit pull requests?
>>
>
> Not in the way you are trying to - no.
>
> Pretty much all our documentation is centered around the initial step
> which is getting the entire LiveCode system (engine and IDE) to build from
> source first. The main docs for that start in the LiveCode repo README -
> https://github.com/livecode/livecode/blob/develop/README.md.
>
> What you are asking for is slightly different: "How do I make it so that I
> can modify the IDE in a pre-built distribution and submit patches/PR from
> that".
>
> The main issue here (and perhaps the only issue) is that the HEAD versions
> of the version branches (release-* branches for specific releases,
> develop-* for the frontier of maintenance releases and develop for the next
> release) in the three main community repositories are all mutually
> dependent to a greater or lesser degree. Whilst you can try and use the
> develop HEAD version of the IDE with an engine built from develop-9.0 or
> earlier, the reality is that it might not work.
>
> Whilst it would be really really nice to have the IDE completely
> independent of a given engine version, that is still a dream we are quite a
> way from realizing.
>
> In order to submit a PR which has any chance of being accepted, you have
> to make sure it is submitted against the HEAD of the appropriate branch.
> Whilst you can certainly checkout just the IDE repository, and then
> redirect the Toolset folder from within a LiveCode distribution to use it -
> you might find it does not work as the engine version required to run that
> version of the Toolset (from the HEAD of the branch) might be 'newer' (and
> as-yet unavailable as a built distribution to download) than that which you
> have.
>
> To cut a long story short: right now I'd strongly advise against thinking
> of the engine and IDE as separate things if you want to contribute to the
> LiveCode project because for the most part they are too mutually dependent.
> As it stands, you really need to build the LiveCode repo from source on
> your chosen development platform - as that's the only way you can guarantee
> that you can submit patches against the current HEAD of any of the branches.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: Contributing to the IDE

[Geoff Canyon via use-livecode]

Thanks, on the basis of this document I *think* I was able to submit a pull
request for an update to the documentation for the itemOffset function.
We'll see if that's what I really did, and if successfully so.

I'd highly recommend removing/updating the reference to a specific version
in this document. It points to LC 8.2, which is over 4,000 commits behind,
making it somewhat likely that pull requests based on updates to it will
fail. Instead, it should (I think?) be pointing to
https://github.com/livecode/livecode/tree/develop/docs/dictionary

But again, I could be failing at this completely.

Again, thanks!

On Thu, Apr 19, 2018 at 8:30 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I also just remembered that much of the information that you may find
> helpful is in the contributing to docs page which you may not have read if
> your interest is in source contributions. https://github.com/livecode/
> livecode/blob/develop/docs/contributing_to_docs.md <
> https://github.com/livecode/livecode/blob/develop/docs/
> contributing_to_docs.md>
>
> I’m thinking we would do well to reorganise this doc by moving the docs
> style stuff to the docs style guide and the rest into a more general (not
> just about docs) your first PR doc.
>
> > On 20 Apr 2018, at 12:39 pm, Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hmm… OK Geoff, sorry for being flippant and causing a rant!
>
> ___
> 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: Contributing to the IDE

[Mark Waddingham via use-livecode]

On 2018-04-17 03:44, Geoff Canyon via use-livecode wrote:

Are there instructions available somewhere on how to set up the IDE in
GitHub so I can make changes and submit pull requests?


Not in the way you are trying to - no.

Pretty much all our documentation is centered around the initial step 
which is getting the entire LiveCode system (engine and IDE) to build 
from source first. The main docs for that start in the LiveCode repo 
README -https://github.com/livecode/livecode/blob/develop/README.md.


What you are asking for is slightly different: "How do I make it so that 
I can modify the IDE in a pre-built distribution and submit patches/PR 
from that".


The main issue here (and perhaps the only issue) is that the HEAD 
versions of the version branches (release-* branches for specific 
releases, develop-* for the frontier of maintenance releases and develop 
for the next release) in the three main community repositories are all 
mutually dependent to a greater or lesser degree. Whilst you can try and 
use the develop HEAD version of the IDE with an engine built from 
develop-9.0 or earlier, the reality is that it might not work.


Whilst it would be really really nice to have the IDE completely 
independent of a given engine version, that is still a dream we are 
quite a way from realizing.


In order to submit a PR which has any chance of being accepted, you have 
to make sure it is submitted against the HEAD of the appropriate branch. 
Whilst you can certainly checkout just the IDE repository, and then 
redirect the Toolset folder from within a LiveCode distribution to use 
it - you might find it does not work as the engine version required to 
run that version of the Toolset (from the HEAD of the branch) might be 
'newer' (and as-yet unavailable as a built distribution to download) 
than that which you have.


To cut a long story short: right now I'd strongly advise against 
thinking of the engine and IDE as separate things if you want to 
contribute to the LiveCode project because for the most part they are 
too mutually dependent. As it stands, you really need to build the 
LiveCode repo from source on your chosen development platform - as 
that's the only way you can guarantee that you can submit patches 
against the current HEAD of any of the branches.


Warmest Regards,

Mark.

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

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

Re: OpenLanguage: abstract syntax trees

[Mark Waddingham via use-livecode]

On 2018-04-19 09:57, David Bovill via use-livecode wrote:

So let's ask some dumb questions:

   1. Is there an abstract syntax tree (AST) for the Livecode language?


Yes - the AST is defined by the set of syntax classes in the engine 
source-code (such as MCAnswer, MCMinus, MCProperty).



   2. Where can I buy it?


You don't need to - all the source-code is at 
https://github.com/livecode/livecode.git



   3. How hard would it be to create one?


Well, one already exists so there is no real need to 'create' one 
per-se, although whether its current form is suitable for your needs is 
another matter - I suspect you aren't asking the right question :)




Google told me that I should use Coco, to generate an AST from the C++
code. But i don't trust Google, I much prefer Siri due to her business
model. My hope is that Mark Waddingham will explain this properly. I 
trust

Mark.


CoCo is a compiler front-end generator. It allows you to express a 
tokenizer as a set of regular expressions, and a parser as a formal 
grammar conforming to LL(k)ish 
(https://en.wikipedia.org/wiki/LL_grammar). CoCo then generates 
something which given a source-text will give you a syntax tree of some 
kind.



*Open Language*
My understanding is that we are steadily, if not slower than hoped, 
moving
towards open language in Livecode. It's something I need, hence my 
interest

in DSL's, AST's and compilers. I'd like to know more.


Yes we are still moving towards it, but it is taking a lot longer than 
expected (although lc-compile, the LCB compiler, does have a non-dynamic 
version of Open Language to a certain extent which, unfortunately, isn't 
suitable for LCS in its full gory detail).


At the moment I believe from previous posts, it is possible to create 
DSL's
in Livecode, but you have to compile from source. I'd like to have a go 
at
that if possible, as it may well be a shorter path to creating my DSL, 
than

trying to get Siri to teach me about abstract syntax trees.


Without knowing any details of the new project, or what you would like 
to be able to do it is hard for me to advise here.


Certainly augmenting engine syntax is possible by writing C++ and 
building from source - although the difficult in doing that is entirely 
related to what syntax you'd like to augment / extend / change. That 
wouldn't really create a DSL per-se, but an extended version of LiveCode 
Script (which may be what you want, or maybe not).


Indeed, it is entirely possible that the DSL you want to create doesn't 
require fettling with the engine at all - LCS is a really good language 
for writing DSLs as it stands, as well as interpreters and compilers. 
For example, Ali's tutorial system is a simple DSL, using a parser and 
interpreter both written in LCS 
(https://github.com/livecode/livecode-ide/tree/develop/Toolset/palettes/tutorial).



Mark any chance of sending the gift of your knowledge our way?


I could ramble on at length ( not that I'm prone to that, of course ;) ) 
about designing programming languages, interpreters, compilers, parsers, 
tokenisers, name analysis, abstract syntax trees, concrete syntax trees, 
code generation and a great many other things...


However, I suspect something more focused would be more helpful and for 
that I really need a greater idea of what you are wanting to achieve - 
in particular, what is the DSL you are wanting to create, how do you 
want it to be used, and what is it intended to do?


Warmest Regards,

Mark.

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

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