Hi All,
Recently, I have been looking at running Javascript libraries inside
LiveCode (like bzip2 decompress) but instead of using RevBrowser or CEF
Browser, have been taken a look at using SpiderMonkey JavaScript shell:
> JLG wrote:
> ... "t" for handler-local variables, "g" for globals,
> "s" for script-locals, and "k" for constants ...
> If you adopt a system like this, you'll never have a
> naming conflict.
> Mark W. wrote:
> tExt is all I'll say ;) (thanks to Ken Ray for that one)
The LC Builder StyleGuide
Alex Tweedly wrote:
> On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
>> Alex Tweedly wrote:
>>
>> > On 08/06/2017 20:20, Richard Gaskin wrote:
>> >> If you're committed to a script-only stack there's no decision to
>> >> make: every control must be instantiated dynamically, because
On Thu, Jun 8, 2017 at 2:39 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Would name-spaces help?
I'm no fan of C, but I'd sure like to get its variable scoping into
livecode . . .
[*duck*]
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
Alex Tweedly wrote:
> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only
glad u worked it out Tom
On Thu, Jun 8, 2017 at 5:22 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> There's a spoil-sport in every crowd. :P
>
>
> On 6/8/17 4:19 PM, Mark Waddingham via use-livecode wrote:
>
>> tExt is all I'll say ;) (thanks to Ken Ray for that
On Thu, Jun 8, 2017 at 7:44 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
> here is no logical reason a 64 bit app would run slower than a 32 bit one.
At least in the special case of needing to load data that gets stored in 64
bit words where 32 bit words would have
Mark Waddingham wrote:
> Jacque wrote:
>> That's the main reason I preface all variables with a letter, usually
>> "t" for handler-local variables, "g" for globals, "s" for script-
>> locals, and "k" for constants. You don't have to use the same letters
>> but those have pretty much become the
Alex Tweedly wrote:
> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well,
There's a spoil-sport in every crowd. :P
On 6/8/17 4:19 PM, Mark Waddingham via use-livecode wrote:
tExt is all I'll say ;) (thanks to Ken Ray for that one)
Warmest Regards,
Mark.
Sent from my iPhone
On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode
tExt is all I'll say ;) (thanks to Ken Ray for that one)
Warmest Regards,
Mark.
Sent from my iPhone
> On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode
> wrote:
>
>> On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
>> Thanks for the encouragement,
Andre Garzia wrote:
> On Wed, Jun 7, 2017 at 7:43 PM, Richard Gaskin wrote:
>> VPSes are great when you need custom configuration, but they can be a
>> challenge to set up when you're learning, and a bigger challenge to
>> harden sufficiently, things a shared hosting service takes care of.
>
>>
On 6/8/17 2:35 PM, tbodine via use-livecode wrote:
Another clue... If I use the message box to call any simple stack level
handler, LC 8 changes that command to a put statement.
Example:
I type in msg box: zzShow -- a stack level handler
Msg box changes my cmd to "put zzShow" and then puts
On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
Workout" for quite some time.
For future list searchers who might have this same symptom, I found the
cause: One of my stack level scripts used "theme" as a parameter
Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
Workout" for quite some time.
For future list searchers who might have this same symptom, I found the
cause: One of my stack level scripts used "theme" as a parameter name, but
apparently that's a reserved term that is
On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
In general I try to "go to TOWN": Touch Only What's Needed.
If I don't need to create an object I probably won't, adjusting an
existing object instead. It only saves one step, but its a savings
just the same.
If you're committed
Simple: Unicode support. It's not 64 bit that is slowing you down. Not sure how
you make that connection.
Bob S
> On Jun 8, 2017, at 09:08 , JosebaTELUR via use-livecode
> wrote:
>
> Hello:
>
> Why LiveCode 8 or 9 in 64bits are more slwww than LiveCode
Microsoft suffered for years over backwards compatibility with DOS. MS wanted
to move forward with their OS at a quicker pace but there were so many
"critical" apps running under DOS that talked directly with the hardware, that
no one wanted MS to depricate it. Windows 95 was supposed to be the
Hey Tom...I jsut yesterday switched my huge project to 8.1.4 and when
i first started migrating i had a lot of issues .
i don't have an answer to your particular problem except to say that LC 8.1
engine is much more strict and actually more trustworthy and less ambiguous.
every error i
Another clue... If I use the message box to call any simple stack level
handler, LC 8 changes that command to a put statement.
Example:
I type in msg box: zzShow -- a stack level handler
Msg box changes my cmd to "put zzShow" and then puts "zzShow" in the output
area.
Tom
--
View this
Hi all.
I am migrating a big project from LC 7.1.4 to LC 8.1.4, and hitting a wall
right away.
When my card scripts call stack level scripts directly, LC 8 throws a "can't
find handler" error. (I confirmed that the defaultStack is my main stack.)
LC 7 had no problem with this.
Example:
Card
On 6/8/17 6:56 pm, Richard Gaskin via use-livecode wrote:
Roger Eller wrote:
> On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin wrote:
>> Using a supported version of an OS that's receiving critical security
>> patches along with other updates is the safest choice, and one that
>> could not be
Has anyone apart from me actually tried running Linux on a Mac PPC machine.
A few years ago I installed Lubuntu on a MacMini PPC and tried to build
a PPC Linuxversion of Livecode,
and got nowehere.
Quite apart from my sad efforts at that, the machine was as slow as wet
cement; functionally
Sannyasin Brahmanathaswami wrote:
> 1) does it make sense to build this dynamically as needed from script
> using "create" and then you put this "create control" script into a
> library? It has the advantage of no binary object, so you can keep it
> in your text only "stacks" .livecodescript,
On 6/8/17 1:19 pm, Mark Waddingham via use-livecode wrote:
On 2017-06-08 12:04, Richmond via use-livecode wrote:
So, backwards compatibility does not interest you?
Seriously - you ask that question?
LiveCode 9 still happily runs stacks which were written in the early
days of MetaCard.
Tut, tut, Roger: you forgot the kilt!
Richmond.
On 6/8/17 1:34 pm, Roger Eller via use-livecode wrote:
-- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
tan trenchcoat, dumps a large bag of Monopoly money onto the table. Marks
eyes are now like saucers. "Moot",
Hello:
Why LiveCode 8 or 9 in 64bits are more slwww than LiveCode 5.5.4 in my new
iMac with Sierra??
Please LiveCode programmers move forward, not back
Un saludo.
Joseba Aguayo Fernández
(jagu...@telur.es)
___
use-livecode mailing list
Hi Richmond,
Did you miss the memo about:
Apple Zero-Day Flaw Leaves OS X Systems Vulnerable to Attack
Zero day flaws have always been there in the Mac OS X operating system
from the very beginning. These have been patched in later versions of
Mac OS X, but earlier versions were never patched.
Roger Eller wrote:
> On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin wrote:
>> Using a supported version of an OS that's receiving critical security
>> patches along with other updates is the safest choice, and one that
>> could not be more economical given a purchase price for most Linux
>>
On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Richmond wrote:
>
> > So, backwards compatibility does not interest you?
> >
> > I, for one, run Mac Machines running MacOS 10.4 PPC.
> >
> > A lot of these machine are being dumped in poor
Richmond wrote:
> So, backwards compatibility does not interest you?
>
> I, for one, run Mac Machines running MacOS 10.4 PPC.
>
> A lot of these machine are being dumped in poor countries where they
> can be used for good purposes.
I can appreciate the desire to get full life out of hardware,
LOVE IT!!! Thanks for that info, Richard.
~Roger
On Thu, Jun 8, 2017 at 10:46 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Roger Eller wrote:
> > Once in a while I still miss running "Revolution" on Irix. We move
> > forward, not backward.
>
> FWIW, IRIX is
On Thu, Jun 8, 2017 at 3:34 AM, Roger Eller via use-livecode <
use-livecode@lists.runrev.com> wrote:
> -- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
> tan trenchcoat, dumps a large bag of Monopoly money onto the table. Marks
> eyes are now like saucers. "Moot",
Roger Eller wrote:
> Once in a while I still miss running "Revolution" on Irix. We move
> forward, not backward.
FWIW, IRIX is coming back - and as a Linux desktop, so we should be able
to use the Linux build of LiveCode with it:
Silicon Graphics' IRIX and Magic Desktop return as Linux
I was going to respond to this earlier but I decided not to. There is no
logical reason a 64 bit app would run slower than a 32 bit one. Certainly not
noticably slower. In fact, there is every reason to expect it to be faster in
some respects, as the pipe to the processor is twice as wide. Not
On 2017-06-08 16:19, Paul Dupuis via use-livecode wrote:
On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:
As a general request, can people let us know if they are relying on
externals on Mac which are currently 32-bit only?
Forgive the dumb question Mark, but how does someone tell
On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?
Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?
In my first LC
Thank you Panos.
Henry
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/LC-8-1-4-and-Xcode-8-3-3-tp4715579p4715596.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
On Thu, Jun 8, 2017 at 2:55 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?
I have a couple of externals I use in my apps that are 32-bit. I
Hi Henry,
This will be fixed in the next LC 8.1.5 RC1 release.
For anyone interested, see the bug report (and the fix):
http://quality.livecode.com/show_bug.cgi?id=19826
Best,
Panos
--
On Thu, Jun 8, 2017 at 8:32 AM, panagiotis merakos <
panos.mera...@livecode.com> wrote:
> Hi Henry,
>
> It
Congratulations!
>> Heather
>> (who is now the longest surviving staff member other than Kevin)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
I use a G4 Quicksilver as a server. I have taken it apart and put it back
together several times, something I can't do with a Mac Mini or MacBook. I use
Revolution 4.x for special server tasks. It would be convenient if I could use
the latest version of LiveCode to build not only for Windows,
Once in a while I still miss running "Revolution" on Irix. We move
forward, not backward.
On Jun 8, 2017 6:39 AM, "Mark Waddingham via use-livecode" <
use-livecode@lists.runrev.com> wrote:
> On 2017-06-08 12:34, Roger Eller via use-livecode wrote:
>
>> -- In a dark back office, Richmond,
On 2017-06-08 12:34, Roger Eller via use-livecode wrote:
-- In a dark back office, Richmond, wearing dark glasses, a fedora, and
a
tan trenchcoat, dumps a large bag of Monopoly money onto the table.
Marks
eyes are now like saucers. "Moot", Richmond says under his breath,
then
leaves the room
-- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
tan trenchcoat, dumps a large bag of Monopoly money onto the table. Marks
eyes are now like saucers. "Moot", Richmond says under his breath, then
leaves the room with a strut, as if he is carrying the world in his pocket.
On 2017-06-08 12:28, hh via use-livecode wrote:
1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special case LiveCode and was a bit caused by
the fact that the first 64bit-Finder was
Thanks for the enlightening explanation.
Of course I don't go into a technical discussion with an expert.
Only two remarks:
1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special
On 2017-06-08 12:04, Richmond via use-livecode wrote:
So, backwards compatibility does not interest you?
Seriously - you ask that question?
LiveCode 9 still happily runs stacks which were written in the early
days of MetaCard.
We are *extremely* careful not to break existing scripts and
So, backwards compatibility does not interest you?
I, for one, run Mac Machines running MacOS 10.4 PPC.
A lot of these machine are being dumped in poor countries where they can
be used
for good purposes.
Richmond.
On 08/06/17 09:19, Mark Waddingham via use-livecode wrote:
On 2017-06-07
On 2017-06-07 22:14, hh via use-livecode wrote:
64bit mode usually makes apps slower. So what's Apple's intention?
To make their own apps "relatively faster" by making all others slower?
Do you have some benchmarks to back that up? I'd be interested to know
what sort of workloads the
On 2017-06-08 08:48, Tiemo Hollmann TB via use-livecode wrote:
I would love to build 64-bit for Mac, but up to now, the Valentina
extension
is still 32-bit, I hope they'll get it fixed by time.
I must confess that we always had the intent of dropping the 32-bit
slice of the engine on Mac
Hi Henry,
It seems that Xcode 8.3.3. was released yesterday, too. I will have a look
at this issue. My guess is that in Xcode 8.3.3., Apple has (again!) changed
some internal frameworks we use for deploying to simulator, so we need to
tweak our code to workaround this.
So yes, I suggest sticking
I would love to build 64-bit for Mac, but up to now, the Valentina extension
is still 32-bit, I hope they'll get it fixed by time.
Tiemo
-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Mark Waddingham via use-livecode
Gesendet:
On 2017-06-07 21:59, Richmond Mathewson via use-livecode wrote:
I disagree as there are plenty of Macs "out there" in the worldthat
run 32-bit systems.
Not that LiveCode supports.
Far better to have BOTH possibilities checked as default.
Only if there existed a Mac which can run LiveCode
The release docs for LC 8.1.4 state:
"Last but not least, LiveCode 8.1.4 includes support for building iOS apps
using the latest iOS SDKs, included in Xcode 8.3.x."
Installed LC Indy 8.1.4 on a Mac under MacOS 10.12.5, installed the new
version of Xcode (8.3.3) and I get this error message when
I've done it both ways but usually only create controls on the fly when
there are only a few objects (two or three usually.) Anything more complex,
I use a template group and copy that instead. It's nearly instantaneous. I
did a mobile app that copied a group dozens of times in a preOpenCard
56 matches
Mail list logo