trygve command line arguments and GUI

[Andreas Söderlund]

I'd like to make some suggestions to the trygve project that may make things more convenient for programmers, which may not be the primary target audience for trygve, but I will try to explain why I still think it's worthwhile (and others won't notice any difference anyway).

First, a huge thanks to Cope for the work on trygve, and especially relevant to this post, its GUI. It's never easy to make, and in a verbose language such as Java, it takes plenty of time.

Unfortunately, as a programmer, it's hard not to compare the GUI and its editor, to the ones you use in your daily work, such as VS Code. Though it will take lifetimes to forgive Microsoft for the years of pain caused by their OS and everything around it, they have at least started treading the road to penance by making an excellent editor, available for free as open source, and on most platforms. I can't ask for much more in an editor, so compared to that, the trygve GUI feels a bit limiting. It's not a fair comparison of course, but the fact remains that I miss syntax highlighting, multi-line editing, its nice debugging interface, search/replace, remembering last window position, the list goes on.

But when starting trygve, I saw a glimmer of hope. There were command-line options that, after some experimentation, seemed to be able to run in headless mode, acting as a compiler and VM without GUI:

> trygve -c examples/helloworld.k -r

Compilation complete
0 errors
Hello world!!!

This is basically all that's needed to use VS Code for editing and testing trygve programs, at least those with only console output, because when you start something with more advanced graphical usage:

> trygve -c examples/breakout.k -r

Compilation complete
0 errors
line 0: FATAL: Bad call to Frame (1) constructor.

[...errors...]

After communicating with Cope, I found out that the -r flag is used to run scripts unattended, signaling safety to use in scripts. Hard to know, I thought it meant just "run what you've just compiled". :) And not very safe either way, since the script crashed, making the script writer responsible that no graphics are used.

But before finding out more about -r, my eagerness had taken me to figuring out why it didn't work in the first place. I actually hacked together a way to make it work. Not pretty, relying on creating a hidden GUI, triggering events on it. Couldn't find a way to make it work programmatically. But the biggest question was (and still is) how to know if a script wants to use the GUI, calling the underlying graphical framework only when it's really needed.

It would be nice to run a feat like this breakout game (kudos to Egon Elbre) directly from command line, because that code is advanced enough to really make me long for VS Code... The breakout game shows that we will reach that level of code complexity, so a more polished editor is pretty much a necessity when you're stepping up from the simplest of examples.

Therefore, finally, I'd like to suggest some updated command line options, with functionality:

trygve -c file.k 

No change, compile a file and report eventual errors, exiting with 0 or 1 depending. Useful for live reload, as the editor can keep track of errors.

trygve -c file.k -r

Compile a file, and if no errors, run the file like any program, without compilation notices like "0 errors, compilation complete", just its output. If errors, it reports them and exits with 1.

As said, I'd also like it to detect when a graphical component (a Frame class) is used, and open it up as a new window. I suspect this is the most difficult thing, since I've hacked together everything else, and polishing it up is trivial. I hope it will be doable. Note: Stdout/stderr will still be outputted to the terminal.

trygve -c file.k -r -t

Adding -t puts the script in text mode, making it script-safe by preventing any graphics output. 

I don't think it should be the default when using -r, since protecting the programmer in this case is dubious. When I'm working on a script that uses graphics, I'd like to be certain that it works, nothing should be suppressed, as will happen when using -t. Actually, when is it useful to run a script containing graphics, that should only output to stdout/err? Wouldn't a separate script be better and simpler?

The next big thing, if this sounds good, would be to implement the Debug adapter protocol, enabling trygve to communicate with external debuggers, making it possible to not only write, but also debug code directly in VS Code. That would be simply awesome, but maybe just food for thought for now. I welcome your thoughts on all of this.

/Andreas

[James O Coplien]

Hej, all,

On 26 Sep 2022, at 09.12, Andreas Söderlund <gaz...@gmail.com> wrote:

