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
Special pages? #9
Comments
Yes re WhatLinksHere. Lists by type I would make not functions with labels in a particular language, but rather ZObjects according to their Z1K1. That already will get us quite far. Other search functionality would be ZFunctions by return type and ZFunctions by types of input. If we had that that would already be a huge help! |
Ok, pull request #11 fixes WhatLinksHere! |
Thanks for merging; so I'm working on the other Special pages by type. I have it basically working, but I'd like to put a label by each Z object id on the pages (if possible for WhatLinksHere too). The "Z36(zid)" method seems to produce very nice text for a label, but it's super-slow to run it as is done in AbstractTextContent.php (it would be nice to speed that up too!) So alternatives I've been considering for fixing this are: Any strong feelings on any of this? |
Actually I got a little distracted there with the alternatives - Z36 doesn't quite do what I'm looking for anyway. I'm going to try adding labels just using the getLabel approach for now, and see how bad that is. But feedback on running eneyj as a server (and how that might be done) is still of interest to me! |
to follow up - getLabel is quite speedy and works well, going with that for now |
Yes, we'll probably need to run eneyj as a server anyway at some point. Also this would improve performance not just for the start up but also for the caching, which is quite considerable. I haven't looked into that yet. Thank you so much for making WhatLinksHere work! I am very much looking forward to the other special pages! |
Ok, see pull request #14 ! |
I am trying out your pull request, but the DB table doesn't seem to be created, so the special pages fail. I started with a fresh docker, i.e. running
Error message:
|
Uh-oh, I should have tried restarting the docker instance from scratch! php maintenance/update.php |
Hmm, maybe that just needs to be added to the docker startup. I'll try that. |
Ok - see pull request #15 - I don't know if there's a better way to do that, but this works! |
I am trying it again, but the Functions by Parameter and FUnctions by Return type don't seem to work? |
The objects by type works beautifully and so fast! |
Are you going to http://localhost:8081/index.php/Special:FunctionsByReturnType and (or whatever port you're using) |
Ok, I did the docker rebuild and I'm seeing the same issue - digging in! |
The problem appears to come from the sequence of Z object imports. If a function is imported before its types, then it doesn't get to the code that adds the return and argument types. I've tweaked this to fix this specific problem, but maybe we should adjust the import sequence to import types first? Or maybe that's not really necessary? The import process doesn't really need to do as much as it does right now... |
@arthurpsmith Are you using |
@vrandezo see pull request #17 - that should fix the issue when building from scratch with docker. An alternate workaround is to log into the docker container and run the refreshLinks.php maintenance script, which will reprocess everything and does work this time because the types have already been imported! But with #17 everything should work from scratch. @thadguidry as far as I know the Dockerfile here will work with or without buildkit - I'm not too familiar with that though, what are the advantages? |
@arthurpsmith try it out, its very simple to use, just add the environment variable as described in docs. The advantages are:
It makes repeated builds much faster, since it introduces "smarts" around caching (cache this layer, skip it, or build from scratch again) to know about changes. Akin, to other build caching in MAVEN, Buildr, etc. |
@thadguidry thanks, I'll have to try it. However, the slowness in import is almost entirely due to the text rendering running 2 eneyj scripts via shell calls, so that means it's starting up node 1000+ times; otherwise the standard docker build caching is plenty fast! |
@arthurpsmith Sure. This info might be useful for you later as well, if ever needed. https://www.docker.com/blog/advanced-dockerfiles-faster-builds-and-smaller-images-using-buildkit-and-multistage-builds/ |
@thadguidry Ah I see - the main advantage I think is where you need parts of an image, but want to throw away the rest of it to keep the final image small. I don't think that's something that is an issue here, but it might be if we diverge more from the Mediawiki base image. For now I think everything we're adding in the builds (extensions, npm modules, mediawiki updates etc.) is stuff we need to keep around. |
@arthurpsmith Exactly my thinking and why I mentioned it.... for your future. :-) |
Thank you so much @arthurpsmith ! The special pages are really great, they make navigating the wiki so much easier! I have tested them and think we can close this issue now. Thank you! |
Great! Closing! |
Hi Denny - I'm wondering if you've had a chance to think about/look at what some of the Special pages should do? I'm particularly interested in:
I've taken a peak at the Mediawiki extension documentation on this, but it will take a bit more time to figure out how best to do this I think, so if you have any advice I'd appreciate it!
The text was updated successfully, but these errors were encountered: