Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of skript-parser #25

Open
3 tasks
Olyno opened this issue Aug 5, 2020 · 10 comments
Open
3 tasks

Future of skript-parser #25

Olyno opened this issue Aug 5, 2020 · 10 comments
Labels
future Long-term plans of requests-for-comment about future/desired features.

Comments

@Olyno
Copy link
Contributor

Olyno commented Aug 5, 2020

Future of skript-parser

Overview

The skript-parser project was created to improve the current Skript parser.

Here is a simple roadmap to guide current and future contributors throughout the project

Based on the big spots of the initial Skript project (SkriptLang/Skript#121):

  • Sane addon API, and documentation for it.
  • Skript-to-JVM compiler, which generates classes from parsed scripts and possibly exports them
  • Optimized variable storage

With regard to this project directly:

  • Having a high-performance module system to extend the skript-parser
  • Being able to execute a script via a CLI
  • Have a more complex and efficient variable system with memory management.

Roadmap

Here is the proposed roadmap:

Duration Activity Releases
2 months Dev Work
Implement all existing Skript syntax that does not require Minecraft (example: amount of %objects%)
/
2 months Dev Work
Add a testing system like the current Skript project
/
2 months Dev Work
Create a CLI in order to execute scripts in an efficient way
0.1.0
1 month Quality & Stability
Fix parser & CLI issues
0.2.0
3 months Dev Work
Rework the system of variables to make it much more efficient
0.3.0
1 month Quality & Stability
Fix potential variables issues
0.4.0
4 months Dev Work
Having a high-performance module system to extend the skript-parser
0.5.0
1 month Quality & Stability
Fix potential modules system issues
0.6.0
2 months Quality & Stability
Full documentation
1.0.0
6 months Dev Work
Skript-to-JVM compiler
2.0.0
2 months Quality & Stability
Fix potential issues with JVM compiler
2.1.0

Total duration: planned on 26 months, September 2022

To note: All these dates are only approximate and may change depending on the speed of the project and its contributors. Please do not take them for granted, but only as a guide.

skript-parser projects

If we have projects created with the new parser, it will be easier to see our progress. Here are some interesting projects to do:

  • Web server: make a website with skript-parser
  • Desktop app: make a desktop app using GUI
  • Mobile app: make an android mobile app with skript-parser

To note: These are only project ideas. The goal is not to push them to the maximum but only to see the skills that skript-parser possesses.

@Mwexim
Copy link
Owner

Mwexim commented Aug 6, 2020

It is good to have a central place for progress. I think the road map is fairly detailed and pretty realistic. I have a few remarks:

  1. I currently think the parser lacks in-depth API for addon developers. I recently added the PropertyExpression class, but I think there should be more utility still. I am currently developing another pretty large utility branch that should be out in 2 weeks probably. This should be another priority in the road map, maybe like a side quest ;)
  2. I already created an implementation of skript-parser here. It has basic utility functions like dates, classes, strings and more. It is not fully extended but it actually uses a lot (if not all) non-Minecraft related things from Skript. Only some minor things like waiting effect (there is a wait section though), mapping and other stuff. Others may use this as well if they want. I am currently developing the first addon for skript-parser called BDiscord. It’s meant to interact with JDA like Vixio does for normal Skript, but then without a Spigot server needed of course.
  3. This changes the overall plans drastically. Skript-parser (afaik) was a library that could be implemented. The basic syntax was present to have some sort of foundation for developers. If we want to transfer this amazing project into an application, we should probably pick a name for it, like I did for mine. Buzzle is a pretty silly name and mostly acts as a placeholder, but I think we should think about this further if we want to go this direction. I currently think Syst3ms has some voice here, since he is the contributor/admin of this project.
  4. We should make a small developers Discord, shouldn’t we? Nothing special, just a small group. It’s not supposed to become a community. I can take care if this but I’m currently on vacation, so if anyone wants to do this, that’d be nice.
  5. We should start creating a wiki if we want to stick onto this road map. Creating simple expressions like most of the contributors did currently is fine, but I think the TriggerContext system and the overall way of parsing should be explained better.

Beside that, I don’t want to go too in-depth into the end goals of the road map, but I think making a JVM parser will be hard, especially with all the events etc. It’s definitely possible but I don’t know if this should be a priority.

About the application parts, I always was thinking about making an IDE for skript-parser, that automatically installs the main plugin and registered addons. I do not know how to make one, but maybe this could be a thing on the road map? Because that sounds a lot more useful and practical than making an Android application. We can be ambitious, but our dreams need to be realistic. We have no budget whatsoever and we all do this because we like this project.

