Google Play API 28 11/1/2019

[Ralph DiMola via use-livecode]

FYI: Received this from Google Play today. I submitted QCC report 22407.

Hello Google Play Developer, 
This is a reminder that starting November 1, 2019, updates to apps and games on 
Google Play will be required to target Android 9 (API level 28) or higher. 
After this date, the Play Console will prevent you from submitting new APKs 
with a targetSdkVersion less than 28. 
Configuring your app to target a recent API level ensures that users benefit 
from significant security and performance improvements, while still allowing 
your app to run on older Android versions (down to the minSdkVersion). 

Action required 
Please ensure that your apps are configured to target at least Android 9 (API 
level 28) by November 1, 2019. For technical advice on how to change your app's 
target API level to meet these requirements, refer to the migration guide. 
Affected apps 

The apps included below have one or more APKs—in production or testing 
tracks—that aren't currently targeting API level 28 or higher. Apps are listed 
with the maximum version code and corresponding targetSdkVersion. If you have 
more than 20 apps that could be affected in your account, please check the Play 
Console for a full list. 

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: Give a bug a hug

[Mike Kerner via use-livecode]

wow, i managed to mute this conversation.  fail.
@paul, that's exactly why we ponied up, too, as an insurance policy.  we
have been burned by numerous organizations either abandoning their software
work product or disappearing.  thankfully, for most of our mission-critical
stuff, we have, own, and maintain the source.
@Sean, I'm not generally thinking of the underlying engine for the bounty
program, I'm thinking of pieces in LCS/LCB.  In those cases, the PR doesn't
get submitted to the LC repo until whatever step it was further down.
There isn't any reason why private repos can't be used to manage this
process, especially with submodules.  The patrons would have access to the
repo, no one else would.
As for the conversation about the unfinished projects that all of us ponied
up for on a promise, I 100% agree, which is why the funds are escrowed.
The developer proposing a solution doesn't get paid until the patch is
tested and approved by the patrons of the patch.

On Wed, Oct 9, 2019 at 11:02 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> +1 Richard. I got onboard with what user to be Runtime Revolution (I think
> it was version 2!) Where livecode is today is orders of magnitude more than
> it was when it first started. There was no datagrid. No way to display
> tabular data apart from a very simple table field. No arrays. Difficult and
> confusing database APIs. No mobile support. The list goes on.
>
> LC is like a really good girlfriend. She isn't everything I ever wanted,
> but she's good enough for me. :-)
>
> Bob S
>
>
> > On Oct 8, 2019, at 19:49 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Pi Digital wrote:
> >
> > >> On 8 Oct 2019, at 21:42, Richard Gaskin wrote:
> > >>
> > >> And here is a May 2016 update:
> > >>
> > >>
> https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/
> > >>
> > >>
> > >> A small number of people keep going round and round on this a large
> > >> number of times.
> > >>
> > >> How many times will the same conversation happen before more recent
> > >> information is absorbed?
> > >
> > > An excellent article. Which part was you pointing to in reference to
> > > Lagi’s question about older campaigns funded that have still not met
> > > the core?
> >
> > There's a section in the middle listing off the accomplishments since
> the Kickstarter, and some of the discussion goes into how much of that was
> paid for out-of-pocket.
> >
> >
> > > And which part do you refer to when asserting that absorption of info
> > > is needed to reduce the same conversations recursion rate?
> >
> > The portion of Lagi's post I had originally quoted in my reply:
> >
> >This is what I was talking about being treated like mushrooms
> >- no communication as to what the future holds.- rough timescales
> >as to when new or reassigned resources will be implemented - what
> >is the intention with sqlite, 2d physics, Audio 
> >
> > He's one of about three people who keep going back to the Kickstarter
> list as some form of eternal damnation against the team, and he knows that
> I know that he's read comments here and in the forums from Kevin and other
> team members that have discussed all of that over and over and over and
> over again.
> >
> > How many times does Kevin need to post a mea culpa about being among the
> 80% of software project leaders that underestimated cost?  Apparently half
> a dozen isn't enough.
> >
> > In summary: Most of the list was delivered, most of the remainder is in
> the DB as feature requests to be completed as resources permit.
> >
> >
> > Kevin, Heather, Mark and others have been very forthcoming here about
> what the company is working on, at least to the degree that this community
> allows.  But there's not much allowance granted:
> >
> > As they've explained many times, they've joined the majority of
> companies less willing to offer loose projections about delivery times
> precisely because of things like this.  If they give a projected deadline
> and circumstances change, it will become a dominant and repeated theme
> among a very small but very vocal minority.  This isn't unique to LC; their
> previous candor was a distinction.  Now they operate like everyone else,
> because the moment they dare to discuss anything not already in the can
> they expose themselves to a continuation of this same tediousness that
> every other company figured out how to avoid by keeping cards close.
> >
> > Wanna know what Apple's working on for 2020? Good luck.
> >
> > --
> > 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 su

Re: Primary Student Livecode Interface (Simplified Developer Interface)

[Richmond via use-livecode]

I have moved this discussion over here as there is the possibility to 
use pictures here,

while one cannot on the Use-List.

http://forums.livecode.com/viewtopic.php?f=107&t=33206&p=184151#p184149

On 10.10.19 22:01, Richard Gaskin via use-livecode wrote:
Three years ago I spent several months researching both the learner 
experience and how to fund, document, and market a UI specifically for 
young learners based on LiveCode Community Edition.


Many of the readers here may recall phone conversations and emails 
with them during my information-gathering phase.


I had to set the project aside because funding proved difficult. I 
hope to return to it as my own resources allow me to resume the 
arduous funding process.


The UI part of it was based around levels, but less like HyperCard's, 
and more like what you're looking for.  HC's user levels were based 
around authoring capabilities by role, while my EDU design used them 
more like gaming levels for pedagological reasons.


