Re: OpenCore Legacy Patcher Supports 2012 iMac!

[harrison--- via use-livecode]

Thanks Henry, for confirming that Ventura runs on your 2012 iMac with OpenCore 
Legacy Patcher.

Rick

> On May 29, 2023, at 10:59 PM, HENRY LOWE via use-livecode 
>  wrote:
> 
> Mac OS Ventura runs just fine on my 2012 iMac courtesy of OpenCore Legacy 
> Patcher. I don’t run LC on this machine - use a 2019 iMac for that.
> 
> Henry 

___
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: OpenCore Legacy Patcher Supports 2012 iMac!

[HENRY LOWE via use-livecode]

Mac OS Ventura runs just fine on my 2012 iMac courtesy of OpenCore Legacy 
Patcher. I don’t run LC on this machine - use a 2019 iMac for that.

Henry 

> On May 29, 2023, at 7:42 PM, harrison--- via use-livecode 
>  wrote:
> 
> https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#imac
> 
> You are very lucky!  You must have looked at an old post.
> 
> Have fun!
> 
> Rick
> 
>> On May 29, 2023, at 1:11 PM, doc hawk via use-livecode 
>>  wrote:
>> 
>> If memory serves, the problem with older machines was not running the metal 
>> graphical system, as they lacked the hardware.
>> 
>> There were some near-contemporaneous patches that allowed at least the first 
>> post-mohave osx to run, put were reported as glacially and painfully slow as 
>> metal got emulated on older hardware.
>> 
>> This says that the patch allows supporter non-metal graphical cards, 
>> though—I’m curious how that would work on apple stuff that calls to metal.
>> 
>> But, alas, the 2012 iMac isn’t the list, so I guess I’m out of luck anyway.
>> 
>> 
>> ___
>> 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

OpenCore Legacy Patcher Supports 2012 iMac!

[harrison--- via use-livecode]

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#imac

You are very lucky!  You must have looked at an old post.

Have fun!

Rick

> On May 29, 2023, at 1:11 PM, doc hawk via use-livecode 
>  wrote:
> 
> If memory serves, the problem with older machines was not running the metal 
> graphical system, as they lacked the hardware.
> 
> There were some near-contemporaneous patches that allowed at least the first 
> post-mohave osx to run, put were reported as glacially and painfully slow as 
> metal got emulated on older hardware.
> 
> This says that the patch allows supporter non-metal graphical cards, 
> though—I’m curious how that would work on apple stuff that calls to metal.
> 
> But, alas, the 2012 iMac isn’t the list, so I guess I’m out of luck anyway.
> 
> 
> ___
> 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

LC Server and forcing page refreshes

[Tim Selander via use-livecode]

Once again find myself over my head in just a simple programming project.

I made a little club members directory website, using LC server on 
on-rev's hosting site.


Members can edit their info. I use a form, with the action going to an 
LC script. This script gets all the post data, shuffles it off to the 
database, and then goes back to the member's page using a re-direct:


 

where vlink has the member's URL.

My Problem: If folk update their photos, their browser cache still shows 
the old picture -- logically leading them to think the update failed.


The photos are simply stored on the server, the database only stores the 
path of the file. The photo file shown on the member's page with an 
image tag.


Can any of the gurus here tell me how to get the page to ignore the 
cache so the browser shows the new photo?


Many thanks.

Tim Selander
Tokyo, Japan


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

Re: OpenCore Legacy Patcher for LC

[harrison--- via use-livecode]

No problems with LC that I have found so far.

> On May 29, 2023, at 11:17 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> It's on my to-do list but I haven't got to it yet. Is there a problem with LC?

___
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: LC compilation

[Mark Smith via use-livecode]

Hi Mike, sorry I thought it would have been copied with the reply. The original 
post from Skip Kimpel was more or less asking if LC is compiled. The exact post 
was…

"Wait… what?  I have been away from this list for a while, LC is not 
currently compilable??

SKIP”

I do have a question based on your reply. You indicate LC doesn’t compile but 
then go on to list all of the stuff it compiles into a standalone application 
(most of which, such as the LC engine, extensions, libraries, etc) are just (I 
would argue) libraries when it builds an application. Taking the definition of 
compiler as “a process to convert (a program) into a machine-code 

 or a lower-level 

 form in which the program can be executed.” I would argue it “sort of” does 