@Olyno
Copy link
Contributor Author

Olyno commented Aug 6, 2020

I currently think the parser lacks in-depth API for addon developers. I recently added the PropertyExpression class, but I think there should be more utility still. I am currently developing another pretty large utility branch that should be out in 2 weeks probably. This should be another priority in the road map, maybe like a side quest ;)

Of course. The addon developers api of this project will not be available before 0.5.0.

I already created an implementation of skript-parser here. It has basic utility functions like dates, classes, strings and more. It is not fully extended but it actually uses a lot (if not all) non-Minecraft related things from Skript. Only some minor things like waiting effect (there is a wait section though), mapping and other stuff. Others may use this as well if they want.

Maybe it could be interesting to share with the main project what you did. Like create a pull request for functions, one for dates etc...

I am currently developing the first addon for skript-parser called BDiscord. It’s meant to interact with JDA like Vixio does for normal Skript, but then without a Spigot server needed of course.

I'm not sure to make it right now. Like you see in the roadmap, modules system (so addons which are non-related to Minecraft) will start to work only for the 0.5.0. I think you are getting this too fast.

we should probably pick a name for it

We already think about it. It takes time, and we didn't chose any name yet. Let's see in the future.

We should make a small developers Discord, shouldn’t we?

It already exists since a while. We call it skript-chat. You can find it using this link.
To note: It's not the official invite link, just one of mines

We should start creating a wiki if we want to stick onto this road map.

It's the same thing of BDiscord. While the api for addons dev is not stable (and so api for modules), we can't make it.

@Mwexim
Copy link
Owner

Mwexim commented Aug 6, 2020

I currently think the parser lacks in-depth API for addon developers. I recently added the PropertyExpression class, but I think there should be more utility still. I am currently developing another pretty large utility branch that should be out in 2 weeks probably. This should be another priority in the road map, maybe like a side quest ;)

Of course. The addon developers api of this project will not be available before 0.5.0.

I already created an implementation of skript-parser here. It has basic utility functions like dates, classes, strings and more. It is not fully extended but it actually uses a lot (if not all) non-Minecraft related things from Skript. Only some minor things like waiting effect (there is a wait section though), mapping and other stuff. Others may use this as well if they want.

Maybe it could be interesting to share with the main project what you did. Like create a pull request for functions, one for dates etc...

If Syst3ms wants to go this way, I think I’ll just abandon it and transfer everything here. The main reason I made my own project is that Syst3ms initially wanted to keep this library, welp, a library, with little function to have a bare foundation.

I am currently developing the first addon for skript-parser called BDiscord. It’s meant to interact with JDA like Vixio does for normal Skript, but then without a Spigot server needed of course.

I'm not sure to make it right now. Like you see in the roadmap, modules system (so addons which are non-related to Minecraft) will start to work only for the 0.5.0. I think you are getting this too fast.

You can currently make a perfectly fine addon for this parser using the tools provided. It is actually pretty straightforward, yet given that there is no documentation for it yet.
I do have to admit that the current tools lack mobility and accessibility and we should focus on this. This is just in a testing fase so don’t worry.

we should probably pick a name for it

We already think about it. It takes time, and we didn't chose any name yet. Let's see in the future.

I currently think this is a priority. We can’t go from a library to a full functional program without going to this relatively simply process.

We should make a small developers Discord, shouldn’t we?

It already exists since a while. We call it skript-chat. You can find it using this link.
To note: It's not the official invite link, just one of mines

I think we should make a separate one only for this project if we want to take it this far. You’re ambitious, and I want to be too, but this’ll only work if we can get more people on track. This should go together with finding a name.

We should start creating a wiki if we want to stick onto this road map.

It's the same thing of BDiscord. While the api for addons dev is not stable (and so api for modules), we can't make it.

Agreed. I took another look at the road map and it’s on the right spot.

I currently am just waiting for @Syst3ms to reply. If he wants to go this way, I’ll transfer Buzzle onto this after a new name is chosen.

@WeeskyBDW
Copy link
Contributor

WeeskyBDW commented Aug 6, 2020

