New command line parameter not really working?

Solar2D Daily Builds and Public Releases
#1

Hi Ansca team,

the new command line parameters which were introduced with build 277, what are they suppose to do? The old ones are still valid. The new ones just open the simulator, I get an output like this one

2011-02-09 22:46:32.162 Corona Simulator[858:903] projectname: /users/MikeHart/Desktop/Corona/Games/NeonCommand_proj/NeonCommand/main.lua

But nothing more happens. Corona waits that you manually load a project to run.

Btw. if the path to a project contains spaces, then you can’t start that via the command line. Even surounding the path with " doesn’t help.

Example:

/applications/corona.277/simulator "/users/MikeHart/Desktop/Corona/Games/Breakout\_proj/Break out"

Cheers
Michael Hartlef

http://www.whiteskygames.com
[import]uid: 5712 topic_id: 6315 reply_id: 306315[/import]

#2

i have seen a bug about command line that krept up… will find out what happened…

make sure you always have 268… :wink:

c [import]uid: 24 topic_id: 6315 reply_id: 21895[/import]

#3

np, I am on the save side. [import]uid: 5712 topic_id: 6315 reply_id: 21898[/import]

#4

All the command line parameter stuff needed to be rewritten because the way it worked was fundamentally incompatible with Mac/Cocoa GUI infrastructure. For example, we now allow you to drag main.lua or folders containing main.lua onto the Application or Dock icon to load/run a simulation. But this mechanism was confused by the old command line argument system. For now, all command line switches require the form:
-key value

(and notice the single dash, not double.)
If you need to launch Corona with a specified project, you must now specify a switch called -project in front of it.

Example:
Corona\ Simulator.app/Contents/MacOS/Corona\ Simulator -project /Applications/Corona.268/SampleCode/GettingStarted/HelloWorld/main.lua

If you were using any other switches, those probably broke too. Let me know if you were using them.
However, moving forward, we encourage you to not launch through the command line if you can avoid it. We are introducing a URL scheme/handler so you can open scripts in a much more flexible manner:

Example:
corona://open?url=file:///Applications/Corona.268/SampleCode/GettingStarted/HelloWorld/main.lua

So things like NSWorkspace openURL, typing in Safari, or calling open on the command line e.g.
open “corona://open?url=file:///Applications/Corona.268/SampleCode/GettingStarted/HelloWorld/main.lua”

