• Replies 21 replies
  • Subscribers 21 subscribers
  • Views 5063 views
  • Users 0 members are here
Options
Related

I get "terminated with exit code: 100" when following the "Your first Connect IQ app"

JoeK1973
over 2 years ago

Hi - I've followed all the instructions so far and I'm getting the error above:

Here is the log:

 *  Executing task in folder 55watchface: C:\Program Files\Common Files\Oracle\Java\javapath\java.exe -Xms1g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -jar c:\Users\brain\AppData\Roaming\Garmin\ConnectIQ\Sdks\connectiq-sdk-win-4.1.5-2022-08-03-6e17bf167\bin\monkeybrains.jar -o bin\55watchface.prg -f c:\Users\brain\OneDrive\Desktop\Tech\Garmin Watch SDK\55\55watchface\monkey.jungle -y  -d fr55_sim -w 
 
 ERROR: Missing argument for option: y
org.apache.commons.cli.MissingArgumentException: Missing argument for option: y
        at org.apache.commons.cli.Parser.processArgs(Parser.java:363)
        at org.apache.commons.cli.Parser.processOption(Parser.java:395)
        at org.apache.commons.cli.Parser.parse(Parser.java:210)
        at org.apache.commons.cli.Parser.parse(Parser.java:88)
        at com.garmin.monkeybrains.Monkeybrains.run(Monkeybrains.java:2431)
        at com.garmin.monkeybrains.Monkeybrains.simpleMain(Monkeybrains.java:342)
        at com.garmin.monkeybrains.Monkeybrains.main(Monkeybrains.java:371)
usage: monkeyc [-a <arg>] [-b <arg>] [-c <arg>] [-d <arg>] [-e]
       [--Eno-invalid-symbol] [-f <arg>] [-g] [-h] [-i <arg>] [-k] [-l <arg>]
       [-m <arg>] [-o <arg>] [-p <arg>] [-r] [-s <arg>] [-t] [-u <arg>] [-v]
       [-w] [-x <arg>] [-y <arg>] [-z <arg>]
-a,--apidb <arg>       API import file
-b,--apimir <arg>      API MIR file
-c,--api-level <arg>   API Level to target
-d,--device <arg>      Target device
-e,--package-app       Create an application package.
   --Eno-invalid-symbolDo not error when a symbol is found to be invalid