I discussed this project as part of the second half of my Community 
Keynote at the last LC conference, for those of you who have access to 
them (I've asked that my community talks be made available publicly, 
but I can understand that it's not be a high priority).


I'm up to my armpits in commercial development at the moment, but am 
eager to return to this EDU project as soon as funding makes the 
effort viable. Anyone seriously interested in contributing to the 
efforts to help find funding for such a system is welcome to email me 
at ambassador AT fourthworld.com


--
 Richard Gaskin
 Fourth World Systems


John Patten wrote:


Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?


If you’ve been around awhile, you might remember how HyperCard had 
multiple development modes. Level one allowed you to use drawing 
tools create buttons that would allow you to ”go to next card” etc. 
Pretty much no script access.

Levels 2-3 gradually provided more capabilities.
If you new the correct procedure, you could completely unlock 
Hypercard, with access to all developer components (Level 4?)


Has anybody created a simplified Livecode developer interface for 
newbies?  Something that could be used to introduce, but not 
initially over whelm a new user?


Just trying to not reinvent the wheel, if someone has already gone 
down this path and would be willing to share :)


Thank you!
John Patten



___
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: Android/Java PKCS12 Industry format Keystore

[J. Landman Gay via use-livecode]

I use the example from Google, which is identical to the example in the 
LC lesson. This is Google:


keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 
2048 -validity 1 -alias my-alias


This is the LC lesson (using Windows exe):
keytool.exe -genkey -v -keystore release.keystore -alias TicTacToe 
-keyalg RSA -keysize 2048 -validity 1


I have never seen any warnings.

On 10/10/19 1:55 PM, JJS via use-livecode wrote:

Hi,


have some people already changed their  (Android/Java) keystore keys to 
the PKCS12 format?



When creating a keystore key i get this warning a few times:


Warning:
The JKS keystore uses a proprietary format.
It is recommended to migrate to PKCS12 which is an industry standard 
format using "keytool -importkeystore -srckeystore yourapp.keystore 
-destkeystore yourapp.keystore -deststoretype pkcs12".


Or still using the proprietary format?

Regards.

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

http://lists.runrev.com/mailman/listinfo/use-livecode



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


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

Re: Primary Student Livecode Interface (Simplified Developer Interface)

[Tore Nilsen via use-livecode]

Hi!

I teach a beginners course in programming on highschool level in Norway. Just 
like Devin, I have found that the most important thing is what you want your 
students to learn. The development environment is not very important. I try to 
introduce various components in a way that helps build the students 
understanding of the fundamental concepts and principles used in programming.

I use a methodology quite similar to the one Devin suggests at the end of his 
reply. 

1. I present and show my students a concept/principles/method
2. We use this concept on various simple problems together in the class - this 
will often be accompanied by classroom discussion
3. The students then get a task where they can apply the concept on a problem 
that is quite similar to the problems used in point 1 and 2
4. Then I give my students a task which involves a more complex problem, where 
the application of the concept is not very obvious. At this point I encourage 
my students to help each other with the task.
5. The students then show their various attempts at solving the problem, either 
to a group of students or the whole class, and we discuss the various solutions 
in class
6. If needed I will then show them examples of «best practises». Here I will 
also present various controls and how they can be used as part of the solution 
of the given problem

At the moment we are setting up the classroom to facilitate this approach in a 
better way. The classroom is divided into five groups, each group having its 
own large table with a 42 inch monitor, that all students can connect to, at 
the end of the table. We are about to set up a solution with HDMI Matrix 
Switches that will allow each student to route their screen to any of the 
monitors and to the main projector if needed. Likewise, I can share my screen 
with any of the monitors or the main projector. This will help my students in 
sharing their solutions/problems with each other.

Like Devin, I have also come across research that seems to indicate that 
drilling is better than complex problem solving in teaching basic skills. 
However, my experience is that to much of this will make it harder for my 
students to become good problem solvers. In my course, all students must 
develop an application of their own choosing, from initial idea to finished 
product, in the last term. Many of my students have indicated that this have 
been the most important factor in the development of both understanding of and 
skills in programming. I think that the most important factor in this is the 
kind of problem the students face in step 4 of this method. This problem most 
be near enough to the original problem, but still different from it. This 
decides the quality of the discussions we get after the students have tried to 
solve the problem.

Best regards
Tore Nilsen

> 10. okt. 2019 kl. 20:36 skrev Devin Asay via use-livecode 
> :
> 
> RIchmond has an excellent point: your development environment is less 
> important than your goal.
> 
> The reason that all of us immediately typed ’set the userLevel to 5’ in 
> HyperCard is that you wouldn’t get far in your task until you needed a 
> bump-up to a higher level of capabilities.
> 
> I also teach beginning programming (beginning application development is 
> actually a better term), but to college students rather than primary kids. I 
> realized recently like a bolt of lightening that I have been spending far too 
> much instruction time describing the development environment and too little 
> on setting tasks and then telling the students about the tools in LC that let 
> them accomplish the task. I don’t know why it took me so long to come to that 
> insight, because “need-based” learning is how I learned both HyperCard and 
> LiveCode. (And probably how most of us learned.) Now I’m thinking about ways 
> to incorporate more task-based instruction into my classes.
> 
> But then I’m faced with the paradox that, according to some of the research 
> I’ve looked at on teaching programming, large problem solving assignments are 
> less effective than focused focused practice in teaching fundamental 
> programming concepts. What I take from that is that students are helped by 
> “drilling” a concept with canned, focused, smaller tasks than they are by 
> setting them a complex problem to solve. So my evolving approach is 1. 
> present a concept, 2. do some drill and practice on the concept, 3. set them 
> a more complex task that requires them to apply the concept.
> 
> I had imagined by this time in my career that I’d have figured this all out. 
> I might just be slow. :-)
> 
> Devin