should generally work and is not dependent on the location of the app or the whether the application is closed or already open (unlike the command line switch).
Our intention is to make it much easier for 3rd party apps to invoke/integrate with Corona using standard Mac mechanisms.
Right now, we only support opening local files (file:///). and it must be a main.lua or a folder containing a main.lua.

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

#5

Does this mechanism support reading the output pipe and writing to the input pipe? [import]uid: 5712 topic_id: 6315 reply_id: 22001[/import]

#6

We currently don’t do anything internally about standard in/out/error. But I expect that any redirection of these things are a product of your shell, so when you set up redirection and pipes and launch via command line, these get intercepted/processed by the shell and Corona never sees this. So I would think this should just work.

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

#7

How do I start the debugger then? [import]uid: 5712 topic_id: 6315 reply_id: 22012[/import]

#8

Bugger!!!

  1. Spaces in filepaths are still not allowed.
  2. Even worse, I don’t get the output via the pipe now. :frowning: [import]uid: 5712 topic_id: 6315 reply_id: 22015[/import]
#9

Ok, I tried this new method now via the terminal. Even there I get no output. I guess I can then stop working on IndeED. :-(((( [import]uid: 5712 topic_id: 6315 reply_id: 22017[/import]

#10

Thanks for testing!
First, I found some bugs in the argument parsing routines. I think you have to supply the directory to the folder and not the main.lua itself. Also, you can’t use ‘~’. I will try to fix both of these soon. But for now, you might try again. I also still expect the output redirection to still work once you get the simulator correctly launched. What is your pipe command?

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

#11

I use no pipe command, just start a process and read the stdout and stderr pipe from that process. Anyway I would expect to get output inside the terminal window too when I use your example you wrote above. But even there I get no output.

Getting the damn output of Corona into IndeED was the most difficult task I had to face when I started developing IndeED. Now you guys changing this, I don’t think I have the motivation to go after that again. My OSX/Shell/UNIX/whatever knowledge is to limited in that part. Windows makes it much much easier.

But it is not the end of the world. Life goes on.

Thanks for listening!

Over and out
Michael [import]uid: 5712 topic_id: 6315 reply_id: 22028[/import]

#12

If you are unable to launch a script with the -project switch, then wait for the next fix.
As I said, the standard out/error stuff is unchanged (for now). This should still work. I still see output on my system in the console.

FYI, if you don’t launch through a shell, the output gets redirected to the standard Mac system log. You can see it in Console.app. You can also read through those files directly. The command ‘tail’ is often used by people to periodically watch a file and grab just the bottom entries.

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

#13

Forgot to respond to this: The debugger switch is
-debug 1
[import]uid: 7563 topic_id: 6315 reply_id: 22121[/import]

#14

  1. Does the URL handler scheme work in 268?

  2. How do you specify the skin to use with the new URL handler?

  3. -debug 1 looks like a command line argument – what should be used with the new URL handler?

I still wish you guys would open a socket for 2-way communications, then we wouldn’t have to do anything tricky to get the output – just listen for it.

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

#15

  1. No. It is in the first daily build though.

  2. Not supported (yet). The command line switch is -skin . We didn’t think anybody was using this switch besides us.

    3) Also not supported (yet).

    Right now the URL handler only supports opening scripts. This is an opening shot to get people to think about what is possible. We need feedback on what you guys really want and need. The command line switch implementation was really only a quick implementation to meet certain mostly internal needs and was not really intended for external use. And you can see the limitations of command line switches as it does not fit into the Mac world view where an application may already be running but you want to make it do something.

    We have various thoughts about what we want to do with the debug output. We do not like the current system. We would ultimately like to provide an in-app display, though it is clear that some of you want access to the output. Sockets are one thing among many we are considering for output. But what information do you really want/need?

    As for input sockets, I suppose that is possible, but again, it would help us to know what you really want/need. At least on the Mac, there are many different and arguably better ways to communicate to an application. Skipping past signals and pipes, we have URL schemes, System Services (the thing in the Services menu), Applescript/Scripting Bridge and ultimately Automator.
    [import]uid: 7563 topic_id: 6315 reply_id: 22129[/import]

#16

>>we have URL schemes, System Services (the thing in the Services menu), Applescript/Scripting Bridge and ultimately Automator.

For a suppose to be cross platform tool you guys go a very apple centric way. :slight_smile:

Anyway, all these things are out of my league/knowledge atm. So I can’t say anything about these. I just want to be able to catch the output in an easy way and talk to the debugger also in an easy way. Let me know when you guys have made up your mind.

When do you guys will disable the old way of calling Corona and the debugger?

[import]uid: 5712 topic_id: 6315 reply_id: 22151[/import]

#17

It is not our intention to disable anything, but technically we never really supported the command line switches directly in the first place. The command line switch code had to change because it interfered with fundamental Cocoa things like being able to drag a Lua file on top of the app icon to launch.

The debugger is an entirely different subject compared to the other items. The other items are geared towards automation. The debugger tends to be a very manual/interactive process.
[import]uid: 7563 topic_id: 6315 reply_id: 22205[/import]

#18

FYI, I pushed in fixes for paths with spaces which should be available in the daily builds starting with 295.
[import]uid: 7563 topic_id: 6315 reply_id: 22272[/import]

#19

Well, then I feel better. Calling Corona and the debugger the old way is enough for me. [import]uid: 5712 topic_id: 6315 reply_id: 22303[/import]

#20

Someone just sent me a bug report that CPM doesn’t select the skin starting with build 280. No matter what they set as the default device it only shows iPhone.

So whatever you guys are doing with the next version breaks a part of CPM.

Right now the URL handler only supports opening scripts. This is an opening shot to get people to think about what is possible. We need feedback on what you guys really want and need.

What I need is the following:

  1. A way to launch the Simulator.
  2. A way to tell the Simulator to open/launch a project.
  3. A way to tell the Simulator which skin to use.
  4. A way to tell the Simulator to quit.
  5. A way to tell the Simulator to open a project to Build.
  6. A way to receive the terminal feedback from the Simulator.

I *think* that’s everything I need, and if you want reasons why I think I need those things, let me know and I’ll explain my thinking.

Right now with the Mac I can do all of those, although I’m telling it to launch a project by quitting and restarting the Simulator which has some drawbacks.

But they way Windows works I can do 1, 2, and 3 (but only as part of 1) but I don’t have any way to do 4, 5, or 6.

Jay

PS - On my wish list is a way to do an entire build from inside CPM, but launching the Sim with the Build window open is fine.
[import]uid: 9440 topic_id: 6315 reply_id: 23156[/import]