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.
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.
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.
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.
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.
F5
, and build with gradle using Ctrl+Shift+B”?
--
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.
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.”
Maybe we should decide what problem we’re trying to solve.
--
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.
--
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.
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;
everyone I know is now using it for something or other.
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
.
It is possible to use VS codeIn other environmentsImport this into your IDEUse your IDE to run or debug
IF xTHEN do yELSE z
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.
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.
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.
--
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.
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.
On 28 Sep 2022, at 16.02, Andreas Söderlund <gaz...@gmail.com> wrote:
- OpenJDK 17+ is required and won't download automatically
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.
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
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.
--
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.
> 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.”
"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.