___
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: Catalina

[J. Landman Gay via use-livecode]

Sand Which

On 10/10/19 1:18 PM, Dar Scott Consulting via use-livecode wrote:

Yes!

We need a cool name like that, too.
Code32
MoreMojave
CantLetGo
TimeScope
macWrap32
32Palms
Wrap32with64
DoubleMy32
Sand

It looks like I can't come up with anything as cool as WineBottler

Dar Scott




On Oct 10, 2019, at 11:51 AM, Richmond via use-livecode 
 wrote:

This sounds a bit like WineBottler:

http://winebottler.kronenberg.org/

On 10.10.19 20:48, Dar Scott Consulting via use-livecode wrote:

Being a mad scientist causes my mind to wander. I implied some sort of 
application that would take a 32-bit macOS app and turn it into a 64-bit app 
suitable for delivering to customers in the interim. But I gave solutions only 
for a sophisticated user to run 32-bit applications from Catalina (or so) 
desktop.

My immediate thoughts: Bundles might make a conversion for the macOS easier. 
Dependent 32-bit dynamic libraries would have to be moved into a folder in the 
bundle, and file I/O will do redirection. The app's program would be moved and 
replaced with something else that uses some sort of hyper-something to catch 
the INTs or that will use ptrace() as a debugger would. In the latter case the 
INTs might need to be translated statically by the converter. I have not made a 
modern debugger, tracer or hyper-thing, so I'm just guessing.

Dar


On Oct 10, 2019, at 8:34 AM, Bob Sneidar via use-livecode 
 wrote:

Mad scientist indeed! ;-)

Bob S



On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
 wrote:

Oh. That looks hard. I don't even know how to take control of the 0x80 
interrupt.

However, here are some ideas for alternatives.

Virtual

Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. (I 
don't use these, so check out what I say.) The capability is roughly the same. 
You can run an application on a client OS in a window on the host. So, if you 
have an older macOS running on a virtual machine that can run your app, you can 
set things up so that you can double-click on your desktop and run a 32-bit app.

Real

Another method is to set up little "servers" you can remote into. For example, 
instead of upgrading to Catalina on your old Mac Mini, get a new Mac Mini with Catalina 
and remote desktop into the old Mac Mini. Or have a Mac that is running several virtual 
machines you can remote into (use memory ballooning to share it well). The Apple EULA has 
constraints, but I think this is OK.

Now, what if you can run an app on a remote machine like Coherence/Unity/SM? 
You can readily run a single app in a window for a linux server using several 
programs such as nomachine and (I think) xpra. But I don't know about macOS. 
Maybe you can make a single-window app full screen and adjust the size of the 
client window. I haven't tried this.

Dar Scott
Mad Scientist


___
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




--
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: Primary Student Livecode Interface (Simplified Developer Interface)

[Richard Gaskin via use-livecode]

Three years ago I spent several months researching both the learner 
experience and how to fund, document, and market a UI specifically for 
young learners based on LiveCode Community Edition.


Many of the readers here may recall phone conversations and emails with 
them during my information-gathering phase.


I had to set the project aside because funding proved difficult.  I hope 
to return to it as my own resources allow me to resume the arduous 
funding process.


The UI part of it was based around levels, but less like HyperCard's, 
and more like what you're looking for.  HC's user levels were based 
around authoring capabilities by role, while my EDU design used them 
more like gaming levels for pedagological reasons.


I discussed this project as part of the second half of my Community 
Keynote at the last LC conference, for those of you who have access to 
them (I've asked that my community talks be made available publicly, but 
I can understand that it's not be a high priority).


I'm up to my armpits in commercial development at the moment, but am 
eager to return to this EDU project as soon as funding makes the effort 
viable. Anyone seriously interested in contributing to the efforts to 
help find funding for such a system is welcome to email me at ambassador 
AT fourthworld.com


--
 Richard Gaskin
 Fourth World Systems


John Patten wrote:


Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?

If you’ve been around awhile, you might remember how HyperCard had multiple development modes. Level one allowed you to use drawing tools create buttons that would allow you to ”go to next card” etc. Pretty much no script access. 

Levels 2-3 gradually provided more capabilities. 


If you new the correct procedure, you could completely unlock Hypercard, with 
access to all developer components (Level 4?)

Has anybody created a simplified Livecode developer interface for newbies?  
Something that could be used to introduce, but not initially over whelm a new 
user?

Just trying to not reinvent the wheel, if someone has already gone down this 
path and would be willing to share :)

Thank you!
John Patten



___
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

Android/Java PKCS12 Industry format Keystore

[JJS via use-livecode]

Hi,


have some people already changed their  (Android/Java) keystore keys to 
the PKCS12 format?



When creating a keystore key i get this warning a few times:


Warning:
The JKS keystore uses a proprietary format.
It is recommended to migrate to PKCS12 which is an industry standard 
format using "keytool -importkeystore -srckeystore yourapp.keystore 
-destkeystore yourapp.keystore -deststoretype pkcs12".


Or still using the proprietary format?

Regards.

___
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: Primary Student Livecode Interface (Simplified Developer Interface)

[Devin Asay via use-livecode]

RIchmond has an excellent point: your development environment is less important 
than your goal.

The reason that all of us immediately typed ’set the userLevel to 5’ in 
HyperCard is that you wouldn’t get far in your task until you needed a bump-up 
to a higher level of capabilities.

I also teach beginning programming (beginning application development is 
actually a better term), but to college students rather than primary kids. I 
realized recently like a bolt of lightening that I have been spending far too 
much instruction time describing the development environment and too little on 
setting tasks and then telling the students about the tools in LC that let them 
accomplish the task. I don’t know why it took me so long to come to that 
insight, because “need-based” learning is how I learned both HyperCard and 
LiveCode. (And probably how most of us learned.) Now I’m thinking about ways to 
incorporate more task-based instruction into my classes.

But then I’m faced with the paradox that, according to some of the research 
I’ve looked at on teaching programming, large problem solving assignments are 
less effective than focused focused practice in teaching fundamental 
programming concepts. What I take from that is that students are helped by 
“drilling” a concept with canned, focused, smaller tasks than they are by 
setting them a complex problem to solve. So my evolving approach is 1. present 
a concept, 2. do some drill and practice on the concept, 3. set them a more 
complex task that requires them to apply the concept.

I had imagined by this time in my career that I’d have figured this all out. I 
might just be slow. :-)

