New command line parameter not really working?

Skin:
First, the command line switch should still work. Did you remember to use a single dash instead of double dashes? e.g.

./Corona\ Simulator.app/Contents/MacOS/Corona\ Simulator -project ~/Desktop/ModifiedExamples/SimplePool -skin NexusOne

Next, I just added a URL scheme to specify the skin. Check the next daily build. (probably 301).

Examples:

corona://open?url=file:///Applications/Corona.2011.301/SampleCode/GettingStarted/HelloWorld&skin=iPad

corona://open?url=file://~/Desktop/ModifiedExamples/SimplePool&skin=NexusOne

Quit:
Specifically, why do you need to quit? We need to be careful here. What if some day we add functionality that prompts the user to save their data? Also, the URL handlers will let you specify another project if Corona is already open.

Build:
As I said, this is something we are interested in for our own internal purposes. But it is a non-trivial amount of work so I don’t know if/when it will happen.

Terminal Feedback:
Specifically, what information do you need? As I said, we do not like the current system and will probably overhaul it in the future. I expect our changes to break anybody depending on the current system.

Also, I suspect with Scripting Bridge, we should be able to return values and information via the API.
Windows:
Windows is still a work in progress and the items discussed here are lower priority items for us. (Fair warning.)
[import]uid: 7563 topic_id: 6315 reply_id: 23347[/import]

I just created a 2-minute video that shows why I want Quit and Terminal feedback. If you want you can see that here:

http://instantvideowebpages.com/play/notmplvid.php?567

But it boils down to making the people who use Corona Project Manager more productive. The smoother the communication between CPM and Corona Simulator, the better for everyone.

Quit: Since you can launch the Sim from inside CPM it makes sense to be able to quit it from inside CPM.

Build: I’d at least like to pass the parameters (or some of them, maybe not the Code Signing Stuff) because I’m launching the Build window using AppleScript and that feels kind of “brittle” to me.

Terminal: I’d like CPM to be a “one stop shop” for Corona devs so having the print statements, syntax errors, etc., show up in the Terminal pane means one less window to keep track of.

Thanks.

Jay
[import]uid: 9440 topic_id: 6315 reply_id: 23361[/import]

As far as launching with a skin goes, in the current build (268) am I supposed to be using a single or double dash before the skin?

In the Mac version I’m using a double-dash and it works fine, launching the correct skin.

In the Windows version I’m launching like this:
start C:\PROGRA~1\Ansca\CORONA~1\CORONA~1.EXE C:\Users\JAYJEN~1\DOCUME~1\CORONA~2\Sandbox\4\main.lua -skin myTouch

…and no matter whether I use single or double dashes the Simulator ignores that.

If the current Windows version is broke, no problem, I’d just like to know so I can stop banging my head against it. :slight_smile:

Thanks.

Jay
[import]uid: 9440 topic_id: 6315 reply_id: 23363[/import]

268 is before the changes…double dash.

I don’t think any of this works in Windows right now.
[import]uid: 7563 topic_id: 6315 reply_id: 23367[/import]

>1> It is not our intention to disable anything, but technically we never really supported the command line

>2> Terminal Feedback:
>2> I expect our changes to break anybody depending on the current system.

Well, that is the information I needed. Thank you. I will ask the people who are testing IndeED atm what they think about this.

For any tool like CPM or IndeED that has to communicate with Corona to make it stand out from general tools like BBEdit, you need a clean way to do this. Since at least April 2010 it was your supported and documented way to communicate with Corona. Now you say you never supported this??? What a change of mind. I am surprized. Slowly I regret ever asking Carlos to implement more command line switches to control Corona.

Imho as a company you have two choices. Provide the tools people want/need yourself or create a system that makes it easy for 3rd parties to support your product. And this includes the ability to control Corona from these tools. It doesn’t help if you keep changing the way a tool has to communicate with Corona every other week. I am stretching here but for it looks kinda like that to me. Without the ability to communicate, you have just a tool that exports source code in a format that Corona can read. That’s all. Like Jay said, our tools are ment to be one shop tools, or least close to that.
[import]uid: 5712 topic_id: 6315 reply_id: 23393[/import]

Thanks Jay for the video. I have a better understanding of what you need now.
[import]uid: 7563 topic_id: 6315 reply_id: 23402[/import]

As I said, it is not our intention to disable or break anything. However, when we need to improve Corona, we cannot necessarily allow our current existing broken behavior to become an obstacle. For example, it should be quite obvious that our command line system was simply a hack and never actually designed or thought out. The fact that we had some switches require double dashes and others single dashes should reek of a kludge. And more to the reason why we recently fixed this, the original implementors failed to understand the subtle conflicts the implementation had with core Mac/Cocoa functionality which prevented things like drag-and-drop launches.

That said, even though we made these changes, in this case, all the functionality we provided before still exists via command line switches. We have not (intentionally) removed anything. Only the semantics changed.

Also, when we made these changes, we sent out some emails to people we knew might be using these features to alert them of these coming changes. I’m sorry if you did not receive these. But that’s also why we introduced this subscriber forum and the daily builds.

Looking forward, it is not my intention to frustrate you. But our mandate is to make the best product possible. In my opinion, we will need to make significant changes underneath the hood to improve the product which affect areas like console output and debugging. But these same changes will also make things like programmable builds possible.