that in that the included scripts (as I understand it) are not in their 
original editable form but have been converted into something that is more 
easily interpreted by the engine. I know it’s not ML, nor is it bytecode, but 
it’s one step removed from the actually editable text in the script editor. 
Would’t you agree?

The true advantage of the byte code, I believe, is that it brings LC in line 
with other similar compilers and therefore allows a more sophisticated (and 
standardised) approach to code optimisation. Or at least that will be one of 
the advantages. Obfuscation of code, as you mention, is another (although I 
have never personally worried about anyone wanting to steal my code 😊). 

Mark


> On 29 May 2023, at 5:56 pm, Mike Kerner via use-livecode 
>  wrote:
> 
> I don't see the original post, so I can only part-comment on this.
> LC doesn't compile, per se. It builds standalone apps for all
> platforms, but those apps include the LC engine, extensions,
> libraries, and your stack(s). There is an obfuscator, but, no, no
> bytecode or ML, yet. The apps behave as you would expect a standalone
> app to behave, but, with a disassembler, you will have an easier time
> with them than you would with a ML or BC compiled app.
> The good news is that the current architecture makes remote debugging
> from mobes much simpler, and, whether you are on a desktop or mobile
> platform, you can include functionality such as side-loading and
> real-time code execution trivially.
> For example, let's say you have a debug build. If you include a button
> in your debug build, with the following script, you can prompt for a
> command, and execute it, live, in your standalone:
> 
> on mouseUp
>   global gDo
>   ask "Do what?" with gDo
>   if it is not empty then
>  put it into gDo
>  do gDo
>   end if
> end mouseUp
> 
> The above script will also, as I am sure you deduced, store the last
> command you typed, and prompt you with it, the next time you press the
> button.
> This is, of course, especially useful if you want to invoke the
> debugger and then debug some routine. You can do that like by clicking
> the button I just described, and then typing into the dialog:
> breakpoint;send "mouseUp" to button "someButton" # steps you through
> the debug button script, then to the mouseUp handler of "someButton"
> 
> We are all patiently waiting for the script compiler, which, as of
> last conversation with Mark W., is going to be a bytecode compiler,
> not a ML compiler.
> 
> On Mon, May 29, 2023 at 6:27 AM Mark Smith via use-livecode
>  wrote:
>> 
>> Hi Skip,
>> 
>> I’m surprised no one has taken a stab at answering this. I'm certainly no 
>> expert on the internal workings of LC or compilers but I can take a stab at 
>> articulating what I think the answer is, and when I get it wrong someone 
>> else can jump in to correct me (I should probably know this stuff better 
>> anyway).
>> 
>> So if I am correct, the current environment converts LC script into some 
>> sort of (possibly binary) tree structure that is better organised to be 
>> executed by the LC engine. The engine is a big chunk of what I think is 
>> mostly Obj C (or some relative thereof) code that interprets the tree 
>> structures created in the first phase. So I guess that makes it sort of 
>> compiled? Compiled to execute in/on the LC engine, but also interpreted 
>> because the tree code is not executed on the target platform directly but is 
>> interpreted by the engine to generate the final executable result.
>> 
>> As far as the script compiler project is concerned, I believe the goal is to 
>> create a byte code stream that can be interpreted more efficiently by (a 
>> possibly new?) engine. Not sure about the new engine part, but the idea is 
>> the tree structure thin

Re: Run LC on old Mac with Ventura!

[doc hawk via use-livecode]

If memory serves, the problem with older machines was not running the metal 
graphical system, as they lacked the hardware.

There were some near-contemporaneous patches that allowed at least the first 
post-mohave osx to run, put were reported as glacially and painfully slow as 
metal got emulated on older hardware.

This says that the patch allows supporter non-metal graphical cards, though—I’m 
curious how that would work on apple stuff that calls to metal.

But, alas, the 2012 iMac isn’t the list, so I guess I’m out of luck anyway.


___
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: LC compilation

[Mike Kerner via use-livecode]

