Page 1 of 1

ParserTool

Posted: Sat Mar 04, 2017 8:06 am
by smaudet2
It'd be kinda nice if there was a ParserTool or something - something where it just lets you play with the parser, without firing up/understanding the whole of MapTool.

I might make one, just saying, but throwing this idea out there in case I go missing.

Re: ParserTool

Posted: Sat Mar 04, 2017 8:23 am
by aliasmask
What exactly would you be parsing, the MT code? Are you thinking of an IDE or something like that?

Re: ParserTool

Posted: Sat Mar 04, 2017 2:32 pm
by smaudet2
aliasmask wrote:What exactly would you be parsing, the MT code? Are you thinking of an IDE or something like that?
Think of it like a light-weight front-end to parser-lib (https://github.com/RPTools/parser - what (if any) maven artifact is this? version is 1.4.0.0, but it doesn't look like gradle forces you into good habits like making everything part of a group+artifact).

Maptool is the giant IDE that is bloated and chock full of everything you could want in one place, parsertool would probably be a project that just offered basic REPL and help functionality for the Maptool parser language. So, like, if you want to get crazy you could make it headless and throw it into a docker container on AWS and have it do Big Data analysis of a bunch of player stats or something crazy like that :P

Re: ParserTool

Posted: Sun Mar 05, 2017 8:21 am
by JamzTheMan
FYI, there is a push to move to JavaScript and the bones are in 1.4.1...

Re: ParserTool

Posted: Sun Mar 05, 2017 10:44 am
by smaudet2
Does that deprecate the macro language entirely then?

Even if you move entirely to JavaScript you still are going to see advantages to a macro DSL (domain specific langauge) over a 'pure' javascript implementation - I don't particularly care if you implement the macro language on top of ANTLR or Javascript or PyJS, its still a language...

Re: ParserTool

Posted: Sun Mar 05, 2017 2:24 pm
by smaudet2
New post, as its pretty different from my previous reply - I've started on this.

I went down the route of JavaFX for the gui bit - I don't mind JavaFx, but a couple things:
  • The CSS support in JavaFX isn't totally there. If you're used to CSS3 or CSS4, this is more like CSS1 with java-specific prefixes. You *cannot* re-use much existing CSS knowledge, I'm not sure what the point of even calling it CSS is, other than it sort-of-looks-like CSS and kind-of-behaves-the-same. Unless you think CSS is just key value pairs...which is what this feels like. Argh, no.
  • The nice thing is that (from fxml) you can use css files...but this is besides the point if the css files are stuck inside of a jar. This is only useful if you can figure out how to load externally from the jar, which I aim to do. Its not in the tutorials or anywhere obvious.
  • gradle+jfx integration (shoot me please). There was a plugin, which died, and then another guy built a different but sort-of-related plugin which doesn't seem entirely to work, although apparently there's a deeper issue where JAVA_HOME must be set (not sure what's up with that, so that may be a deeper environment problem on my end), or you'll get a misleading message that your main class cannot be found.
I have to do things that are not java-coding hobbies for a bit. I might not work on this till next weekend, I'll try to get something hammered out tomorrow though.

Re: ParserTool

Posted: Mon Mar 06, 2017 4:15 pm
by JamzTheMan
I assume your gradle+javafx woes are in relation to deployment? (I had no issues developing FX with Eclipse Neon + SceneBuilder out of the box)

I've been hoping the package deployment gets better. I had choosen to go with jWrapper last year because it was the easiest option for all 3 OS's at the time and served my needs. With Java 9, I had planned on taking another look at the packaging again. In any case, packaging with a JRE has worked out awesomely...

Re: ParserTool

Posted: Mon Mar 06, 2017 5:47 pm
by smaudet2
JamzTheMan wrote:I assume your gradle+javafx woes are in relation to deployment?
Yeah. The default 'application' packaging works like a charm, I had zero issues with just straight up JavaFX development in IntelliJ. Deployment/Building w. gradle was very weird though. I'm not actually sure the jfx or the javafx gradle plugins do anything useful at all... but you search 'gradle javafx' on google and its the first search result. Misleading...

Re: ParserTool

Posted: Tue Mar 07, 2017 8:43 am
by jfrazierjr
I am not sure what you are trying to accomplish, so forgive me if I say something stupid. If your goal is to run various test cases on the Parser... why not just add JUnit test cases to the Parser repo? I am assuming that a) there are no tests(I have not checked) or b) they don't all do what you what to test if they are there.

