partial script import

[benloh]

In GitLab by @jdanish on Apr 29, 2021, 06:16

[benloh]

I assume this means import one agent script from one project into another?

• UI for showing available agent scripts 2h
• Selecting and showing scripts from another project 1h
• Insert script into project data 1h

[benloh]

changed time estimate to 4h

[benloh]

In GitLab by @daveseah on Sep 19, 2021, 16:42

RAW NOTES ON PROBLEM SCOPE

Looking at #127 Partial Script Import, which QOL feature for researcher developers. The overarching goal is to make this system usable by grad students to make their own stuff, because ultimately we want a lot of people making stuff.

First step is to just get my head around the granularity of the data, and what might be import/exportable in whole or in part.

SYSTEM ELEMENTS

Using moths-sandbox as an example to start with, I see these elements:

• project:
  • bounds: topleft, bottomright rectangle in pixels, and bgcolor
  • scripts: [ blueprint, ... ]
  • instances: [ agent:{ blueprintname, initscript }, ... ]
  • rounds: [ round_def, ... ]
  • round_def: duration, intro/outro text, intro/end setup script
• initscripts for rounds( context: simulation of many agents )
  • initScript: scriptText to set up certain things before the round starts
  • endScript: scriptText to asses simulation, possibly cleanup
• initscripts for instances (context: an agent instance)
  • initScript: scriptText to set properties of the agent instance

There's other kind of data that I don't see directly represented in here, but probably exist somewhere else:

• organization context:
  • the id of my installation
  • the id of my class, at the installation
  • the id of my group, in the class
  • my user id, in the class
• asset references
  • these are referred to in the various scripts so they are bound to the project level, possibly as url to the right asset path. each project relies on a particular asset directory path

KINDS OF IMPORT/EXPORT

1. The QOL issue is that there's no automated way to get it out of there the ScriptEditor and into Visual Studio Code (and vice versa). I think this is manually doable with just careful cut/paste, but

2. The ultimate use case for import/export is, if I read between the lines, is being able to assemble projects by picking bits from other projects. The most rudimentary version of this is being able to support copy/paste of folders in a filesystem, but since our projects are now inside of a database this isn't easy to do (hence the need for import/export).

3. Specifically we might want to move these types of data between projects:

   • move entire blueprints between projects (they may have asset dependencies differences that would have to be merged)

4. And move chunks between blueprints

   • entire when and every clauses that do cool things, but they have blueprint context dependencies in the form of blueprint names. They also have GFEATURE dependencies and GPROP declarations that may differ between source and destination blueprint.

[benloh]

In GitLab by @daveseah on Sep 19, 2021, 17:15

Looking at the old estimate at the top of this issue:

• UI for showing available agent scripts 2h
• Selecting and showing scripts from another project 1h
• Insert script into project data 1h

I think the actual input/output work could be better handled once there is a GUI for selecting selectable projects on the database to launch, if this is a planned feature that's part of Round 3 Full. I don't see it listed though.

So putting that aside for now:

(option 1) I could write routines that minimally queries the database and produces an export format based on the current MODEL data structure. The GraphQL interface may already be able to spit it out, so I should have a look at the way GraphQL is currently being used to load projects.

The GUI might be pretty basic...the MAIN APP has all the project data in it, and is set to a specific project at any given time. A simple import GUI would itemize all the keys and ask you which ones to import. However, this is probably not really what you want, because users have no way to preview what it does and for this to work we also need to add more robust script error detection for missing assets or mispelled names.

(option 2) When talking about this, Ben suggested making the export command creates a folder somewhere that has the file-based version of everything inside of the database, and if this folder exists it's the one that actually is used. This gives us the ability to edit it "live" in visual studio code, and have a way to bring it back into the database with an import command. The term might be "sync local project folder" rather than "import".

Either version has some possible gotchyas, and I don't think we get away from having to implement a better script editor experience to catch errors in a way developers expect.

[benloh]

In GitLab by @daveseah on Sep 19, 2021, 17:29

A lot of the above touches on #119 also, so I'm taking a quick read of it.

[benloh]

In GitLab by @jdanish on Sep 20, 2021, 06:00

Just wanted to clarify a few things:

1. There are really only 2 benefits to using studio code right now:

• a. see all of the methods / characters in one place
• b. don't save / make public until something is working

With respect to a, I think a better solution than import / export would be to just have a button that let's us see the whole thing in script viewer. If that were possible. Assuming we are getting import / export anyhow, then this is really low priority despite being potentially useful.

With respect to b, I think Ben brought this up in his thread (my next step). However, I'd say that it's not a huge issue since we can do that local editing using a local install / app if we have import / export so that we can make changes until happy locally, then export and import to classroom server.

2. A key QoL issue is sharing code across installations, even more than the other reasons. It's quite common that one or more of us are developing locally on our laptop, and then need to run classroom implementations on a different machine. This includes having at least two separate locations currently (IU and VU) and may at some point include having multiple classrooms at each location where those classrooms are running different versions or are at different points in time. This is where being able to easily share projects that are ready becomes really key. I am currently updating aquatic and decomposition, Corey is updating moths, and Morgan might be working on bees. For each of us to share our code with the 3 other sites requires either that a) we use GitHub (less convenient with the data base model) or ideally, b) just be able to send stuff over email. The careful copy and paste approach would take an absurd amount of time. Also note, it is dependent on things like being able to create characters that are not yet possible. This was also a huge hassle in MEME lately (one of the reasons I am focused on it) where we would test ideas on my DO server, but then want a clean server with just the one project kids should see, and basically have to re-create it by hand because there was no way to copy part without the rest. Trying to avoid that here.

3. Our hope is that grad students will use the app / editor to build new models / templates, not Studio Code. Only a few have the experience with script to use Studio Code anyhow, so we sort of don't have a choice on this.

[benloh]

In GitLab by @daveseah on Sep 20, 2021, 08:09

Thanks for the clarification, especially of the use cases that are most important to you! I only found out you were all using Visual Studio Code for editing a few days ago, so I didn't have a clear picture of what it's been like.

[benloh]

In GitLab by @daveseah on Sep 20, 2021, 08:48

Reframing IMPORT/EXPORT context

• Easily consolidating multiple projects (e.g "moths", "decomposition") that are frequently updated from different authors and machines.
• Also move multiple projects from installation to installation easily.
• Minimum tool

Review of current storage (ben, correct me if this is not correct)

• a project corresponds to "moths", "bees", "decomposition"
• projects are stored as project documents in the database, each containing bounds, scripts, instances, and rounds objects.
• historical note: projects used to be stored as the .js files like moths-sandbox.js because of the convenience of using template strings (allowing multiline string declarations for use in blueprints) and (maybe) livereload convenience to see changes.

Minimum tech support is adding project document import/export to the server, then providing hooks so a GUI can make use of it. To test hooks and serve immediate needs, implement as a command line tool to support commands that look like:

import "project" < file    # imports a named project from the export file
import -a < file           # import all projects
list                       # shows a list of projects in the database
export "project" > file    # dumps project to export file
export > file              # dumps all projects to export file

• Ideally the file format can be edited in Visual Studio Code for touch-ups before imports.
• scope creep extra: being able to load a project from the export file instead of the database on startup, and livereload based on changes to it

[benloh]

In GitLab by @jdanish on Sep 20, 2021, 09:35

Cool. I was mostly using it since you all had starting using it, and now it's just my code editor of choice, but ... happy to edit elsewhere as needed or as formatting is supported :)

[benloh]

@jdanish Can you say more about what you're thinking with

a button that let's us see the whole thing in script viewer

Are you thinking you'd be able to view and edit the raw JSON of the whole project (e.g. similar to how you're editing aquatic.js in VSC? Or are you wanting a single view that just lists all the components of the project, e.g. the names of all the blueprints and instances?

[benloh]

In GitLab by @jdanish on Sep 20, 2021, 11:26

Right now, the main reason I prefer using an external app such as Studio Code over gem-step is that in studio code I can see and edit all of the things at once. Often I need to glance at both the algae and the fish to make major changes. So if we had a script editor view that let us edit everything instead of just the algae or just the fish, that’d remove that benefit of studio code.

For kids using the wizard I think it’s fine to keep what we have for now.

I suppose an alternative might be to be able to easily switch between characters within the project in the script editor such as a drop down to change from fish to algae?

[benloh]

In GitLab by @daveseah on Sep 20, 2021, 12:34

that's great that you've adopted VSC as a code editor of choice...that snuck on me too when I started using it (somewhat reluctantly) because SublimeText wasn't being updated and all the cool kids were using VSC.

To now, I naively thought you were all using the ScriptEditor panel to edit code, forgetting that it didn't actually save scripts/synchronize in a developer-friendly way.

[benloh]

You could always open two Script Editors. Though it does take up a lot of room.

The other worry I have is that the ScriptEditor was never meant to be a full fledged editor, certainly not something that kids would use. It was only meant to be a placeholder while we work on the script UI, and we threw in the codejar editor because it was a convenient library to use. If you've spent time with it, you'll notice that the behavior can be a little quirky. And while the syntax coloring is nice, it doesn't have other text editor niceties like indent support and autoindent. It's fine for tweaking a value here and there, but I find for serious development it's a pain.

I think for now it makes sense to retain the ability to edit the whole project in an outside text editor and keep the script editor for minor in-app changes, and not worry about a full project view, unless you feel it's really important.

We have some other discussion about the workflow in #119.

[benloh]

In GitLab by @jdanish on Sep 20, 2021, 15:19

Sounds good!

...

---- (from my iPhone) Joshua Danish http://www.joshuadanish.com > On Sep 20, 2021, at 6:18 PM, Ben Loh (@benloh) wrote: > >  > Ben Loh commented on a discussion: > > You could always open two Script Editors. Though it does take up a lot of room. > > The other worry I have is that the ScriptEditor was never meant to be a full fledged editor, certainly not something that kids would use. It was only meant to be a placeholder while we work on the script UI, and we threw in the codejar editor because it was a convenient library to use. If you've spent time with it, you'll notice that the behavior can be a little quirky. And while the syntax coloring is nice, it doesn't have other text editor niceties like indent support and autoindent. It's fine for tweaking a value here and there, but I find for serious development it's a pain. > > I think for now it makes sense to retain the ability to edit the whole project in an outside text editor and keep the script editor for minor in-app changes, and not worry about a full project view, unless you feel it's really important. > > We have some other discussion about the workflow in #119. > > — > Reply to this email directly or view it on GitLab. > You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings.

[benloh]

marked this issue as related to #119

[benloh]

Closing this for now.

Character import can be handled via copy and paste in Script Editor or with project files.

Any more sophisticated solution would require a lot more UI work -- e.g. how do you display source characters and the current project at the same time?