After communicating with Cope, I found out that the -r flag is used to run scripts unattended, signaling safety to use in scripts. Hard to know, I thought it meant just "run what you've just compiled". :) And not very safe either way, since the script crashed, making the script writer responsible that no graphics are used.

If that is the problem to be solved, it’s easy to make the code give an error message if there is an attempt to use GUI primitives in an environment without a GUI. Clean, small, direct, reasonable, informative.

But before finding out more about -r, my eagerness had taken me to figuring out why it didn't work in the first place. I actually hacked together a way to make it work. Not pretty, relying on creating a hidden GUI, triggering events on it. Couldn't find a way to make it work programmatically. But the biggest question was (and still is) how to know if a script wants to use the GUI, calling the underlying graphical framework only when it's really needed.

I don’t understand why this is an important change in line with our goal better to understand DCI. I don’t think anyone is asking for it and I can’t think of any real world use case that begs this kind of change.

There are other reasons not to do this, such as the fact that it lacks parallelism in the way it treats input and output (will you do the same for single-character input? what will you provide as results for its touch location coordinates after instantiating the GUI?). And there are more embarrassing questions. Let’s say you are writing to System.out throughout the program. Somewhere in the middle of the program, it invokes a Frame primitive. Does subsequent text output go to the IDE so that half of the text output is in the original output stream associated with the batch indication, and the other half is on the GUI? Or do you keep System.out tied to the original? If so, the program will run differently (with respect to text output) for the two different modes of execution.

My key concern and underlying principle here is that I don’t want to load up trygve with bells and whistles that add to the code mass — and documentation, and cognitive load on the users — without adding to our ability to further the main work to be done (e.g., there are five or so additional issue reports that need attention.) Changes should be major enabling levers. There is no end to the things we can add that allow a Windows user to start up a program by pressing F5 instead of typing gradle run. I would prefer to keep it clean and minimal.

I also have difficult believing that a better text editor will make any measurable difference in peoples’s ability to use the current IDE, let alone make any difference in our progress at understanding the difficult issues. I am also concerned about what current features we would have to abandon in such an approach (such as context highlighting when a breakpoint fires). And speaking from an architectural perspective I think we need a multi-module management strategy before changing the interface that edits those modules (e.g., a design that supports multiple open edit windows). There is a potentially large maintenance cost in pulling in VS and a whole Microsoft empire that has hitherto been unnecessary, and that raises the bar of the learning curve for the potential population we hope to help evolve the concepts, for whatever sake. Maybe it is worth it, but I am not sure we have had enough discussion about the costs.

And none of these would be high on my list.

The recent resurrection of the code is a great thing, and I’m grateful for that, and some of the subsequent edits (like reducing the .jar footprint) are worthwhile. I appreciate Andreas on this round, and others on other rounds of changes, for adding value with their volunteer time. I don’t think these add value in nearly the same way.

[Andreas Söderlund]

After communicating with Cope, I found out that the -r flag is used to run scripts unattended, signaling safety to use in scripts. Hard to know, I thought it meant just "run what you've just compiled". :) And not very safe either way, since the script crashed, making the script writer responsible that no graphics are used.

If that is the problem to be solved, it’s easy to make the code give an error message if there is an attempt to use GUI primitives in an environment without a GUI. Clean, small, direct, reasonable, informative.

With "an environment without a GUI", you mean when redirecting input/output, or using a text console? The terminal I'm using on windows is capable of handling a GUI, shown by trygve -gui. But when doing trygve -c breakout.k -r in the same terminal, it doesn't work currently, though the only difference is that the breakout Frame class should be displayed instead of the trygve GUI. So maybe we're just talking about a bug here?

 

