Run the same stack from two LC installs

[stam]

Well said Mark, couldn’t agree more.
I’m a single dev and find this invaluable. For bigger teams it’s practically mandatory…

[mtalluto]

Well said Mark, couldn’t agree more.
I’m a single dev and find this invaluable. For bigger teams it’s practically mandatory…

[edited for clarification...instead of rapid typing - press submit ]
I was inspired by your post on version control Stam to come out. I decided to throw my hat in the ring due to some of the threads about the state of LiveCode, where the newbies are, and other conversations about pricing. I have been lurking about, wondering if I should express some of my thoughts.

My post on version control could be viewed as a bit heavy-handed. I do not intend to say that this is the only way to develop software. From my experience, supportive tools like version control will provide tremendous value to anyone making software today. Those who worked on software before VC became mainstream could make a living without it. It is easy to stay in the old ways and not adopt new tech available around us. We are all in different phases of our careers and will make the best decisions possible.

But readers from the outside will get the wrong impression about LiveCode if our views do not include the tools that new developers are taught in Universities worldwide. If we wonder where the new blood will come from, we should start with young people who have not yet solidified on a particular tech stack. I also see value in enticing people from similar development environments. The other problem is that it is hard to be seen in a sea of options.

Marketing comes up a lot in the forums. LiveCode has been very active in the social media space. It is the first place companies go with small budgets to market their products. Their reach and engagement is low, unfortunately. That form of marketing is moving to a pay-for-eyes model that works well for larger businesses with more cash.

From LiveCode’s website, they have a larger team count than most in their shoes. They seem to be focusing hard on development. Advertising is not cheap and is a long game before there is a return. Most of their social media voice is about LiveCode Create. When we put all this together, we will not see them do heavy marketing until they are ready with the new service. I have no inside information, and thus, I am only speculating here.

There is a strong representation of hobbyists in the forums. I will not address their pricing views as I am not in this category yet. I can provide insight from the ISV (independent software vendor) side of the customer base. I think LiveCode’s pricing is fair for what we get. My team is highly productive with the LiveCode language. Running a business requires us to purchase many SaaS packages from various vendors. Our monthly service costs might be shocking. Relative to our income, the services make our business possible. We are careful in how we spend our revenue. If a service is not providing value, we remove it. LiveCode is always expected to be in our services budget.

There must be enough of us in the ISV, contractors, and developers for an organization to buy the more expensive packages needed to keep LiveCode afloat. I have some friends who are in the retired category who buy a license from LiveCode as a way to help them stay in business. Customers like that are gold. Running a business is hard. Many decisions have to be made every day. Smaller companies like LiveCode have to be careful in the way a deer is cautious in an open field.

Supporting a wide range of customers is honorable. Diversification is great! But to stay alive, they must attract those buying multiple, expensive licenses. The business case for buying their software is the message they will shout about when they are ready. My thought is that the LiveCode service we have today is deserving of that marketing messaging now. Future features and products take a long time to develop. It takes even longer to make them great. Waiting for them engages the Osborne Effect when all we hear about is the future. It also devalues the LiveCode product available today.

[jacque]

