Re: Thoughts about Functions, Pseudocode & Natural Language

[Richmond]

On 09/12/2015 12:50 PM, Richmond wrote:

On 09/12/2015 12:07 PM, Graham Samuel wrote:

Richmond, I was actually programming in the 1960s in languages that had ‘go to’ 
but very few or maybe no other control structures. It was a mess and I made a 
great many unnecessary mistakes, admittedly not helped by my lack of training 
and experience (none was available where I was working!), the lack of comment 
capability in early assemblers and indeed the limited instruction sets in early 
computers.


Well, I started with MiniFORTRAN and then FORTRAN IV in 1975 . . . up 
to my ears in GOTO statements.

The problem of ‘go to’ is the problem of going back to where you came from: 
subroutines (procedures) obviously take that problem away, so ‘go to’ is vastly 
different from ‘gosub'.


The difference is something I hadn't reflected on: not having a decent 
setup for playing around with BASIC to hand.


Sometimes I wish I could find a way to ship my BBC Micro and its 
non-standard monitor over here from my attic in Scotland just so I could
relax in front of a black screen occasionally: it has BBC BASIC on a 
ROM chip and the things boots up in the blink of an eye.


*Sheer joy!* 
https://muffinresearch.co.uk/ubuntu-installing-the-beebem-bbc-micro-emulator/


Well, perhaps not exactly 'sheer'.

I would *urge all list-users* who have difficulty recalling *GOTO* and 
*GOSUB*, as well as those who are too young to have
"been through the fire" to download Beebem [ 
http://www.mkw.me.uk/beebem/ ] and give it a go. *BASIC* is 
automatically loaded,
one programs with line numbers and as soon as one types *RUN* it 
compiles and runs: instant gratification.


Even if nothing else it shows how far things have come with LiveCode!

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: Thoughts about Functions, Pseudocode & Natural Language

[Dr. Hawkins]

On Sat, Sep 12, 2015 at 12:47 PM, Jerry Jensen  wrote:

> And then there’s the well-known Forth construct: ComeFrom . . .
>

That's Cobol, not Forth.

Forth's own stack behavior can be psychotic, too.

-- 
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: Thoughts about Functions, Pseudocode & Natural Language

[Mark Wieder]

On 09/12/2015 02:33 PM, Dr. Hawkins wrote:

On Sat, Sep 12, 2015 at 12:47 PM, Jerry Jensen  wrote:


And then there’s the well-known Forth construct: ComeFrom . . .



That's Cobol, not Forth.

Forth's own stack behavior can be psychotic, too.



InterCal, I believe, from the April Fools 1984 issue of the CACM.
http://c2.com/cgi/wiki?ComeFrom

How to add two numbers in InterCal:

 DO WRITE IN .1
 DO WRITE IN .2
 DO (1) NEXT
 DO READ OUT .1
 PLEASE GIVE UP
 PLEASE STOP GIVING UP


 (1) DO COME FROM (3)
 (3) DO (2) NEXT
 (2) DO .3 <- "?'.1$.2'"~'#0$#65535'
 DO .2 <- "&'.1$.2'"~'#0$#65535'
 PLEASE .2 <- '.2$#0'~'#65535$#1'
 PLEASE DO .1 <- .3
 DO .3 <- '.2~.2'~#1
 DO .3 <- "?'.3$#1'"~#1
 PLEASE DO FORGET .3
 DO RESUME #1

--
 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: Thoughts about Functions, Pseudocode & Natural Language

[Mark Wieder]

On 09/12/2015 07:12 AM, Dr. Hawkins wrote:


The missing control structure that is killing me in livecode is something
like

repeat for some reason or another :georgeCheck

...
exit repeat georgeCheck


which would allow leaving an outer repeat from within an inner repeat.


If you work at it hard enough, you can exit from an outer repeat by 
adjusting the loop indices before the next repeat.


But otherwise, yes. Named control structures would be nice.

--
 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: Jane Austen's peculiarity

[Richmond]

I am wondering whether this is a relevant point or not,but, here goes 
anyway:


I am looking for occurrences of BE + Past Participle in on-passive, 
intransitive constructions, with examples such as:


*I am arrived*, *He is become*, *She is returned* in publicly available 
versions of English literature 'standards' [no, not going to get

distracted by what constitutes a canon here].

These constructions were displaced over the period 1750-1850 by *I have 
arrived*, *He has arrived* and *She has returned* respectively.


This is for thinking up reasons why this grammatical change may have 
taken place (or a syntactic rather than grammatical change),
and whether English writers (and non-English writers such as Walter 
Scott, who wrote in English contemporaneously) were inherently
conservative.  There is a possibility that Dr Snezha Tsoneva-Mathewson 
(my wife) could construct a model inwith the framework of

Cognitive Grammar to explain how this change may have taken place.

This should be relatively easy using LiveCode, and it is, except for one 
thing: searching through an *html* text loaded into a textField
for the relevant constructions is *far, far slower* than doing the same 
thing by opening the documents in Firefox and doing a 'find' operation.


Of course one cannot put the results into a 'sexy' colour-coded 
textField when one uses Firefox.


Now, possibly I am being a bit foolish expecting LiveCode to crunch its 
way through textFields (even if, as some helpful people
on this list suggested, /they are loaded into variables/) looking for 
strings faster than Firefox (a dedicated html-thing) does.


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

Has anyone created a Pedometer in LiveCode?

[Todd Fabacher]

An iPhone pedometer is one that counts each step a person takes by
detecting the motion of the person's hands or hips. We should be able to
get this using the change in the Y of the accelerometer.

Because the distance of each person's step varies, an informal calibration,
performed by the user will be required, plus we want to match that against
the distance covered using lon/lat of the GPS in the phone.

I looked but was not able to find anything.

I will publish this when done, but any help would be appreciated.

--Todd
___
use-livecode mailing list
use-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: Thoughts about Functions, Pseudocode & Natural Language

[Jerry Jensen]

And then there’s the well-known Forth construct: ComeFrom . . .
.Jerry

> On Sep 12, 2015, at 2:07 AM, Graham Samuel  wrote:
> 
> Richmond, I was actually programming in the 1960s in languages that had ‘go 
> to’ but very few or maybe no other control structures. It was a mess and I 
> made a great many unnecessary mistakes, admittedly not helped by my lack of 
> training and experience (none was available where I was working!), the lack 
> of comment capability in early assemblers and indeed the limited instruction 
> sets in early computers.
> 
> The problem of ‘go to’ is the problem of going back to where you came from: 
> subroutines (procedures) obviously take that problem away, so ‘go to’ is 
> vastly different from ‘gosub'. The classic exposition of the ‘go to’ problem 
> AFAICR is Edgar Dijkstra’s 1968 paper "Go To Statement Considered Harmful”. 
> Google will take you there if you’re interested. Not everyone agreed with 
> Dijkstra even at the time, but he was certainly on to something. You might 
> also give some thought to the idea of if/then/else and case statements being 
> other forms of disciplined control structure. When I started programming, I 
> used languages in which no such pre-defined structures existed. I think we’ve 
> made some progress since then, no?
> 
> Your other issue - the nearer you are to logically expressed natural language 
> / pseudocode, the easier it is to find out what a program is doing, I 
> certainly agree with. This is a genuine dilemma, since there’s a lot 
> inherently complex stuff out there, and it’s getting worse by the minute, and 
> incorporating it in a ’natural-language-like’ form is a huge challenge and 
> one where success is not at all guaranteed. The aim of xTalk languages IMHO 
> is to remove unnecessary obscurity and complexity of vocabulary, syntax and 
> grammar in computer languages so one can get to the real point - but that in 
> itself doesn’t make programming simple, since the actual task and logic of 
> most worthwhile programs is inherently complex.
> 
> Just a couple of eurocents from  me.
> 
> Graham
> 
> 
>> On 12 Sep 2015, at 10:24, Richmond  wrote:
>> 
>> Last night I was reading "C++ How to Program" from 1998, for no better 
>> reason than that I had left my novel
>> at work . . .
>> 
>> Oddly enough bits of it proved thought-provoking:
>> 
>> "During the 1960s, it became clear that the indiscriminate use of transfers 
>> of control was the root of much
>> difficulty experienced by software development groups."
>> 
>> "The notion of so-called /structured programming/ became almost synonymous 
>> with "/*goto* elimination/."
>> The research of Bohm and Jacopini had demonstrated that programs could be 
>> written without any *goto* statements."
>> 
>> [Which is rather odd as from 1975 to 1985 all my programming seemed to 
>> revolve round subroutines.]
>> 
>> When I read this I thought of a *function* in LIveCode, and thought that a 
>> *function* was a /transfer of control/.
>> 
>> The authors of this book don't actually bother to explain why /transfer of 
>> control/ is supposed to be a bad thing.
>> 
>> But they do say this:
>> 
>> "structured programs are clearer, easier to debug and modify, and more 
>> likely to be bug-free in the first place."
>> 
>> I actually find that statement pretty contentious. Particularly "more likely 
>> to be bug-free in the first place." The authors
>> do not give examples and explanations as to why this might be true.
>> 
>> The other thing is that programs written without transfers of control would 
>> seem to necessitate the needless *repetition*
>> of code-blocks that, if hived-off into a *function*, can be written once, 
>> and control can be transferred to them when and
>> if that functionality is required.
>> 
>> Certainly calling a *function* in *LiveCode* seems no different from using a 
>> *goto* or *gosub* statement.
>> 
>> --
>> 
>> Further on I came across this:
>> 
>> "Pseudocode is often used to "think out" a program during the program design 
>> purpose.
>> The the pseudocode is converted to C++."
>> 
>> And it occurred to me that *LiveCode scripting* is considerably nearer to 
>> what these authors call 'pseudocode' than C++ is,
>> and wondered if:
>> 
>> The closer a programming language approximates to pseudocode the easier it 
>> becomes to use.
>> 
>> At which point I started wondering if LiveCode, from its starting point in 
>> HyperCard and MetaCard hadn't, subsequently,
>> moved further away from the pseudocode 'ideal' and further towards a more 
>> 'traditional' programming language with,
>> as it has become more sophisticated and powerful, the introduction of stuff 
>> that looks less like natural language and
>> more like a computer language?
>> 
>> --
>> 
>> Certainly, from the point of view 

Re: How We Can Have Nice Things

[Monte Goulding]

> On 11 Sep 2015, at 6:46 pm, Ali Lloyd  wrote:
> 
> maybe using yaml or
> something similar

Interesting you mention YAML. I’ve started looking at implementing a YAML file 
<-> array in a combination of LCB library and libyaml for the parser/emitter. 
For lcVCS I used JSON because I’d only just implemented a JSON <-> array 
external. However, JSON isn’t brilliant because if you add an element to an 
object or array you will get a diff on the new trailing comma of the previous 
element. I looked at CSON because that resolves the issues but YAML can do 
multi-line values which will be good for script, htmlText and some custom 
properties.

Anyway, my plan is to see what it looks like if everything is exported to one 
file rather than a directory. It probably means base64Encoded image data in the 
hope people mostly use referenced images.

If it’s all in one file the object hierarchy can be represented in the nesting 
structure which is something I couldn’t do in directories because of 
limitations on windows. Now that we can use stacks as behaviors I can drop the 
UUID translation on those in that instance also. Whether diffs are any less 
confusing I’m not sure however they won’t be any less confusing than those on a 
storyboard or xib files. Probably significantly less confusing actually…

Anyway, not sure when I’ll have time to get all this done but the target would 
be LC 8+ so it’s really not much to do with this conversation if we are mainly 
focussed on the 6 & 7 IDEs.

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: Thoughts about Functions, Pseudocode & Natural Language

[Dr. Hawkins]

On Sat, Sep 12, 2015 at 3:09 PM, Mark Wieder  wrote:

> InterCal, I believe, from the April Fools 1984 issue of the CACM.
> http://c2.com/cgi/wiki?ComeFrom
>

Yes, but it was really there, and really used, in Cobol



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

Thoughts about Functions, Pseudocode & Natural Language

[Richmond]

Last night I was reading "C++ How to Program" from 1998, for no better 
reason than that I had left my novel

at work . . .

Oddly enough bits of it proved thought-provoking:

"During the 1960s, it became clear that the indiscriminate use of 
transfers of control was the root of much

difficulty experienced by software development groups."

"The notion of so-called /structured programming/ became almost 
synonymous with "/*goto* elimination/."
The research of Bohm and Jacopini had demonstrated that programs could 
be written without any *goto* statements."


[Which is rather odd as from 1975 to 1985 all my programming seemed to 
revolve round subroutines.]


When I read this I thought of a *function* in LIveCode, and thought that 
a *function* was a /transfer of control/.


The authors of this book don't actually bother to explain why /transfer 
of control/ is supposed to be a bad thing.


But they do say this:

"structured programs are clearer, easier to debug and modify, and more 
likely to be bug-free in the first place."


I actually find that statement pretty contentious. Particularly "more 
likely to be bug-free in the first place." The authors

do not give examples and explanations as to why this might be true.

The other thing is that programs written without transfers of control 
would seem to necessitate the needless *repetition*
of code-blocks that, if hived-off into a *function*, can be written 
once, and control can be transferred to them when and

if that functionality is required.

Certainly calling a *function* in *LiveCode* seems no different from 
using a *goto* or *gosub* statement.


--

Further on I came across this:

"Pseudocode is often used to "think out" a program during the program 
design purpose.

The the pseudocode is converted to C++."

And it occurred to me that *LiveCode scripting* is considerably nearer 
to what these authors call 'pseudocode' than C++ is,

and wondered if:

The closer a programming language approximates to pseudocode the easier 
it becomes to use.


At which point I started wondering if LiveCode, from its starting point 
in HyperCard and MetaCard hadn't, subsequently,
moved further away from the pseudocode 'ideal' and further towards a 
more 'traditional' programming language with,
as it has become more sophisticated and powerful, the introduction of 
stuff that looks less like natural language and

more like a computer language?

--

Certainly, from the point of view of teaching LiveCode to school 
children, the closer LiveCode is to both English and

'pseudocode' the easier the job that is involved turns out to be.

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: Thoughts about Functions, Pseudocode & Natural Language

[Richmond]

On 09/12/2015 12:07 PM, Graham Samuel wrote:

Richmond, I was actually programming in the 1960s in languages that had ‘go to’ 
but very few or maybe no other control structures. It was a mess and I made a 
great many unnecessary mistakes, admittedly not helped by my lack of training 
and experience (none was available where I was working!), the lack of comment 
capability in early assemblers and indeed the limited instruction sets in early 
computers.


Well, I started with MiniFORTRAN and then FORTRAN IV in 1975 . . . up to 
my ears in GOTO statements.


The problem of ‘go to’ is the problem of going back to where you came from: 
subroutines (procedures) obviously take that problem away, so ‘go to’ is vastly 
different from ‘gosub'.


The difference is something I hadn't reflected on: not having a decent 
setup for playing around with BASIC to hand.


Sometimes I wish I could find a way to ship my BBC Micro and its 
non-standard monitor over here from my attic in Scotland just so I could
relax in front of a black screen occasionally: it has BBC BASIC on a ROM 
chip and the things boots up in the blink of an eye.


You are quite right.


The classic exposition of the ‘go to’ problem AFAICR is Edgar Dijkstra’s 1968 paper 
"Go To Statement Considered Harmful”. Google will take you there if you’re 
interested. Not everyone agreed with Dijkstra even at the time, but he was certainly 
on to something. You might also give some thought to the idea of if/then/else and 
case statements being other forms of disciplined control structure. When I started 
programming, I used languages in which no such pre-defined structures existed. I 
think we’ve made some progress since then, no?


That does not stop me thinking that a *function* in LiveCode is very 
close to a *subroutine* in a 'traditional' program:

not that that is intended as a criticism.



Your other issue - the nearer you are to logically expressed natural language / 
pseudocode, the easier it is to find out what a program is doing, I certainly 
agree with. This is a genuine dilemma, since there’s a lot inherently complex 
stuff out there, and it’s getting worse by the minute, and incorporating it in 
a ’natural-language-like’ form is a huge challenge and one where success is not 
at all guaranteed. The aim of xTalk languages IMHO is to remove unnecessary 
obscurity and complexity of vocabulary, syntax and grammar in computer 
languages so one can get to the real point - but that in itself doesn’t make 
programming simple, since the actual task and logic of most worthwhile programs 
is inherently complex.


Of course. But teaching children to think through the logic involved in 
programming is made a lot easier when they don't also have

to navigate the complexities of a 'traditional' computer language.

I do tend to teach the logic of programming (however naturalistic the 
language in LiveCode may be) by messing around with physical
objects on a table; then writing pseudocode next to the objects (nothing 
quite like having a wipe-clean table and a pack of washable
board-markers!), before considering LiveCode: keeping children away from 
the keyboard and the computer is about half of the

struggle.

I think I began to feel a bit queasy when I attended the Edinburgh 
conference about 6 years ago and saw Benjamin Beaumont demonstrate
the Graphic Effects: and I don't mean that either Ben Beaumont or the 
Graphic Effects made me feel queasy; it was the syntax involved to

code the Graphic Effects (rather than just use the Props palette).

I think that may be the moment when LiveCode began to depart from the 
fairly natural language it had inherited from HyperCard: it may
have been necessary, or it may have been that the work to effect that 
stuff using fairly natural language was just a lot of hard work for
too little return: especially as I don't seem to see many people paying 
the Graphic Effects much attention (my Devawriter depends on

them for user feedback).



Just a couple of eurocents from  me.


Well, as 2 Eurocents is 4 Bulgarian Stotinki . . .  :)