Devin


On Oct 10, 2019, at 11:48 AM, Richmond via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Well: for starters you are going to have to trawl right through LiveCode and 
decide
which capabilities fall into which of the 5 levels . . .

Then decide who you are going to block, for instance, access to a button script 
at level 4;
or partial blocking as you are going to allow buttons to do some things.

I designed a HyperCard-like set of tools for LiveCode a few years ago because,
over on a Yahoo group, various people who haven't worked a few home truths out 
were
bemoaning having a sophisticated interface to LiveCode instead of a dumed-down 
version: mine
was so dumbed-down it was almost moronic. For "some odd reason"
there were no takers as far as I am aware.

I teach Primary kids LiveCode every summer and we do just fine with the 
standard set of tools:
the kids use exactly what they require and are generally self-limiting.

Richmond.

On 10.10.19 18:53, Devin Asay via use-livecode wrote:
Hi John,

This idea has been discussed over the years, but I don’t know of anyone who has 
implemented it.

The userLevels were:

1 - Browsing - the ability to run and explore stacks, but no ability to make 
changes.
2 - Typing - added the ability to type and edit text in fields.
3 - Painting - added the ability to use the Paint tools to change the appears 
of cards and backgrounds.
4 - Authoring - added the ability to create buttons and fields and to link 
buttons to cards and stacks.
5 - Scripting - gave you full access to all developer components, including 
scripting.

The “magic words” were ’set the userLevel to 5’.

I found this information in my cobwebby brain, but was helped by the 
information on this page: http://folkstream.com/muse/teachhc/using/hcusing.html

Best of luck. I think there are other people here who would be interested in 
this if you find or make something.

Devin

On Oct 10, 2019, at 9:41 AM, JOHN PATTEN via use-livecode 
mailto:use-livecode@lists.runrev.com>>
 wrote:

Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?

If you’ve been around awhile, you might remember how HyperCard had multiple 
development modes. Level one allowed you to use drawing tools create buttons 
that would allow you to ”go to next card” etc. Pretty much no script access.

Levels 2-3 gradually provided more capabilities.

If you new the correct procedure, you could completely unlock Hypercard, with 
access to all developer components (Level 4?)

Has anybody created a simplified Livecode developer interface for newbies?  
Something that could be used to introduce, but not initially over whelm a new 
user?

Just trying to not reinvent the wheel, if someone has already gone down this 
path and would be willing to share :)


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

Re: Catalina

[Richmond via use-livecode]

Cider!

On 10.10.19 21:18, Dar Scott Consulting via use-livecode wrote:

Yes!

We need a cool name like that, too.
Code32
MoreMojave
CantLetGo
TimeScope
macWrap32
32Palms
Wrap32with64
DoubleMy32
Sand

It looks like I can't come up with anything as cool as WineBottler

Dar Scott




On Oct 10, 2019, at 11:51 AM, Richmond via use-livecode 
 wrote:

This sounds a bit like WineBottler:

http://winebottler.kronenberg.org/

On 10.10.19 20:48, Dar Scott Consulting via use-livecode wrote:

Being a mad scientist causes my mind to wander. I implied some sort of 
application that would take a 32-bit macOS app and turn it into a 64-bit app 
suitable for delivering to customers in the interim. But I gave solutions only 
for a sophisticated user to run 32-bit applications from Catalina (or so) 
desktop.

My immediate thoughts: Bundles might make a conversion for the macOS easier. 
Dependent 32-bit dynamic libraries would have to be moved into a folder in the 
bundle, and file I/O will do redirection. The app's program would be moved and 
replaced with something else that uses some sort of hyper-something to catch 
the INTs or that will use ptrace() as a debugger would. In the latter case the 
INTs might need to be translated statically by the converter. I have not made a 
modern debugger, tracer or hyper-thing, so I'm just guessing.

Dar


On Oct 10, 2019, at 8:34 AM, Bob Sneidar via use-livecode 
 wrote:

Mad scientist indeed! ;-)

Bob S



On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
 wrote:

Oh. That looks hard. I don't even know how to take control of the 0x80 
interrupt.

However, here are some ideas for alternatives.

