[Feature Request] Decouple the GUI and the interpreter

[KDr2]

As said in the title, could we provide a script mode that has nothing to do with the turtle and the GUI, just run a script file like what load does?

ucblogo --script file.lg

So we can use it on a box without a GUI system (like *NIX without X).

Thank you.

[dmalec]

This might not be exactly what you're looking for; but, I thought it might be close enough to be worth mentioning. If you build the latest release (6.2.1) on a *NIX system without a GUI, it should be possible to just run a script file that doesn't contain any turtle commands by passing it as a command line argument:

ucblogo file.lg

And you should be able to pass in command line arguments to the logo script by using a single hyphen - and then the arguments (which will be available in :COMMAND.LINE):

ucblogo file.lg - arg1 arg2

More Details

Concretely, if I set up a Linux VM using a Vagrantfile like so:

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/bionic64"

  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get upgrade -y

    apt-get -y install build-essential \
                       autoconf \
                       automake \
                       libtool \
                       texinfo \
                       texlive
  SHELL
end

Then vagrant up, vagrant ssh, and do the following:

$ wget https://github.com/jrincayc/ucblogo-code/releases/download/version_6.2.1/ucblogo-6.2.1.tar.gz
$ tar -zxf ucblogo-6.2.1.tar.gz
$ cd ucblogo-6.2.1
$ ./configure
$ make
$ sudo make install

I can create a file hello_world.lg with the following:

PRINT [Hello World]
BYE

And run it like so:

vagrant@vagrant:~/ucblogo-6.2.1$ ucblogo hello_world.lg 
Hello World
vagrant@vagrant:~/ucblogo-6.2.1$ 

For passing arguments, I can modify hello_world.lg to the following:

PRINT (SENTENCE "Hello :COMMAND.LINE)
BYE

And run it like so:

vagrant@vagrant:~/ucblogo-6.2.1$ ucblogo hello_world.lg - Linux
Hello Linux
vagrant@vagrant:~/ucblogo-6.2.1$

[brianharvey]

... and if you start a text file with

!/usr/local/bin/logo foo.lg

(or wherever you put the executable file) that'll give you a shell-runnable executable Logo program.

[KDr2]

Oh, Thank you @dmalec, so for now, instead of using a --script-like option, I can install two versions of UCBLogo, one with GUI and one without GUI, then use them respectively according to my intention.

[KDr2]

... and if you start a text file with

!/usr/local/bin/logo foo.lg

(or wherever you put the executable file) that'll give you a shell-runnable executable Logo program.

This should use a no-GUI logo installation if I don't have X on my box :)

[dmalec]

You're welcome @KDr2, no worries :). That's essentially how I have my dev setup running - one checkout configured for wxWidgets GUI builds and one for non-GUI builds.

[KDr2]

Furthermore, if we already had a configuring option for turning the GUI on or off, is it hard to make it a runtime option?

[dmalec]

It's an interesting idea and I think it resonates with people. This broad idea was mentioned in a comment on another, now closed, issue regarding getting script loading working in the GUI version: https://github.com/jrincayc/ucblogo-code/issues/36#issuecomment-631168863

There are a few challenges I can see:

wxWidgets side

I looked at documentation for wxWidgets and had a hard time finding anything about dynamically deciding whether to open a GUI or run as a console application. It seems like wxWidgets is fairly opinionated about wanting to own the application lifecycle and applications having some amount of GUI.

That said, I'm still learning how the wxWidgets lifecycle and framework work, so I may be incorrect in my core understanding.

(EDIT: I may have spoken too soon, this looks like something worth digging into: https://docs.wxwidgets.org/3.0/classwx_app_console.html)

ucblogo side

Earlier versions of ucblogo were built on a variety of different platforms with very different libraries/calls available. So, the config option is removing all code not relevant to the target platform prior to compiling (since the other platforms' code would not be able to compile). The way the GUI mode is toggled on and off via config is in line with that model. I tend to mentally model wxWidgets as a being a full virtual platform that happens to be capable of compiling and running in a number of different environments (not saying this is technically accurate; but, it's my "just so story" when I navigate the code).

That said, I think there are ways code could be refactored to handle this type of GUI/non-GUI mode, just setting expectations that my personal estimate here is that it's not a simple change.

All of the above said, I'm curious what others think - if there's additional challenges here or if the two above have straightforward solutions :)