Moduldiskusjon:External links

Rang

Denne løsningen vil liste alle oppføringer, inklusive de som har rang deprecated. — Jeblad 10. mar. 2016 kl. 20:16 (CET)

Logikken er kopiert "rått" fra Modul:Sportslenker, så jeg har ikke kommet så langt enda.. ser at det er en del som må tas hensyn til her ja. Stigmj (diskusjon) 10. mar. 2016 kl. 20:23 (CET)

regexConverter

Ja, det er en veldig begrenset regex-converter, men så langt er det kun slike enkle tester som benyttes i qualifierene for de enkle utsagnene. P1793 for selve "hovedutsagnet" bruker flere egenskaper som også ikke er støttet og det bør finnes en bedre løsning på dette. Synes det er litt rart at dette ikke har blitt tatt hensyn til i forbindelse med implementasjonen av Lua her. De legger inn regex'er for å kvalifisere utsagnene, men gir oss ikke verktøyene for å gjøre noe med dette, eller har jeg oversett noe her? Stigmj (diskusjon) 29. mar. 2016 kl. 14:39 (CEST)

Wikibase skrives i PHP, mens vi bruker Lua. I Lua er det kun implementert en nokså begrenset form for regulæruttrykk, som har en mye mer kompakt kodebase. PCRE er en reimplementering av Perl sine regulæruttrykk, og de er tunge. Det er heller ingen garanti for at disse avslutter i endelig tid. Det finnes noen ufullstendige implementasjoner av PCRE i Lua, det er eventuelt mulig å spørre om å få satt opp disse. Lurer på om de ble utelatt pga sikkerhetsproblemer, men de er uansett nokså tunge. Et alternativ til et PCRE-kompatibelt bibliotek er å oversette til FST. — Jeblad 29. mar. 2016 kl. 14:57 (CEST)

Bruk av qorder

I linje 94; for _, qualid in ipairs( qorder ) do, ser ikke helt hvorfor det loopes over en enkelt property. Vil vel tro at det kan settes opp flere i fremtiden, men det trenger muligens en forklaring. — Jeblad 29. mar. 2016 kl. 14:49 (CEST)

Duplisering av data

Vær snill å fjern duplisering av informasjon.

Eksempel fra Tecumseh (Nebraska)

(en) Kategori:Tecumseh, Nebraska – bilder, video eller lyd på Wikimedia CommonsRedigere på wikidata

Det er mange som jobber hardt for å rydde opp i rot og duplisering på Wikipedia og andre prosjekter, ikke legg inn slikt som skal i sidemargen. — Jeblad 10. mai 2016 kl. 16:13 (CEST)

Dette er ikke en diskusjon som hører hjemme her, men på Wikipedia:Tinget da det er en større endring i forhold til innholdet i artiklene som er påvirket, samt at det er et kontroversielt tema, basert på tidligere diskusjoner jeg har sett om dette. Jeg er personlig helt enig i at det er totalt unødvendig fra en desktop-site sitt behov, men mobilbrukere har ikke disse sidemarg-lenkene og vil følgelig miste denne informasjonen. -- Stigmj (diskusjon) 10. mai 2016 kl. 16:45 (CEST)

Du har utvidet malen med oppføringer som ikke hører hjemme i den. At Tecumseh (Nebraska) ikke har en sidemarg med disse lenkene er en stråmann. — Jeblad 10. mai 2016 kl. 17:18 (CEST)

Akutt behov for refactoring

Denne modulen er i akutt behov for refactoring. Cyclomatic number er ikke i nærheten av å være på håndterbart nivå. — Jeblad 21. nov. 2016 kl. 14:58 (CET)

Refactoring anyone? — Jeblad 28. apr. 2018 kl. 14:04 (CEST)

Sitt profil for juniorer

Det står nå Harry Connick jr. sitt profil på .... Kan noen korrigere slik at det blir sin når etiketten slutter på punktum eller et ord med små forbokstaver? Eller droppe sin/sitt som det har vært diskutert her. --Avilena (diskusjon) 23. aug. 2017 kl. 22:07 (CEST)

Funktionen mw.wikibase.getEntity er meget langsom

Sporet i Phabricator (?)
T203357