Virtual

Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. (I 
don't use these, so check out what I say.) The capability is roughly the same. 
You can run an application on a client OS in a window on the host. So, if you 
have an older macOS running on a virtual machine that can run your app, you can 
set things up so that you can double-click on your desktop and run a 32-bit app.

Real

Another method is to set up little "servers" you can remote into. For example, 
instead of upgrading to Catalina on your old Mac Mini, get a new Mac Mini with Catalina 
and remote desktop into the old Mac Mini. Or have a Mac that is running several virtual 
machines you can remote into (use memory ballooning to share it well). The Apple EULA has 
constraints, but I think this is OK.

Now, what if you can run an app on a remote machine like Coherence/Unity/SM? 
You can readily run a single app in a window for a linux server using several 
programs such as nomachine and (I think) xpra. But I don't know about macOS. 
Maybe you can make a single-window app full screen and adjust the size of the 
client window. I haven't tried this.

Dar Scott
Mad Scientist

___
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



___
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: Catalina

[Dar Scott Consulting via use-livecode]

Yes!

We need a cool name like that, too. 
Code32 
MoreMojave
CantLetGo
TimeScope
macWrap32
32Palms
Wrap32with64
DoubleMy32
Sand

It looks like I can't come up with anything as cool as WineBottler

Dar Scott



> On Oct 10, 2019, at 11:51 AM, Richmond via use-livecode 
>  wrote:
> 
> This sounds a bit like WineBottler:
> 
> http://winebottler.kronenberg.org/
> 
> On 10.10.19 20:48, Dar Scott Consulting via use-livecode wrote:
>> Being a mad scientist causes my mind to wander. I implied some sort of 
>> application that would take a 32-bit macOS app and turn it into a 64-bit app 
>> suitable for delivering to customers in the interim. But I gave solutions 
>> only for a sophisticated user to run 32-bit applications from Catalina (or 
>> so) desktop.
>> 
>> My immediate thoughts: Bundles might make a conversion for the macOS easier. 
>> Dependent 32-bit dynamic libraries would have to be moved into a folder in 
>> the bundle, and file I/O will do redirection. The app's program would be 
>> moved and replaced with something else that uses some sort of 
>> hyper-something to catch the INTs or that will use ptrace() as a debugger 
>> would. In the latter case the INTs might need to be translated statically by 
>> the converter. I have not made a modern debugger, tracer or hyper-thing, so 
>> I'm just guessing.
>> 
>> Dar
>> 
>>> On Oct 10, 2019, at 8:34 AM, Bob Sneidar via use-livecode 
>>>  wrote:
>>> 
>>> Mad scientist indeed! ;-)
>>> 
>>> Bob S
>>> 
>>> 
 On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
  wrote:
 
 Oh. That looks hard. I don't even know how to take control of the 0x80 
 interrupt.
 
 However, here are some ideas for alternatives.
 
 Virtual
 
 Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. 
 (I don't use these, so check out what I say.) The capability is roughly 
 the same. You can run an application on a client OS in a window on the 
 host. So, if you have an older macOS running on a virtual machine that can 
 run your app, you can set things up so that you can double-click on your 
 desktop and run a 32-bit app.
 
 Real
 
 Another method is to set up little "servers" you can remote into. For 
 example, instead of upgrading to Catalina on your old Mac Mini, get a new 
 Mac Mini with Catalina and remote desktop into the old Mac Mini. Or have a 
 Mac that is running several virtual machines you can remote into (use 
 memory ballooning to share it well). The Apple EULA has constraints, but I 
 think this is OK.
 
 Now, what if you can run an app on a remote machine like 
 Coherence/Unity/SM? You can readily run a single app in a window for a 
 linux server using several programs such as nomachine and (I think) xpra. 
 But I don't know about macOS. Maybe you can make a single-window app full 
 screen and adjust the size of the client window. I haven't tried this.
 
 Dar Scott
 Mad Scientist
>>> 
>>> ___
>>> 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: Catalina

[Richmond via use-livecode]

This sounds a bit like WineBottler:

http://winebottler.kronenberg.org/

On 10.10.19 20:48, Dar Scott Consulting via use-livecode wrote:

Being a mad scientist causes my mind to wander. I implied some sort of 
application that would take a 32-bit macOS app and turn it into a 64-bit app 
suitable for delivering to customers in the interim. But I gave solutions only 
for a sophisticated user to run 32-bit applications from Catalina (or so) 
desktop.

My immediate thoughts: Bundles might make a conversion for the macOS easier. 
Dependent 32-bit dynamic libraries would have to be moved into a folder in the 
bundle, and file I/O will do redirection. The app's program would be moved and 
replaced with something else that uses some sort of hyper-something to catch 
the INTs or that will use ptrace() as a debugger would. In the latter case the 
INTs might need to be translated statically by the converter. I have not made a 
modern debugger, tracer or hyper-thing, so I'm just guessing.

Dar


On Oct 10, 2019, at 8:34 AM, Bob Sneidar via use-livecode 
 wrote:

Mad scientist indeed! ;-)

Bob S



On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
 wrote:

Oh. That looks hard. I don't even know how to take control of the 0x80 
interrupt.

However, here are some ideas for alternatives.