There are other reasons not to do this, such as the fact that it lacks parallelism in the way it treats input and output (will you do the same for single-character input? what will you provide as results for its touch location coordinates after instantiating the GUI?). And there are more embarrassing questions. Let’s say you are writing to System.out throughout the program. Somewhere in the middle of the program, it invokes a Frame primitive. Does subsequent text output go to the IDE so that half of the text output is in the original output stream associated with the batch indication, and the other half is on the GUI? Or do you keep System.out tied to the original? If so, the program will run differently (with respect to text output) for the two different modes of execution.

If you start with -gui, System.out and err should be displayed in the GUI, otherwise, in the terminal that executed the command. Invoking a user-created Frame should be possible without the trygve GUI being instantiated. They have the same base class.

 

My key concern and underlying principle here is that I don’t want to load up trygve with bells and whistles that add to the code mass — and documentation, and cognitive load on the users — without adding to our ability to further the main work to be done (e.g., there are five or so additional issue reports that need attention.) Changes should be major enabling levers. There is no end to the things we can add that allow a Windows user to start up a program by pressing F5 instead of typing gradle run. I would prefer to keep it clean and minimal.

Having two extra files in the source code of the project, that only very interested, highly skilled programmers will ever come into contact with, that will make their endeavour a bit easier, can't hurt much. There are no bells, no documentation, no cognitive load. 

There are configuration files for IDEA present currently, should they be removed then?

 

I also have difficult believing that a better text editor will make any measurable difference in peoples’s ability to use the current IDE, let alone make any difference in our progress at understanding the difficult issues. I am also concerned about what current features we would have to abandon in such an approach (such as context highlighting when a breakpoint fires). And speaking from an architectural perspective I think we need a multi-module management strategy before changing the interface that edits those modules (e.g., a design that supports multiple open edit windows). There is a potentially large maintenance cost in pulling in VS and a whole Microsoft empire that has hitherto been unnecessary, and that raises the bar of the learning curve for the potential population we hope to help evolve the concepts, for whatever sake. Maybe it is worth it, but I am not sure we have had enough discussion about the costs.

I'd like to know what could make a big difference, then. I know that people can get used to almost anything, which means that resizing the GUI every time you start it up, is it to be considered a minor annoyance, at worst?

It's a tough crowd out there, which practically no reason to take DCI into consideration. Given how many programmers are eager to jump onto every new hype train says something more than just hype - they are looking for something that will make their lives easier. DCI can do that, I know for sure. But it needs a few bells and whistles, those are the times we live in. The crowd will grow out of a bank transfer example quickly, and will ask for more. But when they are forced to use a toy-like GUI instead of their own tools, and can't run a cool breakout game without jumping through hoops... they will move on, I'm afraid.

[James O Coplien]

Andreas,

On 26 Sep 2022, at 12.10, Andreas Söderlund <gaz...@gmail.com> wrote:

I'd like to know what could make a big difference, then.

Generating code for the JVM, and interoperability with Java libraries, and perhaps with native Java class instance objects as Role-players.

Adding interface management and separation of modules to the language (which is largely an IDE change; this then creates a need for a multi-window editor).

Evolving the language and environment for CLR compatability and linkage.

Port the entire IDE to an Apple watch so you can create trygve apps there.

Add debugging commands to examine named instances in a qualified dynamic scope (adding facilities for a protocol to an external debugger won*t help you at all until you do the basic stuff like this first, anyhow — why propose interfacing to an external debugger if you know this needs to be done first?)

…

Do you see how these are not in the same class as:"To make it easier to debug and build in VS Code. Makes it possible to debug just by pressing F5, and build with gradle using Ctrl+Shift+B”?

[Andreas Söderlund]

Does it matter if they aren't in the same class? I thought small improvements was a thing here, Kaizen. If I will do even one of these improvements, I must debug hundreds of times, but if I can't do that without switching context and typing a string into the terminal, compared to pressing a single key, that is wasting too much time.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/7FA58410-BAD4-4440-8896-AAD4FC4C6613%40gmail.com.

[James O Coplien]

