Topic on User talk:Pastakhov

While I haven't yet used PhpTags beyond some quick testing, I've had a look at it and it seems quite interesting overall, because it seems like it could be relatively easily extended so that scripts can bring together functionality from several extensions.

I don't know what you plan for it, or how it is likely to develop from here on. Anyway, some ideas for uses of and possible extensions to PhpTags functionality came to mind in looking at it, and I'll mention them in case any of them may be interesting to you as well. It would be interesting to hear your thoughts about them:

1. Automating sortkey generation for pages. This could currently be done using PhpTags Functions as follows: take the title of the calling page, use string functions to transform it, then use the returned result inside {{DEFAULTSORT: }}. The same can be done using Scribunto. But with PhpTags, it could easily be improved by adding a function to PhpTags Wiki so that the default sortkey can be set directly – with no need for returning something to DEFAULTSORT any more.
2. Querying similar to DynamicPageList. I see that you've begun working on some query code, though while it's in Gerrit, it's not been merged yet. One comment in case it is helpful: Have you looked at Extension:DynamicPageListEngine? It is a modular, more well-written DPL implementation that only offers PHP and Lua APIs. Perhaps, for a number of querying features, its code may be a good reference to look at?
3. Processing results from Semantic MediaWiki queries. Semantic Result Formats includes support for Extension:Arrays and Extension:HashTables, in both cases the results are efficiently stored in a PHP array. I think it would be quite simple to make a PhpTags extension to get and set arrays from the Arrays and HashTables extensions. Then a query can be made in the usual way, and afterwards PhpTags can be used to process the results in whatever way is desired.
4. Semantic MediaWiki queries. An extension that allows SMW querying using PhpTags. This would take much more effort than the previous item, but would allow greater flexibility. PhpTags could be used to extend the functionality of Semantic MediaWiki inside a wiki – combining queries and processing of results however one wants, without having to write further extensions. I think the code of the Semantic Query Interface extension could be worth looking at for this.

If I decide to use PhpTags, then for my own needs I would need to extend it according to at least one of the last two options. That means one new, or possibly two new, MediaWiki extensions (which would be the first one(s) I'll ever write). Especially if attempting the second option, supporting SMW queries directly, that may take some time and effort. Anyway, I may give it a try, though no idea if and when it may be completed.

The other options in the list (the top two) are not as high priority for me. Maybe you'd be interested in the ideas, or maybe not. The first in the list may however be trivial enough for me to quickly add just to get more familiar with PhpTags, if you'd like the functionality. The second, I guess it may or may not fit what you have in mind with the querying functionality you have begun working on.

Finally, regarding performance: What I've seen mentioned ("10 times slower" than Lua for large scripts) sounds good enough for my purposes. However, that might improve even further simply by using HHVM, if it significantly speeds up PHP (and then in turn also PhpTags). It seems Wikimedia is now focusing on HHVM, and as of recently, MediaWiki-Vagrant also uses HHVM by default – you may already be aware of this, but I thought I'd mention it just in case, in case it would be useful for testing.

Hi, Joel, thanks for the message! You're the first person who showed interest in using this extension :-)

You are right, this extension can to combine the functionality of other extensions and this is really simple, it needs to write just a few lines of code. The problem is that all of the available extensions are monolithic and I'm trying to make the constructor, where instead of the cubes are functions or classes, and anyone will be able to make of them what he needs.

My plans are a very ambitious :-) The query code with which I've begun working is an alternative to {{#ASK: }} of SMW. At the first stage it will be similar the DynamicPageList and at the second stage I plan to develop a database similar to SMW. The peculiarity is that queries can be more flexible and automatically grouped to increase performance and reduce latency.

Displaying query results will be using the PhpTags Widgets. There will be all sorts of user interface elements and such as fontawesome and foundation...

I can't say exactly when this will be done and whether it is implemented at all. It's just what I wanna get. I have no deadline, I have a lot of fun :-)

I started out using a magnificent SMW extension, but for me it was too confusing, large and unwieldy (most likely this is because I used it not on purpose).

Now, regarding your needs. I'm going to do the first point anyway. I'm also not difficult to do for you 3 and 4 points, but I can't devote time to their further development and support. Also I can do the second point, but it seems it is not necessary to me nor to you.

PhpTags also needs finishing improvement, such as cache for the compiler and category for pages with errors and probably other.

Regarding performance: PhpTags is not designet for running PHP code like LUA in Scribunto, It is implementation Magic expressions therefore any comparison is incorrect. By pre-compiled to bytecode, it must run faster than Magic words with parameters. By easy initialization in general cases (when used properly) it is faster than Scribunto.

If you make a PhpTags SMW extension, that's way more than I expected. :) I think I can then maintain it (and perhaps add further functionality, if needed) without problems. I'm keeping track of the development of the major extensions I use in any case, and then that would come to include both Semantic MediaWiki and PhpTags.