We think your products that work with Corona are terrific and we don’t want to stymie your development. But you need to understand that the current system we have which you use to communicate with Corona was originally a byproduct of us needing to get things done internally and was not really something we expected third parties to latch onto and need to endure. I don’t know what Carlos told you, and maybe he will correct me, but my impression for these features were that only our elite developers were using these features and they would be prepared for the possibility that we may need to break things. But it is my full intention that if/when it comes time to finally fix/overhaul this system, we will provide a replacement system that is much better.

The URL scheme handler was a first shot at proposing things that might be possible. But it was never meant as an end-all. Right now I’m leaning towards Scripting Bridge as the solution to most of the problems you are trying to solve.

Finally, the changes we need to make are non-trivial and will take time. Thus the changes I’m warning about will probably not happen for quite awhile. Given the intense interest you guys have generated in this thread, I will be sure to announce changes in this forum and solicit your feedback as appropriate.
[import]uid: 7563 topic_id: 6315 reply_id: 23403[/import]

I understand going back to add features to something that was “fine” and realizing the future might not have been fully prepared for. (I hate when that happens!)

If you need to break something to make the product better, that’s cool. But if possible, try not to break existing things until whatever is new and better is in place. :smiley:

I think CPM can be a cool tool without *any* 2-way communication with Corona – but I imagine fewer people would think so. That’s not your problem, but if you don’t have to sink my boat, I’d appreciate it if you don’t. :wink:

And I DO appreciate the open conversation about this stuff, the new URL scheme you’re putting in place, etc.

I whine because I care. And not just about CPM, but about Corona SDK itself.

Jay
[import]uid: 9440 topic_id: 6315 reply_id: 23411[/import]

+1 [import]uid: 5712 topic_id: 6315 reply_id: 23419[/import]

Hi Ansca Mobile,

I made up my mind. I have no need for any possible communication anymore.

Good luck Jay!

Cheers
Michael [import]uid: 5712 topic_id: 6315 reply_id: 23452[/import]

Hey, not sure if I should post this here, but it’s related to the discussion…

When I launch Win Sim from the command line, passing in the path to a project, the Sim launches and the project runs. Sometimes.

Jungle Scene, for example, always works. Egg Breaker, for example, never works.

But here’s the weird part – Egg Breaker loads, you can see the splash screen, but it never actually “starts.” But if you hit Control-R to relaunch, it then works fine. So it sees the project, it just doesn’t get past the splash screen.

Here’s a 60-second video showing what happens:

http://instantvideowebpages.com/play/notmplvid.php?568

And one more data point to ponder, I removed the Default.png file from Egg Breaker and then it went straight to the game and worked. So I figured that was the problem, but when I put in a Default.png in Jungle Scene that one didn’t break, so not sure if that has anything to do with it.

I know, we’re talking about the Windows version which is a lower priority, but the fact that one of your sample code projects works when launched from the command line and one doesn’t is kind of weird.

Thanks.

Jay
[import]uid: 9440 topic_id: 6315 reply_id: 23554[/import]

This works:

/Applications/Corona301/simulator -project “/Applications/CoronaSDK/SampleCode/Ghosts”

This should work right?

/Applications/Corona301/simulator -project “/Applications/CoronaSDK/SampleCode/Ghosts\ Monsters”

I’m backslashing the space. between “Ghosts Monsters”

[import]uid: 36395 topic_id: 6315 reply_id: 24288[/import]

You need to pick quotes xor backslashes.
Either use the backslash to escape the space (and no quotes) or use quotes around the entire string. Don’t combine the two.
[import]uid: 7563 topic_id: 6315 reply_id: 24289[/import]

Yep,

Pasted the wrong one. Here’s the right one and still doesn’t work.

Doesn’t Work

/Applications/Corona301/simulator -project /Applications/CoronaSDK/SampleCode/Ghosts\ Monster

/Applications/Corona301/simulator -project “/Applications/CoronaSDK/SampleCode/Ghosts Monster”

Works!

/Applications/Corona301/simulator -project “/Applications/CoronaSDK/SampleCode/Ghosts”

[import]uid: 36395 topic_id: 6315 reply_id: 24292[/import]

I’ve only been testing against the real app, not the shell script, i.e.:
./Corona\ Simulator.app/Contents/MacOS/Corona\ Simulator

I suspect the shell script is mangling the arguments you are passing.

I recommend you skip the shell script. (Or feel free to post a fixed shell script.)

[import]uid: 7563 topic_id: 6315 reply_id: 24303[/import]

>>/Applications/Corona301/simulator -project “/Applications/CoronaSDK/SampleCode/Ghosts Monster”

Huh, when I type your command line into the terminal I get a message popup from Corona:

The document “Monster” could not be opened. Corona Simulator cannot open files of this type.
[import]uid: 5712 topic_id: 6315 reply_id: 24374[/import]

Ok

So to clarify, to work with file paths that have spaces in the name, you would call the Application directly, an example of this is ewing’s note above #34, then supply the path to your executable wrapped in quotes or with the spaces escaped with back slashes.

Let me know if this helps.
[import]uid: 36395 topic_id: 6315 reply_id: 24401[/import]

Ok will try that.

But would you agree that you posted a sample that is not working in the post you said it works? I find that confusing. [import]uid: 5712 topic_id: 6315 reply_id: 24403[/import]

-project "/Applications/CoronaSDK/SampleCode/Ghosts Monster"

Got it to work with the quotes. No worries, I believe I had the wrong directory earlier.

[import]uid: 36395 topic_id: 6315 reply_id: 24310[/import]

Yes, #36 as original posted does not work. [import]uid: 36395 topic_id: 6315 reply_id: 24409[/import]