I agree the VC approach is convenient in some situations, and I've used it. I think it depends on the type of work you do, though. When I said I frequently use a different approach, I should have clarified that most of that depends on the source stacks I'm working with which, even now, can be updates of old HC stacks (I'm doing one of those now.) Those don't lend themselves to version control very well.These usually have buttons specifically coded to a unique action (often, "go card id xxxx") that apply only to the card they are on. Sometimes there's a stack script or a card script that applies to more than one control but I'm not sure there's a benefit to using a script-only stack for those when there are backups available, or when the easy duplicate stack method is so convenient.

I worked with Swami for a long time and he was deeply committed to script-only stacks and git, which worked well because there were several of us and we all had our own areas of work. But I'm not so sure it would be useful for me, a lone developer, working on a single handler in a single stack. And with Swami's huge project I had trouble finding the handlers I needed in the sea of text files in the git repository.

I mostly only mentioned my method because the OP wanted a quick automated way to update a second duplicate stack. I know my method is unconventional. If his work can be divided into segments that lend themselves to script-only stacks then that may be the way to go.

I'm curious though. Would it be useful to create a script-only stack for a single handler that applies only to a single control? That's HyperCard for you.

[mtalluto]

...And with Swami's huge project I had trouble finding the handlers I needed in the sea of text files in the git repository.

I do all my searching for handlers and other coding practices directly in LiveCode. This is how we would find a handler in a binary stack. Script-only stacks are no different.

I'm curious though. Would it be useful to create a script-only stack for a single handler that applies only to a single control? That's HyperCard for you.

Suppose the project is commercial, then yes. Having it structured this way allows you to move the project to someone else. They will be able to see the historical changes and how the project grew. They can see what was tried and why it changed. Commercial projects are expected to grow, and version control will be set up to help support that growth.

If the project is a one-off for internal use, then maybe not. I have plenty of one-button, one-field stacks that do something just for me, and I did not use VC here. If I end up sharing it with another coder, I would use VC to track changes to the project.

[FourthWorld]

The point is: can I put the main stack on a shared HD and run it, in the same time, from both Macs, updating, saving, etc?
And, if yes, what should I be aware of?

Can you tell us a bit about why you want to do this?

Many helpful suggestions have been presented here, but once we learn more about your goals we'll be in a better position to find the optimal mix of tradeoffs for your situation.

[trevix]

My app work on Android and iOS mobile.
The main characteristic of it is that the same app gets installed on a TvBox and on a mobile. Once connected using wifi and sockets, the mobile app controls the tvbox app (and gets data from it).
Just to clarify why it does this:
- The app is a sport scoring app for tennis, padel, pong and teqball (www.referi.io).
- the TvBox is HDMI connected to a TV set and act as a in court scoreboard
- the judge, from his mobile, start the mach (the two apps connect), set the type of match, players names, etc
- each point is sent from the mobile and visualised on the tv
- many more interaction happens between the two apps, like "timeout" if nothing happens for a while.

As you can image, most of my developer problems and bugs are coming from my communication protocol and from the need that every situation (wifi goes off, UI navigation, etc) will not disrupt the connection and the point advance (the match cannot be stopped because of problems: the players won't take it very well ).

Coming to the subject of this post, my LC development most of the time happens on two computers connected with wifi and running the same version of stack: one act as a mobile (client) and one as a tvbox(server).
When I find a problem, I have to save the stack, close LC, copy the stack to the other computer and relaunch both stacks. Very time consuming.
My original question (my error) didn't take in account that LC load the stack in memory. So running from two computers the same stack in a shared HD would only partially shorter my development time (the "revert to saved" solution has to restart the stack, which in my case take sometime) and quite prone to errors.
I know that, generally speaking, syncing is a tough business and, believe me, I have enough problems as of now, without resorting to some some syncing script.
So, I think I will keep going like I am doing now.
Trevix

[jacque]

When you copy the stack to the other computer, it has to restart anyway, right? Your situation is a good example of when to use the revert method. Since you only develop on one machine I think you won't have any problems with mistaken overwritten data. But of course, the best approach is what you're comfortable with.

[mtalluto]

I have a much better understanding of what is going on here.

There are two concerns.

1. Development - keeping updated code in sync between the two devices using the same code base
2. When a game is active - make service as resilient as possible to network outages

The development could be improved by putting all your code into script-only stacks and using them as behaviors and libraries as appropriate. In your socket code, you would have a reload message sent. The message would fire a reload of all your behaviors and libraries. This can happen very quickly. Your app will have access to the updated code without reloading binaries. The binaries would hold the code needed to load the setup.lib, which has a repeat to load your behaviors and a repeat to load your other libraries.

I think you have resolved problem #2, keeping the networking local and using your socket system for communication.

If I am missing something or you need more detail, please post.