Funktionen mw.wikibase.getEntity (eller aliaset mw.wikibase.getEntityObject) er meget langsom at udføre for store entiteter. Jeg målte omkring 400 ms for at hente entiteten Usain Bolt (Q1189) på dansk Wikipedia. Dette modul bruger mw.wikibase.getEntityObject to gange for hver property det tester. Det er ekstremt ineffektivt. Det er derfor at der er time-out (over 10 sekunder Lua-tid) på artiklen Usain Bolt. Vi havde samme problem på dansk Wikipedia. Jeg løste det der med en simpel ændring (se da:Special:Diff/9647818), så entiteten kun hentes en gang. Jeg anbefaler at I gør tilsvarende. --Dipsacus fullonum (diskusjon) 25. aug. 2018 kl. 23:51 (CEST)

Da ingen svarede, lavede jeg selv rettelsen. Antal artikler i Kategori:Sider med skriptfeil faldt fra 27 til 8 på grund af ændringen. (De øvrige 39 sider i kategorien er i andre navnerom). --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 00:11 (CEST)

The function getEntityObject hits a cache holding the last six entries, and should be pretty fast. If you measure several seconds then something else is probably wrong. Most likely some hits empties the cache. — Jeblad 2. sep. 2018 kl. 03:43 (CEST)

@Jeblad: Nej, rationalet for ændringen er ikke forkert. Der er en cache på 14 entiteter (se mw:Extension:Wikibase Client/Lua#mw.wikibase.getEntity), men selv når entiteten hentes fra cachen tager det tid at oprette mange nye tabeller og strenge. Her er et eksempel udført i feilsøkingskonsollen hvor samme entitet hentes to gange i træk:

=os.clock() ..  ' '.. type(mw.wikibase.getEntity('Q28614')) .. ' '.. os.clock() .. ' ' .. type(mw.wikibase.getEntity('Q28614')) ..  ' ' .. os.clock()
0.31644 table 0.39596 table 0.40668

Det ses at mw.wikibase.getEntity-kaldet udføres på 79 ms første gang, og 10 ms anden gang. De 10 ms tæller op når kaldet bruges ca. 500 gange for {{Sportslenker}}. Og avfallsinnhenting vil også give et meget stort ekstra tidsforbrug når minnet bliver fyldt op med nye entitetsdata hele tiden. Derfor betød ændringen at 19 artikler som har store entiteter på Wikidata gik fra skriptfeil på grund af tidsutløp til at kunne renderes på få sekunder. --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 10:01 (CEST)

Nice, cache changed last year, wasn't aware of that.

Checked in the console for one call with the timing module and your result are consistent

timing=require 'Module:Timing'
=timing.count(1)
=timing.sets(1)
=timing(mw.wikibase.getEntity, 'Q28614')
=timing(mw.wikibase.getEntity, 'Q28614')

First gives

Each call was running for about 8.3e-02 seconds.
	Mean runtime for each set was 8.3e-02 seconds,
	with standard deviation of 0.0e+00 seconds,
	minimum 0.0e+00, maximum 0.0e+00.
	Total time spent was about 8.3e-02 seconds.
Relative load is estimated to inf.

Second gives

Each call was running for about 1.0e-02 seconds.
	Mean runtime for each set was 1.0e-02 seconds,
	with standard deviation of 0.0e+00 seconds,
	minimum 0.0e+00, maximum 0.0e+00.
	Total time spent was about 1.0e-02 seconds.
Relative load is estimated to inf.

And a new run for 100 calls after reload

timing=require 'Module:Timing'
=timing.count(10)
=timing.sets(10)
=timing(mw.wikibase.getEntity, 'Q28614')

That gives

Each call was running for about 1.1e-02 seconds.
	Mean runtime for each set was 1.1e-01 seconds,
	with standard deviation of 2.5e-02 seconds,
	minimum 0.0e+00, maximum 2.0e-05.
	Total time spent was about 1.1e+00 seconds.
Relative load is estimated to 57,461.0.

That is bad as it implies the code does something wrong. With caching this should be way less than 1ms. I'll write a bug about it.

Anyhow, the module code has a lot of issues and should be fixed. (In particular it loops through very large structures instead of using hashes, but in general its complexity is way beyond any sensible limit.) — Jeblad 2. sep. 2018 kl. 18:06 (CEST)

Det tager så lang tid fordi at der skal oprettes mange tusinde tabeller ved hvert kald af getEntity (5386 tabeller for Q28614), og de skal bagefter fjernes af avfallsinnhentingen. Det er ingen feil. Det er sådan lua fungerer. --Dipsacus fullonum (diskusjon) 2. sep. 2018 kl. 21:23 (CEST)

= #mw.dumpObject(mw.wikibase.getEntity('Q28614')) - #string.gsub(mw.dumpObject(mw.wikibase.getEntity('Q28614')),'{','') 
5386