Best, Richmond.



Graham



On 12 Sep 2015, at 10:24, Richmond  wrote:

Last night I was reading "C++ How to Program" from 1998, for no better reason 
than that I had left my novel
at work . . .

Oddly enough bits of it proved thought-provoking:

"During the 1960s, it became clear that the indiscriminate use of transfers of 
control was the root of much
difficulty experienced by software development groups."

"The notion of so-called /structured programming/ became almost synonymous with 
"/*goto* elimination/."
The research of Bohm and Jacopini had demonstrated that programs could be written 
without any *goto* statements."

[Which is rather odd as from 1975 to 1985 all my programming seemed to revolve 
round subroutines.]

When I read this I thought of a *function* in LIveCode, and thought that a 
*function* was a /transfer of control/.

The authors of this book don't 

Re: Thoughts about Functions, Pseudocode & Natural Language

[Graham Samuel]

Richmond, I was actually programming in the 1960s in languages that had ‘go to’ 
but very few or maybe no other control structures. It was a mess and I made a 
great many unnecessary mistakes, admittedly not helped by my lack of training 
and experience (none was available where I was working!), the lack of comment 
capability in early assemblers and indeed the limited instruction sets in early 
computers.

The problem of ‘go to’ is the problem of going back to where you came from: 
subroutines (procedures) obviously take that problem away, so ‘go to’ is vastly 
different from ‘gosub'. The classic exposition of the ‘go to’ problem AFAICR is 
Edgar Dijkstra’s 1968 paper "Go To Statement Considered Harmful”. Google will 
take you there if you’re interested. Not everyone agreed with Dijkstra even at 
the time, but he was certainly on to something. You might also give some 
thought to the idea of if/then/else and case statements being other forms of 
disciplined control structure. When I started programming, I used languages in 
which no such pre-defined structures existed. I think we’ve made some progress 
since then, no?