Virtual

Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. (I 
don't use these, so check out what I say.) The capability is roughly the same. 
You can run an application on a client OS in a window on the host. So, if you 
have an older macOS running on a virtual machine that can run your app, you can 
set things up so that you can double-click on your desktop and run a 32-bit app.

Real

Another method is to set up little "servers" you can remote into. For example, 
instead of upgrading to Catalina on your old Mac Mini, get a new Mac Mini with Catalina 
and remote desktop into the old Mac Mini. Or have a Mac that is running several virtual 
machines you can remote into (use memory ballooning to share it well). The Apple EULA has 
constraints, but I think this is OK.

Now, what if you can run an app on a remote machine like Coherence/Unity/SM? 
You can readily run a single app in a window for a linux server using several 
programs such as nomachine and (I think) xpra. But I don't know about macOS. 
Maybe you can make a single-window app full screen and adjust the size of the 
client window. I haven't tried this.

Dar Scott
Mad Scientist


___
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: Catalina

[Dar Scott Consulting via use-livecode]

Being a mad scientist causes my mind to wander. I implied some sort of 
application that would take a 32-bit macOS app and turn it into a 64-bit app 
suitable for delivering to customers in the interim. But I gave solutions only 
for a sophisticated user to run 32-bit applications from Catalina (or so) 
desktop. 

My immediate thoughts: Bundles might make a conversion for the macOS easier. 
Dependent 32-bit dynamic libraries would have to be moved into a folder in the 
bundle, and file I/O will do redirection. The app's program would be moved and 
replaced with something else that uses some sort of hyper-something to catch 
the INTs or that will use ptrace() as a debugger would. In the latter case the 
INTs might need to be translated statically by the converter. I have not made a 
modern debugger, tracer or hyper-thing, so I'm just guessing.

Dar

> On Oct 10, 2019, at 8:34 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Mad scientist indeed! ;-)
> 
> Bob S
> 
> 
>> On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
>>  wrote:
>> 
>> Oh. That looks hard. I don't even know how to take control of the 0x80 
>> interrupt.
>> 
>> However, here are some ideas for alternatives.
>> 
>> Virtual
>> 
>> Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. (I 
>> don't use these, so check out what I say.) The capability is roughly the 
>> same. You can run an application on a client OS in a window on the host. So, 
>> if you have an older macOS running on a virtual machine that can run your 
>> app, you can set things up so that you can double-click on your desktop and 
>> run a 32-bit app.
>> 
>> Real
>> 
>> Another method is to set up little "servers" you can remote into. For 
>> example, instead of upgrading to Catalina on your old Mac Mini, get a new 
>> Mac Mini with Catalina and remote desktop into the old Mac Mini. Or have a 
>> Mac that is running several virtual machines you can remote into (use memory 
>> ballooning to share it well). The Apple EULA has constraints, but I think 
>> this is OK. 
>> 
>> Now, what if you can run an app on a remote machine like Coherence/Unity/SM? 
>> You can readily run a single app in a window for a linux server using 
>> several programs such as nomachine and (I think) xpra. But I don't know 
>> about macOS. Maybe you can make a single-window app full screen and adjust 
>> the size of the client window. I haven't tried this.
>> 
>> Dar Scott
>> Mad Scientist
> 
> 
> ___
> 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: Primary Student Livecode Interface (Simplified Developer Interface)

[Richmond via use-livecode]

Well: for starters you are going to have to trawl right through LiveCode 
and decide

which capabilities fall into which of the 5 levels . . .

Then decide who you are going to block, for instance, access to a button 
script at level 4;

or partial blocking as you are going to allow buttons to do some things.

I designed a HyperCard-like set of tools for LiveCode a few years ago 
because,
over on a Yahoo group, various people who haven't worked a few home 
truths out were
bemoaning having a sophisticated interface to LiveCode instead of a 
dumed-down version: mine

was so dumbed-down it was almost moronic. For "some odd reason"
there were no takers as far as I am aware.

I teach Primary kids LiveCode every summer and we do just fine with the 
standard set of tools:

the kids use exactly what they require and are generally self-limiting.

Richmond.

On 10.10.19 18:53, Devin Asay via use-livecode wrote:

Hi John,

This idea has been discussed over the years, but I don’t know of anyone who has 
implemented it.

The userLevels were:

1 - Browsing - the ability to run and explore stacks, but no ability to make 
changes.
2 - Typing - added the ability to type and edit text in fields.
3 - Painting - added the ability to use the Paint tools to change the appears 
of cards and backgrounds.
4 - Authoring - added the ability to create buttons and fields and to link 
buttons to cards and stacks.
5 - Scripting - gave you full access to all developer components, including 
scripting.

The “magic words” were ’set the userLevel to 5’.

I found this information in my cobwebby brain, but was helped by the 
information on this page: http://folkstream.com/muse/teachhc/using/hcusing.html

Best of luck. I think there are other people here who would be interested in 
this if you find or make something.

Devin


On Oct 10, 2019, at 9:41 AM, JOHN PATTEN via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?

If you’ve been around awhile, you might remember how HyperCard had multiple 
development modes. Level one allowed you to use drawing tools create buttons 
that would allow you to ”go to next card” etc. Pretty much no script access.

Levels 2-3 gradually provided more capabilities.

If you new the correct procedure, you could completely unlock Hypercard, with 
access to all developer components (Level 4?)

Has anybody created a simplified Livecode developer interface for newbies?  
Something that could be used to introduce, but not initially over whelm a new 
user?

Just trying to not reinvent the wheel, if someone has already gone down this 
path and would be willing to share :)

Thank you!
John Patten



Sent from my iPhone

___
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

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



___
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: Thank you for the 9.0.5 update

[Mark Talluto via use-livecode]

As Brian stated, 9.5 will get the bug fix as well. I believe Heather indicated 
that this was coming pretty soon. 

I have been using 9.0.5 since the stable update and have not had a single 
crash. The debugger is an important component to me. LiveCode does a great job 
allowing us to drop breakpoints in real-time during a debugging session. But, 
until this bug fix, I had to stop using them because the feature would cause a 
crash within seconds/minutes of using them.

This single bug fix has changed the way I code. I use the debugger frequently 
to test my logic and variable contents on complex portions of the projects I 
work with. Now we are cooking with gas.

When 9.5 gets the update, I will move back to 9.5. Till then, I am happy in 
9.0.5. We still build our executables using 9.5. I would highly suggest moving 
back to 9.0.5 for development and breathe easy again.


Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 




> On Oct 10, 2019, at 4:46 AM, Brian Milby via use-livecode 
>  wrote:
> 
> Yes, 9.0.5 has a fix that 9.5 does not for the debug crash.  That fix will 
> appear in the next update for 9.5.
> 
> Thanks,
> Brian
> On Oct 10, 2019, 4:55 AM -0400, Lagi Pittas via use-livecode 
> , wrote:

___
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: Primary Student Livecode Interface (Simplified Developer Interface)

[Devin Asay via use-livecode]

Hi John,

This idea has been discussed over the years, but I don’t know of anyone who has 
implemented it.

The userLevels were:

1 - Browsing - the ability to run and explore stacks, but no ability to make 
changes.
2 - Typing - added the ability to type and edit text in fields.
3 - Painting - added the ability to use the Paint tools to change the appears 
of cards and backgrounds.
4 - Authoring - added the ability to create buttons and fields and to link 
buttons to cards and stacks.
5 - Scripting - gave you full access to all developer components, including 
scripting.