On 26 Sep 2022, at 13.11, Andreas Söderlund <gaz...@gmail.com> wrote:

Does it matter if they aren't in the same class? I thought small improvements was a thing here, Kaizen. If I will do even one of these improvements, I must debug hundreds of times, but if I can't do that without switching context and typing a string into the terminal, compared to pressing a single key, that is wasting too much time.

You would be right were these changes free, and free of consequences.

They are not.

Common sense says we build up a little at a time.

You say: “Let’s hook up to an external debugger!”

I say: “Let’s put something in the environment so the debugger can do any work at all.”

Common sense also says to deliver value with regard to “pull,” rather than “push.” The environment was created as a minimal proof-of-concept research environment.

Your concerns and wishes seemed to be tied to application — that is, it seems to be the applied “pull." If we want to make this into an application, adding VS or doing builds with  Ctrl+Shift+Ctrl+Shift+B aren’t the path to get us there, even as much as one waves the kaizen flag.

These feel like solutions in search of a problem. I’m happy with that if there is a research question at stake, but I don’t understand what research questions these address. These changes have risks and drawbacks.

Maybe we should decide what problem we’re trying to solve.

[Andreas Söderlund]

You would be right were these changes free, and free of consequences.

They are not.

Common sense says we build up a little at a time.

You say: “Let’s hook up to an external debugger!”

I say: “Let’s put something in the environment so the debugger can do any work at all.”

No, no, hooking up a debugger was food for thought. The files I want to add in the PR doesn't change anything, it's not "adding VS" or anything, there are no consequences for anyone except making it a bit simpler for apparently the only one that wants to help you on this project. Is that really too much to ask?

 

Maybe we should decide what problem we’re trying to solve.

I'd like that, but I can't even begin to solve any problems when I can't even debug the project.

[Matthew Browne]

I think the adding the VS Code config is a great idea. Isn't the whole point of the trygve project to make the language easy to play around with so you can easily try it out and also do research projects? VS Code is massively popular; everyone I know is now using it for something or other. I don't think this is about trying to make it into an environment to build production-ready apps - not at all. It's just about making it easy to get started, and I think Andreas's contributions in that area should be welcomed.

On some of the other points, perhaps there are certain bells and whistles that are too much, not worth the maintenance, etc. given that this is a research language. But I literally don't see any downside to adding a simple IDE config file for VS Code, only a significant benefit.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/CAA%3DT-6TcqvKsBNfKTcFPd_MCb20NBbdnPt9%2Bq_zynx0qSpwSMA%40mail.gmail.com.

[Lund Soltoft]

I see two different concerns. 

- Research

- Application development

trygve is meant for the former and I think we would get more traction if we could provide tooling for the latter as well. Where we could adopt the tooling based on the learnings from the research. I have a working proof of concept that shows that true DCI can be supported on dotnet. To make it full fletched requires substantial work, which is the reason why I haven't proceeded any longer than the proof of concept. The major part of the work is a decompiler from CIL to ExpressionTrees. There are some ground works that could likely be used as a starting point. The decompiler of JustDecompile is open source.

If we created the tooling for C# (the decompilation is language specific eg an C# if-statement is compiled differently than an F# if-expression), we would gain IDE support with all bells and whistles and baking it into an existing language would also make adoption easier. However, the likelihood of me ever finishing that work is close to zero

but I do see some merit in having a tool for research and one for "production"

/Rune

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/2ae818db-8ff6-4917-a433-263dfe7f2531n%40googlegroups.com.

[James O Coplien]

All,

On 28 Sep 2022, at 03.49, Matthew Browne <mbro...@gmail.com> wrote:

I think the adding the VS Code config is a great idea. Isn't the whole point of the trygve project to make the language easy to play around with so you can easily try it out and also do research projects? VS Code is massively popular;

Hardly anyone has been screaming for it. We have exactly one user who has ever mentioned it — as many as want XCode.