-f,--jungles <arg>     Jungle files
-g,--debug             Print debug output
-h,--help              Prints help information
-i,--import-dbg <arg>  Import api.debug.xml
-k,--profile           Enable profiling support
-l,--typecheck <arg>   Type check [0=off, 1=gradual, 2=informative, 3=strict]
-m,--manifest <arg>    Manifest file (deprecated)
-o,--output <arg>      Output file to create
-p,--project-info <arg>projectInfo.xml file to use when compiling
-r,--release           Strip debug information
-s,--sdk-version <arg> SDK version to target (deprecated, use -c
-t,--unit-test         Enables compilation of unit tests
-u,--devices <arg>     devices.xml file to use when compiling (deprecated)
-v,--version           Prints the compiler version
-w,--warn              Show compiler warnings
-x,--excludes <arg>    Add annotations to the exclude list (deprecated)
-y,--private-key <arg> Private key to sign builds with
-z,--rez <arg>         Resource files (deprecated)

 *  The terminal process "C:\Program Files\Common Files\Oracle\Java\javapath\java.exe '-Xms1g', '-Dfile.encoding=UTF-8', '-Dapple.awt.UIElement=true', '-jar', 'c:\Users\brain\AppData\Roaming\Garmin\ConnectIQ\Sdks\connectiq-sdk-win-4.1.5-2022-08-03-6e17bf167\bin\monkeybrains.jar', '-o', 'bin\55watchface.prg', '-f', 'c:\Users\brain\OneDrive\Desktop\Tech\Garmin Watch SDK\55\55watchface\monkey.jungle', '-y', '', '-d', 'fr55_sim', '-w'" terminated with exit code: 100. 
 *  Terminal will be reused by tasks, press any key to close it.

Any tips please?

  • over 2 years ago in reply to FlowState

    I don't agree with "a time and place". On forums I think the CLI is king, because every action is copy/pasteable. You can run the commands and it just works (tm).

    Also, I do not know VSCode but I do know how to mass update files and contents. So I'm giving advice that I can give. It is generic enough to use without the use of any IDE. If the user cannot execute them because of $reasons than that's outside of my control. But I should be able to freely donate my .02

  • over 2 years ago in reply to waterkip

    On forums I think the CLI is king, because every action is copy/pasteable. You can run the commands and it just works (tm).

    Also, I do not know VSCode but I do know how to mass update files and contents. So I'm giving advice that I can give. It is generic enough to use without the use of any IDE. If the user cannot execute them because of $reasons than that's outside of my control. But I should be able to freely donate my .02

    I agree with all of this in principle (*), but on the flip side, if you specifically asked for help with something, I probably wouldn't respond with instructions on how to achieve your task in Windows and VS Code (knowing that you use neither), except with the disclaimer that it's generic advice and not specifically directed at you. Like I said, there's a bunch of assumptions that go along with that advice, and if it were me I would've listed them:

    - You're using Linux, WSL on Windows, Mac OS, or some *nix compatibility layer on Windows like cygwin

    - Your project files are source-controlled with git

    (*) I'm nearly 100% certain it wouldn't Just Work for OP though.

    I don't agree with "a time and place".

    Sorry, to be clear: I didn't mean that I don't think you should've posted your comment.

    I meant that for me personally, using the UI is sometimes faster than using the CLI, even though I use the CLI all the time. I think especially for users who aren't used to Linux and/or the command line, the UI is especially faster for one-off tasks.

  • over 2 years ago in reply to FlowState
    But I should be able to freely donate my .02

    For sure! My bad: your comment added to the discussion and my subsequent ones didn't.

  • over 2 years ago in reply to FlowState

    One other thing to note, is there are some things with CIQ which are just easier with Eclipse or VS Code.  I've used CLI with CIQ, and I find the tools in the IDE easier, even when it comes to the SdkManager for new SDKs and getting device updates.  Right now, switching between the production and beta SDKs for example.

    CLI takes me back to make files in the 70's and 80's.  I think it was the last in-person developer summit where someone kept rallying for make files instead of jungle Slight smile

  • over 2 years ago in reply to FlowState

    Fair enough, "this should do the trick as well" was a he, you don't need to recreate your project. I'll add a disclaimer: if you are not affraid of the CLI you, can as an alternative issue these commands, feel like a CLI god and fix your problems too. Hehehe :)

  • over 2 years ago in reply to jim_m_58

    the SDK manager is a horrid thing, it is a GUI around some API calls that can easily be done without the G in the UI.

    Truth be told I have a project to fully CLI the SDKmanager but I'm a bit reluctant to open source it because reasons. 

  • over 2 years ago in reply to waterkip

    You don't know what it was like back when devices were part of the SDK, and to support new devices, you had to wait for the next SDK update.  Or when you could only test app settings with Eclipse.  Eclipse/Vs code are what the majority of devs use.  And not many use git.

    Seems you want to re-invent things that Eclipse/VS Code already handles.

  • over 2 years ago

    I like your verbal or rather written duels :-)

  • over 2 years ago in reply to jim_m_58

    Well I have an itch that both Eclipse and VS Code can't scratch. My itch being: I don't use either. 

    I'll make an even more outrageous comment: If you don't use a VCS you are not a developer, but merely a script kiddie.

  • over 2 years ago in reply to waterkip
    waterkip said:
    Truth be told I have a project to fully CLI the SDKmanage

    :D

    waterkip said:
    but I'm a bit reluctant to open source it because reasons. 

    :/

    waterkip said:
    the SDK manager is a horrid thing, it is a GUI around some API calls that can easily be done without the G in the UI.

    Agreed. I actually hate the UI/UX of all the CIQ GUI tools (sdk manager, ERA viewer, monkeygraph). I still think that GUIs have their place, just like the CLI has its place.

    I say this as someone who spent years in the embedded space and where using the CLI was a must. And I still use the CLI quite often at work, every single day. I also use and write scripts all the time, in bash, perl (yep), python, node.js, etc. When I joined my current company, I wrote a lot of scripts to automate frequent tasks people had previously done using mind-numbingly repetitive UI actions. After doing the same 10-step process in the UI for the 20th time, I simply had enough. (This was something we had to do pretty much every day, in the course of development and testing.)

    That's really where scripts shine: when you want to automate stuff that's done over and over again in the UI.

    I will make the argument that for a noob CIQ dev who is not a pro or even hobbyist dev, the barrier for entry for using the command line is higher than using a UI.

    jim_m_58 said:
    CLI takes me back to make files in the 70's and 80's.  I think it was the last in-person developer summit where someone kept rallying for make files instead of jungle

    make/makefiles is a very old technology, but still used in linux and other open-source projects. May as well criticize Garmin Connect IQ for offering Windows batch files and bash shell scripts as part of the SDK.

    Of course make has been superseded by many different modern build systems, but it still has its place imo. To be fair, a new version hasn't been released since 2020.

    jim_m_58 said:
    And not many use git.

    Every professional dev -- who works at sought-after modern companies -- uses git. Devs who work at companies with an older mindset or companies that maybe only focus on Windows development still use *some* other form of source control, but git is by far the most popular.

    Perhaps you're only referring to CIQ developers, which is fair (but is hardly representative of the larger community.) See to me, the difference is that many CIQ developers seem to be completely new to development altogether. For someone like that, I agree the command line is intimidating and using the UI is almost always preferred. But at some point, you want to learn the command line so you can do some things more efficiently. UI = low barrier of entry, but is less flexible and sometimes less efficient. Command line = higher bar of entry, but much more flexible and sometimes more efficient.

    I'll say that I think your development mindset is stuck in the 90s / early 00s, with your conception of what counts as useful, modern or popular in today's *professional* development world.

    Again I will admit that trends come and go in development, but the key thing to notice is that when a trend returns, it's usually improved in one way or another (due to improved technology and lessons learned). This applies to things like the command line (terminals and command line tools have been modernized in many ways since the 70s and 80s).

    I've worked in and around a few startup-type environments in the past few years, and also watched industry trends. (This is after working a long time at a company which was frustratingly stuck in the past.)

    - git is the de facto source control system of choice for professional developers in 2022 (has been for a long time)

    - VS Code is "modern" in many ways that Eclipse is not (despite your arguments that VS Code is more like a 90s IDE.) It's far from perfect, but I'll take it over Eclipse any day.

    - People have moved on from Eclipse a long time ago (for example, many Java developers use IntelliJ)

    - In professional environments, it's very common to use command line tools such as npm, brew, bazel, mvn, git, curl, etc. and there's often no GUI alternative

    - Also in professional environments, when we require our own tooling for building and testing, these tools are often delivered in the form of...you guessed it...command line shell scripts

    - If you're developing in linux (e.g. embedded systems), you *have* to be able to use the command line.

    A long time ago I worked with a Windows IT administrator who had zero knowledge of even basic scripting or command line usage. He did everything in the GUI. His server "backup procedure" was to use Windows Explorer to copy the contents of the server hard drive to an external USB hard drive. Because the latest backup would be copied to the same place as the previous backup, Explorer would constantly prompt to replace files on the destination. Because multiple prompts would come up and they had to be dismissed manually, this procedure could take a day or two.

    At one point, my responsibilities as a dev slightly intersected with his as an admin (it was a small company), so I automated this process with a simple batch file which used the ancient Windows xcopy command. The new process took a fraction of the time (a couple of hours) and required no manual intervention.

    When I showed him what I had done, his first question was "Isn't there a GUI for this???" Like you, he thought that scripting and command line tools were relics of the past. Which is funny, because in 2022, professional devs use the command line more than ever. Windows literally gives you the ability to install Linux as a subsystem now, they've released a modern terminal app (which fixes a ton of problems in the decades old legacy console), and they've released a command-line package manager.

    So you tell me which paradigm is more primitive: the one that's flexible enough to get the job done quickly and efficiently, or the one that forces you to do things one way, takes forever and requires a ton of manual intervention.

    As an analogy, people have been trying to GUI-fy the entire process of software development for a long time, so far without success. (What I mean is literally replacing source code text files with some sort of GUI representation of code.) The only place this has actually succeeded is in toys and tutorials aimed at literal children.

    Again nothing wrong with GUIs (especially in the consumer/end-user space), but the command line is really the dev's best friend in 2022 IMO.

    waterkip said:
    I'll make an even more outrageous comment: If you don't use a VCS you are not a developer, but merely a script kiddie.

    Agreed.