The “magic words” were ’set the userLevel to 5’.

I found this information in my cobwebby brain, but was helped by the 
information on this page: http://folkstream.com/muse/teachhc/using/hcusing.html

Best of luck. I think there are other people here who would be interested in 
this if you find or make something.

Devin


On Oct 10, 2019, at 9:41 AM, JOHN PATTEN via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?

If you’ve been around awhile, you might remember how HyperCard had multiple 
development modes. Level one allowed you to use drawing tools create buttons 
that would allow you to ”go to next card” etc. Pretty much no script access.

Levels 2-3 gradually provided more capabilities.

If you new the correct procedure, you could completely unlock Hypercard, with 
access to all developer components (Level 4?)

Has anybody created a simplified Livecode developer interface for newbies?  
Something that could be used to introduce, but not initially over whelm a new 
user?

Just trying to not reinvent the wheel, if someone has already gone down this 
path and would be willing to share :)

Thank you!
John Patten



Sent from my iPhone

___
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

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

Primary Student Livecode Interface (Simplified Developer Interface)

[JOHN PATTEN via use-livecode]

Good Morning from SoCal,

Quick question, anybody ever develop a simplified LiveCode “developer 
interface/tool“ project?

If you’ve been around awhile, you might remember how HyperCard had multiple 
development modes. Level one allowed you to use drawing tools create buttons 
that would allow you to ”go to next card” etc. Pretty much no script access. 

Levels 2-3 gradually provided more capabilities. 

If you new the correct procedure, you could completely unlock Hypercard, with 
access to all developer components (Level 4?)

Has anybody created a simplified Livecode developer interface for newbies?  
Something that could be used to introduce, but not initially over whelm a new 
user?

Just trying to not reinvent the wheel, if someone has already gone down this 
path and would be willing to share :)

Thank you!
John Patten



Sent from my iPhone

___
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: .rev files going back to 2001/2002 fails to open

[Bob Sneidar via use-livecode]

launch LC. Supress messages from the Development window. Open stack. Does it 
crash now? It's not your code. If it doesn't crash, set a breakpoint in your 
openStack handler, turn off suppress messages, run Openstack. Trace until it 
crashes. 

Bob S


> On Oct 9, 2019, at 19:23 , Meitnik via use-livecode 
>  wrote:
> 
> open, crash, boom…logs shortly…so am hoping 10 yr old .rev stacks can be 
> worked with??!!

___
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: Catalina

[Bob Sneidar via use-livecode]

Mad scientist indeed! ;-)

Bob S


