Re: do. command. safety. ?
The user input was indirected through a variable in the safe version - not made part of the do string... That's the critical difference. The unsafe version allows user input to change the do'd code, the safe version only changes the content of a variable the do string uses. Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 19:24, J. Landman Gay via use-livecode > wrote: > > Well yes, but as Bob mentioned, wouldn't a variable do the same thing? > > put ";delete hard drive;put " into x > do x > > vs: > > do "put " && quote & ";delete hard drive;put " & quote && "into x" > > This actually came up way back in MetaCard where it was pointed out that the > engine was about as secure as it gets as long as you validate all user input > when using "do" or (I think) "value". In the first example above, input needs > to be examined before the "do" command is issued. So I think there's a line > or two missing in there somewhere. ;) > > >> On 3/30/18 12:15 PM, Mark Waddingham via use-livecode wrote: >> Think about the string that can be constructed in the quoted version - user >> input could be "; ...;put " where ... is any code you would like... >> Sent from my iPhone >>> On 30 Mar 2018, at 18:09, J. Landman Gay via use-livecode >>> wrote: >>> >>> These look the same to me. Both versions place content into a variable. Is >>> the difference because of how the engine evaluates the input somehow? >>> >>> -- >>> Jacqueline Landman Gay | jac...@hyperactivesw.com >>> HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 11:04:54 AM Mark Waddingham via use-livecode wrote: Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using quotes, use a local var instead: put user input into tVar1 do "put tVar1 into x" -- safe Rather than do "put " && quote & user input & quote && "into x" -- not safe Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 16:43, Tom Glod via use-livecode > wrote: > > Dear Geniuses > > Sometimes late at night just before falling asleep I think about the > dangers of the do command. Is it possible to inject code into this > mechanism through malware? > > I do not have enough understanding of operating systems and their > processes > ...and the livecode engineto be able to know if its a reasonable > question or not. > > Thanks for any input on this. > ___ > > > -- > 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
Browser Widget Document Download
I have a url(that does not directly reference a file) that on iOS displays a PDF in the iOS native PDF viewer and on Android Downloads the PDF as Android has no native PDF viewer. I would like to download the PDF at all times. Testing in the IDE... When I set the widget to the url the PDF displays. When I put the url into a var "put url (tURL) into MyVar" I see some html/javascript in MyVar but no PDF. What I would like to do is download the PDF on both mobile platforms. Is this even possible with LC? Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: variable xref
Mark Wieder wrote: > A good question to ask here might be "what are the pain points of the > language as it now exists?" For me performance is a pain point. If I can demonstrate LC is at least on par with other scripting languages I get a foot in the door. But in server work performance counts a lot. So the question I've been wondering is: what exactly did the PHP team do in their v7 to boost its speed so far beyond v5, blowing pretty much every other scripting language out of the water, and is there anything among those optimizations that can be applied to LC? If LC were even close to being as fast as PHP7, it would so destroy Rails it would open many doors -- 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: do. command. safety. ?
Tom Glod wrote: > Sometimes late at night just before falling asleep I think about > the dangers of the do command. Is it possible to inject code into > this mechanism through malware? Mark's discussion handled the security aspect well. The only thing I could add would be to examine each case and determine if "do" is even needed at all there. In addition to the risk of inviting arbitrary code execution, it's usually slower than any more direct alternative. And its use is often dependent on concatenated expressions, making code more cumbersome to both write and read. We used to use "do" a lot in HC, where we had to rely on it often to circumvent limitations with concatenated object references, variables with names that could not be known in advance, and others. LC has much more intelligent handling of concatenated object expressions, and with arrays we can handle any number of variables where we need the variable name determined on the fly. In LC "do" is still sometimes useful, but far less often. I can't remember the last time I needed to use, probably a couple years ago. -- 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: variable xref
Hence my original statement about the xTalk language trying to be English like. (Back then I don't think Hypercard was multi-language). Bob S > On Mar 30, 2018, at 10:53 , Mikey via use-livecode > wrote: > > When I was thinking about unquoted literals I was thinking about string > literals, something like > put one into counter > Or > put one into two > > Numeric literals don’t offend the senses: > put 1 into counter ___ 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: do. command. safety. ?
Well yes, but as Bob mentioned, wouldn't a variable do the same thing? put ";delete hard drive;put " into x do x vs: do "put " && quote & ";delete hard drive;put " & quote && "into x" This actually came up way back in MetaCard where it was pointed out that the engine was about as secure as it gets as long as you validate all user input when using "do" or (I think) "value". In the first example above, input needs to be examined before the "do" command is issued. So I think there's a line or two missing in there somewhere. ;) On 3/30/18 12:15 PM, Mark Waddingham via use-livecode wrote: Think about the string that can be constructed in the quoted version - user input could be "; ...;put " where ... is any code you would like... Sent from my iPhone On 30 Mar 2018, at 18:09, J. Landman Gay via use-livecode wrote: These look the same to me. Both versions place content into a variable. Is the difference because of how the engine evaluates the input somehow? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 11:04:54 AM Mark Waddingham via use-livecode wrote: Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using quotes, use a local var instead: put user input into tVar1 do "put tVar1 into x" -- safe Rather than do "put " && quote & user input & quote && "into x" -- not safe Warmest Regards, Mark. Sent from my iPhone On 30 Mar 2018, at 16:43, Tom Glod via use-livecode wrote: Dear Geniuses Sometimes late at night just before falling asleep I think about the dangers of the do command. Is it possible to inject code into this mechanism through malware? I do not have enough understanding of operating systems and their processes ...and the livecode engineto be able to know if its a reasonable question or not. Thanks for any input on this. ___ -- 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: variable xref
When I was thinking about unquoted literals I was thinking about string literals, something like put one into counter Or put one into two Numeric literals don’t offend the senses: put 1 into counter In the case of property assignments I could be persuaded either way: that there is a global constant left that means “left” (making it a reserved word), that in the context of certain properties, certain string values are constants and not containers (not as ideal since there is then also going to have to be a warning to the user that their container called “left” is not going to work in the context of the property), that we’re going to have to quote “left” (also not ideal), or that we’re going to allow unquoted string literals in property assignments (but then we are back to the parser/lexer really should error check assignments for some properties so someone doesn’t set the align to tpo unless tpo had previously been used and/or assigned a value, and therefore appears in the symbol table). The last one gets us back to having the parser/lex doing some spellchecking or symbol lookup. Deprecating “features” is often the right thing to do because it cleans up kluges that are no long necessary, and clarity and simplicity and order are restored. Yes, that means that some code will be affected and have to be reworked. It’s either that or n00bs need a separate note in the dictionary for every kluge, the same way that non-native English speakers get to fight through every exception in spelling and punctuation. I sometimes mention the running joke in 4D, “The Tao”, a collection of all the things that are counterintuitive that you have to work around. ___ 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: do. command. safety. ?
Couldn't the same be said about tVar? I suppose you mean that you could check the user input before doing it. Bob S > On Mar 30, 2018, at 10:15 , Mark Waddingham via use-livecode > wrote: > > Think about the string that can be constructed in the quoted version - user > input could be "; ...;put " where ... is any code you would like... ___ 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: variable xref
We have computers automate these processes, but always with a human ready to intervene. The computer will act based upon the inputs it receives. If the inputs go wrong, you may have an exceptional diagnostic routine running to detect it and act accordingly, but only a human can make a judgement at "runtime" if you will. The value to using computers in these instances is that computers can react much more quickly, and given all the corrects inputs, and assuming it is functioning correctly, will always make the right "decision" based upon a predetermined set of parameters. A human can be slow. A human can make mistakes. A human can become malicious. A computer cannot. A computer can however, lack all the inputs to make what we would call a right decision. Take the classic arguement of a person walking a dog. The dog breaks away right in front of an oncoming car with no time to stop. Does the car swerve to avoid the living mammal right in front of it and hit the dog owner instead? How could you program a computer to make that distinction? If computers are going to drive cars, then it needs to be done all at once. A switch gets thrown and now no one's car will work unless the computer is driving it. Also, I think it would be better if auto driving cars were restricted to places without crossing traffic, like highways/freeways. A car leaving a freeway would have to come to a stop and the driver should have to take control to proceed on streets. Ideally self driving cars should never be based entirely upon optics. For this sort of thing to be really as safe as can be managed, every car would need to have beacons at the corners and maybe along the sides, and the cars would need to be in communication with all the other cars within a certain distance of it. People however would not accept this because there would be the potential to track people without them knowing it's being done. (Of course that is likely happening now but that's another discussion). Bob S > On Mar 30, 2018, at 09:51 , Mark Waddingham via use-livecode > wrote: > > In terms of computers driving cars then we let computers monitor and > interpret sensors for humans in nuclear power stations. We let them 'drive' > very large aircraft and provide simulated feedback and sensor interpretation > there to pilots. Same for trains, trams, vehicles in factories and > warehouses... So why not cars? ;) ___ 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: do. command. safety. ?
Think about the string that can be constructed in the quoted version - user input could be "; ...;put " where ... is any code you would like... Sent from my iPhone > On 30 Mar 2018, at 18:09, J. Landman Gay via use-livecode > wrote: > > These look the same to me. Both versions place content into a variable. Is > the difference because of how the engine evaluates the input somehow? > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com >> On March 30, 2018 11:04:54 AM Mark Waddingham via use-livecode >> wrote: >> >> Using do safely is the same as making database queries safe, or URL requests. >> >> You 'just' need to make sure that any input from outside is sanitized to >> ensure that it doesn't change the meaning of the expression you are 'doing'. >> >> For example, don't interpolate strings directly in the script using quotes, >> use a local var instead: >> >> put user input into tVar1 >> do "put tVar1 into x" -- safe >> >> Rather than >> >> do "put " && quote & user input & quote && "into x" -- not safe >> >> Warmest Regards, >> >> Mark. >> >> Sent from my iPhone >> >> > On 30 Mar 2018, at 16:43, Tom Glod via use-livecode >> > wrote: >> > >> > Dear Geniuses >> > >> > Sometimes late at night just before falling asleep I think about the >> > dangers of the do command. Is it possible to inject code into this >> > mechanism through malware? >> > >> > I do not have enough understanding of operating systems and their processes >> > ...and the livecode engineto be able to know if its a reasonable >> > question or not. >> > >> > Thanks for any input on this. >> > ___ >> > 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 ___ 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: do. command. safety. ?
These look the same to me. Both versions place content into a variable. Is the difference because of how the engine evaluates the input somehow? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 11:04:54 AM Mark Waddingham via use-livecode wrote: Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using quotes, use a local var instead: put user input into tVar1 do "put tVar1 into x" -- safe Rather than do "put " && quote & user input & quote && "into x" -- not safe Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 16:43, Tom Glod via use-livecode wrote: > > Dear Geniuses > > Sometimes late at night just before falling asleep I think about the > dangers of the do command. Is it possible to inject code into this > mechanism through malware? > > I do not have enough understanding of operating systems and their processes > ...and the livecode engineto be able to know if its a reasonable > question or not. > > Thanks for any input on this. > ___ > 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: do. command. safety. ?
your point still applies about not being responsible that the user has allowed malware onto their system. On Fri, Mar 30, 2018 at 12:52 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Ah I saw command in the subject and thought you were talking about shell > commands. > > Bob S > > > > On Mar 30, 2018, at 09:49 , Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Valid point Bob. Thank You. > > > > Useful info, Thanks Mark. I was doing it the right way sometimes. the > > wrong way other times. thank you. > > > ___ > 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: do. command. safety. ?
Ah I saw command in the subject and thought you were talking about shell commands. Bob S > On Mar 30, 2018, at 09:49 , Tom Glod via use-livecode > wrote: > > Valid point Bob. Thank You. > > Useful info, Thanks Mark. I was doing it the right way sometimes. the > wrong way other times. thank you. ___ 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: variable xref
That's pretty much my point of view - the compiler should keep you out of trouble but not get in the way. Colours are the same case as left in the context of textAlign. If we reserved all lowercase alphabetic identifiers, so your vars had to contain an uppercase letter or non letter character then that would 'solve' that problem at the expense of freedom of the coder. (But only for natural languages which have casing!). So really what we want is 'reserved in context' - the problem there though is the context - in many cases that can only be known at runtime. In terms of computers driving cars then we let computers monitor and interpret sensors for humans in nuclear power stations. We let them 'drive' very large aircraft and provide simulated feedback and sensor interpretation there to pilots. Same for trains, trams, vehicles in factories and warehouses... So why not cars? ;) Although that being said - I do have a slight issue with computers driving cars at this point in time - but only because they have to deal with humans driving cars and those pesky pedestrians with free will... Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 17:27, Mark Wieder via use-livecode > wrote: > >> On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote: >> >> I'd suggest that the language doesn't matter - so 'natural language like' >> would perhaps be a better term but even then is that really what we mean? > > A good question to ask here might be "what are the pain points of the > language as it now exists?" > > Since I always use strict variable checking I don't have to worry about > unquoted literals because the compiler will always give me an error. For me > the pain of having to put quotes around literals is muchly offset by the > security of having the compiler keep me out of trouble. Mostly. YMMV. > > On the other hand, there are certain keywords that I think really should be > constants and not unquoted literals. I find it a pain to have to put quotes > around color names. If I want to set a text color to black, I find it awkward > to have to set it to "black". > >> So we are perhaps talking about constructing language(s) which allows a >> computer to be instructed more like we would a human - i.e. not having to >> define every single thing in mind numbing detail, knowing that the receiver >> has enough competence and knowledge to infer and fill in the gaps correctly >> and then carrying out those actions with a high degree of accuracy (although >> computers are probably already better for accuracy in many domains - they >> just need their hand held throughout!) or at least have the ability to shout >> when things really don't 'compute'. In this vein I'm not sure syntax is so >> important. > > I'm still not ready to have computers drive cars. > -- > 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: do. command. safety. ?
Valid point Bob. Thank You. Useful info, Thanks Mark. I was doing it the right way sometimes. the wrong way other times. thank you. On Fri, Mar 30, 2018 at 12:02 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Using do safely is the same as making database queries safe, or URL > requests. > > You 'just' need to make sure that any input from outside is sanitized to > ensure that it doesn't change the meaning of the expression you are 'doing'. > > For example, don't interpolate strings directly in the script using > quotes, use a local var instead: > > put user input into tVar1 > do "put tVar1 into x" -- safe > > Rather than > > do "put " && quote & user input & quote && "into x" -- not safe > > Warmest Regards, > > Mark. > > Sent from my iPhone > > > On 30 Mar 2018, at 16:43, Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Dear Geniuses > > > > Sometimes late at night just before falling asleep I think about the > > dangers of the do command. Is it possible to inject code into this > > mechanism through malware? > > > > I do not have enough understanding of operating systems and their > processes > > ...and the livecode engineto be able to know if its a reasonable > > question or not. > > > > Thanks for any input on this. > > ___ > > 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: variable xref
I think we are not seeing the elephant in the room here. Programming languages work because a great deal of effort has been exherted defining what we MEAN when we SAY something to the computer. In fact the whole process of writing software is precicely that of removing all ambiguity. It's true that on the surface it appears that we can tell the computer what we want and it can interpret what we mean, but only because under the hood someone wrote code that says in effect, given all these inputs, produce this output. That process is after all at it's heart a binary one. The fact that we are not constantly aware of this is why some men are able to believe that "artificial" intelligence means "actual" intelligence. The only intelligence a computer can posess is that of the developer and the end user. Anything else is an illusion. A grand one I grant, but still it's only the old smoke and mirrors of the ancient sorcerers. The "magic" is making sure no one sees what the sorcerer is actually doing while his subjects are distracted by something else. Let the flaming begin! ;-) Bob S > On Mar 30, 2018, at 08:56 , Mark Waddingham via use-livecode > wrote: > > An important question to ask here is 'what do we mean by English-like'? > > I'd suggest that the language doesn't matter - so 'natural language like' > would perhaps be a better term but even then is that really what we mean? > > There's no inherent difference (formally at least) between a programming > language and a natural language - at least from the way they are written > (letters, punctuation, grammar, vocabulary) and perhaps not even in terms of > interpretation (what a phrase in a language means - they are either > declarations/definition of things, providing context or instructing actions). > > The difference comes at the point we consider the 'machine' which the > language is instructing - human or computer. > > From this (very narrow) point of view, human machines (the brain) are perhaps > just a great deal better 'engineered' to process language quickly and have a > much greater capacity for storing, recalling and processing contextual > information which means ambiguities can be resolved with a much greater > degree of precision and fault tolerance. > > So we are perhaps talking about constructing language(s) which allows a > computer to be instructed more like we would a human - i.e. not having to > define every single thing in mind numbing detail, knowing that the receiver > has enough competence and knowledge to infer and fill in the gaps correctly > and then carrying out those actions with a high degree of accuracy (although > computers are probably already better for accuracy in many domains - they > just need their hand held throughout!) or at least have the ability to shout > when things really don't 'compute'. In this vein I'm not sure syntax is so > important. > > I don't think the experiment as you put it has yet ended - computers and > their software development have just not caught up yet which is, in part, > probably at least related to performance of computer machines for these kinds > of tasks. > > Warmest Regards, > > Mark. ___ 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: variable xref
On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote: I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean? A good question to ask here might be "what are the pain points of the language as it now exists?" Since I always use strict variable checking I don't have to worry about unquoted literals because the compiler will always give me an error. For me the pain of having to put quotes around literals is muchly offset by the security of having the compiler keep me out of trouble. Mostly. YMMV. On the other hand, there are certain keywords that I think really should be constants and not unquoted literals. I find it a pain to have to put quotes around color names. If I want to set a text color to black, I find it awkward to have to set it to "black". So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important. I'm still not ready to have computers drive cars. -- 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: do. command. safety. ?
Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using quotes, use a local var instead: put user input into tVar1 do "put tVar1 into x" -- safe Rather than do "put " && quote & user input & quote && "into x" -- not safe Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 16:43, Tom Glod via use-livecode > wrote: > > Dear Geniuses > > Sometimes late at night just before falling asleep I think about the > dangers of the do command. Is it possible to inject code into this > mechanism through malware? > > I do not have enough understanding of operating systems and their processes > ...and the livecode engineto be able to know if its a reasonable > question or not. > > Thanks for any input on this. > ___ > 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: variable xref
An important question to ask here is 'what do we mean by English-like'? I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean? There's no inherent difference (formally at least) between a programming language and a natural language - at least from the way they are written (letters, punctuation, grammar, vocabulary) and perhaps not even in terms of interpretation (what a phrase in a language means - they are either declarations/definition of things, providing context or instructing actions). The difference comes at the point we consider the 'machine' which the language is instructing - human or computer. >From this (very narrow) point of view, human machines (the brain) are perhaps >just a great deal better 'engineered' to process language quickly and have a >much greater capacity for storing, recalling and processing contextual >information which means ambiguities can be resolved with a much greater degree >of precision and fault tolerance. So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important. I don't think the experiment as you put it has yet ended - computers and their software development have just not caught up yet which is, in part, probably at least related to performance of computer machines for these kinds of tasks. Warmest Regards, Mark. Sent from my iPhone > On 30 Mar 2018, at 15:35, Bob Sneidar via use-livecode > wrote: > > I agree. The goal was to make computing as english like as possible, but the > take away to that great experiment is that one can only go so far. People > interpret what a person may mean. Computers do not have that luxury. Still > xTalk is a magnificient accomplishment. > > Bob S > > >> On Mar 29, 2018, at 21:34 , Mike Kerner via use-livecode >> wrote: >> >> I agree that unquoted literals are not ideal. I think they should be >> deprecated, and I think they should have been removed in 1986, so add that >> to the LC10 list. They have always made reading scripts more difficult. >> Readability and approachability are two things that have set xtalk apart. >> Unquoted literals detract from that. > > > ___ > 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: do. command. safety. ?
Any shell command that can do anything dangerous is typically protected by the host OS. You could not for example install software in a way that would bypass UAC in Windows. You *could* conceivably delete all the files in a folder I suppose, but you couldn't copy files to a protected location. Essentially anything the end user is capable of doing, LC can do, but this is not unique. You can say that about any application. If the IT department has given complete write access to everything to all their users (a common practice I am learning as I interact with our customer IT departments) then it's not up to LC to try to protect themselves from themselves. HTH Bob S > On Mar 30, 2018, at 08:43 , Tom Glod via use-livecode > wrote: > > Dear Geniuses > > Sometimes late at night just before falling asleep I think about the > dangers of the do command. Is it possible to inject code into this > mechanism through malware? > > I do not have enough understanding of operating systems and their processes > ...and the livecode engineto be able to know if its a reasonable > question or not. > > Thanks for any input on this. ___ 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
do. command. safety. ?
Dear Geniuses Sometimes late at night just before falling asleep I think about the dangers of the do command. Is it possible to inject code into this mechanism through malware? I do not have enough understanding of operating systems and their processes ...and the livecode engineto be able to know if its a reasonable question or not. Thanks for any input on this. ___ 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: Blurring field contents
Or cover the hidden fields with graphics of daisies. :-) Bob S > On Mar 30, 2018, at 08:40 , J. Landman Gay via use-livecode > wrote: > > Or make a generic "blur" image in a graphics program and overlay it on the > fields when needed. ___ 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: Blurring field contents
Or make a generic "blur" image in a graphics program and overlay it on the fields when needed. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 9:07:48 AM Rick Harrison via use-livecode wrote: You could also make up bogus text data to show instead of using real data. Rick > On Mar 29, 2018, at 11:48 PM, scott--- via use-livecode wrote: > > If blurring turns out to be too problematic you might consider just replacing text with bullets or Lorem Ipsum. > > -- > Scott Morrow ___ 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: variable xref
I agree. The goal was to make computing as english like as possible, but the take away to that great experiment is that one can only go so far. People interpret what a person may mean. Computers do not have that luxury. Still xTalk is a magnificient accomplishment. Bob S > On Mar 29, 2018, at 21:34 , Mike Kerner via use-livecode > wrote: > > I agree that unquoted literals are not ideal. I think they should be > deprecated, and I think they should have been removed in 1986, so add that > to the LC10 list. They have always made reading scripts more difficult. > Readability and approachability are two things that have set xtalk apart. > Unquoted literals detract from that. ___ 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: Blurring field contents
You could also make up bogus text data to show instead of using real data. Rick > On Mar 29, 2018, at 11:48 PM, scott--- via use-livecode > wrote: > > If blurring turns out to be too problematic you might consider just replacing > text with bullets or Lorem Ipsum. > > -- > Scott Morrow ___ 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: variable xref
On Mar 29, 2018, at 10:34 PM, Mike Kerner via use-livecode wrote: > > I don't want to pretend to be an expert on the topic of writing compilers, > since I only ever wrote two, both under the watchful obsession of a > professor, and my lex and parse code were not optimal in either case. In > general, they were some of the easiest pieces of large code I ever wrote > because the grammars were so rigid and rule-based. Building forgiveness > into them would have made the poor developer's life easier, even thought > that meant adding a third pass to try to ascertain context instead of > blindly aborting when something didn't exactly fit the formula. > > I agree that unquoted literals are not ideal. I think they should be > deprecated, and I think they should have been removed in 1986, so add that > to the LC10 list. They have always made reading scripts more difficult. > Readability and approachability are two things that have set xtalk apart. > Unquoted literals detract from that. +1 Devin Asay Director Office of Digital Humanities Brigham Young University ___ 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