Your other issue - the nearer you are to logically expressed natural language / 
pseudocode, the easier it is to find out what a program is doing, I certainly 
agree with. This is a genuine dilemma, since there’s a lot inherently complex 
stuff out there, and it’s getting worse by the minute, and incorporating it in 
a ’natural-language-like’ form is a huge challenge and one where success is not 
at all guaranteed. The aim of xTalk languages IMHO is to remove unnecessary 
obscurity and complexity of vocabulary, syntax and grammar in computer 
languages so one can get to the real point - but that in itself doesn’t make 
programming simple, since the actual task and logic of most worthwhile programs 
is inherently complex.

Just a couple of eurocents from  me.

Graham


> On 12 Sep 2015, at 10:24, Richmond  wrote:
> 
> Last night I was reading "C++ How to Program" from 1998, for no better reason 
> than that I had left my novel
> at work . . .
> 
> Oddly enough bits of it proved thought-provoking:
> 
> "During the 1960s, it became clear that the indiscriminate use of transfers 
> of control was the root of much
> difficulty experienced by software development groups."
> 
> "The notion of so-called /structured programming/ became almost synonymous 
> with "/*goto* elimination/."
> The research of Bohm and Jacopini had demonstrated that programs could be 
> written without any *goto* statements."
> 
> [Which is rather odd as from 1975 to 1985 all my programming seemed to 
> revolve round subroutines.]
> 
> When I read this I thought of a *function* in LIveCode, and thought that a 
> *function* was a /transfer of control/.
> 
> The authors of this book don't actually bother to explain why /transfer of 
> control/ is supposed to be a bad thing.
> 
> But they do say this:
> 
> "structured programs are clearer, easier to debug and modify, and more likely 
> to be bug-free in the first place."
> 
> I actually find that statement pretty contentious. Particularly "more likely 
> to be bug-free in the first place." The authors
> do not give examples and explanations as to why this might be true.
> 
> The other thing is that programs written without transfers of control would 
> seem to necessitate the needless *repetition*
> of code-blocks that, if hived-off into a *function*, can be written once, and 
> control can be transferred to them when and
> if that functionality is required.
> 
> Certainly calling a *function* in *LiveCode* seems no different from using a 
> *goto* or *gosub* statement.
> 
> --
> 
> Further on I came across this:
> 
> "Pseudocode is often used to "think out" a program during the program design 
> purpose.
> The the pseudocode is converted to C++."
> 
> And it occurred to me that *LiveCode scripting* is considerably nearer to 
> what these authors call 'pseudocode' than C++ is,
> and wondered if:
> 
> The closer a programming language approximates to pseudocode the easier it 
> becomes to use.
> 
> At which point I started wondering if LiveCode, from its starting point in 
> HyperCard and MetaCard hadn't, subsequently,
> moved further away from the pseudocode 'ideal' and further towards a more 
> 'traditional' programming language with,
> as it has become more sophisticated and powerful, the introduction of stuff 
> that looks less like natural language and
> more like a computer language?
> 
> --
> 
> Certainly, from the point of view of teaching LiveCode to school children, 
> the closer LiveCode is to both English and
> 'pseudocode' the easier the job that is involved turns out to be.
> 
> Richmond.
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> 

