The 32-bit issue at https://github.com/rdfhdt/hdt-cpp/issues/135 that was mentioned above seems to be resolved, so perhaps this can be revisited now?

@Bstorm Can you comment on the Web UI issue that @Ssamuel1010 has added to the task description?

I just set up T270915 to discuss a Wikimedia BinderHub deployment.

I have been using the autosave feature for a while now but recently noticed another hickup (see the autosave remark just above cell 39 in this notebook).

There is a JupyterCon talk on Provbook, with a demo starting at about 19 min 10s.

Thanks. Wasn't aware of the autosave option.

I also checked https://public.paws.wmcloud.org, which is still accessible and suggests that the problem occurred after 2020-Nov-10 16:17.

I have the same problem.

In T266943#6597350, @Chicocvenancio wrote:

Launch in Binder as in mybinder.org or should it be Launch in PAWS? If the latter, this becomes T264603

A brief update on the topics listed above:

A stumbling block along the way is described in https://phabricator.wikimedia.org/T266915 .

Perhaps it would be useful to take NEP 29 as a guideline for which versions to support.

@srodlund I've seen your post above but have not had the time yet to go through the included links systematically. Of course, feel free to use anything from the JupyterCon presentation.

@srodlund I'd be happy to assist with the PAWS part, which is featured prominently in my JupyterCon presentation.

This was fixed by way of https://wikitech.wikimedia.org/wiki/Special:PasswordReset .

@LucasWerkmeister I did not use the back button back then, and I just retried it (without hitting the back button) now, getting "Internal Server Error - The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application." after submission and reload.

I'm fine moving this to GitHub. The reason I posted it here is that
https://tools.wmflabs.org/lexeme-forms/
links to
https://phabricator.wikimedia.org/source/tool-lexeme-forms/

I can reproduce the bug in Firefox 70.0.1 (64-bit) on MacOS Mojave 10.14.6.

Here are two more batches that just stopped mid-way:
https://tools.wmflabs.org/quickstatements/#/batch/20371
https://tools.wmflabs.org/quickstatements/#/batch/20372

Batch https://tools.wmflabs.org/quickstatements/#/batch/18811 also stopped (at " 82.2% (488) of 595 done, 1 errors") without manual interference.
Trying to reset errors...

I am now running https://tools.wmflabs.org/quickstatements/#/batch/18806 as a replacement for https://tools.wmflabs.org/quickstatements/#/batch/18726 .

In that example, I was trying to indicate the publisher of these journals. This does not absolutely have to be via an image, and we do not necessarily have a logo image for all of them. But the main problem right now is that the tool somehow converts the image file name to all UPPERCASE, which then impedes fetching the file from Commons.

Another use case is described at https://twitter.com/fnielsen/status/1129865931528843264 , as compared to the topics-works matrix at https://tools.wmflabs.org/scholia/author/Q5565155 .

Thanks to everyone who helped resolve this!

It worked for a while today but now I'm logged out again and cannot log back in.
All edits through the tool seem to have stalled as well (for any user), and https://tools.wmflabs.org/quickstatements/api.php gives a HTTP 500 error.

I am having those repetitive logout issues again.

From my end, the repetitive logout issue looks resolved. Anyone know what caused and fixed it? Anyone still having problems?

As far as I can see, this is not limited to QuickStatements - when I'm logged out (as just happened again - my "usual" time is at 21 min into the hour), I cannot access SourceMD either. Access normally comes back around 37 min into the hour, even if I press the "log in" button immediately after being logged out.

Thanks!

In T211629#4812463, @Fnielsen wrote:

"Non-tabular WDQS embeds do not display": Note embedded tables neither works. Embedded tables show the same errror

Here's how this looks like in Scholia (it's a whole-page screenshot which is apparently outsized for Phabricator, so you have to click on the image to actually see it rather than the mystery placeholder image).

This could be related to the UI update, as per https://twitter.com/wikimediatech/status/1072190613636952069 .

Thanks for the progress so far. I'd like to see the tool expanded to cover usage of Wikidata outside namespace 0 (including on Wikidata itself) and in SPARQL queries/ API calls.

Ideally, clicking that button would translate into something SPARQLable attached to that statement, e.g. a reference of the kind "within focus list" (P5008) "WikiProject Citation needed". See also citation needed constraint (Q54554025), which works on basically any statement involving a property, rather than a specific statement.

Thanks!

I just got French text on https://www.wikidata.org/wiki/Q1035 (with language set to English) but a purge fixed it.

Thanks. This is a known issue (cf. https://github.com/fnielsen/scholia/issues/53 and https://github.com/fnielsen/scholia/issues/189 ) for which we have not found a good solution yet - see discussion at https://github.com/fnielsen/scholia/issues/301 .

Thanks all!

The problem seems to affect graphs in general, not just the two types mentioned above. Other examples are the Co-author graph and Academic tree graphs in author profiles, e.g. https://tools.wmflabs.org/scholia/author/Q8219 .

@WMDE-leszek Can you provide some more details on why this is to be phased out?

Thanks for working on this, @Addshore . Looking forward to see this resolved - had to cancel a demo of it due to the spam interfering.