Adding JUnit tests(or additional ones) is IMHO, a very worthwhile pursuit which will benefit everyone and could answer both yours and other coders expectations of what to expect with a given input(or resolve bugs).

Re: ParserTool

Posted: Tue Mar 07, 2017 6:18 pm
by smaudet2
jfrazierjr wrote:I am not sure what you are trying to accomplish, so forgive me if I say something stupid. If your goal is to run various test cases on the Parser... why not just add JUnit test cases to the Parser repo? I am assuming that a) there are no tests(I have not checked) or b) they don't all do what you what to test if they are there.

Adding JUnit tests(or additional ones) is IMHO, a very worthwhile pursuit which will benefit everyone and could answer both yours and other coders expectations of what to expect with a given input(or resolve bugs).
Good suggestion.

I'm afraid you won't deter me from my current line of thinking though...do you know what a REPL is?

Like, when you type 'python' into a console and you can start writing python commands, or you open up developer tools in your browser and you can start typing javascript (or you can run node.js on runMyCommands.js) file.

The _other_ thing I'm doing, is using this as an excuse to familiarize myself with JavaFX - I like it for the most part, it seems not as bad as swing, not as deprecated as Abeille Forms Designer, and I know other developers here were interested in it...so if I wanted to see if I could be of assistance, it probably makes sense to learn it, or better yet, write a PoC that uses the existing MapTool libraries, and maybe benefit everybody.

Re: ParserTool

Posted: Tue Mar 07, 2017 9:33 pm
by JamzTheMan
Yea, I did the exact same thing using token tool. Although I got distracted...Oh shiny!

It was nice, def better than swing and using scenebuilder much nicer than abilie forms...

Re: ParserTool

Posted: Tue Mar 07, 2017 10:30 pm
by smaudet2
JamzTheMan wrote:Yea, I did the exact same thing using token tool. Although I got distracted...Oh shiny!

It was nice, def better than swing and using scenebuilder much nicer than abilie forms...
Oh? Does Token tool use JavaFX already?

I don't see it in the current (master) build...

Also, Art, like Fire, is both useful, and pretty to look at. It also burns you.

The trick, as with fire, is to find its 'proper' use - and that depends on who is using it. Burning down buildings may be fun, but only useful to arsonists. Cooking meals may not be glamorous, but is tasty. Fire-breathing may look pretty, but that's about it. And sometimes, you just need to keep the house warm.

Re: ParserTool

Posted: Wed Mar 08, 2017 4:15 pm
by JamzTheMan
For token tool, its work in progress, partially working. I want to test using layered TIFF's for embedded masks...

It's only checked into my maptool fork, 1.4.3.x branch if you want to check it out...

Re: ParserTool

Posted: Thu Mar 09, 2017 6:37 am
by smaudet2
FYI, I found the jfx plugin 'bug' - I have openjdk and jdk installed...most considerate plugins try to use the jdk they've been told to use, gradle-jfx does the dumb thing and assumes 'java' is the java you want it to run with.

Case in point, OpenJDK doesn't have JFX, JDK does, compiles and runs fine with JDK, as soon as you let the (badly built) jfx gradle plugin do its thing it picks up the wrong java.

*mutters something about kids getting off their lawns*

Basically, an inexperienced developer wrote this... this happens time after time, do NOT make assumptions about the environment you are running in, especially if your host isn't the JVM directly. I'd file a bugfix, but you can't fix people... </end rant>

Re: ParserTool

Posted: Sat Mar 11, 2017 4:54 am
by smaudet2
Initial version is done:

https://github.com/smaudet/parsetool

Very, very basic implementation, but it uses JavaFX, it packages deb/rpm/exe/dmg (although I've not been able to test the later two), and it provides a REPL (with variable support!) for parselib.

There's a lot of missing stuff (better History support), a headless mode of some sort, and I've not tried this on any of my Android devices yet.

EDIT: One major real-world problem I've run into with JavaFX - Multiple-Open Accordion support. The 'single open' accordian works just fine, as soon as you want multiple options to open, with configurable scroll support, you're a bit on your own. There's a workaround, but it needs workarounds, and doesn't feel polished.