I don't see the original post, so I can only part-comment on this.
LC doesn't compile, per se. It builds standalone apps for all
platforms, but those apps include the LC engine, extensions,
libraries, and your stack(s). There is an obfuscator, but, no, no
bytecode or ML, yet. The apps behave as you would expect a standalone
app to behave, but, with a disassembler, you will have an easier time
with them than you would with a ML or BC compiled app.
The good news is that the current architecture makes remote debugging
from mobes much simpler, and, whether you are on a desktop or mobile
platform, you can include functionality such as side-loading and
real-time code execution trivially.
For example, let's say you have a debug build. If you include a button
in your debug build, with the following script, you can prompt for a
command, and execute it, live, in your standalone:

on mouseUp
   global gDo
   ask "Do what?" with gDo
   if it is not empty then
  put it into gDo
  do gDo
   end if
end mouseUp

The above script will also, as I am sure you deduced, store the last
command you typed, and prompt you with it, the next time you press the
button.
This is, of course, especially useful if you want to invoke the
debugger and then debug some routine. You can do that like by clicking
the button I just described, and then typing into the dialog:
breakpoint;send "mouseUp" to button "someButton" # steps you through
the debug button script, then to the mouseUp handler of "someButton"

We are all patiently waiting for the script compiler, which, as of
last conversation with Mark W., is going to be a bytecode compiler,
not a ML compiler.

On Mon, May 29, 2023 at 6:27 AM Mark Smith via use-livecode
 wrote:
>
> Hi Skip,
>
> I’m surprised no one has taken a stab at answering this. I'm certainly no 
> expert on the internal workings of LC or compilers but I can take a stab at 
> articulating what I think the answer is, and when I get it wrong someone else 
> can jump in to correct me (I should probably know this stuff better anyway).
>
> So if I am correct, the current environment converts LC script into some sort 
> of (possibly binary) tree structure that is better organised to be executed 
> by the LC engine. The engine is a big chunk of what I think is mostly Obj C 
> (or some relative thereof) code that interprets the tree structures created 
> in the first phase. So I guess that makes it sort of compiled? Compiled to 
> execute in/on the LC engine, but also interpreted because the tree code is 
> not executed on the target platform directly but is interpreted by the engine 
> to generate the final executable result.
>
> As far as the script compiler project is concerned, I believe the goal is to 
> create a byte code stream that can be interpreted more efficiently by (a 
> possibly new?) engine. Not sure about the new engine part, but the idea is 
> the tree structure thing goes away and in its place is a linear stream of 
> byte codes that can both be executed more effiencetly but also optimised more 
> fully. This particular byte stream (and here I’m going way outside my 
> wheelhouse) is similar to what other compilers like Java, Python, (Pascal? — 
> which I do know was a byte code compiled run time interpreted language… 
> although companies like Borland eventually wrote Pascal compilers that 
> executed directly on the target platform without any interpretation) produce. 
> So, it would bring the LC compiled code more in line with what other 
> compilers are producing which means post compilation the code could be 
> optimised more completely using well developed industry standard approaches. 
> And so everything ends up a little smaller and faster but it also opens the 
> door to doing other things with the script code down the road.
>
> Well, that's my take on Mark Waddinghams’ most recent seminar on this topic. 
> But he assuredly can fill you in much better than I can.
>
> Cheers,
> Mark
>
>
>
> > On 28 May 2023, at 3:54 pm, Skip Kimpel via use-livecode 
> >  wrote:
> >
> > Wait… what?  I have been away from this list for a while, LC is not 
> > currently compilable??
> >
> > SKIP
> >
> >> On May 27, 2023, at 4:39 PM, harrison--- via use-livecode 
> >>  wrote:
> >>
> >> Hi Skip,
> >>
> >> Doubtful.  I would wait until after we have a compilable version of LC and 
> >> then it will be more possible.
> >>
> >> Rick
> >>
> >>> On May 27, 2023, at 12:26 PM, Skip Kimpel via use-livecode 
> >>>  wrote:
> >>>
> >>> Has anybody done anything with LC and AR?
> >>>
> >>> Curious minds want to know :)
> >>>
> >>> SKIP
> >>
> >> ___
> >> 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.c

Re: OpenCore Legacy Patcher for LC

[J. Landman Gay via use-livecode]

It's on my to-do list but I haven't got to it yet. Is there a problem with LC?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 29, 2023 8:30:00 AM harrison--- via use-livecode 
 wrote:



Is there anyone on this list that has tried
OpenCore Legacy Patcher to run LiveCode
on their old mac?

