Abbiamo un bel problema

Gkx

Admin
Dunque siamo passati alla versione sandboxed? Da quando?
le chiamate a lua sono sempre nella loro sandbox, che nella versione luasandboxed (che non stiamo utilizzando perché mandava in segfault php) sono interne ai processi php (adesso sono esterne)

la mia idea comunque era di avere nell'articolo solo un richiamo a un nuovo modulo

nel modulo elenchi/per_tipo dovrebbe esserci una funzione che itera con un ciclo for su una tabella lua e ogni volta chiama il modulo dell'entry per aggiungere il risultato (in html) all'oggetto che viene ritornato alla fine...

in pseudolua scritto in due minuti

-- articolo

{{#invoke elenchi/per_tipo|render}}
 
 
-- modulo:elenchi/per_tipo
 
local entry = import "modulo:entry/blah"
 
local e = {}
 
local data = {
  {'alakazam', 14, 22, 45, 66},
  {'arbok', 65, 28, 58, 33},
  ...
}
 
e.render = function()
  html = ''
  for obj in data
    html += entry(obj[1], obj[2], obj[3], obj[4], obj[5])
  return html
end

return e
 

il contro è che i dati stessi finirebbero nel modulo

non so se questo sia fattibile o una buona idea, però è la prima cosa che mi è venuta in mente per velocizzare il tutto, dato che alla fine si farebbe una sola chiamata a lua.
 
Ultima modifica di un moderatore:

Maze

TypoMzn
Wiki
Io avevo pensato a un qualcosa del tipo

-- Commenti vari

local h = {}

h.entry = function(frame)
local p, pz = par(mw.clone(frame.args)), {}
local entry = require(table.concat{'Modulo:', p[1], '/entry'})
for a, b in pairs(p) do
table.insert(pz, entry(args))
end
return table.concat(pz)
end

return h

in cui par è una funzione che fa robe tipo il trim al frame.args e ritorna i risultati e args sono gli argomenti degli entry singoli, che dipende da come facciamo la chiamata. Mi si sta formando qualcosa in mente, ma non sarebbe meglio concentrare i nostri sforzi su come far partire la versione sandboxed? Oltre a risolvere il problema sarebbe anche più performante, e questo è lo scopo primario dell'introduzione di lua nel wiki.
 

Gkx

Admin
scusami, forse non ho capito bene il funzionamento di questa cosa... come lo useresti negli articoli?

comunque se il funzionamento di luasandbox non è perfetto è perché tecnicamente l'estensione è ancora in beta... ma a prescindere da questo, luajit utilizzato com'è adesso dovrebbe essere comunque molto performante, il problema si verifica appunto quando le chiamate sono tante e singole.  una cosa come quella che ho descritto sopra, usando mw.load al posto di require, dovrebbe essere gestibile tranquillamente dal server, e forse avere i dati delle entry come tabelle lua nei moduli invece che nelle invocazioni è anche più pratico per fare cose tipo ordinare gli elementi automaticamente, oltre al fatto che alla fine sono dati che non cambiano...

non so, vedi tu, io una prova adesso la faccio e misuro quanto ci impiega
 

Maze

TypoMzn
Wiki
Per le tabelle avevo già pensato da tempo di fare un bel modulo con alcuni dati molto utilizzati sui singoli Pokémon, ad esempio il tipo e il numero, ma alcune informazioni, ad esempio il livello a cui un Pokémon impara una data mossa, devono necessariamente essere passati di volta in volta.

Non dimentichiamo i nostri editor, poi, per i quali questo sistema risulterebbe alquanto più ostico. Io sono dell'idea di adottare la versione sandboxed appena possibile, senza però dimenticare questa cosa del rendering, perché credo che 600 e passa chiamate potrebbero risultare problematiche anche per la versione sandboxed

La mia idea era quelle di lasciare come argomenti del modulo direttamente le attuali chiamate ai template, e poi con un po' di lavoro sulle stringhe estrapolare le informazioini utili.
 

Silez

BEST LURKER EVER.
A volte ritornano.. come mai anche oggi la wiki fa qualche capriccio? :D
 
Ultima modifica di un moderatore:

CiaobyDany

あなたと見る絶望は あなた無しの希望など霞むほど輝くから
Wiki
Potrebbe essere colpa mia, ho fatto una sostituzione automatica di un po' di pagine, ma che io sappia non dovrebbero dare problemi...
 
Top Bottom