Implementation Discussion Thread: CLI

[Gaelan]

Here's a thread to discuss the implementation of the CLI, which will be a command-line wrapper around the client core. It will be the main UI for this until the GUI is implemented. Questions we need answered before we can start work on this:

• [ ] What technologies will be used to implement this?
• [ ] Can these technologies work with a small memory footprint?
• [ ] How hard is it to port a tool written with these technologies across OS X, Linux, and Windows?
• [ ] Are these technologies compatible with the interface provided by the Client Core?
• [ ] Who will work on this?

[MaPePeR]

Small memory footprint, easy to port and good on CLI? The only thing I can think of is C, because it does not come with an interpreter like Python/Java or a giant executable like Go.

[Gaelan]

Yeah, a systems language (C family, Rust) seems like probably the best option. Note that this decision is related to #2, as the CLI will need to talk to that library. Also, we will eventually want a GUI, so our technology decision should factor in support for GUI frameworks as well. We certainly can't go wrong with C, though Rust might be easier to work with. Downside: newer.

[rchard2scout]

The CLI should probably be a simple wrapper for the library (the same way most *nix commands have an equivalent system call). That means it'd probably be easiest to write it in the same language as the core. If we're using a C family language, portability will be harder. We could use Java (or another language that compiles to JVM bytecode, like Scala), which will be easier for portability, but slower.

[MaPePeR]

Besides shipping multiple binaries I don't see much problems with portability when writing in C.

At least not when writing a CLI. (except for some simple rules when dealing with file paths)

[rchard2scout]

For the CLI, maybe not that much. For the core library, it'll be a bit harder, because that'll have to deal with stuff like networking and multithreading. I've used a Microsoft API in the past, and it's quite complicated (granted, that was DirectX 9, but I can't image the Win32 API being much easier). We could write the core in Java and use the JNI (which I just learned about existed, and which sounds interesting), but that might be overcomplicating things.

[Gaelan]

I think the client should not be written in Java, unless we can get it to run with less than a few hundred megabytes (I have found that often I want to close the launcher when running a big pack on my 4GB laptop to save memory). C, C++ and Rust seem like the viable options. C has the advantage being callable from pretty much anything, letting us do native UIs. I'm not sure how good Rust's C interface is; I know there is a library for Cocoa, not sure about Win32 and Qt/Gtk.

[shadowfacts]

C is a good candidate for performance/low overhead and cross-platform compatibility. andlabs/libui is good for cross-platform native UI, but I"m not sure how viable it is to use for the MC launching portion of it

[Gaelan]

MC launching is just automatically assembling all the command line arguments to Java/MC, then running the command. Definitely doable from C.

[MaPePeR]

For the most stuff you can use posix. Even networking with C on Windows is very easy to do cross platform.

We could write the core in Java and use the JNI

That is a horrible idea. We should stick to one language and not create a monstrosity that uses n different programming languages.

[Turmfalke2]

I feel like java would be good idea, everyone needs it for minecraft anyway. Also is there any reason why the launcher should continue running once minecraft is launched? Surely we don't need the launcher just to fancy up stdout and stderr.

[gjgfuj]

Some log program is definitely important. But don't use java, it's horribly inefficient. Use a natively compiled language.

On Fri, 27 May 2016, 9:44 PM Turmfalke2 notifications@github.com wrote:

I feel like java would be good idea, everyone needs it for minecraft anyway. Also is there any reason why the launcher should continue running once minecraft is launched? Surely we don't need the launcher just to fancy up stdout and stderr.

— You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub https://github.com/MCModMachine/Design/issues/3#issuecomment-222126242, or mute the thread https://github.com/notifications/unsubscribe/AC1W3CzCch45qfTKR9Rh_SSafdOATTNpks5qFtkOgaJpZM4Idqt_ .

[acun1994]

As long as some form of the console is visible, that should be enough. Assuming the Vanilla launcher is used like in Curse, then there's no reason to leave this launcher open

[gjgfuj]

Of course, that's true. I would be more for "drop into very minimal mode until subprocess closes then start again" so I wouldn't have to launch the program again if it crashes.

Also please don't only use the vanilla launcher it's slow, unoptimized garbage, but that's just my thoughts.

On Fri, 27 May 2016, 9:46 PM Alvin Soo notifications@github.com wrote:

As long as some form of the console is visible, that should be enough. Assuming the Vanilla launcher is used like in Curse, then there's no reason to leave this launcher open

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/MCModMachine/Design/issues/3#issuecomment-222126698, or mute the thread https://github.com/notifications/unsubscribe/AC1W3FhtNdzaC7Que8EKv1m8d1WEP1K0ks5qFtmxgaJpZM4Idqt_ .

[Turmfalke2]

Why do we need to any additional logging while minecraft is running, what would you log? Just redirect the output to file and if someone wants to look at it he can open it.

[acun1994]

To get a progress report on what the launcher is actually doing.

However, you have a point, since recent forge versions have that displayed on the main loading screen...

[Gaelan]

We will probably support both a native launcher and exporting to the vanilla or MMC launchers. If we are using the native launcher, I think displaying logs is vital. That can be done without hogging memory.

[Turmfalke2]

What is the appeal behind exporting to other launchers? Isn't this one supposed to be better? What does the vanilla launcher provides that we can't? I have never used it.

[Gaelan]

Some people (understandably) don't want to give us their Mojang account. Also MMC does have some very nice features.

[gjgfuj]

Multimc has nice features like not being incredibly laggy like every single other launcher. Also, you need real-time logs because the forge loading screen is often not enough imo. (Like if a mod has a lot to load that mod'll probably print), and it allows one to spot errors or mistakes while it's launching rather than reading a massive file at the end.

On Sat, 28 May 2016, 12:45 AM Gaelan notifications@github.com wrote:

Some people (understandably) don't want to give us their Mojang account. Also MMC does have some very nice features.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MCModMachine/Design/issues/3#issuecomment-222165316, or mute the thread https://github.com/notifications/unsubscribe/AC1W3JaEdQPdPaTCPhFDNKyFBVFYgOBaks5qFwNvgaJpZM4Idqt_ .

[MaPePeR]

Writing a good log viewer is hard.

We should not do it like ATLauncher, that is proven to drop messages from the log, when there is a lot of stuff logged at once.

Also rendering the log should not have a huge cpu impact. (When they fixed the dropping of messages the launcher became unusable, because it consumed too much cpu rendering the log messages, so it was reverted)

Mojang is working on improving the launcher especially the logging. And from the looks of it I think they might have addressed these issues properly. (there were screen shots on Twitter that showed the log of FTB Infinity)

[Turmfalke2]

watch tail

I am pretty sure nothing we can write is going to have less performance impact.

[Ameliorate]

I'd like to add my support for writing in rust. I personally write most of my current stuff in rust, and know a lot about the language. To address some concerns brought up in this thread:

• C interfacing is very good. This link contains an example of running C from rust. The FFI page of the Rust Book has everything else about C interfacing, however most of it isn't needed for day-to-day use of rust. Almost any C library you can find already has a safe rust wrapper already made, either already in the standard library or on crates.io.
• The rust standard library also has usable APIs for networking, files, and anything else a launcher might need. The only thing missing is GUI, and a good number of crates exist that provide this functionality.
• Rust also requires that for an API to be added to their standard library that it work on all Tier 1 platforms. This makes porting as simple as compiling the code on the desired platform or using a cross-compiler

[Gaelan]

@Ameliorate Rust is definitely my first choice as well.