Let me know.

Thanks,

Rick

On May 27, 2023, at 4:54 PM, harrison--- via use-livecode 
 wrote:


Hi LC Mac users,

Last week I came across the following:

https://www.macupdate.com/app/mac/64141/opencore-legacy-patcher

I was very skeptical at first, so I took out my old 15 inch 2012 MacBook Pro
that I was thinking about recycling, and I tried it.  It works like a new 
machine

running Ventura!  It’s fast enough too!

After I saw how good it works, all I could think of was how terrible
it is that Apple has sidelined all of these old computers, that are
perfectly capable.

It behaves well with LC too!

Check it out and let me know what you think.

Cheers,

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

OpenCore Legacy Patcher for LC

[harrison--- via use-livecode]

Is there anyone on this list that has tried
OpenCore Legacy Patcher to run LiveCode
on their old mac?

Let me know.

Thanks,

Rick

> On May 27, 2023, at 4:54 PM, harrison--- via use-livecode 
>  wrote:
> 
> Hi LC Mac users,
> 
> Last week I came across the following:
> 
> https://www.macupdate.com/app/mac/64141/opencore-legacy-patcher
> 
> I was very skeptical at first, so I took out my old 15 inch 2012 MacBook Pro
> that I was thinking about recycling, and I tried it.  It works like a new 
> machine
> running Ventura!  It’s fast enough too! 
> 
> After I saw how good it works, all I could think of was how terrible 
> it is that Apple has sidelined all of these old computers, that are 
> perfectly capable.  
> 
> It behaves well with LC too!
> 
> Check it out and let me know what you think.  
> 
> Cheers,
> 
> Rick
> ___
> 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: LC compilation

[Mark Smith via use-livecode]

Hi Skip,

I’m surprised no one has taken a stab at answering this. I'm certainly no 
expert on the internal workings of LC or compilers but I can take a stab at 
articulating what I think the answer is, and when I get it wrong someone else 
can jump in to correct me (I should probably know this stuff better anyway).

So if I am correct, the current environment converts LC script into some sort 
of (possibly binary) tree structure that is better organised to be executed by 
the LC engine. The engine is a big chunk of what I think is mostly Obj C (or 
some relative thereof) code that interprets the tree structures created in the 
first phase. So I guess that makes it sort of compiled? Compiled to execute 
in/on the LC engine, but also interpreted because the tree code is not executed 
on the target platform directly but is interpreted by the engine to generate 
the final executable result. 

As far as the script compiler project is concerned, I believe the goal is to 
create a byte code stream that can be interpreted more efficiently by (a 
possibly new?) engine. Not sure about the new engine part, but the idea is the 
tree structure thing goes away and in its place is a linear stream of byte 
codes that can both be executed more effiencetly but also optimised more fully. 
This particular byte stream (and here I’m going way outside my wheelhouse) is 
similar to what other compilers like Java, Python, (Pascal? — which I do know 
was a byte code compiled run time interpreted language… although companies like 
Borland eventually wrote Pascal compilers that executed directly on the target 
platform without any interpretation) produce. So, it would bring the LC 
compiled code more in line with what other compilers are producing which means 
post compilation the code could be optimised more completely using well 
developed industry standard approaches. And so everything ends up a little 
smaller and faster but it also opens the door to doing other things with the 
script code down the road. 

Well, that's my take on Mark Waddinghams’ most recent seminar on this topic. 
But he assuredly can fill you in much better than I can.

Cheers,
Mark



> On 28 May 2023, at 3:54 pm, Skip Kimpel via use-livecode 
>  wrote:
> 
> Wait… what?  I have been away from this list for a while, LC is not currently 
> compilable??
> 
> SKIP
> 
>> On May 27, 2023, at 4:39 PM, harrison--- via use-livecode 
>>  wrote:
>> 
>> Hi Skip,
>> 
>> Doubtful.  I would wait until after we have a compilable version of LC and 
>> then it will be more possible.
>> 
>> Rick
>> 
>>> On May 27, 2023, at 12:26 PM, Skip Kimpel via use-livecode 
>>>  wrote:
>>> 
>>> Has anybody done anything with LC and AR?
>>> 
>>> Curious minds want to know :)
>>> 
>>> SKIP
>> 
>> ___
>> 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