Regarding being the only one (apart from you of course) showing interest in PhpTags, it seems to me that there is generally not much interest in scripting so far. That includes Scribunto as well, outside of the Wikipedia sites. This lack of interest is perhaps not so surprising, because as of yet, what has been made available does not add such great capabilities. When that changes, I think that's the time when interest in scripting extensions may increase in general.

The plans you have sound very interesting, though I'd also expect that getting it all done, if that happens, will take quite some time. Though in the meantime, as PhpTags functionality is extended, it may sooner become the most powerful scripting extension thus far. Good luck, and I guess we'll see where it all goes. :)

As for performance: I know that PhpTags doesn't directly run PHP code, but I was thinking that if PHP itself is speeded up, then the PhpTags bytecode interpreter would run the scripts faster. That may not be so important, though, since it performs well anyway.

Yes, I'm sure the users will be interested only after the widgets are implemented. But I was hoping to attract the attention of other developers to this solution but it's failed. All I have been told that the direct execution the code is not good, it is reinventing the wheel, it is slower than pure PHP while Lua is faster than PHP and then Scrubunto is the best choice.

I tried to explain that this all wrong but I had been ignored. For me, it remains a mystery why this happened. May be the interest in scripting is not much, but it seems this is the only possible solution to resolve all problems at once. Prior to Scribunto have been other attempts to do this, for example: WikiScripts, StackFunctions, PHPTemplates, Winter and likely other.

I strongly believe the best solution is upgrading Magic words. I removed the deficiencies and added new features in it and named this as Magic expressions. And I believe PhpTags has the best performance.

Maybe I'm too chatty, just, I have been developing this solution for more than a year and you're first with whom I can discuss it. I sometimes think that all this nonsense and unnecessary. Thanks for the chat. I still know English not very well, but I hope you understand me perfectly. :-)

Regarding communicating the ideas and not being understood by other developers, it seems to me that there's very different ideas about what scripting is to be used for. I think this may play a part, and that it is perhaps also related to which approach people take to wikis and the software they use. For example, Wikimedia is fairly conservative – the Wikipedias don't generally embrace new extensions that change how things are done, especially not how the content is structured and what is stored. (Some interface and workflow changes are exceptions.) So to them, scripting is not about combining the functionality of extensions – because they have fairly few things to combine. Instead, each "module" they write is like a little "extension" in itself, in the form of a script which uses more "standard" means. Together, the collection of such scripts forms a big codebase inside the wiki, used to accomplish tasks.

At present, Scribunto is more suited to that kind of scripting. It requires sometimes large "modules" which depend on other modules – the modules build on one another to provide functionality.

Then there are people who have a different approach to wiki software in general. You could say it is more "progressive" in the sense of a willingness to explore and experiment with new functionality and new ways of doing things. That includes advanced extensions that greatly change the "way" things are done on a wiki. Such people will notice both what is made possible by the software they use and/or develop, and the limitations. And then ideas such as PhpTags and "magic expressions" can more easily make sense: use scripts to combine all that advanced functionality you're interested in, removing the limitations and using it the way you'd like to. So I think such developers are the most likely to be interested.

Finally, you will probably find that this question of "conservative vs. progressive" is a spectrum, a little bit like the political spectrum. In other words, you will also find a lot of people somewhere in the middle. Most of them (whether users and/or developers) are probably going to be more hesitant, waiting until they see something concrete done that they also find would work for them.

Anyway, that's what I think regarding Scribunto vs. PhpTags: They are intended for two different problems – and which solution makes the most sense depends on which problem you think in terms of.

I have added property WPage::$DEFAULT_SORT_KEY. Example. I hope it is what you meant in the first point.

Also I have requested space in Git for new extension PhpTagsSMW where I'll do 3 and 4 points for you.

Yes, that's the feature I had in mind. :)

And I see the repository is in place. Thanks a lot for doing this – as mentioned in the above reply, I can then maintain it in the future, and do any further development that comes to mind, if any.

I've added two objects (ExtArrays and ExtSQI) to repo. I was able to check the ExtArrays object, but I cannot check the ExtSQI object. it is in gerrit. As we've agreed, you yourselves will develop this extension, Chad has already added you to owners.

For my part, I will provide all possible assistance and I will write documentation for developers. Feel free to ask me any questions :-)

I've tested ExtArrays and will get to testing and finishing the ExtSQI addition next. Then we'll see how I continue, and I'll ask any questions that come up. :)

For now, I ran into a problem/bug while testing ExtArrays, but I think it's unlikely the source of it is in the new code you added. See the message I added in gerrit for details.

Four eyes are better than two :-)

There are still some code that has test covered is not enough. Thanks for the bug report.

As you can see, I've made changes in PhpTags that are incompatible with older versions of extensions, so I had to update all PhpTags extensions.

Regarding HHVM

I installed MediaWiki-Vagrant at my computer and did test with 100100 loops. It took 2.062 sec therefore PhpTags in HHVM 5.5 times faster than in Zend PHP (11.462/2.062=5.56)

Unfortunately, there are some compatibility issues bugzilla:69014. I'll test and fix it.