Hey @Mwexim
I will explain you branchs of skript-parser (dont take it bad, it's not to decribilize you):

  • master: skript-parser core with defaults implementations (like original skript plugin)

  • skript-librairy: only the skript-parser core, without defaults implementations

  • modularize: an older branch made by @bensku who is deprecated

It was what Syst3ms saying me in a vocal discussion
I hope i have help you 😃

@Olyno
Copy link
Contributor Author

Olyno commented Aug 6, 2020

If Syst3ms wants to go this way, I think I’ll just abandon it and transfer everything here. The main reason I made my own project is that Syst3ms initially wanted to keep this library, welp, a library, with little function to have a bare foundation.

See @WeeskyBDW post above

I currently think this is a priority. We can’t go from a library to a full functional program without going to this relatively simply process.

Literally not. Find a new name is not the priority at all. Change the project name takes 5 minutes, but working on the projects take months.

think we should make a separate one only for this project if we want to take it this far. You’re ambitious, and I want to be too, but this’ll only work if we can get more people on track. This should go together with finding a name.

Let see with @Syst3ms & Skript contributors

@WeeskyBDW
Copy link
Contributor

I agree for separeted discord server, it permit to not be loosed whith many channels (1 by skript addon in skript-chat server) and then a better activity/responce time from other contributors.

Also, it permit to people who just interrest by skript-parser to have a special discord server for that

For finish, it permit to make public discussions about skript-parser and more opinions

@Romitou
Copy link
Contributor

Romitou commented Aug 6, 2020

Why wouldn't this be possible to be done on the Skript Chat Discord server? I just think it would be much more convenient to create a specific category on Skript Chat.

@Mwexim
Copy link
Owner

Mwexim commented Aug 6, 2020

Hey @Mwexim
I will explain you branchs of skript-parser (dont take it bad, it's not to decribilize you):

  • master: skript-parser core with defaults implementations (like original skript plugin)
  • skript-librairy: only the skript-parser core, without defaults implementations
  • modularize: an older branch made by @bensku who is deprecated

It was what Syst3ms saying me in a vocal discussion
I hope i have help you 😃

I already knew this. I’m just putting my arguments here because I do feel I am engaged with it.

Although I am not a Skript contributor, I do have had regular conversations with Syst3ms since may. I don’t know how long each of you guys contributed to this project in particular (I mean skript-parser), but suddenly (since a month or so) there are a lot more contributions from several people like @Olyno and @Romitou .
I just wanted go give my take on this. I don’t know what the reason for the current ‘spike’ in activity is on this project, but all of the sudden there is this road map and a ‘plan’ for the future of this project that always seemed so dead to me. I just started developing it out of curiosity and asked a lot of information from Syst3ms, which was very informative. I pointed out issues and even some suggestions he always was willing to implement.

So sorry if I am not taken as an active contributor to this project, I did not want to force my opinion onto anyone here. I just think it’s weird after all this time suddenly there are plans. Was this planned with the contributors of Skript itself?

@Olyno
Copy link
Contributor Author

Olyno commented Aug 6, 2020

Peak contributions are due to several factors. On my side, it's mainly because I have time and I like to contribute to Skript at my scale.
As for the roadmap, I proposed it to Skript contributors, without having (as far as I saw) big changes about it. I guess most of them are for it. It allows to organize the project and to be able to progress correctly, while informing the contributors (current or future) of the project status.
Plus, like you already did some contributions, you are technically a contributor, do not underestimate yourself, and any opinion is welcome 😃

@Syst3ms
Copy link
Contributor

Syst3ms commented Aug 7, 2020

I just think it’s weird after all this time suddenly there are plans. Was this planned with the contributors of Skript itself?
@Mwexim Well, there are a couple reasons for that. First of all, all of the recent contributors are part of the French Skript community, and recently they collectively gained interest in the project, hence the spike in contributions.
The next reason why I accepted having a roadmap (or at least a draft thereof) is because I will probably be virtually inactive in the coming months due to school becoming far more intensive, so I wanted to have a direction set so that the project doesn't just stagnate when I'm not working on it.

If you want to contribute to an implementation of the parser using what you've written yourself, you are more than welcome to do so. Nonetheless, I am somewhat reluctant to begin implementation right away, because my mentality is "logic & API first, implementation later". I am very much open to any suggestions or propositions for a better API. The core logic and library aspect of the project will always be kept to some extent.

I'm mixed about creating a dedicated discord or something of the sort. Right now I don't feel like the project is quite active enough to warrant one.

A good start for the documentation would be to generate the javadoc of the project, which might need some changes to do because the syntaxes Javadoc follows Skript's custom documentation format right now. A wiki is still welcome.

@Syst3ms Syst3ms added the future Long-term plans of requests-for-comment about future/desired features. label Aug 20, 2020
@Syst3ms Syst3ms pinned this issue Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Long-term plans of requests-for-comment about future/desired features.
Projects
None yet
Development

No branches or pull requests

5 participants