6.7.6 Project Browser

[Mike Kerner]

I just downloaded 6.7.6 stable and noticed that the PB doesn't seem to be
populating.  Anyone else?

-- 
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: 6.7.6 Project Browser

[Terence Heaford]

> On 12 Sep 2015, at 16:30, Mike Kerner  wrote:
> 
> I just downloaded 6.7.6 stable and noticed that the PB doesn't seem to be
> populating.  Anyone else?


Yes, I have noticed this.

Closing it and reopening does it for me.


All the best

Terry
___
use-livecode mailing list
use-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: Release 6.7.7 RC 4 / 7.1.0 RC 3

[Dr. Hawkins]

On Fri, Sep 11, 2015 at 7:55 PM, James Hale  wrote:

> Er, 10.10 gold master was released to developers earlier this week.
>

I see that I can download the "GM Seed"--which then warns the 10.11 is
already installed (I'm at Developer Beta 8), and should update instead.

But there is no update available (developer betas generally appear in the
app store)



-- 
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: Thoughts about Functions, Pseudocode & Natural Language

[Dr. Hawkins]

On Sat, Sep 12, 2015 at 2:07 AM, Graham Samuel  wrote:

> The classic exposition of the ‘go to’ problem AFAICR is Edgar Dijkstra’s
> 1968 paper "Go To Statement Considered Harmful”. Google will take you there
> if you’re interested. Not everyone agreed with Dijkstra even at the time,
> but he was certainly on to something


And in time this morphed into the notion that goto should never be used . .
.

When I was writing the program for my dissertation, I eventually realized
that I was updating to identical blocks of code solely to avoid a goto.  I
put it in, and life became much easier (now, that was an exotic case, where
I had to escape a nested control structure or some such; I forget the
details.  The routine could be entered from multiple states, requiring
different startup prep)

The missing control structure that is killing me in livecode is something
like

repeat for some reason or another :georgeCheck

...
exit repeat georgeCheck


which would allow leaving an outer repeat from within an inner repeat.


As far as transfer of control, even into the 90s it could be "expensive".
To call a function or subroutine, there were variables and registers to be
dumped in some manner, possibly by pushing to the stack, new ones to be
loaded and initialized, and then the restoration of the original state on
return.

I wrote a model in smalltalk in 95 or 96, with "proper" message passing and
functions.  It was insanely slow.

I rewrote, pretty much line for line, in Fortran with arrays and no effort
to optimize, and got a 45,000:1 speedup . . .

Also, note that at least older Fortran had two types of functions, one with
code that returned a value, and the other was a an inline math expression,
which wouldn't require a transfer of control.

It's probably part of my 8 bit hangover, but I still hesitate every
function call or subroutine aI write, wondering how expensive it will be .
. .

-- 
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: Release 6.7.7 RC 4 / 7.1.0 RC 3

[Colin Holgate]

To go from beta 8 to GM I had to click the button in the developer page. That 
then did a new download from the App Store. I used the link on this page:

https://developer.apple.com/osx/download/


> On Sep 12, 2015, at 9:50 AM, Dr. Hawkins  wrote:
> 
> On Fri, Sep 11, 2015 at 7:55 PM, James Hale  wrote:
> 
>> Er, 10.10 gold master was released to developers earlier this week.
>> 
> 
> I see that I can download the "GM Seed"--which then warns the 10.11 is
> already installed (I'm at Developer Beta 8), and should update instead.
> 
> But there is no update available (developer betas generally appear in the
> app store)
> 
> 
> 
> -- 
> 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


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