everyone I know is now using it for something or other.

Amazing claim. You may be right as regards the Microsoft world. But I count myself among the people you know, and I certainly am not using it.

Trygve is a research platform, and platforms should be technology-neutral. The platform contains everything necessary to configure it for Windows. Maybe, if people want local scripts to customize for their own platform, so be it. 

VS does not come packaged on my Mac. We currently ask trygve users to download gradle (which also does not come on my Mac); that’s bad enough. Now the trygve platform has another external dependency. The fact that I may or may not satisfy that dependency is just another decision I must make to get trygve up and running.

Adding decisions is not a simplification. It already has made the README file larger, more complicated, and frankly, wrong. It says:

VS Code is a very accessible way to develop trygve. Installation instructions are available here.

For other environments, import this repository as a Gradle project into your IDE. (Or as a regular project if you wish.) Then run or debug info.fulloo.trygve.editor.Main.

This implies that VS Code is the only option for environments (unspecified) where it is available (or something — it doesn’t say). It gives no guidance on when to use VS and what “other environments” mean (non-Windows environments? Environments whee VS Code is not installed? How do I know?)

If the next person comes along and adds XCode, we have another option — and soon we will need to process a small logic table, to arrive at the decision of how to configure trygve. It would have been so nice if we could have a single configuration command for everyone. Maybe it wouldn’t even be optimal for everyone, but there is strength in genericity,

Oh, gee, I think we once had that.

I am still unclear what problem this solves, and if the benefit over the future will ever accrue to compensate for the energy we have expended in discussing it.

Here is a more concrete sticking point irrespective of the arguable benefits or not of implementing the change. More broadly, I think that I am somehow not being effective in communicating my vision of the purpose of the repository. Part of that vision is in the tradition of being minimal: cookbook for the inexpert programmer, and non-obtrusive for the more advanced user. Adding bells and whistles broadens the footprint and makes it obtrusive for advanced users and, at best, confusing for novices. The installation procedure formally was generic and straightforward. In general terms, the README now is of the form:

It is possible to use VS code

In other environments

Import this into your IDE

Use your IDE to run or debug

If there are options from which I must choose I expect something of the form:

IF x 

    THEN do y

    ELSE z

The README relates y and z but not x. That’s just silly.

There are questions that arise in this README that would not arise in the old one:

1. The first statement unqualifiedly asserts that VS Code works. I know that VS code does not work in my environment. That isn’t to say that I can’t make it work, but you are just making more work for me to install VS Code yet implying that you will save me work.
2. There is nothing in the README that clarifies to me whether I should use VS code or to go on to the second statement. How do I choose between VS code and using an IDE? The README does not speak to that question. Do you presume I am an expert? That denies trygve to inexpert users. At best, I need to switch context and read another file to improve my understanding. You should not make it the user’s problem; you own the problem of explicitly laying out the options in the REAME. We previously did this.
3. The alternative to using VS Code, according to the README, is to use an IDE. Currently, Apple has deprecated the version of Eclipse on my machine so I currently have no Java IDE other than XCode. The README does not tell me how to use XCode. In fact, I configure trygve using gradle directly — which is what I always did previously. Why does the new README eliminate that general, simple path to configuring trygve?
4. If I install VS Code, do I have to install the JDK again (if I follow the instructions and follow the recommendations for the simplest path, the answer is: Yes). The instructions (https://code.visualstudio.com/docs/languages/java) also imply that to get Java support (“If you have already installed VS Code and want to add Java support to it”) (and since trygve is written in Java I presume I want Java support)I need to install one or more of stuff from Red Hat, Java debugger support, Maven, a project management package, and Visual Studio. You might think this sounds silly, but if you have any background in directing users how to do stuff you have to be blindingly explicit, and Microsoft fails badly at this.)

Even if VS Code is a good idea, the current delivery to the end user is a mess and only sews confusion and complication. Inexpert users not proficient in Java development will be lost. My guess is that trying to fix this problem (go ahead, try) will add even more complexity.

This radically violates my sense of good taste and minimalism.

We can heed all the cheerleading and idealistic expectations of why this might be a great thing, as Matthew has tried to do, and maybe he is right. But we must also look soberly at the details as I have done here, evaluate how users will apply it, anticipate the problems that may arise, and attend to the details. I was expecting more critique here as follow-up of the nature that I have offered above, but it seems that folks have leapt right over that and start waving the Banner Of Their Favorite Tool. We can hope that it adds value. But hope is not a plan.

Y'all can try to fix these problems and I can look at it again, but I will not be very happy to approve it unless it conveys the same minimalism as the original.

I don't think this is about trying to make it into an environment to build production-ready apps - not at all. It's just about making it easy to get started, and I think Andreas's contributions in that area should be welcomed.

I think that someone following the current README will now be lost with regard as to how to get started unless they make assumptions or have expert knowledge. I do not see Java experts as our target market.

On some of the other points, perhaps there are certain bells and whistles that are too much, not worth the maintenance, etc. given that this is a research language. But I literally don't see any downside to adding a simple IDE config file for VS Code, only a significant benefit.

First, that in itself is not the only issue. In addition to the end point, we must consider the path. But, with regard to that issue, it’s also important to ponder that we can’t do everything. What we do know should be contextualized in a larger long-term picture of trygve as a research prototype. I don’t see how that vision feeds or tempers any of the discussion here so far.

If improved maintenance is the goal, then support for XCode has a higher priority (at least for me) than support for VS. How will we instruct users to configure trygve for their system using XCode? For make? 

I could go on, but enough for now.

[Egon Elbre]

Just to add my one cent.

There's definitely value in letting people use the environment they are most comfortable.

If I'm not able to use easily one of my usual environments, then I usually skip experimenting with it.

However, I'm also sympathetic to Cope, that the effort to do something like LSP support is rather large,

time which could be spent elsewhere.

However, the amount of things you need to have minimal support in an editor is not much.

Mostly it'll involve:

1. create a textmate grammar file; most editors support these, or have converters for it (AFAIK, XCode, VSCode, Sublime Text all support it)

2. create a configuration files to run "trygve" line, this usually is specific to an editor, unfortunately... but, luckily, it's usually a few lines

3. I haven't checked, but, if trygve supports linespec for printing errors, then some editors pick it up automatically

The question is how to make it easier to run trygve for people, without having to run gradle.

I think there are quite a few Java compilers out there that can give you a runnable artifact,

something that could be run as a usual command line tool.

Github can be used to automate building of such "binaries" and automatically upload them to releases.

Overall this would reduce the process to "install this extension" and "download trygve from releases page".

Similarly, it would still allow running the built-in editor directly.

+ Egon

[James O Coplien]

On 28 Sep 2022, at 11.01, Egon Elbre <egon...@gmail.com> wrote:

The question is how to make it easier to run trygve for people, without having to run gradle.

They can download the .jar file. It’s on the fulloo.info site. If we need to add that to the README I suppose we can do that, but it seems like a strange place to put that pointer.

If we need to create a script to explicitly invoke Java with the .jar file as a parameter, we can do that.

If that’s the problem we are solving, there are solutions that are an order of magnitude simpler than this delta.

[Lund Soltoft]

Language support in VS code is generally done with an extension which is mostly a collection of text files. I see now reason why such an extension shouldn’t live in it’s own repository? 

Is theee anything missing making ir impossible to do a launch configuration I VS code with the CLI?

Mvh

Rune

Den 28. sep. 2022 kl. 11.01 skrev Egon Elbre <egon...@gmail.com>:

Just to add my one cent.

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/f14ca1e3-75d8-4af2-b9dd-9b2bf2f6796dn%40googlegroups.com.

[Egon Elbre]

Ah, if a jar is already available somewhere, then it's less of a problem.

The releases page (e.g. https://github.com/jcoplien/trygve/releases), usually makes it easier to discover the binaries for a given project, but a link in README would be fine as well.

> If we need to create a script to explicitly invoke Java with the .jar file as a parameter, we can do that.

The script wouldn't be necessary, for configuring the editors, as they can specify arbitrary command-line to run.

I generally dislike .jar files, because it requires a java to be installed. But, I wouldn't say it's an hinderance for most people.

[Jonathan Crossland]

What is the specific target audience and the specific use cases you wish to share with them?

What is the least friction to achieve this?

All else is nonsense.

I already won't install it, because it's Gradle/Java. 

I would want a website sandbox to play and view it, so I don't have to get all serious dependencies and rubbish on my boxes. So having it available for vscode, which I use, still wouldn't satisfy.

What is the primary objective for your primary audience? What is their tooling and/or how can you reach the people you want, with little to no friction?

Do you want feedback? Do you want a showcase? Do you want uptake? Research kudos? All different cases.

Kind

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/e60b880c-5e5d-48fd-bdd5-e1cee1e83bb8n%40googlegroups.com.

[Egon Elbre]

I need to correct myself,

looks like XCode doesn't support tmsyntax and adding a new language is more involved than I expected.

[Andreas Söderlund]

The download instructions for trygve have been updated at https://fulloo.info/Downloads/

That is how you get trygve up and running without touching the source code, git or any development editor/IDE.

It's not a very user-friendly experience though, for example:

• OpenJDK 17+ is required and won't download automatically
• It's a zip/tar package, so no installation is done (install location, creating icons on desktop/start menu, etc)
• You can't start it by simply clicking on bin/trygve.bat, since the examples requires the cwd to be in the directory above bin, so you need to open a terminal and execute bin/trygve.

[James O Coplien]

On 28 Sep 2022, at 13.07, Jonathan Crossland <jonathan...@gmail.com> wrote:

What is the specific target audience and the specific use cases you wish to share with them?

What is the least friction to achieve this?

All else is nonsense.

I already won't install it, because it's Gradle/Java. 

I would want a website sandbox to play and view it, so I don't have to get all serious dependencies and rubbish on my boxes. So having it available for vscode, which I use, still wouldn't satisfy.

What is the primary objective for your primary audience? What is their tooling and/or how can you reach the people you want, with little to no friction?

Do you want feedback? Do you want a showcase? Do you want uptake? Research kudos? All different cases.

I’m sorry that you feel almost as strongly about Java as I do, but I certainly can relate to your concern and respect your position.

Even more so, it’s good finally to see someone asking the right questions.

[James O Coplien]

On 28 Sep 2022, at 16.02, Andreas Söderlund <gaz...@gmail.com> wrote:

• OpenJDK 17+ is required and won't download automatically

Well, the .bat script could validate whether the JDK is there and, if not, download it.

That’s no less ridiculous that what was in some of the earlier suggestions relating to starting a graphics window.

[James O Coplien]

On 28 Sep 2022, at 12.35, Egon Elbre <egon...@gmail.com> wrote:

The releases page (e.g. https://github.com/jcoplien/trygve/releases), usually makes it easier to discover the binaries for a given project, but a link in README would be fine as well.

I encourage you to send me a pull request.

[James O Coplien]

On 28 Sep 2022, at 12.35, Egon Elbre <egon...@gmail.com> wrote:

I generally dislike .jar files, because it requires a java to be installed

… and if you follow the recommended installation procedures currently awaiting approval in the GitHub branch,  you *always* re-install the JDK — whether or not you already have it on your machine.

[Andreas Söderlund]

Well, the .bat script could validate whether the JDK is there and, if not, download it.

Those scripts are a part of the gradle build process, and I have no idea where to start to integrate such a change into them. An installer is the only reasonable way.

 

That’s no less ridiculous that what was in some of the earlier suggestions relating to starting a graphics window.

Such a snide remark can do nothing but lessen the enthusiasm and interest about this project.

[Matthew Browne]

Hi Cope,

Thanks for clarifying—I understand your point better now. I hadn't looked at the updated readme in the PR, I was only thinking of the VS Code config itself.

To be clear, this is the PR I was referring to:
https://github.com/jcoplien/trygve/pull/126/files

Not a VS Code extension or anything like that, just basic IDE configuration so you can easily build or debug the project.

I think you raise a good point about the readme, and making VS Code the primary suggested way to get started could be problematic. I was inclined to think that it could just be mentioned in the readme with a link to instructions for someone who happens to be a VS Code user. The other option would be to just not mention it at all, since as you pointed out, it's more decisions for the beginner user to make (although I'm not sure I'm convinced that it has no place in the readme at all—if nothing else it seems like there could be links at the bottom of the readme for this sort of thing).

But even if it's not in the readme at all, I still think there would be value in including those config files. Then at least those already using and familiar with VS Code (which is a large percentage of developers) can benefit from it.

As for the larger question of what is most helpful for DCI to gain more traction, I agree with Rune that focusing on languages and environments intended for production usage is what would be the most helpful. The trygve project is still important and a great way for people to be introduced to DCI, but I don't think it needs a whole lot more features to accomplish that at this point—the current feature set is quite good to learn about DCI itself. The main thing I can think of off the top of my head is asynchronous calls—it could be interesting to explore asynchronicity with DCI. But IMO that's more in the nice-to-have category at the moment.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/47655947-8C34-4845-97A4-E297D09E397D%40gmail.com.

[James Coplien]

Sent from my iPad

> On 28 Sep 2022, at 19.49, Matthew Browne <mbro...@gmail.com> wrote:
>
> I was inclined to think that it could just be mentioned in the readme with a link to instructions for someone who happens to be a VS Code user. The other option would be to just not mention it at all, since as you pointed out, it's more decisions for the beginner user to make (although I'm not sure I'm convinced that it has no place in the readme at all—if nothing else it seems like there could be links at the bottom of the readme for this sort of thing).

This is much in the direction of what I was considering doing. Instead of headlining VS Code, discarding the gradle option, and pulling in IDEs, I was considering just putting a note at the bottom of the old README noting that “VS code is supported; see the relevant adminstrative files for details.” Then those who want the “elegant” VS Code solution will be happy while we restore the simple, common gradle invocation that seems currently to be missing.

Thanks!

[Andreas Söderlund]

> I was inclined to think that it could just be mentioned in the readme with a link to instructions for someone who happens to be a VS Code user. The other option would be to just not mention it at all, since as you pointed out, it's more decisions for the beginner user to make (although I'm not sure I'm convinced that it has no place in the readme at all—if nothing else it seems like there could be links at the bottom of the readme for this sort of thing).

This is much in the direction of what I was considering doing. Instead of headlining VS Code, discarding the gradle option, and pulling in IDEs, I was considering just putting a note at the bottom of the old README noting that “VS code is supported; see the relevant adminstrative files for details.”

Where is VS Code headlined?! Directly from the README:

"VS Code is a very accessible way to develop trygve. Installation instructions are available here."

This is the ONLY line where VS Code is mentioned, it's mentioned NOWHERE on fulloo.info, and I'm not lying - it's a very accessible way to develop trygve, and incredibly accessible compared to how it was before. The current trygve user guide has instructions for getting started in Eclipse, and that's headlined in the README... it's only 30 steps!

Then those who want the “elegant” VS Code solution will be happy while we restore the simple, common gradle invocation that seems currently to be missing.

It's not missing! Both the sections Running and Developing in the README describes how to use gradle. Give me a break!

I will make a PR for a fixed readme (also because the OpenJDK version is wrong), then I won't care anymore what development environment anyone uses on this project.