> On Oct 9, 2019, at 16:59 , Dar Scott Consulting via use-livecode 
>  wrote:
> 
> Oh. That looks hard. I don't even know how to take control of the 0x80 
> interrupt.
> 
> However, here are some ideas for alternatives.
> 
> Virtual
> 
> Parallels has Coherence; Virtual Box has Seamless Mode; VMware has Unity. (I 
> don't use these, so check out what I say.) The capability is roughly the 
> same. You can run an application on a client OS in a window on the host. So, 
> if you have an older macOS running on a virtual machine that can run your 
> app, you can set things up so that you can double-click on your desktop and 
> run a 32-bit app.
> 
> Real
> 
> Another method is to set up little "servers" you can remote into. For 
> example, instead of upgrading to Catalina on your old Mac Mini, get a new Mac 
> Mini with Catalina and remote desktop into the old Mac Mini. Or have a Mac 
> that is running several virtual machines you can remote into (use memory 
> ballooning to share it well). The Apple EULA has constraints, but I think 
> this is OK. 
> 
> Now, what if you can run an app on a remote machine like Coherence/Unity/SM? 
> You can readily run a single app in a window for a linux server using several 
> programs such as nomachine and (I think) xpra. But I don't know about macOS. 
> Maybe you can make a single-window app full screen and adjust the size of the 
> client window. I haven't tried this.
> 
> Dar Scott
> Mad Scientist


___
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: Thank you for the 9.0.5 update

[Tom Glod via use-livecode]

Agreed. this was a critical release, I was struggling with the property
inspector for what seems like 18 months. now all those bugs are fixed,
not to mention the memory leaks.

way fewer interruptions and new users won't be asking themselves what is
wrong with this thing.

Happy coding everyone.



On Thu, Oct 10, 2019 at 8:12 AM Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thank You Brian, I was hoping that would be the answer.
>
> Regards Lagi
>
> On Thu, 10 Oct 2019 at 12:47, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Yes, 9.0.5 has a fix that 9.5 does not for the debug crash.  That fix
> will
> > appear in the next update for 9.5.
> >
> > Thanks,
> > Brian
> > On Oct 10, 2019, 4:55 AM -0400, Lagi Pittas via use-livecode <
> > use-livecode@lists.runrev.com>, wrote:
> > > Hi Mark,
> > >
> > > My mileage is varying.
> > >
> > > I have been using 9.5 stable and thought it was the complexity of an
> > > application that was the cause of crashing with "red dots"
> > >
> > > I created a play/test stack yesterday - 1 button 2 functions and a
> mousup
> > > of a couple of lines no more than 30 lines of code. Did some debugging
> > and
> > > got a crash
> > > in less than 15 minutes. Does 9.05 stable have extra fixes that 9.5
> > stable
> > > doesn't?
> > >
> > > Thanks
> > >
> > > Lagi
> > >
> > > On Wed, 9 Oct 2019 at 21:10, Mark Talluto via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > For the time being, I am developing on 9.0.5 stable. The reason is
> that
> > > > debugging with red dots no longer crashes LiveCode. I appreciate the
> > time
> > > > taken to implement this bug fix.
> > > >
> > > > https://github.com/livecode/livecode/pull/7185 <
> > > > https://github.com/livecode/livecode/pull/7185>
> > > >
> > > > My productivity has increased by not having to restart my rather
> > complex
> > > > LiveCode setups after a crash. Plus, I can live breakpoint (using the
> > dots)
> > > > while already in debug mode.
> > > >
> > > > Thanks again for this important update.
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Mark Talluto
> > > > livecloud.io 
> > > > nursenotes.net 
> > > > canelasoftware.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
> > ___
> > 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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Office:226-706-9339
Mobile:226-706-9793
___
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: Thank you for the 9.0.5 update

[Lagi Pittas via use-livecode]

Thank You Brian, I was hoping that would be the answer.

Regards Lagi

On Thu, 10 Oct 2019 at 12:47, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yes, 9.0.5 has a fix that 9.5 does not for the debug crash.  That fix will
> appear in the next update for 9.5.
>
> Thanks,
> Brian
> On Oct 10, 2019, 4:55 AM -0400, Lagi Pittas via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > Hi Mark,
> >
> > My mileage is varying.
> >
> > I have been using 9.5 stable and thought it was the complexity of an
> > application that was the cause of crashing with "red dots"
> >
> > I created a play/test stack yesterday - 1 button 2 functions and a mousup
> > of a couple of lines no more than 30 lines of code. Did some debugging
> and
> > got a crash
> > in less than 15 minutes. Does 9.05 stable have extra fixes that 9.5
> stable
> > doesn't?
> >
> > Thanks
> >
> > Lagi
> >
> > On Wed, 9 Oct 2019 at 21:10, Mark Talluto via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > For the time being, I am developing on 9.0.5 stable. The reason is that
> > > debugging with red dots no longer crashes LiveCode. I appreciate the
> time
> > > taken to implement this bug fix.
> > >
> > > https://github.com/livecode/livecode/pull/7185 <
> > > https://github.com/livecode/livecode/pull/7185>
> > >
> > > My productivity has increased by not having to restart my rather
> complex
> > > LiveCode setups after a crash. Plus, I can live breakpoint (using the
> dots)
> > > while already in debug mode.
> > >
> > > Thanks again for this important update.
> > >
> > >
> > > Best regards,
> > >
> > > Mark Talluto
> > > livecloud.io 
> > > nursenotes.net 
> > > canelasoftware.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
> ___
> 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: Thank you for the 9.0.5 update

[Brian Milby via use-livecode]

Yes, 9.0.5 has a fix that 9.5 does not for the debug crash.  That fix will 
appear in the next update for 9.5.

Thanks,
Brian
On Oct 10, 2019, 4:55 AM -0400, Lagi Pittas via use-livecode 
, wrote:
> Hi Mark,
>
> My mileage is varying.
>
> I have been using 9.5 stable and thought it was the complexity of an
> application that was the cause of crashing with "red dots"
>
> I created a play/test stack yesterday - 1 button 2 functions and a mousup
> of a couple of lines no more than 30 lines of code. Did some debugging and
> got a crash
> in less than 15 minutes. Does 9.05 stable have extra fixes that 9.5 stable
> doesn't?
>
> Thanks
>
> Lagi
>
> On Wed, 9 Oct 2019 at 21:10, Mark Talluto via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > For the time being, I am developing on 9.0.5 stable. The reason is that
> > debugging with red dots no longer crashes LiveCode. I appreciate the time
> > taken to implement this bug fix.
> >
> > https://github.com/livecode/livecode/pull/7185 <
> > https://github.com/livecode/livecode/pull/7185>
> >
> > My productivity has increased by not having to restart my rather complex
> > LiveCode setups after a crash. Plus, I can live breakpoint (using the dots)
> > while already in debug mode.
> >
> > Thanks again for this important update.
> >
> >
> > Best regards,
> >
> > Mark Talluto
> > livecloud.io 
> > nursenotes.net 
> > canelasoftware.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
___
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: Thank you for the 9.0.5 update

[Bernard Devlin via use-livecode]

>>
I created a play/test stack yesterday - 1 button 2 functions and a mousup
of a couple of lines no more than 30 lines of code. Did some debugging and
got a crash
in less than 15 minutes.
<<

I was getting multiple random crashes with a test stack in 9.5 that were
apparently totally unrelated to debugging.   Having not seen such crashes
for years, I assumed that it was the introduction of the 64bit build for
Windows. So I switched to using the 32bit build for Windows and the random
crashes continued.  I haven't got anywhere with finding a reproducible
pattern.

Regards, Bernard
___
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: Thank you for the 9.0.5 update

[Lagi Pittas via use-livecode]

Hi Mark,

My mileage is varying.

I have been using 9.5 stable and thought it was the complexity of an
application that was the cause of crashing with "red dots"

I created a play/test stack yesterday - 1 button 2 functions and a mousup
of a couple of lines no more than 30 lines of code. Did some debugging and
got a crash
in less than 15 minutes. Does 9.05 stable have extra fixes that 9.5 stable
doesn't?

Thanks

Lagi

On Wed, 9 Oct 2019 at 21:10, Mark Talluto via use-livecode <
use-livecode@lists.runrev.com> wrote:

> For the time being, I am developing on 9.0.5 stable. The reason is that
> debugging with red dots no longer crashes LiveCode. I appreciate the time
> taken to implement this bug fix.
>
> https://github.com/livecode/livecode/pull/7185 <
> https://github.com/livecode/livecode/pull/7185>
>
> My productivity has increased by not having to restart my rather complex
> LiveCode setups after a crash. Plus, I can live breakpoint (using the dots)
> while already in debug mode.
>
> Thanks again for this important update.
>
>
> Best regards,
>
> Mark Talluto
> livecloud.io 
> nursenotes.net 
> canelasoftware.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