Re: [Python] struct unpack di un intero
Ciao, perche' di default viene rispettato l'allineamento che il dato
dovrebbe avere in memoria se fosse una struttura c:
https://docs.python.org/3/library/struct.html#struct-alignment
Roberto De Ioris
Il giorno gio 21 ott 2021 alle ore 11:12 Marco De Paoli
ha scritto:
> ciao a tutti!
> ho un problema con struct.unpack e non capisco cosa sto sbagliando...
>
> >>> struct.unpack("i", b'\x03\x00\x00\x00') # OK!
> (3,)
> >>> struct.unpack("ih", b'\x03\x00\x00\x00\x04\x00') # OK!
> (3, 4)
> >>> struct.unpack("ihi", b'\x03\x00\x00\x00\x04\x00\x00\x00\x04\x00') #
> ARGHHH
> Traceback (most recent call last):
> File "", line 1, in
> struct.error: unpack requires a buffer of 12 bytes
>
> Perché mai se ne aspetta 12? Dovrebbero bastare i 10 che ci sono nel
> buffer!
>
> Mi aspettavo:
> >>> struct.unpack("ihi", b'\x03\x00\x00\x00\x04\x00\x00\x00\x04\x00')
> (3, 4, 4)
>
> Cosa sto sbagliando?
>
> Marco
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python
Re: [Python] Lavorare con le matrici.
> Buongiorno. Che modulo consigliereste ad un principiante, per iniziare a > 'lavorare' con le matrici numeriche? Matrici intendo bi o tridimensionali. > R_ora ottengo le bidimensionali annidando delle liste, ma immagino ci > siano modi più agili. Ad esempio se volessi 'shiftare ' l'intero contenuto > di una matrice, oppure ruotarlo, lavorare con le liste sarebbe > lunghissimo, lento e scomodo. > Gabriele. > > Inviato da Gabryphone 7 Plus. > _______ > direi numpy -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
[Python] Nuova release per UnrealEnginePython
Ciao a tutti, vi segnalo che e' disponibile una nuova release del plugin python per Unreal Engine 4. Ci tengo particolarmente ad annunciarla perche' e' la prima che include una test suite che puo' essere usata anche come base per i propri giochi/simulazioni (a meno che non vogliate scrivere i vostri unit test in C++ ;) Il sito del progetto e' qui: https://github.com/20tab/UnrealEnginePython (i binari sono disponibili per mac e win, su linux tocca ancora compilare da sorgente ma sto facendo del mio meglio per risolvere sta rottura) Per chi non sapesse cosa e' unreal engine vi linko lo showreel nuovo di zecca per il 2017: https://www.youtube.com/watch?v=WC6Xx_jLXmg A pycon terro' un talk sul progetto, vi aspetto :P -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Python e Unreal Engine 4
Ciao a tutti, vi segnalo il rilascio di un plugin per embeddare Python3 in Unreal Engine 4 (per chi non lo sapesse e' tra i game engine piu' usati al mondo, soprattutto dalle grosse compagnie, ed e' open source [ma non free software]). https://github.com/20tab/UnrealEnginePython Sempre per chi non lo sapesse, questo engine si programma tramite c++ o tramite programmazione visuale a nodi (blueprints) ... e ora anche python :) Per ora e' supportato su Windows e MacOSX. A breve arrivera' il supporto per Linux. (driver della scheda video permettendo :( ) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Offerta di lavoro 20Tab
Ciao a tutti, 20Tab, con sede a Roma (zona est) e’ alla ricerca di un programmatore Python full time on-site. La base dell’offerta e’ contratto a tempo indeterminato con netto tra i 1200 e i 1500 in base alle competenze del candidato. La maggior parte dei progetti riguarda applicazioni web realizzate con Django, quindi la conoscenza del framework e’ ampiamente gradita (ma non necessaria). Skill apprezzate sono la conoscenza di PostgreSQL, redis, Solr, uWSGI, nginx, Jira/Taiga e dimestichezza con gli ambienti Linux e/o Mac. Requisiti necessari sono il sapere utilizzare git e dare una adeguata copertura di test al codice. L’offerta e’ aperta a candidati di tutti i sessi, religioni, etnie e gusti alimentari. Se interessati potete inviare il vostro curriculum a i...@20tab.com Grazie e scusate il disturbo -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] OT ma interssante
2015-07-13 0:00 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: il resto della leggenda anti mela ti lascio volentieri le tue convinzioni Ticoto solo una parte dell'annunciodi ricrca personale per l'Apple Store di Bologna di qualche anno fa (gates ancora vivo). Non cerchiamo tecnici, maghi del computer o commessi. Cerchiamo persone in grado di vendere una emozione. Dopo di questo ogni altro commento penso sia superfluo. Io acquisto uno strumento (computer, tablet, smartphone) non una emozione. Le emozioni le provo con le persone non con costosi oggetti. E' appena morto Satoru Iwata (Nintendo, per chi non lo sapesse). Saro' malato, ma a me gli oggetti, i giochi, la musica o i film con Schwarzenegger danno emozioni eccome. E per favore non paragoniamo Jobs a Gates, saranno entrambi marchettari, ma sono due simboli completamente diversi (e francamente so' bene quale vorrei che seguissero i miei figli tra i 2). Che poi la gente comune fraintenda i loro messaggi (ma qui e' piu' colpa dei media) e' un problema che non si risolve di certo dicendo che Ritchie era piu' genio di Jobs. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] OT ma interssante
Beh scusa ma paragonare una azienda che punta sull'entertainment (e lo ha sempre fatto benissimo) con una che afferma di avere rivoluzionato la tecnologia (senza verlo fatto) e' un poco un paragone sballato. Mi riferivo alla tua frase che le emozioni te le danno le persone e non le cose. E comunque quando guardo le pubblicita' dei nuovi prodotti di tecnologia, e' palese che ormai il design sia stato sdoganato anche li', quindi Apple da quel punto di vista una rivoluzione l'ha fatta. Puo' non essere rilevante per te (come per molti altri) ma a me piace non dovermi portare un obrorio di 10k appresso per lavorare. (e se vai in un centro commerciale vedrai che la maggior parte dei prodotti ancora sono orripilanti) Non mi pronuncio sul software, perche' non sono davvero in grado di fare una valutazione onesta o oculata. Per me i loro prodotti hanno un'anima (cosi' come tanti altri), e' un concetto difficile da esprimere senza sembrare un coglione :) Vagli a dire a un alfista che la sua macchina e' solo una macchina. O a un amighista (per restare in tema) che il suo amiga nel 2015 e' solo un pezzo da museo. Io pure, il terzo (non so ancora bene quale tra i tanti che mi vengono in mente sarebbe quello che proporrei, ma di certo nessuno dei due citati, votate per nessuno dei suddetti insomma). purtroppo e' una scelta che faranno loro, quindi e' sempre meglio prepararsi a tutto :) Spiegami quali messaggi si fraintendano? Parlo in particolare di quello di Stefano Lavori (*) piu' che di quelli di Guglielmo Cancelli (*). Innanzitutto non ritengo che Gates sia un icona, ho come l'impressione che il mondo si stia dimenticando di che cavolo ha combinato la SUA compagnia tra meta' anni 90 e i primi 2000. E' stato probabilmente il periodo piu' buio dell'IT, il fatto che Microsoft abbia tirato fuori l'Xbox non e' sufficiente per il mio perdono :) Con Jobs per lo meno puoi sfruttarti (parlo sempre da genitore) tutta la roba smielata, dell'avere sogni, ambizioni e blah blah... e il fatto di dare un'anima a quello che crei. (cosa molto difficile da fare, pochi compagnie nella storia ci sono riuscite) Poi oh, e' ovvio che Ritchie era un genio e ha cambiato davvero al mondo, ma come faccio a spiegarlo a mia zia senza che le esca il sangue dal naso ? Queste sono icone pop, devono essere fruibili a tutti (e quindi romanzarne la vita fa parte del gioco) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
Il 24/03/2015 21:15, Carlos Catucci ha scritto: https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/ Myth #8 Mi era parso di capire che ci sono dati per dire che il problema e' reale ed e' una delle cose che sta spingendo alcuni verso Go. Hmm, python HA una marea di engine di concorrenza, e alcuni di altissimo livello e davvero per tutti i gusti. Il problema forse e' proprio questo: ce ne sono troppi, e tutti incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura delle librerie di comunicazione (come i db adapter e simili). Chi dice che passare da sincrono ad asincrono sia una questione di monkey patching, o e' molto fortunato o non ha capito una mazza di quello che sta facendo. Node e Go hanno deciso che basta un solo engine/approccio, il primo ti dice che con la programmazione a callback fai tutto (e vabbe' qui si apre un mondo [di bestemmie]), il secondo che i thread in userspace (passatemi il termine) sono la cosa piu' bella del mondo. Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa molto pythonica). -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
Il 25 marzo 2015 09:17, Roberto De Ioris robe...@unbit.it ha scritto: Mi era parso di capire che ci sono dati per dire che il problema e' reale ed e' una delle cose che sta spingendo alcuni verso Go. Hmm, python HA una marea di engine di concorrenza, e alcuni di altissimo livello e davvero per tutti i gusti. Il problema forse e' proprio questo: ce ne sono troppi, e tutti incompatibili tra di loro e 9 volte su 10 richiedono la riscrittura delle librerie di comunicazione (come i db adapter e simili). [...] Il non dover scegliere e' un grande vantaggio (ed e' anche una cosa molto pythonica). `asynchio` [¹]·[²]·[³] mira esattamente a risolvere questo problema. Hmm si, fermo restando che la trovo una delle specifiche piu' sovraingegnerizzate di python (che cavolo sembra una roba in java :P), passeranno anni prima che si possa parlare di un qualcosa di concreto. E poi vabbe', qualsiasi applicazione python scritta in asyncio non mi sembra python :) Ho seguito un talk al fosdem (per carita' interessante), ma mostrava in 20 righe quello che si fa da anni con 2... e il problema e' che ne servono 2 anche in go e javascript/node :) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
Roberto De Ioris ha scritto: Node e Go hanno deciso che basta un solo engine/approccio, il primo ti dice che con la programmazione a callback fai tutto (e vabbe' qui si apre un mondo [di bestemmie]) Esattamente. :-D il secondo che i thread in userspace (passatemi il termine) sono la cosa piu' bella del mondo. Beh, il termine non rende molto l'idea. Le goroutine sono dei microthread con un mapping M a N gestito dal runtime del linguaggio. Continuerei a chiamarle goroutine per semplicità. :-) Se vieni a firenze saro' la tua ombra, anche in bagno, appena dici una frase sbagliata ti do' un coppino e ti correggo. Dannato pignolo.. Pace e poliamore... -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
Roberto De Ioris wrote: Se vieni a firenze saro' la tua ombra, anche in bagno, appena dici una frase sbagliata ti do' un coppino e ti correggo. Dannato pignolo... Purtroppo (o per fortuna ;-) ) non ci vengo. Ah, ho aggiunto un puntino alla fine della tua frase, spero non ti scocci. ;-D Pace e poliamore... Pace e poliamore sempre. (Coppini in bagno e poliamore nello stesso messaggio mi lasciano lievemente perplesso.) dannazione. punto tuo. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
enrico franchi wrote: In realta' il comportamento che descrivi e' l'implementazione della versione principale di go. Nella specifica, non dice niente su M - N. Dice solo che viene chiamata as an independent concurrent thread of control. Grazie, m'era sfuggito. E in effetti gccgo, l'ultima volta che ho controllato, le mappava 1:1 sui thread dell'OS. Sul serio?!? È sufficiente per impedirne l'uso in molti casi. :-( Solo nella primissima incarnazione. Gia' nel 4.8 si usava makecontext()/swapcontext(), con l'aggravante che ogni volta che veniva fatta una chiamata a una libreria C veniva generato un pthread (ma questo succedeva anche con le prime versioni di go, proprio per evitare casini con lo stack). Nel 4.9 sono stati introdotti gli split stack (feature belissima, che gia' ho avuto occasione di usare in altri contesti) il che ha avvicinato le goroutine di gccgo a go. Inoltre il runtime di gccgo si embedda (anche se in modo rocambolesco, vedere mio post di qualche giorno fa) in ambienti c/c++/obj-c quindi e' un bel vantaggio. E purtroppo (mi tocca dirlo) l'unico di gccgo :( -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
Nicola Larosa n...@teknico.net: Impatta la scalabilità. Usare un thread per ogni operazione concorrente significa esser limitati a qualche migliaio di esecuzioni contemporanee, con alti consumi di memoria. Per arrivare a milioni di connessioni contemporanee bisogna usare approcci più come gli eventi asincroni, o i processi di Erlang, o appunto le goroutine del runtime di Go. Vista la vostra esperienza, giusto per paragone, visto che conosco bene java, Per scalare milioni di connessioni si usa un selector thread che gestisce tutte le connessioni chiamate native I/O e attiva un thread da un pool per gestire la richiesta una volta che che è arrivata. Questo permette di avere migliaia di connessoni per JVM. Tenendo conto che l'I/O è estremamente più lento di gestire una richiesta, un solo selector thread gestisce facilmente tante socket ciclando su ognuona di esse in modo sequenziale. E i threads che gestisono le richieste sono rapidi in quanto non non sono appesi ad aspettare bytes dalle socket. c'è una libreria python che si avvicina a questo modello? Sei sicuro che funzioni cosi' ? Proprio il mese scorso ho smembrato uno stack j2ee (jboss, coucho resin ecc. ecc.) e da quello che ho visto il thread selector si limita a chiamare l'accept() e tenere il file descriptor in coda nell'attesa che ci sia un thread in attesa (tra quelli fissi del pool). Quindi hai solo aumentato la mole di richieste che puoi mettere in coda, non quante ne puoi gestire in concorrenza. (il che mi sembra un bell'approccio enterprise per vendere a qualche dirigente bambacione) Quello che descrivi te mi sembra parecchio rocambolesco (continuo context switch tra thread dedicati all'i/o e tread puramente cpu-centrici), ma se e' davvero cosi', tanto di cappello :) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 10 myths
2015-03-25 12:36 GMT+00:00 Roberto De Ioris robe...@unbit.it: Nel 4.9 sono stati introdotti gli split stack (feature belissima, che gia' ho avuto occasione di usare in altri contesti) il che ha avvicinato le goroutine di gccgo a go. Ma sbaglio o gli split-stack girano solo su Linux? direi di si (a meno che non sia cambiato qualcosa di recente) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-20 12:35 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Sarebbe comodo se fosse possibile con clone di Linux, dire al kernel di non mappare nel processo figlio una certa regione di memoria, ed usare questa regione per memorizzare tutte le variabili usate per la sincronizzazione. Ma anche se fosse possibile, probabilmente gli sviluppatori di Go non la userebbero perchè aumenta la complessità. proponila alla lkml, a me gia' ha fatto venire in mente diversi usi :) Ripensandoci, non è già possibile con p = mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0) ? Dalla pagina del manuale non mi è chiaro se un processo figlio eredita la regione di memoria. La eredita ma in COW, quindi appena il figlio ci scrive viene generata una nuova pagina (quindi praticamente non e' utilissima senza un file da mappare) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
Allora ho seguito le istruzioni ma uwsgi non ne vuole sapere di partire. Il log file e' desolantemente vuoto, ho provato anche con /etc/init.d/uwsgi restart. Continuo a pensare che sia meglio il mestiere del piadinaro ambulante, alla fine. Carlos Il fatto che parli di /etc/init.d/uwsgi mi lascia molto molto perplesso (upstart e' il tuo unico obiettivo visto che sei su ubuntu.) Hai seguito il quickstart che ti ho linkato da cima a fondo ? Ti e' tutto chiaro ? Ricapitolando: - accertati di aver costruito un file di config decente, per cui se lanci (da utente non privilegiato) uwsgi nomefile.ini hai l'output su terminale e ti puoi collegare con il browser alla porta specificata con successo. Un file di esempio (cambia django_project e percorso_di_wsgi.py con la dir/file del progetto): [uwsgi] ; avvia il server http sulla porta 8080 http = :8080 ; cambia la directory nel progetto di django chdir = django_project ; abilita il master master = true ; metti 4 processi per avere un po' di concorrenza processes = 4 ; carica django wsgi-file = percorso_di_wsgi.py Quando funziona, ti fermi un attimo perche' dovrai prendere delle decisioni: - con che utente e gruppo lo faccio girare (accertati che l'utente possa leggere i file del progetto) ? - dove voglio loggare (file, syslog, socket ...) (accertati che l'utente possa creare/leggere/scrivere il file di log, in caso sia un file)? ipotizziamo che l'utente sia pippo e il gruppo pluto e che vuoi loggare in /var/log/uwsgi.log (ipotizzando che il tuo utente possa creare file dentro /var/log, altrimenti usa /tmp o la dir del progetto). Aggiungi al file .ini: uid = pippo gid = pluto logto = /var/log/uwsgi.log E rilancia (sempre da terminale): uwsgi nomefile.ini se tutto va bene vedrai solo un annuncio che il file .ini e' stato letto e poi il terminale restera' appeso. Apri il file di log e controlla che ci sia tutto. Se c'e' tutto resta solo di sistemare upstart. Crea /etc/init/uwsgi.conf # simple uWSGI script description uwsgi tiny instance start on runlevel [2345] stop on runlevel [06] exec uwsgi --die-on-term percorso_assoluto_al_file.ini (--die-on-term ti serve fino a 2.0, se stai usando uWSGI 2.1 il problema dell'uso idiota di SIGTERM e' stato risolto) Questo e' un setup minimale, tutto il resto viene dopo. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:08 GMT+01:00 Roberto De Ioris robe...@unbit.it: 2015-03-19 17:01 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Comunque credo che tutti gli application server piu' utilizzati possano fare il dropping dei privilegi dopo aver fatto il bind sulla 80 Non proprio tutti: https://github.com/golang/go/issues/1435 vabbe' dai, il runtime di go e' talmente atipico che questi problemi gli si perdonano :) (e te lo dice uno che qualche anno fa si e' pesantemente incazzato per via del fatto che non vogliono supportare fork() come dio comanda) Ho trovato il thread su golang-nuts. Cosa intendi che senza fork non funziona mmap? mi riferisco a mmap(..., MAP_SHARED, ...) che e' la base di tantissime tecnologie (tra cui postgresql). Il succo e' che se mi vendi un linguaggio come 'di sistema' e poi non ci posso riscrivere il mio postgres ci rimango un po' male :) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
L'idea è che postgresql usa un processo per ogni connessione, mentre in Go useresti una goroutine. hmm, mamma mia, mi darebbe la stessa fiducia di mysql che e' multithread :) Un uso di fork molto utile/comodo, IMHO, è quello che ne fa redis quando effettua il dump del database su file. Usando fork non ha bisogno di sincronizzare l'accesso al database, potenzialmente rallendando o bloccando eventuali lettori/scrittori. giusto, non ci avevo pensato Anche la demonizzazione, non la vedo come una mancanza grave. Con systemd, ad esempio, sembra non sia più necessaria. infatti non credo di averla mai citata, anzi e' una di quelle cose di unix che mi ha sempre fatto abbastanza schifo :) Sarebbe comodo se fosse possibile con clone di Linux, dire al kernel di non mappare nel processo figlio una certa regione di memoria, ed usare questa regione per memorizzare tutte le variabili usate per la sincronizzazione. Ma anche se fosse possibile, probabilmente gli sviluppatori di Go non la userebbero perchè aumenta la complessità. proponila alla lkml, a me gia' ha fatto venire in mente diversi usi :) Alla fine, comunque, credo che a Go manchi un nuovo tipo di sistema operativo, oppure per gli sviluppatori sistema significa Plan9 (su questo punto ho letto di molte critiche). in realta' a me go va benissimo cosi', ho imparato a considerarlo un linguaggio via di mezzo. Non sostituisce in toto C, non sostituisce in toto Python. E' un altro livello. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
pero' che due maroni. Ho sempre usato hosting (tipo Alwaysdata) che mi danno la possibilita' di deployare un progetto Django senza dover impazzie troppo. Al massimo richiedono una specigfica struttura nell'albero delel directories, tipo mettere static in root del progetto oppure nelal cartella dove riside anche settings.py, per dire. Stavolta devo deployare su un server su cui o pieno accesso. Primo tentativo: nginx+uwsgi. Non va neppure se lo prendo a calci sui denti. Secondo tentativo: siccome le cose non vanno aggiungiamo un layer di complessita', per farci del male. Ho provato a mettere Gunicorn. Sara' che non sono una giovane fanciulla vergine, ma nessun risultato apprezzabile. Bene mi sono detto, torniamo sul caro vecchio Apache2. Assieme al suo modulo mod_wsgi dovrei avere vita facile (memore dei tempi in cui usavo il poco efficiente mod_pthon ma che andava liscio). Per farla breve sono alla frutta (niente banane, grazie!). Qualcuno ha un link ad un tutorial fatto bene davvero che poi funziona? Il server e' un Ubuntu Server 10.04. Guarda questo di solito fa' contenti tutti: http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html ma seguilo passo passo (quindi non usare i pacchetti di ubuntu, soprattutto della versione obsoleterrima che stai usando) Visto che la distribuzione non e' piu' supportata ipotizzo che sei in una lan, quindi nginx puoi anche evitartelo. Una volta che l'app gira su uWSGI, fermati li' :) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
Beh, probabilmente nessuno, come non hai probabilmente nessun vantaggio a usare nginx in una intranet, gunicorn da solo bastava (come quasi sicuramente potevi usare anche il runserver di django) Questo non lo capisco: in una intranet non c'è ugualmente bisogno di un vero web server? Nel mio caso ho parecchi uffici distanti, qualche centinaio di utenti e dei contenuti statici importanti (immagini di grandi dimensioni), quindi pensavo che lasciare tutto in mano a Gunicorn o al server di sviluppo di Django non fosse fattibile. Grazie, Marco Hmm scusami, nella mia mente una intranet la associo sempre (erroneamente) a una roba piccola (una dozzina di utenti, spesso nella stessa rete). Evidentemente nel tuo caso non e' cosi'. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:43 GMT+01:00 Roberto De Ioris robe...@unbit.it: Quindi /home/jester/public_html/globeX/globeX/wsgi.py esiste ? cat /home/jester/public_html/globeX/globeX/wsgi.py ti restituisce il suo contenuto ? occhio che django si aspetta la chdir nella dir del progetto, quindi e' piu' probabile che sia /home/jester/public_html/globeX e non /home/jester/public_html/globeX/globeX (a meno che non hai qualche impostazione strana) Risolto, dovevo indicare --ini e non --file. Ora mi chiedo, come lo automatizzo? Se io chiudo la console adios uwsgi. Ecco perche' pensavo servisse nginx o qualcosa di simile. http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#automatically-starting-uwsgi-on-boot Visto che sei su ubuntu: http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
On 19 March 2015 at 17:46, Carlos Catucci carlos.catu...@gmail.com wrote: Devo fare un file uwsgi.py che poi punti al file wsgi.py ? Provo intanto Niente. Ho creato un file uwsgy.py [uwsgi] chdir = /home/jester/public_html/globeX/globeX wsgi-file = /home/jester/public_html/globeX/globeX/wsgi.py ma mi dice sempre che wsgi.py non riesce a caricarlo Quindi /home/jester/public_html/globeX/globeX/wsgi.py esiste ? cat /home/jester/public_html/globeX/globeX/wsgi.py ti restituisce il suo contenuto ? occhio che django si aspetta la chdir nella dir del progetto, quindi e' piu' probabile che sia /home/jester/public_html/globeX e non /home/jester/public_html/globeX/globeX (a meno che non hai qualche impostazione strana) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:28 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Non credo sia possibile supportare fork. fork da problemi ovunque, anche su Python... C'e' poco da fare, per supportare fork() devi prenderla in considerazione dall'inizio in fase di progettazione (e ti costringe a scelte solo in funzione di lei) Ossia buttare fuori i threads? :) Perchè il problema di fondo è proprio quello che fork e thread non vanno d'accordo. Questa e' la loro risposta ufficiale e vabbe'. Ma ti assicuro che di approcci ce ne erano eccome. Ad esempio usare pthread_atfork per rigenerare tutti i thread necessari al runtime (lo scavenger e amici). Oppure semplicemente fare un wrapper per fork() che quando la chiami rigenera tutto il runtime (quello che ad esempio fa' uwsgi con gccgo, che pero' e' tutta un'altra bestia) https://github.com/unbit/uwsgi/blob/master/plugins/gccgo/gccgo_plugin.c#L212 Di sicuro roba complicata e che rendeva una parte gia' complessa del codice ancora piu' complessa, ma secondo me ne valeva la pena. Vabbe' oh, alla fine e' una fissa mia, se ai gopher sta bene cosi' mi adatto :) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:01 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Comunque credo che tutti gli application server piu' utilizzati possano fare il dropping dei privilegi dopo aver fatto il bind sulla 80 Non proprio tutti: https://github.com/golang/go/issues/1435 vabbe' dai, il runtime di go e' talmente atipico che questi problemi gli si perdonano :) (e te lo dice uno che qualche anno fa si e' pesantemente incazzato per via del fatto che non vogliono supportare fork() come dio comanda) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 16:46 GMT+01:00 Roberto De Ioris robe...@unbit.it:
Accertati che DEBUG sia a True nel settings, altrimenti non hai speranze
(django fara' i ltrapping di ogni eccezione).
I log ce li hai nello stdout (dovresti vedere una linea per ogni
richiesta)
La sola cosa che mi dice
--- no python application found, check your startup logs for errors ---
[pid: 24482|app: -1|req: -1/9] 192.168.1.82 () {36 vars in 611 bytes} [Thu
Mar 19 17:19:15 2015] GET /routers/access/ = generated 21 bytes in 0
msecs
(HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
Il che mi preoccupa alquanto :)
Sali piu' su', all'inizio uWSGI sputa fuori una marea di informazioni. A
un certo punto ti dice anche che non e' riuscito a caricare qualcosa
(magari qualche path e' sbagliato, la virtualenv e' rotta ecc. ecc.)
--
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
Ho seguito alla lettera ma quando lancio l'applicazione ottengo solo un Internal Server Error senza alcuna spiegazione. Dove trovo i log file di uWSGI? Ho installato con pip in un virtualenv Carlos -- Accertati che DEBUG sia a True nel settings, altrimenti non hai speranze (django fara' i ltrapping di ogni eccezione). I log ce li hai nello stdout (dovresti vedere una linea per ogni richiesta) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
On 03/19/2015 01:13 PM, Roberto De Ioris wrote: Hmm scusami, nella mia mente una intranet la associo sempre (erroneamente) a una roba piccola (una dozzina di utenti, spesso nella stessa rete). Ma anche su di una Intranet non vedo il motivo per cui non mettere un nginx davanti a Django o al vostro framework web preferito, non foss'altro per il fatto di togliersi di torno tutti gli utenti che si lamentano di dover scrivere a mano la porta della webapp (no, far girare una webapp come root non lo considero nemmeno) Perche' e' uno strato in piu' da mantenere. Comunque credo che tutti gli application server piu' utilizzati possano fare il dropping dei privilegi dopo aver fatto il bind sulla 80 (male che vada fai una regola di iptables e via) uWSGI ti permette in aggiunta di usare CAP_NET_BIND di linux per tagliare la testa al toro. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:08 GMT+01:00 Roberto De Ioris robe...@unbit.it: 2015-03-19 17:01 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Comunque credo che tutti gli application server piu' utilizzati possano fare il dropping dei privilegi dopo aver fatto il bind sulla 80 Non proprio tutti: https://github.com/golang/go/issues/1435 vabbe' dai, il runtime di go e' talmente atipico che questi problemi gli si perdonano :) (e te lo dice uno che qualche anno fa si e' pesantemente incazzato per via del fatto che non vogliono supportare fork() come dio comanda) Non credo sia possibile supportare fork. fork da problemi ovunque, anche su Python... C'e' poco da fare, per supportare fork() devi prenderla in considerazione dall'inizio in fase di progettazione (e ti costringe a scelte solo in funzione di lei) Il problema e' che per un linguaggio che si vende come di sistema, non supportarla e' un limite pesantissimo (specialmente su linux dove tutte le funzionalita' piu' interessanti si basano proprio sulla generazione di processi figli che condividono l'address space alla nascita). Guarda docker, alla fine deve richiamare processi esterni per fare una roba che richiede 2 syscall... -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
2015-03-19 17:10 GMT+01:00 Roberto De Ioris robe...@unbit.it: Sali piu' su', all'inizio uWSGI sputa fuori una marea di informazioni. A un certo punto ti dice anche che non e' riuscito a caricare qualcosa (magari qualche path e' sbagliato, la virtualenv e' rotta ecc. ecc.) a naso direi che possano essere le due righe che ho evidenzito con degli asterschi alla fine compiled with version: 4.8.2 on 19 March 2015 16:39:32 os: Linux-3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 nodename: test001 machine: x86_64 clock source: unix detected number of CPU cores: 1 current working directory: /home/jester/public_html/globeX/globeX detected binary path: /home/jester/public_html/globeX/bin/uwsgi !!! no internal routing support, rebuild with pcre support !!! *** chdir() to /home/jester/public_html/globeX/ your processes number limit is 7593 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uWSGI http bound on :8000 fd 4 uwsgi socket 0 bound to TCP address 127.0.0.1:42312 (port auto-assigned) fd 3 Python version: 2.7.6 (default, Mar 22 2014, 23:03:41) [GCC 4.8.2] Python main interpreter initialized at 0x124f970 python threads support enabled your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 415280 bytes (405 KB) for 8 cores *** Operational MODE: preforking+threaded *** failed to open python file wsgi.py *** unable to load app 0 (mountpoint='') (callable not found or import error) *** no app loaded. going in full dynamic mode *** *** uWSGI is running in multiple interpreter mode *** adesso vedo se cosa sia il pcre support e come fare il rebuild No non serve, non credo userai quelle funzionalita', il tuo problema e': failed to open python file wsgi.py pasta il file di configurazioen che stai usando e il path in cui risiede la tua app django. Di regola e': [uwsgi] chdir = directory_progetto_django wsgi-file = nome_progetto/wsgi.py -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Io lo so che coem sistemista faccio schifo
On 19 March 2015 at 17:30, Roberto De Ioris robe...@unbit.it wrote: pasta il file di configurazioen che stai usando e il path in cui risiede la tua app django. Di regola e': [uwsgi] chdir = directory_progetto_django wsgi-file = nome_progetto/wsgi.py WSGI config for globeX project. It exposes the WSGI callable as a module-level variable named ``application``. For more information on this file, see https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/ import os os.environ.setdefault(DJANGO_SETTINGS_MODULE, settings) from django.core.wsgi import get_wsgi_application application = get_wsgi_application() Devo fare un file uwsgi.py che poi punti al file wsgi.py ? Provo intanto Carlos -- No fermo, hai gia' il file wsgi.py dentro il tuo progetto (se non ce l'hai stai usando una versione vecchissima di django, e in tal caso si' ti serve creare un file wsgi.py NON uwsgi.py mi raccomando) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Oggetti condivisi in app uwsgi e multiprocessing in generale
Ciao, utilizzando python puro, quindi senza nessun framework alle spalle, ma con l'esposizione di semplici funzioni tramite l'uso di mod_uwsgi di nginx, uwsgi, e il catch dell'url, tipo: def application(env, start_response): if env['HTTP_HOST'].find(hello_world) -1: hello_world(env, start_response) c'è un modo noto, e magari anche semplice semplice, per tenere degli oggetti condivisi fra le varie istanze lanciate da uwsgi? Ad esempio come farei con web.ctx in web.py https://www.mail-archive.com/webpy@googlegroups.com/msg01208.html? web.ctx funziona con il multithreading, quindi in ogni caso non funzionerebbe con il multiprocesso (a meno che non vuoi usare uWSGI in multithread e in quel caso puoi condividere oggetti come ti pare al semplice costo di distruggere l'universo se non sei bravo con i thread [e in questo pianeta mi dicono non lo sia nessuno]) Tieni presente che se vuoi fare il caching dati, soluzioni come redis o memcached sono lo standard de-facto (nessuno ti impedisce di salvarci dentro oggetti serializzati come fa ad esempio django). Il proxy con twisted mi sembra davvero una esagerazione. Se poi hai esigenze di performance superiori, per cui avere uno stack di rete tra l'app e la cache sarebbe troppo costoso c'e' la cache di uWSGI: http://uwsgi-docs.readthedocs.org/en/latest/Caching.html -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] .net e visual studio open source e versione community
2015-01-22 10:05 GMT+01:00 Vincenzo Campanella vin...@gmail.com: In ogni caso, mi pare prematuro avanzare giudizi, tanto che ancora VS 2015 non è uscito. Sul concreto, si vedrà col tempo se e come i porting di .net verso altre piattaforme ben differenti da Windows (Linux e Mac su tutte) verranno fatti. Miguel (De Icaza) ci ha provato con Mono, con risultati se non deludenti neppure all'altezza delle aspettative. Dici ? Unity (il motore per videogiochi) e' completamente basato su Mono, ed e' molto apprezzato (e personalmente, lavorandoci pesantemente da qualche mese, non posso che concordare). Forse non e' diventato quello che De Icaza si aspettava all'inizio, ma di sicuro si e' preso una fetta di mercato non indifferente. Per quanto riguarda la diffidenza degli sviluppatori open source verso il progetto devo darti ragione, ma alla fine sono i risultati che contano, e Mono ne ha ottenuti (e in un settore difficilissimo) -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs Java
Oh, questo mi interessa... ma *davvero* uno che non ha mai programmato in 10 giorni tira su roba sensata in Django? Perche' capisco il sito della fattoria di nonna papera, ma io penso al numero di cose elementari che vanno conosciute anche per un sito semplice e non mi sembra sia roba che si fa in 10 giorni a prescindere dal linguaggio di programmazione. A me sembra che se su tutto questo inserisci imparare un linguaggio, imparare a programmare e imparare un framework (con i vari annessi, tipo due o tre cose sceme su db e oop) altro che 10 giorni. Direi che forse si comincia a ragionare con 6 mesi se il tipo e' sveglio. Cavolo... mi ero illuso di riuscire ad usare Django qui sotto le ferie... Se gia' programmi e hai un minimo di nozioni base sul web e' possibilissimo. Ma sperare che uno che non ha mai programmato ci riesca e' davvero fantascienza (poi vabbe' se uno e' un genio o e' talentuoso e' un discorso a parte). Forse ci si dimentica che programmare non e' solo usare uno strumento, ma e' anche una forma mentis, un approccio alla risoluzione dei problemi che potrebbe non far parte dei processi mentali di una persona (che per carita' puo' acquisire, ma ci vuole tempo, come per qualsiasi nuovo processo mentale artistico o scientifico) Secondo me anche il sito di nonna papera sarebbe chiedere troppo. -- Roberto De Ioris http://unbit.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Il troppo stroppia (era: Re: Quando è opportuno usare @staticmethod?)
In particolare, il goto di C e' piuttosto safe. Non e' certo il goto dei vecchi basic. E non ci sono molti costrutti che ci fanno a cazzotti (come in C++; ma tanto li ho le eccezioni e vado pure meglio) Perdonami ma io i problemi che evidenzi a NON usarlo mai visti. Ai tempi dell'università, il goto ci era stato caldamente consigliato di non usarlo. Della serie: esiste, ma guai a voi se lo usate. Walter Questa cosa del goto in C e' stata gia' discussa in lista qualche anno fa. Non ho idea di cosa si insegni nei corsi accademici, ma goto in C si usa eccome, anzi e' un ottimo modo per migliorare la leggibilita' e la qualita' del codice. Francamente ci sono svariati costrutti che rabbrividerei al solo pensiero di farli senza goto (mi ritroverei con dei blocchi annidati da competizione). Il kernel linux, apache, nginx, i vari BSD, python stesso sono strapieni di goto. Poi ovvio se si usa il goto al posto di una funzione (come si faceva in basic) stai facendo male. Se usi il goto quando hai altro (come le eccezioni in C++ come diceva enrico) stai facendo male. Ma il c moderno (sempre che voglia dire qualcosa visto che il linguaggio non si e' praticamente mai evoluto) senza goto sarebbe un incubo. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Il troppo stroppia (era: Re: Quando è opportuno usare @staticmethod?)
2014-12-05 17:36 GMT+01:00 Roberto De Ioris robe...@unbit.it: Poi ovvio se si usa il goto al posto di una funzione (come si faceva in basic) stai facendo male. Se usi il goto quando hai altro (come le eccezioni in C++ come diceva enrico) stai facendo male. Ma il c moderno (sempre che voglia dire qualcosa visto che il linguaggio non si e' praticamente mai evoluto) senza goto sarebbe un incubo. a me fu insegnato che se lo usavi avevi sbagliato algoritmo beh ti hanno insegnato qualcosa che si discosta parecchio dalla vita di tutti i giorni (almeno negli ultimi 15 anni) :) Prendi ad esempio l'implementazione di marshal.c in Python. Non puoi non dire che goto renda il tutto piu' leggibile e chiaro. Poi oh, i tempi cambiano, magari tra 10 anni tutti si mettono a usare longjmp/setjmp -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] So che non c'entra
http://www.italia-film.org/17589-mega-python-vs-gatoroid-2011-streaming-film/ Oltre ad essere pesantemente OT, hai segnalato uno dei film più brutti che abbia avuto la (s)fortuna di vedere. Per entrambe le cose si profila la prova TV ed una lunga squalifica per te. ;-) Dai, i film di The Asylum non possono essere giudicati, sono una cosa a se' fuori da ogni schema :) (non dico che mi piacciono, ma alla fine non posso fare a meno di vederli ogni volta che ne esce uno per vedere fin dove si spingono, vi dico solo che in alcuni capita che a meta' film cambino gli attori o spariscano dei personaggi senza motivo ) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Avventure grafiche in stile lucasart
Ciao a tutti. Mi era sconquiferata l'idea di capire come si crea questa tipologia di giochi che amo tantissimo ed, ovviamente, se fosse possibile usare python. Mi chiedevo se c'era qualche sito da leggermi ma con google ho trovato solo un certo Ren py che mi pare troppo orientato sullo stile moderno. Le AGI specifications ti faranno sicuramente commuovere :) In particolare il funzionamento delle priority bands http://wiki.scummvm.org/index.php/AGI/Specifications/Overview#The_priority_screen Piu' in generale sul sito dello scummvm (http://scummvm.org/) troverai tantissime info e tutorial. E si, puoi usare certamente python per realizzare l'engine. Ovviamente ci sono approcci piu' rapidi ed efficienti (e che ti permettono di concentrarti solo sulla trama e la logica dei puzzle), ma se lo fai per capire come funziona/funzionava questo mondo mi sento di suggerirti di partire dal basso livello (pygame, pyglet e amici ti saranno utilissimi, senza contare che potresti lavorare server side e renderizzare su canvas ;) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] celery, uwsgi smart-attach-daemon
On Tue, Sep 23, 2014 at 08:30:15AM +0200, Roberto De Ioris wrote: Ciao a tutti, sto cercando la configrazione ottimale per fare partire celery con django in produzione. Uso nginx + uwsgi per l'applicazione principale e credevo leggendo [1] [2] che smart-attach-daemon avrebbe potuo risolvere il problema di garantirmi che un reload di uwsgi (uwsgi --reload) inviasse un segnale al processo di celery. Forse ho compreso male la documentazione che in effetti non dice esplicitamente cosa dovrebbe succedere ma solo :: Pidfile governed processes can survive death or reload of the master so long as their pidfiles are available and the pid contained therein matches a running pid. This is the best choice for processes requiring longer persistence, and for which a brutal kill could mean loss of data such as a database. smart-attach-daemon serve proprio ad evitare che un demone venga ucciso durante un riavvio. Effettivamente celery (almeno nella mia mente) e' uno di quei servizi che dovrebbe andare per fatti suoi, e quindi smart-attach-daemon e' l'approggio giusto. Mi pare di capire pero' che tu invece vuoi che a ogni reload corrisponda anche un restart di celery, in questo caso attach-daemon e' quello che ti serve. Eventualmente con attach-daemon2 hai un controllo maggiore sul comportamento: https://github.com/unbit/uwsgi-docs/blob/master/AttachingDaemons.rst#--attach-daemon2 Sarebbe esattamente quello che cerco, ma non riesco assolutamente a vedere alcun segnale. La mia conf è: celery_pid = /var/run/uwsgi/cogema-celery.pid attach-daemon2 = cmd=/usr/local/sbin/test-signals.py %(celery_pid),pidfile=%(celery_pid),stopsignal=3,reloadsignal=15 La script test-signals.py è riportata in fondo. Quando io faccio partire uwsgi nei log leggo: [uwsgi-daemons] found valid/active pidfile for /usr/local/sbin/test-signals.py /var/run/uwsgi/cogema-celery.pid (pid: 31952) Ma poi nessun segnale arriva al processo test-signals.py. Se da console per prova eseguo kill -3 31952, vedo subito il log del segnale arrivato. --attach-daemon2 (e piu' in generale tutte le opzioni che finiscono con '2') sono le versioni user-unfriendly :P che ti permettono di modificare i pattern prestabiliti agendo direttamente sulle strutture interne. Nel caso specifico, settando un pidfile stai forzando la modalita' smart, che non e' quella che vuoi tu. cmd=/usr/local/sbin/test-signals.py,stopsignal=3,reloadsignal=15 e' sufficiente a fare quello che vuoi. Quando lo imposterai per celery, accertati che celery non vada in background (detach/daemonize), anche se mi sembra che nelle versioni attuali sia il default. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] celery, uwsgi smart-attach-daemon
Ciao a tutti, sto cercando la configrazione ottimale per fare partire celery con django in produzione. Uso nginx + uwsgi per l'applicazione principale e credevo leggendo [1] [2] che smart-attach-daemon avrebbe potuo risolvere il problema di garantirmi che un reload di uwsgi (uwsgi --reload) inviasse un segnale al processo di celery. Forse ho compreso male la documentazione che in effetti non dice esplicitamente cosa dovrebbe succedere ma solo :: Pidfile governed processes can survive death or reload of the master so long as their pidfiles are available and the pid contained therein matches a running pid. This is the best choice for processes requiring longer persistence, and for which a brutal kill could mean loss of data such as a database. smart-attach-daemon serve proprio ad evitare che un demone venga ucciso durante un riavvio. Effettivamente celery (almeno nella mia mente) e' uno di quei servizi che dovrebbe andare per fatti suoi, e quindi smart-attach-daemon e' l'approggio giusto. Mi pare di capire pero' che tu invece vuoi che a ogni reload corrisponda anche un restart di celery, in questo caso attach-daemon e' quello che ti serve. Eventualmente con attach-daemon2 hai un controllo maggiore sul comportamento: https://github.com/unbit/uwsgi-docs/blob/master/AttachingDaemons.rst#--attach-daemon2 -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [Fwd: HTTP/2 and WSGI]
Vi riporto una richiesta di Robert Collins per la costituzione di un team che possa redarre un PEP che adatti WSGI a HTTP/2. La questione e' abbastanza spinosa (sotto svariati punti, anche non tecnici) quindi ogni parere/aiuto e' ben accetto. - Hi gentle-folk, I'd like to draw your attention to https://mail.python.org/pipermail/web-sig/2014-September/005244.html wherein I am trying to get a working group of folk together to prep WSGI for HTTP/2's new capabilities. Nick pointed out that it would be a terrible thing to do this work and then have major servers and frameworks hate on it because its not going to work for them. If you've limited time but can commit to e.g. reviewing drafts of the PEP, that would be fine; OTOH if you can e.g put draft code together in your respective projects, that would be better still :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [Django-it] [Fwd: HTTP/2 and WSGI]
Bella iniziativa! Ma HTTP2 è stato pensato dopo gli esperimenti fatti con SPDY? Federico Te possino ..., il top posting :) Comunque si', e' al 99% SPDY (le differenze sono veramente pochissime) Ovviamente gia' questo mette i presupposti per la polemica e per non avere un aggiornamento di WSGI per l'ennesima volta :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 05/set/2014, alle ore 18:28, enrico franchi enrico.fran...@gmail.com ha scritto: 2014-09-04 23:49 GMT+01:00 Balan Victor balan.vict...@gmail.com: Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Per quello che posso dirti e' sempre tutto una scuola di pensiero: parlo con un devops e si esalta per docker, lxc e compagnia bella, parlo con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E il bello e' che succede anche il contrario :) Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries), ma dall'altro lato la deduplicazione di file, librerie e binari di sistema che si portano dietro questi sistemi richiedono una grande responsabilita' (qualita' che spesso si costruisce in anni di esperienza da sysadmin e non a colpi di tool 'fashion'). La stessa cosa ad esempio succede con Go, il fatto che sia tutto compilato staticamente (almeno per ora) fa storcere il naso a parecchi... Chi ha ragione ? Boh :) Per come la vedo io il mondo dei container e' una cosa che non si puo' ignorare, e sono contento che Docker abbia avuto successo perche' ha fatto uscire dalle caverne una sfilza di sysadmin intrappolati negli anni 70 convinti che il paradigma UNIX sia perfetto cosi' (ma vaff...) Basta solo ricordarsi che gli aggiornamenti di sicurezza vanno fatti, e vanno fatti per sempre (e se il cliente non vuole pagare per questo servizio NECESSARIO e' meglio che vi firmi qualche bella cartaccia dall'avvocato) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Per quello che posso dirti e' sempre tutto una scuola di pensiero: parlo con un devops e si esalta per docker, lxc e compagnia bella, parlo con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E il bello e' che succede anche il contrario :) Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries), ma dall'altro lato la deduplicazione di file, librerie scusate qui intendevo duplicazione :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 12:36, Roberto De Ioris wrote: Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries) Link or it didn't happen :) Eh hai ragione, ma mica mi ricordo che intervista era :) Il succo era che si lamentava del fatto che molti sviluppatori di librerie non si curassero di rompere le ABI (non le API) complicando la vita a molti utilizzatori. Me lo ricordo perche' prima di sentirlo non mi ero mai curato di rompere le ABI :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] socket e MSG_OOB: bug?
rispondo e per me chiudo il thread: Il thread era il bug (vedi oggetto) di MSG_OOB e non l'affidabilità dei protocolli di rete. Che poi, i nostri cari protocolli, a qualunque livello delle stack, sono tutti un buco. Va bene, ma almeno la curiosita' di sapere cosa volevi fare potevi togliercela :) Cioe' hai dato l'idea che volevi bucare un server a colpi di messaggi out of band, cioe' siamo ai livelli di codice swordfish :P (con tutto il rispetto per il film, che a parte la fanta-informatica trovo divertente) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] socket e MSG_OOB: bug?
Buongiorno lista. Continuando la mia programmazione relativa all'invio di segnali hex, ho potuto confermare quanto letto in linea che un server python con flag MSG_OOB crasha sempre. E questa è una conferma. Ma è anche vero che un socket client con flag MSG_OOB taglia a destra di un byte il messaggio da inviare. L'ho potuto appurare sia in locale con una semplice applicazione client-server ma anche su un mio server remoto. In intrambi i casi il messaggio è risultato tagliato a destra di una byte. Tipo: msg=hello world e arriva hello worl. Per ovviare allungo di un byte il messaggio e questo arriva completo come messaggio da invio originale. Puoi pastare un po' di codice ? Parliamo comunque di una tecnologia piu' che deprecata e con ogni implementazione che si comporta in modo diverso. Forse mi e' sfuggito e in tal caso chiedo scusa, ma a cosa ti serve ? -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] uWSGI spooler running tasks...
Ciao,
sto lavorando con gli spooler di uwsgi,
ho scaricato Celery perché ha dei limiti nell'utilizzo dei processi come
demoni. E nel lanciare dei task Fabric che usano parallel e
multiprocessing
non funziona.
Tornando allo spooler di uwsgi, mi trovo bene,
ho bisogno però di tenere d'occhio cosa sta facendo, quanti task sono in
coda, quanti sono in esecuzione, etc... sarebbe carino che riuscissi a
vedere anche il contenuto (il dizionario) dei task ancora in coda.
Ma mi basta anche solo accedere alle statistiche senza usare il netcat :-)
spoolers:[
{
dir:works/tasks,
pid:2633,
tasks:2,
respawns:0,
running:1
}
]
Perchè ho già trovato qualche magia nel mudulo uwsgi .. tipo
uwsgi.spoolers
('works/tasks',)
uwsgi.spooler_jobs()
['works/tasks/il_mio_job']
uwsgi.spooler_pid()
3389
uwsgi.parsefile('works/tasks/il_mio_job')
{'execution_id': '4'}
c'è modo usando il modulo python uwsgi di accedere alle informazioni di
quali task sono in stato running?
Queste 2 funzioni non mi sono mai piaciute (infatti non sono documentate
da nessuna parte).
Servivano a un mio collaboratore e gliele ho aggiunte anni fa (solo il
plugin python le espone infatti).
Il bello dello spooler e' che e' tutto filesystem based, quindi per sapere
che succede si usano le primitive posix:
- scan della spooldir per sapere l'elenco dei task
- fcntl su ogni file per sapere se e' lockato (il che significa che e' un
task in corso) https://docs.python.org/2/library/fcntl.html
- parsing del dizionario uwsgi di ogni file per conoscere i parametri
tutto questo si potrebbe implementare in un unico tool con non piu' di 30
righe di python (o di ruby visto che ormai sei rubysta ;).
Scatenati :)
--
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Supporto sperimentale ad asyncio in uWSGI
2014-04-19 12:38 GMT+02:00 Roberto De Ioris robe...@unbit.it: Ciao a tutti, vi segnalo il recente push nel repository ufficiale di uWSGI del supporto (sperimentale) ad asyncio. https://github.com/unbit/uwsgi-docs/blob/master/asyncio.rst [...] Vi ricordo che attualmente (e vista la storia passata, mi sento di dire che sara' cosi' per molto tempo) lo standard WSGI NON e' compatibile con asyncio (o meglio con le coroutine introdotte in python 3.3), quindi l'implementazione che vedete fa uso del modulo greenlet per mappare la callable WSGI su un greenthread (che poi a sua volta puo' fare le chiamate asyncio) Tempo fa avevo scritto questo mostro, per una implementazione asincrona di WSGI per Twisted, che volevo usare come riferimento per la implementazione di WSGI per Nginx: https://bitbucket.org/mperillo/txwsgi/src/tip/txwsgi/greenlet.py Anche questo progetto e' molto carino (tra l'altro italiano anche lui): http://pythonhosted.org/pulsar/ (e ha aggiunto recentissimamente il supporto per le greenlet) L'unica nota negativa (a livello di documentazione) e' che mette poca enfasi (come tutti) sul fatto che django non diventa non-bloccante/asincrono per magia... ma vabbe', ormai non mi ci arrabbio piu' :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Supporto sperimentale ad asyncio in uWSGI
Ciao a tutti, vi segnalo il recente push nel repository ufficiale di uWSGI del supporto (sperimentale) ad asyncio. https://github.com/unbit/uwsgi-docs/blob/master/asyncio.rst Per chi non lo sapesse asyncio (un tempo noto come 'tulip') e' il futuro standard (forse) della programmazione evented/non-bloccante in python = 3.4 Io purtroppo non riesco a farmi piacere la programmazione callback-based neanche se me la immagino con le tette, pero' di sicuro puo' tornare utile a tanti. Vi ricordo che attualmente (e vista la storia passata, mi sento di dire che sara' cosi' per molto tempo) lo standard WSGI NON e' compatibile con asyncio (o meglio con le coroutine introdotte in python 3.3), quindi l'implementazione che vedete fa uso del modulo greenlet per mappare la callable WSGI su un greenthread (che poi a sua volta puo' fare le chiamate asyncio) Ogni report e' il benvenuto. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [lavoro] sviluppatore python/django unbit.is
Unbit.is (divisione web di unbit.it/unbit.com) e' alla ricerca di uno sviluppatore/sviluppatrice python/django per la sede di Torino. L'offerta e' rivolta sia a profili junior che senior ed e' subordinata a un periodo di prova (ovviamente retribuito) di max 3 mesi. L'azienda mette a disposizione un appartamento condiviso di foresteria (a 30 metri dall'ufficio, quindi particolarmente comodo) per chi non fosse residente a Torino (e abbia voglia di spostarsi). Il tipo di clienti (come potete vedere dal sito) e' di fascia molto alta, quindi requisito fondamentale e' la professionalita' (l'ambiente e' molto informale, ma questo non deve trarre in inganno, si lavora duro...) Chi fosse interessato puo' mandare il curriculum (ed eventuali domande) a i...@unbit.it. Particolarmente graditi i link ad eventuali repository pubblici github/bitbucket/ecc.ecc. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Una domanda borderline
Capisco che siamo davvero sulla linea di confine pero' non saprei dove chiedere. http://uwsgi-docs.readthedocs.org/en/latest/#contact Serverino, devo mettere su Django dietro un webserver. Nginx con uwsgi. Tutto bene seguendo il tutorial ma quando vado a mettere nel file /etc/rc.local la riga /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data se lancio a manina rc.local tutto bene, ma al riavvio quando deve eseguire va in loop la procedura di startup. Qualcuno ha qualche suggerimento su dove cercare ? Googlolando (probabilmente sbaglio stringhe da cercare, non so) no trovo nulla. fallo loggare (--logto /tmp/pippo o --log-syslog per averlo nel syslog) magari c'e' qualche problema di permessi o chissa' cosa -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
Ciao, un mio collega ha avuto la brillante idea di togliere Orbited da un sistema web push che abbiamo, perchè voleva passare ai websocket. Così dall'avere N web server python che pushavano messaggi ad un singolo orbited (che non ha mai fatto pio) e i client web che li ricevevano sui loro canali siamo passati ad avere ogni client collegato con una connessione websocket persistente al server. Coincidentalmente da quel giorno abbiamo cominciato a incontrare mille problemi e il programma non scala più bene, chissà come mai... Sto provando a insistere a reintrodurre il message broker perché sono convinto che ci ha parato le chiap^W spalle per anni ma lui non vuole recedere dai websocket. Secondo me un broker ci vuole, anche per come immagino il futuro di quel sistema. Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa a cui i client web si connettono su un canale e altri processi possono mandare messaggi sui canali che decidono. Sapete se esiste qualcosa del genere o se è necessario passare ad un server AMQP (RabbitMQ etc.)? Conosceta Autobahn, sapete se è promettente? Vedo che usa l'ennesimo nuovo protocollo di message passing, WAMP invece di Stomp... oddio ma quanti ne servono? Altre alternative? Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai websocket ma io credo che si riferisca ad avere connessioni al server, non un message broker a sé stante. Giusto Roberto? gia', pero' combinarlo con redis e una coda pub/sub e' relativamente semplice (e soprattutto rapido). Fammi pure contattare dal tuo collega, magari ne uscite senza un bagno di sangue... La logica e' che l'app WSGI instaura la sessione websocket e resta in ascolto anche su redis, ogni volta che c'e' un messaggio sul canale websocket questo viene girato a redis, ogni volta che c'e' un messaggio su redis viene passato al websocket. E' molto efficiente, noi lo usiamo per i videogiochi dove la velocita' e' essenziale. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dio prima li fa e poi ...
2014-03-29 8:59 GMT+01:00 Valerio Maggio valerio.mag...@gmail.com: Personalmente, non mi sento di condannare a priori il progetto, anzi. Mi sembra interessante. E' che io mi sono accorto nel tempo che il frutto non cade mai lontano dall'albero. Se il papa di uno dei due progetti e' diventato quello che era Access per gli hobbisti dell'informatica (sono quindi hobBITs?) per gli attuali hobbisti del ... sito web fatto da mio cuggino che e' tanto bravo con il computer, anche se esteso su larga scala (mi chiedo ancora, esistono appositamente per il Big Data fior di db NoSql ma anche YesSql, che senso ha cercare di fare una versione di un Db pensato per carichi medio-piccoli adattata a qualcosa per cui non e' stato progettato all'inizio? Non si rischia forse una serie di pezze a colore che rendereanno poi il progetto inusabile? Se io mi accorgo di avere sbagliato un progetto butto il superfluo, tengo le poche cose (se ci sono) valide e riscrivo dopo avere riprogettato) che possono svolgere bene quel lavoro. Ottimizzare uno di questi sarebbe piu' facile e non dovresti di base mettere mano alle pecche strutturali del padre. Magari le mie sono considerazioni oziose, e comunque non sono certo io a decidere il successo o meno di un progetto, mi limito ad esprimere una mia impressione, suscettibile di cambiamenti; quando mi parlarono di Python pensai: si carino per fare scripting al posto della bash. Oggi e' il mio linguaggio prediletto. Vero che il Python che conobbi io era una cosa tipo 1.2 o 1.3, e non certo la versione di oggi, pero' lo avevo inizialmente valutato meno potente di quanto poi mi sono accorto essere. Si sbaglia, siamo umani. Per questo ho fatto il post. Non voglio scatenare una holy war, solo capire assieme ad altri, anche piu' bravi di me, se quanto l'oggetto possa essere valido. Di primo impatto il fatto di discendere da un prodotto fallace non mi fa intravedere per lui un cammino tutto rose e fiori. Poi se mi sbaglio, ben venga il mio errare, un prodotto valido e' sempre bene accetto. Questa cosa mi mette addosso una tristezza infinita. Sono un grande estimatore di PostgreSQL (ma riconosco senza vergogna la qualita' di Oracle SQL server e di Microsoft SQL server, seppur trovandoli inferiori in tantissimi aspetti, cosi' come trovo postgresql ancora immaturo in altrettanti punti) e questa mossa dei big, la vedo come un ulteriore danno arrecato a uno dei piu' importanti progetti opensource del pianeta (che non dimentichiamoci e' anche uno degli esempi piu' importanti su come fare business con l'opensource, un modello che dovrebbe essere di ispirazione per TUTTI) Spero di sbagliarmi, ma mentre molti si preoccupano della qualita' di un tale prodotto (io dico, chi se ne frega, basta non usarlo), io ho paura che il danno che questa mossa' portera' sara' di ben altro tipo... -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dio prima li fa e poi ...
2014-03-29 19:19 GMT+01:00 Roberto De Ioris robe...@unbit.it: Spero di sbagliarmi, ma mentre molti si preoccupano della qualita' di un tale prodotto (io dico, chi se ne frega, basta non usarlo), io ho paura che il danno che questa mossa' portera' sara' di ben altro tipo... E di che tipo di danno hai paura? Sul non usarlo, siamo d'accordo. scusa (forse ho scritto di melma), mi riferivo a PostgreSQL, uno dei suoi punti di forza commerciali e' la qualita' e l'affidabilita'. E questo e' un aspetto su cui MySQL non puo' competere neanche lontanamente. Questa mossa rischia di dare una immagine a Mysql completamente nuova. A danno di PostgreSQL. Appena ho letto la notizia stamattina ho pensato: Ma perche' non lavorare sul migliorare PostgreSQL ??? Cioe', perche' migliorare topogigio quando puoi migliorare (ulteriormente, e probabilmente con meno soldi) wolverine ? -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 19:40 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi? La soluzione che hai indicato è quella tipica frontend + backend, nel caso in cui il frontend sa gestire 10K ma il backend no (e spesso non deve farlo). Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione Django minimale fa da frontend e tutto il resto (inclusa connessione al database) la fa un ulteriore backend? Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un div. La parte SSE all'inizio deve essere comunque autenticata, deve prendere dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di che django non serve piu', i dati che mi arrivano sono presi da redis. Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli vedere, passa la connessione (la tecnica usata e' irrilevante) al livello back-backend (chiamiamolo cosi') che si occupa di leggere in maniera non bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe durare ore). A questo punto django ha finito il suo ciclo di richiesta ed e' pronto a gestirne un' altra. Il giro e' proxy non bloccante - application server bloccante - application server non bloccante. Non parlerei di vantaggi, ma di necessita', far digerire a django il modello gevent (o quello che sia) e' talmente tedioso come processo che tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine. Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia l'approccio migliore, ma una azienda che ha investito in Django non passa a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.), quindi bisogna ricorrere a workaround che comunque mantengano un certo di grado di solidita'. (e poi devo ancora trovarne di framework non-blocking-friendly che siano al livello di django) Poi se alcune aziende ci riescono, buon per loro, hanno il mio rispetto e la mia somma invidia :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 4:46 GMT+00:00 Roberto De Ioris robe...@unbit.it: Mi rendo conto che non e' un approccio molto tecnico, ma francamente sentirmi dire che cazzo dici !!! ho letto sul blog di topogigio che si puo' fare e senza sforzo, beh un pochino mi rode... Scusa, ma esattamente la soluzione quale sarebbe? Perche' niente da dire sul fare chiarezza riguardo i problemi di gevent e simili, ma io non e' che vedo molte soluzioni. Perche' programmare multithreading preemptivo ha pure tutti i suoi problemi, multiprocesso puro scala solo fino ad un certo punto e lavorare interamente a callback ha pure gli stessi problemi di gevent dal punto di vista di quello che *non* puoi fare (se non che quelli di twisted sono stati piu' chiari nel dire chiaro e tondo quello che *non* potevi fare gratis) e mi pare di ricordare che lo trovi molto meno comodo -- e se non fosse che mi sono girato la testa per trovare naturale CPS e sono fatto strano io -- sono in essenza d'accordo. Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Il client non si accorge di nulla. Se ci sono altri modi piu' semplici, io personalmente non li ho trovati. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-15 0:54 GMT+01:00 Giampaolo Rodola' g.rod...@gmail.com: 2014-03-14 18:12 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. Rispetto ad un thread il costo è però pressochè nullo. Roberto tempo fa ha scritto che ha visto applicazioni con gevent con utilizzo pesante della CPU, nel caso di molte coroutine. purtroppo si, le greenlet hanno comunque uno stack e gevent comunque in media chiama molte piu' syscall rispetto ad un uso classico (per svariati motivi). E' un prodotto/progetto che adoro, ma va' usato nei posti e nel modo giusto. Oggi ho buttato giu' questo: http://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html ... bisogna farla finita di credere alla favola che django gira gratis su gevent (tantomeno su tornado)... Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... questo non puo' avvenire (facilmente) con i linguaggi che sono nati in un mondo multiprocess/multithread e che gia' hanno una libreria sconfinata di moduli di terze parti (costruita in decenni).. In ogni caso il passaggio non potra' essere indolore (e gia' ci sono le prime vittime, senza contare quelli che hanno proprio disertato cambiando bandiera...) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. In che senso ? nella peggiore delle ipotesi Go fa' l'offloading su un pthread, quindi comunque l'utente e' salvo. O intendi altro ? -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... Nicola Larosa wrote: No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. In che senso? nella peggiore delle ipotesi Go fa l'offloading su un pthread, quindi comunque l'utente e' salvo. O intendi altro ? È vero che l'utente non deve preoccuparsi di nulla, ma non perché le librerie siano tutte non bloccanti bensì perché, come dicevo, Go consente di mischiare in modo trasparente codice sincrono e asincrono. ah ok giustissimo, ma calcola anche che praticamente tutta la standard library di Go e' non-bloccante, il che lo mette in posizione di vantaggio (e anche di tanto) rispetto a python (o a perl o a ruby) anche se gli ultimi progetti che ho rilasciato sono in go, ancora non mi sono innamorato, ma sarei ingiusto a dire che non e' fantastico nella maggior parte delle cose che fa... Credo che offloading su pthread corrisponda a quello che descrivevo come mapping N-to-M delle goroutine ai thread di sistema. Giusto? si esatto, anche la nomenclatura che usano e' piu' fica di quella degli altri :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 2014-03-15 18:08, Roberto De Ioris wrote: Oggi ho buttato giu' questo: http://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html Grazie, me lo rileggo domani con un tasso di sangue nell'alcol più alto. Ma, domanda veloce: This is the whole point of this article: do not use the Django ORM in your gevent apps unless you know what you are doing !!! (read, you have a django database adapter that supports gevent and does not sucks compared to the standard ones...) Con questo dici: 1. impossibile usare django+gevent+psycopg2 in maniera realmente non blocking 2. gevent+psycopg2 funzionerebbe se avesse un wrapper django diverso/migliore 3. django+gevent+psycopg2 funzionano, altri driver/database no 4. vai a letto piro, non c'hai capito niente ed è tardi Grazie ancora :) Nessuna di queste :) ci sono adapter che hanno funzionato (notare il passato), altri che funzionano il 90% delle volte e cosi' via. Il mio obiettivo e' insinuare il dubbio, perche' se usi queste tecnologie devi porti delle domande, e non solo sui db, su ogni punto della tua applicazione. Mi rendo conto che non e' un approccio molto tecnico, ma francamente sentirmi dire che cazzo dici !!! ho letto sul blog di topogigio che si puo' fare e senza sforzo, beh un pochino mi rode... Ad esempio la funzione di entropia di openssl e' ultra-bloccante, e guarda un po' l'ho vista usata in un app django-gevent... (comunque, questo, basato su psycogreen, funziona molto bene: https://github.com/jneight/django-db-geventpool) Dei tutorial (quelli diciamo piu' famosi), che ci sono su django + gevent, solo uno riporta psycogreen, gli altri glissano o consigliano di usare adapter pure-python (che sono spesso lontani dall'essere full-featured) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. Sono rimasto perplesso quando ho provato a cercare qualche ORM da usare con tornado e non ho trovato nulla. Dopo un po di ricerche, da quello che ho capito, un orm non è fatto per lavorare in maniera asincrona. E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione(a parte quella con MySql ma sembra non più supportata). Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. Non hai scritto cavolate, e anzi ti faccio i complimenti perche' nonostante dichiari di non capire bene la materia in realta' ti sei accorto del (secondo me) problema piu' grosso di tutte le tecnologie non-blocking nel mondo python: sono vendute MALISSIMO, in modo quasi dannoso. Il paradigma non-blocking ha una semplice regola: o sei non-blocking al 100% oppure la tua app non funziona. punto. il 99.999% non e' sufficiente. Una singola parte non bloccante ti manda l'app in malora. (ovvio, si potrebbero non avere problemi per mesi, ma all'improvviso una query resta bloccata e tutta l'app va giu'...) Ad oggi ho fatto consulenza su quasi 200 app Django che giravano su uWSGI+gevent o gunicorn+gevent. Di queste neanche il 10% erano corrette in quanto la maggior parte usavano i db adapter standard, o si collegavano a servizi esterni (come api http) usando moduli blocking e cosi' via. Parliamo di quasi il 90% di utenti che stanno usando una tecnologia in modo sbagliato e che continuano a pubblicizzare il loro successo con gevent. La stessa cosa succede con tornado, eventlet e sono sicuro che succedera' con asyncio/tulip Uno dei punti di forza di python (secondo me) e' la gigantesca disponibilita' di moduli, e un utente medio si aspetta di poter continuare a usarli tutti senza problemi, soprattutto se NON gli comunichi a caratteri cubitali tutte le implicazioni del non-blocking (e invece gli porti solo i vantaggi) Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) In conclusione, se sei fortunato troverai un adapter per il tuo db che funziona con tornado, ma dovrai tenere a mente che ogni volta che introduci una funzionalita' questa dovra' cooperare con il resto del sistema. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] email receiver in python
ciao a tutti, ho un sistema che può comunicare con l'esterno solo tramite mail e io ho bisogno ricevere queste mail e in base all'oggetto/contenuto devo eseguire cose. Cercando in giro su google quasi tutti suggeriscono di usare server mail come postfix. Io tuttavia vorrei rimaner su python anche perché non ho bisogno di un vero mail server con annessi e connessi, sarebbe uno spreco. Ho trovato questo snippet di django che dovrebbe fare a caso mio https://djangosnippets.org/snippets/96/ però ho alcuni dubbi. questo (per me) e' il top: http://lamsonproject.org/ (comunque imparare cose nuove non e' mai uno spreco, ache se il mondo dei server di posta e' decisamente brutto ;) PS: Qualcuno mi può spiegare il funzionamento di asyncore? Ho già letto sulla doc ma temo di non aver capito ... :( in una mail la vedo dura :) puoi cercare su google non-blocking programming -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote: Mi pare di capire che la soluzione della listen queue che mi hai indicato risolverebbe questo problema. server = HTTPServer(app) server.bind(post, backlog=1) (prova anche con zero, su alcuni kernel funziona, anche se non ricordo se e' per quelli piu' recenti o quelli piu' vecchi) Purtroppo questa strada non ha funzionato. Ricordo che il probelma che cerchiamo di risolvere è che quando viene interrotto una chiamata lunga, nginx libera quella connessione e quindi diritta verso quel processo la prossima chiamata, ma il processo di fatto è occupato. La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa time.sleep() class IsUp(tornado.web.RequestHandler): def get(self): self.write(Is Up Porta %d ...) self.finish() class Blocking(tornado.web.RequestHandler): def get(self, numero=10): time.sleep(int(numero)) self.write(Bloccato Porta %s\n % options.port) self.finish() la chiamata usando 'wget -q -O - http://ngtest/blocking/30/' ed interrompendolo con Control-c. In un terminale separato in ciclo di 'wget -q -O - http://ngtest/is_up' Il ciclo si blocca nel momento della interruzione e riprende solo quando termita il tempo (e quindi il processo si libera) provate a ridurre a 3 secondi il proxy_connect_timeout di nginx, e' probabile che abbiate sempre almeno uno slot listen_queue libero anche se lo avete impostato a 1/0. In questo modo se la connessione non completa in 3 secondi, nginx considera il peer morto (e passa a quello dopo se lo avete configurato a dovere) Credo di capire che vengono descritte più opzioni di configurazione: con i greenlet ed una programmazione asincrona o con processi tornado indipendenti. guarda terrei questo approccio proprio come ultima spiaggia (e probabilmente e' piu' semplice modificare tornado) se la osluzione sopra non dovesse funzionare -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
Ok, come diceva Alessandro in realtà non siamo nemmeno riusciti a fare dei test con uWSGI e il plugin perchè da errori di Segmentation Fault usando --tornado 100 e --greenlet. Ma usando solo --tornado 100 da questo errore: *** DANGER *** tornado mode without coroutine/greenthread engine loaded !!! Installato e abilitato con: UWSGI_EMBED_PLUGINS=tornado,greenlet pip install greenlet uwsgi Dopo aver installato i pacchetti python-greenlet e python-greenlet-dev visto che senza diceva di non trovare greenlet/greenlet.h Qui sotto mette le informazioni che penso siano utili. # uname -a Linux wadev 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux - # uwsgi.ini [uwsgi] socket = 127.0.0.1:9090 uid = service gid = service pythonpath = /usr/local/python/Lib virtualenv = /dati/wall chdir = /dati/wall/src/test wsgi-file = uwsgi_test.py processes = 4 threads = 2 stats = 127.0.0.1:9191 tornado = 100 greenlet = ## Da risposta trovata in rete a proposito di Segmentation Fault. ;master = true ;enable-threads = true ;singe-interpreter = true # backtrace [uWSGI] getting INI configuration from uwsgi.ini *** Starting uWSGI 2.0 (64bit) on [Fri Jan 3 13:07:47 2014] *** compiled with version: 4.6.3 on 03 January 2014 09:42:28 os: Linux-3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 nodename: wadev machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 2 current working directory: /usr/wall/wall detected binary path: /usr/wall/wall/bin/uwsgi setgid() to 1005 set additional group 27 (sudo) setuid() to 1005 your processes number limit is 15866 your memory page size is 4096 bytes detected max file descriptor number: 1024 - async cores set to 100 - fd table size: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address 127.0.0.1:9090 fd 3 Python version: 2.7.3 (default, Sep 26 2013, 20:13:52) [GCC 4.6.3] Set PythonHome to /dati/wall Python main interpreter initialized at 0xa28aa0 python threads support enabled your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 415280 bytes (405 KB) for 8 cores *** Operational MODE: preforking+threaded *** added /usr/local/python/Lib/ to pythonpath. WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xa28aa0 pid: 27566 (default app) !!! uWSGI process 27566 got Segmentation Fault !!! *** backtrace of 27566 *** uwsgi(uwsgi_backtrace+0x29) [0x467b69] uwsgi(uwsgi_segfault+0x21) [0x467cf1] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fa4c9f8b4a0] uwsgi() [0x4a6494] uwsgi(uwsgi_init_all_apps+0xcf) [0x46897f] uwsgi(uwsgi_start+0xe6a) [0x4699fa] uwsgi(uwsgi_setup+0x1885) [0x46b955] uwsgi(main+0x9) [0x41e459] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fa4c9f7676d] uwsgi() [0x41e489] *** end of backtrace *** direi che non hai il modulo greenlet nel venv -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
nono, ho controllato (wall)root@wadev:/dati/wall# python -cimport greenlet;print greenlet.__version__ 0.4.1 Mi ero perso il pezzo in cui dicevi di aver istallato greenlet dai pacchetti di ubuntu. Devi usare la stessa versione di greenlet nel venv usata per compilare uWSGI, probabilmente ti conviene compilare uwsgi direttamente dal venv cosi' eviti di dover disistallare i package di ubuntu (o sovrascriverli) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
2014/1/3 enrico franchi enrico.fran...@gmail.com 2014/1/3 Manlio Perillo manlio.peri...@gmail.com Per concludere, tieni conto che usare cose come Tornado è tutt'altro che banale. Beh, fare scalare qualcosa di non asincrono e' ancora meno banale, IMHO. Tutto lo stack (applicazione + framework + eventuali librerie) deve essere sviluppato con la programmazione asincrona in mente. Vero. Ma d'altra parte non e' che ci sia un mucchio di soluzioni. O molli python del tutto... A parte erlang e nodejs c'è altro di utilizzabile?go? Python e' utilizzabilissimo, e' solo che devi essere consapevole (stessa cosa in ruby o in perl), poiche' ci sono diversi framework per la programmazione asincrona e devi sceglierne uno (io consiglio sempre gevent, ma dopo averlo studiato, non perche' sia migliore tecnicamente ma perche' e' quello con la base di utilizzatori e librerie piu' ampia e mantenuta di questi tempi [e poi io do' sempre valore aggiunto ai progetti in cui il core developer non e' un asshole]). la differenza con node, erlang, go (e rust e tanti altri) e' che il framework asincrono e' direttamente parte del core cosi' come le primitive per i microthread. L'utente non deve preoccuparsi (piu' o meno) che qualche operazione sia bloccante. NOTA personale perche' oggi mi sento polemico: passare da python ad erlang non significa cambiare linguaggio, significa cambiare totalmente l'approccio allo sviluppo, io ho serie difficolta' a credere che questi tipi di transizioni siano rapide come molti millantano, soprattutto in ambiente lavorativo. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
On Tue, Dec 24, 2013 at 11:58:05AM +0100, Roberto De Ioris wrote: io sono convinto che se il modello resta round robbin puro, anche se raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in una chiamata lunga, mentre se potessi evitare di passare chiamate ad un processo che sta lavorando eviterei proprio questa cosa. aggancia una strace ai processi tornado durante un blocco per vedere che succede. Probabilmente non ci sara' molto da fare se non aggiungere altri processi tornado (sempre che sia tollerabile dall'applicazione). le chiamate lunghe non sono chiamate che a random prendono tanto tempo, sono chiamate che fanno molte cose probabilmente non ottimizzate, ma sulle quali io non ho diretto controllo (sono inizializzazioni mensili di alcune posizioni). Grazie per il suggeriemnto sandro *:-) Nginx non puo' farlo (vedi pero' nota sotto) L'approccio migliore (o meglio diciamo quello risolutivo) e' che i processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI: http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html ma non e' compilato di default (per motivi altamente tecnici: ovvero odio la programmazione callback based e non voglio incentivarla ulteriormente ;) anche gunicorn ha un worker model per tornado ma e' deprecato (ma presumo funzioni ancora) Nota: Se abbassi la listen queue del socket dentro tornado a 1 (in alcuni kernel puoi metterla anche a 0 che sarebeb addirittura meglio), otterrai subito un errore in caso di worker occupato e nginx passera' la richiesta al backend successivo. E' un buon trucco (anche se poco diffuso) nel tuo caso specifico. Grazie Roberto, non mi è chiaro se il suggerimento di abbassare la listen queue possa essere usato indipendentemente da uwsgi (come credo). In questo caso non ho capito come farlo. Non ho trovato parametri di tornado. Credo che quello che suggerisci sia poi la backlog della socket.listen() ma veramente non ho alcuna competenza di questo campo... Al momento, dopo essere passato a nginx 1.4+, un tornado minimale di test con 2 handler uno che risponde subito e l'altro che si blocca, arrivo ad una situazione ottimale fino a che uno abortisce la richiesta. A quel punto ho la sensazione che nginx azzeri la lista di connessione attive per una porta particolare mentre tornado resta appeso. Nginx passa la prossima chiamata a quella porta ed il tutto si blocca. Mi pare di capire che la soluzione della listen queue che mi hai indicato risolverebbe questo problema. server = HTTPServer(app) server.bind(post, backlog=1) (prova anche con zero, su alcuni kernel funziona, anche se non ricordo se e' per quelli piu' recenti o quelli piu' vecchi) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] TIOBE vs PYPL
On 25/12/2013 09:04, Nicola Larosa wrote: Sapere di non sapere è importante, però bisogna trarne le dovute conseguenze pratiche, altrimenti è come non saperlo. Enrico Bianchi wrote: Tra l'altro, ad occhio, il modello di parallelizzazione con le goroutines di Go e` di tipo threading, o sbaglio? Sbagli. Ma come!!! Le go routine **sono** thread, come tra l'altro viene scritto nei documenti che hai riportato. La differenza è che sono thread gestiti dal runtime di Go, con alcune proprietà che li rendono flessibili per la concorrenza (invece sospetto che non siano adatti per il parallelismo). Di base e' cosi' (niente parallelismo), pero' puoi specificare tramite una variabile d'ambiente (GOMAXPROCS) su quante cpu vuoi spalmare le goroutine (che poi in realta' significa lanciare piu' pthread su cui lo scheduler distribuisce le goroutine) Questo ti permette di parallelizzare alcuni task. Sono meglio dei pthread nativi ? boh. Lo stile di go impone di usare i channel per passare informazioni tra una goroutine e l'altra (internamente e' un classico mutex/condvar) che ha un impatto rilevante (ma che comunque ti evita i disastri che si ottengono 9 volte su 10 con la programmazione multithread classica) Lo goroutine sono thread ? per dare una risposta bisognerebbe capire cosa si intende con thread... -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
io sono convinto che se il modello resta round robbin puro, anche se raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in una chiamata lunga, mentre se potessi evitare di passare chiamate ad un processo che sta lavorando eviterei proprio questa cosa. aggancia una strace ai processi tornado durante un blocco per vedere che succede. Probabilmente non ci sara' molto da fare se non aggiungere altri processi tornado (sempre che sia tollerabile dall'applicazione). le chiamate lunghe non sono chiamate che a random prendono tanto tempo, sono chiamate che fanno molte cose probabilmente non ottimizzate, ma sulle quali io non ho diretto controllo (sono inizializzazioni mensili di alcune posizioni). Grazie per il suggeriemnto sandro *:-) Nginx non puo' farlo (vedi pero' nota sotto) L'approccio migliore (o meglio diciamo quello risolutivo) e' che i processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI: http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html ma non e' compilato di default (per motivi altamente tecnici: ovvero odio la programmazione callback based e non voglio incentivarla ulteriormente ;) anche gunicorn ha un worker model per tornado ma e' deprecato (ma presumo funzioni ancora) Nota: Se abbassi la listen queue del socket dentro tornado a 1 (in alcuni kernel puoi metterla anche a 0 che sarebeb addirittura meglio), otterrai subito un errore in caso di worker occupato e nginx passera' la richiesta al backend successivo. E' un buon trucco (anche se poco diffuso) nel tuo caso specifico. Altro approccio e' ridurre il proxy_connect_timeout, ma trovare il giusto compromesso sul valore e' dura -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
Roberto De Ioris wrote:
odio la programmazione callback based
Interessante, qui ci va una bella discussione sulla concorrenza.
Solo che diversamente da voi che gozzovigliate, io sto ficcando casa
dentro tanti scatoloni per il trasloco, quindi per me se ne riparla dopo
l'epifania.
Ok,
#callback based:
def pluto():
print(fine);
def topolino():
wait_for('pluto', pluto)
def pippo():
wait_for('topolino', topolino)
wait_for('pippo', pippo)
# coroutine/greenthread/stackswitch/blah blah based:
wait_for('pippo')
pippo()
wait_for('topolino')
topolino()
wait_for('pluto')
pluto()
Personalmente trovo molto piu' leggibile la seconda forma (anche se
internamente l'implementazione e' piu' complessa) Se sei un fan di Go mi
darai regione (visto che e' come funzionano le goroutine) ;)
La prima la trovo molto comoda solo quando il nesting delle callback non
supera le 2 (quindi praticamente mai) e calcolando che e' la base di
funzionamento di node.js (che qui mentre blastate php diventa la nuova
preoccupante moda del momento con l'ultima conferenza che ha fatto 4k
persone) probabilmente sbaglio io :)
--
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] TIOBE vs PYPL
On 21 Dec 2013, at 07:53, Nicola Larosa n...@teknico.net wrote: Massimo Capanni wrote: Pensavo che il Pascal fosse un ricordo dell'università ... Carlos Catucci wrote: vorrai parlare forse di incubo ;) Mi dissocio aspramente. Ho imparato a programmare in Pascal, e mi piaceva parecchio. Di certo più chiaro e meno pericoloso del C. Anche meno potente, d'accordo. Totalmente d'accordo con Nicola. +1 (Visto che chi è invece in disaccordo ha già aggiunto il suo +1, aggiungo il mio per bilanciare :-) Certo, ora sostituirei Pascal con Python quale linguaggio per insegnare a programmare (come fanno al MIT per gli undergraduate, giusto per citarne una), ma di certo non lo rimpiazzerei con il C. I neofiti, l'aritmetica dei puntatori tipicamente non la comprendono *davvero* e, insegnare C senza puntatori, significa IMHO non insegnare C. Questa cosa del problema dei puntatori non la capiro' mai... E' da quando vado alle medie che c'e' l'incubo dei puntatori, colleghi di universita' e colleghi di lavoro che non la capiscono, gente che dice che C e' una merda perche' devi lavorare con i puntatori (???) Per come la vedo io, se non capisci i puntatori vuol dire che non hai capito come funzionano CPU e memoria, o peggio che non te lo hanno insegnato (ma voglio davvero sperare che non si insegni il C senza una base di architetture) Parliamo di un concetto che probabilmente potrebbe essere spiegato facilmente a un bambino delle elementari. Forse mi sfugge qualcosa nel grande schema delle cose ? -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python, redis e bottleneck
2013/12/19 Pietro Battiston m...@pietrobattiston.it [...] Io credo che ci possa essere relazione a come e' scritto il codice. OK, ragionevole dubbio. Prendi _questo_ codice: import redis import random r = redis.Redis(db=0) try: while True: r[random.random()] = random.random() except KeyboardInterrupt: r.flushdb() che gira su un vecchio Intel Core2 Duo CPU T7300, a 2 GHz, con 4 GB di RAM DDR2 a 667 MHz. Scusa ho iniziato a leggere il thread solo ora, spero di avere tutti gli elementi per risponderti: - Cosa mi aspetto: che almeno una delle due CPU sia fissa al 100%. improbabile, sia python che redis passano parecchio tempo in kernel space per trasferire i dati l'uno all'altro - Cosa vedo se avvio top: redis-server non è mai sopra al 45%, Python non è mai sopra al 75%. direi realistico, anche se usando random() hai inficiato il test visto che su Linux random() apre /dev/urandom, quindi di nuovo un bel context switch in kernel space. - Cosa succede se invece che TCP-IP utilizzo un socket unix: l'utilizzo di CPU da parte di Python sale (e la performance pure, e parecchio), ma rimanendo comunque sotto l'80%. il tempo in kernel space diminuisce, i socket unix sono piu' efficienti (anche se tecnicamente e' meglio dire che sono estremamente piu' semplici) - Cosa posso immaginare che stia succedendo: che ci sia una latenza tra CPU e cache, o tra una CPU e l'altra CPU, o tra le CPU e la RAM, che top non sia affidabile al 100%. no no fermo, i risultati che hai sono in linea con il tuo approccio, il collo di bottiglia e' il tuo hardware nel suo insieme :) - Cosa me ne frega: pura curiosità, e magari pure un indizio di quanto parallelizzare codice che utilizza in modo intensivo redis possa o meno migliorare le prestazioni in modo lineare, o se viceversa qualunque cosa mi stia facendo da bottleneck adesso si riproporrebbe anche parallelizzando, magari su più di 2 CPU. redis e' mono thread, puoi 'parallelizzare' la parte python ma visto che l'hardware ha solo 2 cpu e hai comunque 2 processi fissi nell'equazione (python e redis) non otterresti alcun vantaggio (anzi peggioreresti) Spero di averti tolto i dubbi :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python, redis e bottleneck
Il giorno gio, 19/12/2013 alle 13.07 +0100, Roberto De Ioris ha scritto: 2013/12/19 Pietro Battiston m...@pietrobattiston.it [...] Io credo che ci possa essere relazione a come e' scritto il codice. OK, ragionevole dubbio. Prendi _questo_ codice: import redis import random r = redis.Redis(db=0) try: while True: r[random.random()] = random.random() except KeyboardInterrupt: r.flushdb() che gira su un vecchio Intel Core2 Duo CPU T7300, a 2 GHz, con 4 GB di RAM DDR2 a 667 MHz. - Cosa posso immaginare che stia succedendo: che ci sia una latenza tra CPU e cache, o tra una CPU e l'altra CPU, o tra le CPU e la RAM, che top non sia affidabile al 100%. no no fermo, i risultati che hai sono in linea con il tuo approccio, il collo di bottiglia e' il tuo hardware nel suo insieme :) Wow. Confesso che la tua mail mi ha suggerito che forse la seguente riga di top: %Cpu(s): 41,5 us, 13,2 sy, 0,0 ni, 44,8 id, 0,2 wa, 0,0 hi, 0,4 si, 0,0 st non fosse lì per bellezza. A questo punto mi resta un dubbio: sy dovrebbe in effetti rappresentare per l'appunto il tempo speso in kernel space. Considerato che i valori sopra sommano a 100, il tempo speso nel context switching in sé sarà incluso in questo valore? In id? Spalmato tra sy e us (a seconda della direzione del context switching)? Tutto sommato irrilevante? per context switch in realta' si intende il tempo (software) impiegato dal sistema a tornare in kernel mode (e viceversa) diciamo che e' solo una piccola parte di 'sy' (che comprende anche il tempo impiegato dalla syscall stessa) ma ha comunque il suo peso nell'insieme. Se ti interessa (presumo di si) leggiti le vecchie (ora e' cambiato parecchio ed e' imho piu' complesso da capire) guide su come chiamare una syscall in assembler x86 (int 0x80). Questi frammenti di codice (sperando che siano commentati) di solito chiariscono le idee molto piu' di interi libri di teoria sui sistemi operativi. - Cosa me ne frega: pura curiosità, e magari pure un indizio di quanto parallelizzare codice che utilizza in modo intensivo redis possa o meno migliorare le prestazioni in modo lineare, o se viceversa qualunque cosa mi stia facendo da bottleneck adesso si riproporrebbe anche parallelizzando, magari su più di 2 CPU. redis e' mono thread, puoi 'parallelizzare' la parte python ma visto che l'hardware ha solo 2 cpu e hai comunque 2 processi fissi nell'equazione (python e redis) non otterresti alcun vantaggio (anzi peggioreresti) Sento che sto per vedere la luce, ma non mi è ancora chiarissimo perché un processo python aggiuntivo, magari con niceness bassa, non potrebbe sfruttare il 60% di CPU che il processo redis non utilizza - anche eventualmente sprecandone un 10% in kernel space, e quindi girando al 50%... perche' andrebbe a pesare su redis nuovamente, di fatto introducendo un'altra problematica, ovvero che redis deve gestire due stream di richieste diventando il vero collo di bottiglia. Ovviamente se cambi l'architettura in modo che uno solo legga e tutti e due processano il discorso cambia, ma non so quanto sia fattibile nel tuo caso. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [lavoro] Sviluppatore Django a Roma
Ciao a tutti, 20Tab S.r.l. cerca uno sviluppatore Django full-time per la sua sede di Roma (zona piazza Bologna). Il contratto di base proposto e’ un tempo indeterminato 21k (per chi non fosse pratico sono 13 mensilita’ tra i 1000 e i 1100 euro) previa periodo di prova di almeno un mese (20 giorni lavorativi) Sebbene questa tipologia di contratto sia generalmente dedicato a figure junior, se qualche senior vuole farsi avanti e negoziare e’ il benvenuto (si tenga pero’ presente che e’ un azienda piccola, quindi non si puo’ pretendere un budget da multinazionale) L’orario d’ufficio e’ 10:00 - 19:00. L’azienda e’ attiva da 1 anno e mezzo, e per chi e’ stato a europython 2013 e’ quella che ha realizzato bombertab (io lo presentavo solo ;) Chi fosse interessato puo’ inviare il curriculum (o chiedere ulteriori informazioni) a i...@20tab.com Spero di aver fatto un annuncio trasparente e di non aver infranto qualche legge strana. Saluti a tutti -- Roberto De Ioris http://unbit.it (e http://20tab.com) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] gestire processi figli
On 29/11/2013 19:59, Roberto De Ioris wrote: [...] La morte di un child e' segnalata da SIGCHLD (di default, occhio pero' che e' trappabile), ma non lavorerei con i segnali unix (per questo specifico problema) neanche sotto tortura. Dove non hai a disposizione kqueue (e WaitForMultipleObjects) vai di polling e waitpid con WHOHANG: Perchè, epoll + signalfd non va bene? va bene, e' che non mi piace proprio dover fare affidamento su SIGCHLD. Purtroppo i segnali posix/unix sono una di quelle cose che ti fanno pensare: fico c'e' su tutte le piattaforme, uso loro e passa la paura. Il problema e' che poi ogni OS li gestisce a modo suo (soprattutto gli unix proprietari) Inoltre, curiosità personale visto che non ho mai fatto test, quale è la differenza tra sigtimedwait e kqueue + apposito filtro o epoll + signalfd? che kqueue non usa i segnali, quando un processo muore tutti i poller in ascolto vengono svegliati dal kernel. Praticamente non hai nessuno dei problemi dei segnali unix e (soprattutto) non ti costringe a modificare la logica del tuo programma (o a fare trucchi strani, tra cui includo il mio poller su waitpid suggerito nella mail di prima). Purtroppo su Linux kqueue non c'e' :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] gestire processi figli
2013/11/30 Manlio Perillo manlio.peri...@gmail.com: On 30/11/2013 13:18, Roberto De Ioris wrote: [...] Inoltre, curiosità personale visto che non ho mai fatto test, quale è la differenza tra sigtimedwait e kqueue + apposito filtro o epoll + signalfd? che kqueue non usa i segnali, quando un processo muore tutti i poller in ascolto vengono svegliati dal kernel. Vero, hai ragione; ricordavo male. kqueue ha sia il filtro EVFILT_PROC che EVFILT_SIGNAL. Io stavo assumendo il solo EVFILT_SIGNAL, che dovrebbe funzionare come signalfd su Linux, credo/spero. Praticamente non hai nessuno dei problemi dei segnali unix e (soprattutto) non ti costringe a modificare la logica del tuo programma (o a fare trucchi strani, tra cui includo il mio poller su waitpid suggerito nella mail di prima). Purtroppo su Linux kqueue non c'e' :) Già, ed un poco alla volta mi sembra stiano aggiungendo interfacce per fare quello che kqueue fa già! A quando procfd? :) Peccato, perchè se Linux avesse implementato kqueue, c'era una remota possibilità di vederlo standardizzato da POSIX entro il prossimo decennio.. E' meglio di epoll()? Perchè? meglio e' relativo. Sono diverse, a cominciare dal fatto che kqueue non si limita a monitorare file descriptors (ma anche processi, inode, timer...). E' una interfaccia generica per la programmazione ad eventi. Con una sola syscall fai tutto, in linux ne viene aggiunta una nuova per ogni funzionalita' (timerfd, eventfd, signalfd, blahblahfd...) poiche' si preferisce vedere tutto come un file descriptor. Non so quali dei due approcci sia migliore, ma kqueue e' arrivata prima e piaceva a tutti, portandola su linux avremmo (forse) avuto meno mal di testa -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] gestire processi figli
2013/11/27 Manlio Perillo manlio.peri...@gmail.com: La cosa più complessa e restare in attesa fin quando un processo termina. Su sistemi POSIX puoi usare sigtimedwait, su FreeBSD kqueue con apposito filtro, su Linux epoll con quell'orrore di signalfd, su Windows WaitForMultipleObjects. Molto interessante. Sto affrontando esattamente questo problema in psutil, ovvero aspettare che un certo PID termini specificando un timeout: https://code.google.com/p/psutil/issues/detail?id=445 Ho dato un occhio a sigtimedwait() (che tra l'altro hanno esposto in Python 3.3). Vedo che si aspetta una lista di segnali e la cosa mi spiazza un po'. Dovrei passargli SIGTERM e SIGKILL? Ci sono altri segnali che causano la morte di un processo e che dovrei prendere in considerazione? --- La morte di un child e' segnalata da SIGCHLD (di default, occhio pero' che e' trappabile), ma non lavorerei con i segnali unix (per questo specifico problema) neanche sotto tortura. Dove non hai a disposizione kqueue (e WaitForMultipleObjects) vai di polling e waitpid con WHOHANG: while 1: aspetta... if waitpid(blah blah, WNOHANG): break -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] gestire processi figli
La morte di un child e' segnalata da SIGCHLD (di default, occhio pero' che e' trappabile), ma non lavorerei con i segnali unix (per questo specifico problema) neanche sotto tortura. Dove non hai a disposizione kqueue (e WaitForMultipleObjects) vai di polling e waitpid con WHOHANG: while 1: aspetta... if waitpid(blah blah, WNOHANG): break Ho il requirement di farlo per qualunque PID, non solo i figli del mio processo. tutta la famiglia wait() puo' attendere anche i process group, se ti riferisci ad altro, beh non si puo' fare, e' contro lo standard POSIX :) un approccio estremo (che pero' e' usato anche da upstart) e' di agganciare una ptrace che segua le fork(), ma probabilmente e' un filino esagerato... P.S. su Linux in realta' la syscall prctl ha aggiunto una serie di nuove modalita' per cui il legale tra parent e children (e nipoti) puo' essere modificato in modi divertenti -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] leggere flusso da tastiera
ciao a tutti, non me ne vogliate ma mi devo rifare ad un linguaggio 'nonno' ma che risulta ancora utile per tante cose... In Perl riesco a leggere tutto il flusso da tastiera semplicemente con una stringa: $input = ; ## questo mi legge semplicemente tutto il flusso da tastiera ## hmm, in realta' legge da stdin (che e' parecchio diverso) e alla fine della linea (in base al separatore in uso, che di default e' \n) restituisce il contenuto del buffer. Direi che e' esattamente quello che fa raw_input, ma forse non ho capito cosa intendi per tutto l'input -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] uWSGI 1.9.11 con supporto PyPy
Ciao a tutti, oggi e' stata rilasciata la versione 1.9.11 di uWSGI, la prima a includere un plugin per PyPy funzionante (il vecchio plugin utilizzava il lento layer di emulazione cpyext di PyPy che oltre che incompleto non supporta i thread e ha vari problemi di solidita'). Il nuovo plugin e' basato su cffi e, cosa divertente, e' scritto per il 90% in python (quindi puo' essere patchato al volo senza ricompilare). Allo stato attuale, sebbene superi praticamente tutti i test, non mi sento di consigliarlo in produzione (mi perdonino gli amici di PyPy), ma ogni report sara' il benvenuto in quanto questo approccio stressa diverse aree di PyPy che generalmente non vengono utilizzate (e inoltre contribuira' a migliorare il supporto a cffi che a quanto pare sara' il futuro delle estensioni native di PyPy) E' richiesta una versione tip (o nightly) di PyPy (solo fixare i thread ha richiesto una ventina di patch e ha portato alla luce un paio di bug del JIT), e molto tempo a disposizione :) Qui c'e' una doc preliminare: http://uwsgi-docs.readthedocs.org/en/latest/PyPy.html E qui dei benchmark molto specifici (servono piu' che altro agli sviluppatori di PyPy): http://uwsgi-docs.readthedocs.org/en/latest/PyPy_benchmarks.html Grazie a chiunque voglia dare una mano P.S. Se qualche cliente Unbit e' interessato, possiamo fornire degli ambienti di test. Scrivete pure al supporto -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] marco
ciao a tutti,vorrei imparare a programmare,parto da zero,secondo voi che linguaggio posso iniziare?python potrebbe andare bene?oppure mi consigliate visual basic? saluti Marco___ In una lista su python probabilmente la risposta sara' scontata. Io pero' per lavoro/passione sono costretto a usare tantissimi linguaggi diversi e quindi mi auto-eleggo super-partes ;) Quello che posso dirti e' che python ti costringe da subito a fare le cose fatte bene. (io ho iniziato con linguaggi con un approccio totalmente apposto e sebbene porti dei vantaggi a livello personale quando lavori in gruppo sei fottuto) Anche la storia dell'indentazione obbligatoria che fa storcere il naso a molti in realta' diventa fondamentale a livello didattico. E' un linguaggio che copre vari paradigmi (procedurale, a oggetti e anche un po' di funzionale), quindi ti permette (in caso di bisogno) di approcciare facilmente anche altri ambienti. Visual Basic ? per quanto troverai milioni di persone pronte a tirargli merda, io tendo a spostare l'attenzione sul fatto che un linguaggio cosi' legato a un sistema operativo (non siamo piu' negli anni 90 dove tutto e' windows e chi usa il resto e' un terrorista) a livello didattico vale meno di zero. Infine, la community e' importantissima, e quella python italiana e' una spanna sopra alle altre sia tecnicamente che organizzativamente, quindi da questo punto di vista staresti in una botte di ferro ;) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] dongle con penna usb
molto interessante! usare una semplice penna usb? sarebbe un bel guadagno... vittorio - OT - non ti incazzare ma hai fatto top posting di nuovo :) - IT - puoi usare tranquillamente delle pennette da 10 euro con dentro una chiave privata ssl copiata direttamente sui blocchi: dd if=chiave of=/dev/sda (scusa ma non so come si fa su windows, immagino sia molto simile) poi istallati pyusb per verificare che la chiavetta (con determinate caratteristiche) sia inserita e lanciando degli urb (sono i pacchetti usb) ti leggi i primi N blocchi dal dispositivo. (ti consiglio di usare gli urb perche' aggiungono uno 0,001% di sicurezza in piu' al sistema) E' molto piu' facile di quello che sembri e alla fine impari a usare i certificati ssl e capisci come funziona usb a basso livello. Infine (ma spero tu gia' lo sappia) questi sistemi non valgono una cippa a livello di sicurezza, si usano solo per tenere buoni i clienti esaltati o per rendere meno usabili i prodotti ai clienti (e te lo dice uno che ha usato per 4 anni un programma di contabilita' con chiavetta...) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] dongle con penna usb
2012/12/31 Marco Beri marcob...@gmail.com 2012/12/31 Gian Mario Tagliaretti g.tagliare...@gmail.com dissento categoricamente, alcuni modelli di chiave sono decisamente sicuri (tipo la crypto-box) e in alcune circostanze sono indispensabili, come nel nostro caso, non voglio tediare la lista con i perchè, ci vorrebbe una conferenza sull'argomento :) Ok, permettimi allora di dire che nel 99% dei casi sono totalmente inutili. Direi che il 99% è generoso ma ci siamo quasi, sono d'accordo con te, al 99% :p Ti stavo per dare del folle (nella mia mente ovviamente, io sono buono) ma se parliamo del 99% allora ti do' ragione al 100% :P Comunque credo che Vittorio voglia solo imparare (non necessariamente costruirci un business) e direi che con una chiavetta da pochi euro e un po' di google (e pazienza) ha materiale per almeno 1 mese :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] django e strutture dati permanenti
idee? :) Guarda, e' un problema risolvibile abbastanza semplicemente con uWSGI. Fondamentalmente 1) carichi python 2) carichi il modulo con il grafo 3) fork() n volte 4) carichi l'applicazione in ogni 'worker' quando fai modifiche al codice riavvii solo i worker che ripartiranno dal punto 3 (quindi con gia' il grafo in memoria). Ovviamente funziona in sola lettura. Una configurazione per lo sviluppo (con 8 processi) potrebbe essere: [uwsgi] http = :8080 shared-import = modulografo.py module = yourapp.wsgi processes = 8 master = true py-auto-reload = 2 lazy = true i parametri chiave sono shared-import che importa un modulo prima di fork() e lazy che carica l'applicazione in ogni worker a quando il codice cambia vengono riavviati solo i worker anziche' tutto lo stack. Se non conosci il progetto probabilmente il tutto ti risultera' criptico, purtroppo non posso essere piu' prolisso perche' sono all'italian perl workshop e non voglio farmi beccare a pythoneggiare ;) In caso mandami una mail in privato -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] lamson
Il giorno 20/set/2012, alle ore 17:52, Calogero Bonasia kbona...@gmail.com ha scritto: qualcuno in lista usa ha esperienza su http://lamsonproject.org/ Molto carino se devi costruire applicazioni specifiche basate su smtp. (che potrebbe anche essere un filtro antispam, non necessariamente qualcosa a livello utente) Se pero' vuoi solo mettere su' un servizio smtp forse e' meglio che guardi altrove perche' dovresti sviluppare praticamente ogni cosa. -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] lamson
Il giorno 20/set/2012, alle ore 18:13, Calogero Bonasia kbona...@gmail.com ha scritto: Il 20 settembre 2012 18:06, Roberto De Ioris robe...@unbit.it ha scritto: Se pero' vuoi solo mettere su' un servizio smtp forse e' meglio che guardi altrove perche' dovresti sviluppare praticamente ogni cosa. la mia esigenza è quella di aggiungere un pezzo ad un programma nato 10 anni fa e che adesso deve spedire posta elettronica certificata (PEC). non posso modificare il software che ha cablato un meccanismo per spedire messaggi ad un server prestabilito (server smtp) su porta 25 con autenticazione semplice. Mentre per la PEC occorre dialogare con un server smtp su porta 465 e usare anche STARTTLS. ho pensato quindi di mettere in mezzo qualcosa che ascolti su porta 25 il programma e rigiri verso l'smtp pec, impersonando l'utente autorizzato (cicciobo...@pec.it facciamo esempio). so che con exim potrei risolvere, ma mi piacerebbe fare una cosa elegante con python, ottenere un eseguibile e lanciarlo sulla macchina windows, anziché impementare una virtualbox con exim. sono partito da qui http://docs.python.org/library/email-examples.html proseguendo qui http://stackoverflow.com/questions/882712/sending-html-email-in-python prima di imbattermi in lamson Quindi devi fare un proxy smtp che da localhost:25 'rigira' le richieste a un server SMTP autenticato + TLS ? In tal caso si', con exim/postfix e amici faresti presto, ma e' relativamente semplice anche con lamson (in python hai gia' tutte le librerie per collegarti ai server smtp) e sicuramente molto piu' divertente. Tieni pero' in considerazione che la mail che uscira' non sara' assolutamente una PEC con valore legale, non so se questo puo' essere un problema. -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] lamson
Il giorno 20/set/2012, alle ore 19:00, Calogero Bonasia kbona...@gmail.com ha scritto: Il 20 settembre 2012 18:48, Roberto De Ioris robe...@unbit.it ha scritto: Quindi devi fare un proxy smtp che da localhost:25 'rigira' le richieste a un server SMTP autenticato + TLS ? si, esatto In tal caso si', con exim/postfix e amici faresti presto, ma e' relativamente semplice anche con lamson (in python hai gia' tutte le librerie per collegarti ai server smtp) e sicuramente molto piu' divertente. con exim ci sono appena riuscito, ma con python sarebbe meglio dato che vorrei imparare ad usare (meglio) python... Tieni pero' in considerazione che la mail che uscira' non sara' assolutamente una PEC con valore legale, non so se questo puo' essere un problema. ecco, questo mi rende perplesso. perché affermi che perderebbe di valore legale la pec? secondo quanto ho appena fatto con exim io ho utilizzato come mittente (lato exim) proprio il nome utente registrato sul server del provider pec (cicciobomba) e la sua password, quindi le email sembrano essere spedite da cicciobo...@pec.it Mi ero perso questo pezzo (pensavo mandassi da un indirizzo hard-coded nel programma che non era PEC, ma effettivamente riscriverlo e' banale). In tal caso non ci sono problemi :) -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] sys.exit dopo inattività
Ciao a tutti! Qualcuno fra voi mi potrebbe suggerire un metodo elegante per terminare un programma scritto in Python, dopo un tot di tempo di inattività del computer? Grazie mille! Marco Presumo tu intenda inattivita' dell'utente (tastiera, mouse...), l'inattivita' del computer introduce vari problemi filosofici :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: Re: sys.exit dopo inattività
Messaggio originale Da: robe...@unbit.it Data: 23/08/2012 11.41 A: marco...@libero.itmarco...@libero.it, Discussioni generali sul linguaggio Pythonpython@lists.python.it Ogg: Re: [Python] sys.exit dopo inattività Ciao a tutti! Qualcuno fra voi mi potrebbe suggerire un metodo elegante per terminare un programma scritto in Python, dopo un tot di tempo di inattività del computer? Grazie mille! Marco Presumo tu intenda inattivita' dell'utente (tastiera, mouse...), l'inattivita' del computer introduce vari problemi filosofici :) -- Roberto De Ioris http://unbit.it Si certo: inattività di mouse e tastiera. Scusatemi! :-) Marco Su ogni os si fa in modo diverso. Su Linux/*BSD e' ancora piu' complicato per via dei diversi desktop environment. Su gnome devi collegarti via dbus al servizio di gnome-screensaver che esporta idletime. A piu' basso livello hai il comando xidletime che monitora direttamente a livello di x11 (ma chissa' se e' sufficiente...) Ancora piu' a basso livello (solo su Linux) puoi monitorare i file dentro /dev/input (estremamente dispendioso). Su Mac cocoa esporta un attributo in IOHID chiamato HIDIdleTime, perdonami ma non ho la minima idea di come farlo in python (presumo basti usare il modulo objc). Sugli altri sistemi non ne ho la minima idea. Se invece l'inattivita' deve essere riferita solo al tuo applicativo python, allora ti consiglio di crearti un timer (che in realta' e' un timestamp dell'ultimo evento dell'utente che hai processato). Dovrebbe facilmente (e senza overhead rilevante) permetterti di ottenere quello che vuoi -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] visualizzare immagine su schermo separato
Ciao a tutti. Rieccomi con una nuova richiesta ;-) Come da oggetto avrei bisogno di visualizzare alcune immagini (fullscreen e senza bordi) in sequenza su un secondo monitor. Attualmente riesco nel mio intento solo su linux richiamando un altro software in un ciclo: subprocess.Popen(['xloadimage','-display',':0.1','-fullscreen','nomefile.png']) e non ho nessun problema. Come posso far andare le cose anche su windows?? Qualcuno potrebbe indicarmi qualche libreria python che supporti il doppio monitor? Ho cercato on-line e ho trovato -wxpython -tkinter -pygame -pyglet -PIL ma non ho trovato riferimenti per quanto riguarda il separate screen In alternativa potrei richiamare qualcosa tipo xloadimage però per windows (non ho trovato nulla di simile per adesso; qualche idea?) Sarei anche disposto a scrivermi qualche riga in altri linguaggi ma vorrei essere sicuro che il tempo impiegato dia i frutti sperati. Qualche consiglio? Grazie Matteo P Ho avuto lo stesso problema con pygame, e alla fine sono passato a pyglet che ha il concetto di Screen: http://pyglet.org/doc/api/pyglet.window.Display-class.html#get_screens una volta ottenuta la lista degli Screen puoi mappare una finestra direttamente su quello che ti interessa. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Interazione con AS/400
Il giorno 27/mag/2012, alle ore 23:08, Carlo Miron ha scritto: 2012/5/27 Simone Federici s.feder...@gmail.com: http://it.over-blog.com/Zend_Server_cose-1228321777-art360291.html Monitoring Code Tracing Job Queue Cache guardati uWSGI per il deploy delle applicazioni python, async, cache jobs Esiste uWSGI per AS/400? No, solo per AIX (quindi pSeries) , a meno che non stiamo parlando di una AS/400 post-2008 (e quindi pSeries) che quasi tutti chiamano AS/400 ma non lo e' :) E, ha un compilatore C, quel coso? Se AS/400 e' come AIX allora dipende dal contratto che hai fatto, di solito i 'package sviluppatori' si comprano a parte. E comunque si, devo dare ragione a Daniele, far girare roba moderna in quel mondo li' e' una bella sfida (parlo sempre di AS/400 antichi , AIX, per fortuna, e' tutta un'altra cosa) -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Più versioni di Trac sullo stesso server
Il giorno 10/apr/2012, alle ore 18:21, Matteo Magni ha scritto: Ciao a tutti, scusate se la domanda è stupida, ma non riesco proprio a cavarci i piedi. Ho bisogno di far girare sullo stesso server due versioni di Trac diverse. Questo per usare solo su una un particolare plugin che fa una patch di trac, solo su un progetto. Purtroppo non essendo molto esperto di python non riesco a capire come configurare apache per ottenere quello che cerco. In questo momento trac gira con mod_wsgi http://trac.edgewall.org/wiki/TracModWSGI Che strada mi consigliate di usare? Virtualenv (una per virtualhost) http://code.google.com/p/modwsgi/wiki/VirtualEnvironments -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [ANNOUNCE] uWSGI 1.1
I am pleased to announce the 1.1 release of the uWSGI project. This release focuses on a new option parser subsystem, improved perl/psgi and ruby/rack support and a new (stable) php plugin. A lot of optimizations have been introduced for the fastrouter and the various threading modes. This is the first release officially deprecating some old-style configuration (see notes). Changelog [20120317] - new options parser subsystem - improved php support http://projects.unbit.it/uwsgi/wiki/PHP - multiple spooler with multiprocessing simply add multiple --spooler options (on different directories) to have multiple spooler. Add --spooler-processes to fork() them - segmentation fault and floating point exceptions manager you will get a handy backtrace whenever SIGSEGV and SIGFPE are triggered - never-swap option enabling this option will force uWSGI to lock all memory areas on physical memory to avoid on-disk swapping. - zergpool plugin another step towards down-free reloads http://projects.unbit.it/uwsgi/wiki/ZergMode - perl/psgi multiple interpreters support you can now mount multiple perl-apps in the same process - deadlock detector on some specific conditions, uwsgi locking subsystem can be damaged, the master process got a new feature, allowing it to detect such conditions - pluggable cheaper algos by default the old-fashioned apache-style spare algorithm is used for adaptive process spawning. A new one, based on socket listen queue can be used, or you can implement a completely new approach: http://projects.unbit.it/uwsgi/browser/plugins/cheaper_backlog2/cheaper_backlog2.c - new internal routing susbsystem http://projects.unbit.it/uwsgi/wiki/InternalRouting - preliminary support for config logic http://projects.unbit.it/uwsgi/wiki/ConfigLogic - log rotation infrastructure you can now trigger log-rotation simply touching files - support for paste loggers - threading improvements - plugins can now mapped to specific modifiers - app tag is deprecated (use mount option) - report startup time for apps - reintroduced expat support by default libxml2 is searched, if it is not available libexpat will be used. If both are not available, xml support will not be compiled in. - reintroduced remote spooler plugin - various fastrouter optimizations - added ruby rvm support add --gemset name option to set a specific rvm gemset - a lot of fixes all over the place Notes: - app tag has been deprecated, some simple old-style-config still works, but you should move to the new mount option. In uWSGI 1.2 the app tag will map 1:1 to the mount one. - xml support is now automatically detected (and eventually not compiled in) Special thanks for this release go to Anthon van der Neut (mongrel2 fixes and setuptools packaging) Łukasz Mierzwa (bug-hunter in-chief) Raffaele Colace (for the upython contrib script) Cal Leeming Ultrabug (ultrabug.fr, sorry i do not know your real name) Riccardo Magliocchetti C Anthony Risinger Evgeny Turnaev Marcin Deranek Mike Kuznetsov (sorry if i have missed someone) You can download uWSGI 1.1 from http://projects.unbit.it/downloads/uwsgi-1.1.tar.gz -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Impostare il valore di nice
Ho provato a cercare al volo ma non trovato nulla di utile. C'è modo di impostare il valore di nice (ed eventualmente di ionice) da codice ? Mi riferisco a Linux come OS. os.nice() che se usi il cfq elevator ti cambia anche la priorita' di I/O. Se invece vuoi un controllo maggiore puoi usare ctypes per accedere alla glibc e richiamare ioprio_get/set -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [ANNOUNCE] uWSGI 1.0
After 2 years of development, the uWSGI project is at 1.0 This major release focuses on adaptive process spawning (--cheaper mode), the new stats framework, Mules and an incredible amount of bug fixes and code refactoring. Changelog: - adaptive process spawning (--cheaper option) - new control options --stop, --reload, --suspend, --resume, --pause - stats framework http://projects.unbit.it/uwsgi/wiki/StatsServer - new subscription system - support for mime types in static file serving - posix capablities support http://projects.unbit.it/uwsgi/wiki/Capabilities - uWSGI mules and farms http://projects.unbit.it/uwsgi/wiki/Mules - support for multiple --touch-reload options - new logging subsystem - new custom locking subsystem http://projects.unbit.it/uwsgi/wiki/Locks - process name handling - better (and faster) HTTP parser - perl and python threading improvements - new plugins: rrdtool, carbon, cgi, php http://projects.unbit.it/uwsgi/wiki/Carbon http://projects.unbit.it/uwsgi/wiki/CGI http://projects.unbit.it/uwsgi/wiki/PHP - various improvements in the Rack/ruby plugin http://projects.unbit.it/uwsgi/wiki/rubyDSL - Linux KSM support http://projects.unbit.it/uwsgi/wiki/KSM - refactored ping and nagios plugins - support for signals in lazy mode - optimized static-file serving - support for linux unshare() You can download the tarball from http://projects.unbit.it/downloads/uwsgi-1.0.tar.gz * Special Thanks * Lukasz Mierzwa for its incredible amount of test reports with complex configurations Giacomo Bagnoli for the KSM idea Graham Dumpleton (mod_wsgi/newrelic) for help in addressing various threading issues in the python plugin * Issues * A bunch of patches are left out from 1.0, they will be committed in the future - you cannot compile the rack plugin with the spooler disabled - the httprouter subscription system is not solid as the fastrouter one - support for multiple perl interpreters is post-poned to 1.1 - the graphite/carbon plugin should export more metrics * Notes * uWSGI 1.0 is the new LTS release KSM does not grant you memory gain, it is completely app-dependent The ruby/rack plugin has an extremely aggressive GC policy, do not expect extreme performance without tuning it If you run uWSGI on some hosting provider/PaaS supporting only HTTP, be sure to use --http-socket instead of --http (extreme performance gain) Bye -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Documenti su CGI?
Salve sto cercando da molto tempo documenti sui CGI con Python... Dato che le applicazioni web stanno prendendo il sopravvento sui programmi e mi voglio adeguare... mailman/listinfo/python CGI e' una tecnica per eseguire script generici tramite un webserver che si limita a reindirizzarne l'output al client. E' una tecnologia a basso livello (e per lo piu' obsoleta), ma estremamente semplice. Ti consiglio di NON sviluppare su CGI, ma di seguire lo standard python e ragionare in WSGI http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface e' a un livello di astrazione piu' alto, il che implica che puoi eseguire applicazioni WSGI su un motore CGI. Sebbene studiare CGI sia una buona cosa (indipendentemente dal linguaggio) ultimamente mi sto accorgendo di come questo porti alcune persone a continuare a ragionare in termini di script web (stile php) e non di applicazioni web (come invece costringe a fare WSGI). -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] cgi ottimizzati ERA: web: sync vs. async
Il trucco è usare un socket UNIX domain bidirezionale, invece di due pipe. In questo modo per Nginx la comunicazione con il processo CGI dovrebbe essere analoga a quella con un client remoto. In particolare non dovrebbe mai essere necessario chiamare waitpid. Ma cosi' non mi ritrovo pieno di zombie ? Oppure intendi comunque chiamare waitpid(-1...) a intervalli regolari per fare pulizia ? A rigor di logica quando sei in attesa dello STDOUT del CGI se ricevi uno stream vuoto, allora il processo dovrebbe aver finito il suo lavoro. Il problema e' se qualche cgi cattivo chiama una close(1) nel suo codice. A quel punto la chiamata a waitpid() sarebbe bloccante. In realta' poi mi sono ricordato della nuova syscall signalfd (in linux) che si potrebbe agganciare al SIGCHLD, quindi si potrebbe simulare il comportamento di kqueue(). Probabilmente e' una strada percorribile, se non fosse per il fatto che Igor e' da sempre allergico a chiamare fork() (o clone()) in nginx, e quindi ho paura che una inclusione nel ramo ufficiale potrebbe essere problematica. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] cgi ottimizzati ERA: web: sync vs. async
Io stavo valutando un altra strada (nel caso in cui non serva un elevato grado di concorrenza): il buon vecchio CGI. Ovviamente non CGI normale, ma fare in modo che l'interprete Python sia embedato nel server (e pre-caricare in memoria quanto più possibile specialmente se read-only) e poi fare un fork + Python exec. Rispetto ad un CGI normale (fork + sys exec) mi aspetto un miglioramento significativo, anche grazie al copy-on-write. Ho trovato un po' di tempo per tentare questo approccio: http://projects.unbit.it/uwsgi/wiki/CGI#Example10:optimizingCGIs effettivamente il guadagno prestazionale c'e', e anche tanto. Un Hello World su cgi classico su una macchina monoprocessore abbastanza scarsa (tra l'altro virtualizzata con virtualbox) fa circa 15 richieste al secondo. Usando la libreria c che c'e' nel link (scritta in 5 minuti, ma che puo' essere sicuramente migliorata) ne fa 35 (!!!). E' piu' del doppio, senza dover riscrivere una sola linea dei propri cgi. Io ad esempio preferisco quasi sempre eseguire mercurial come cgi, questo approccio mi sarebbe molto utile. Il problema, e' che infilare i CGI in nginx (intendo senza passare per uWSGI) e' fuori discussione (almeno per linux) poiche' tutte le wait() sono bloccanti e anche usando WNOHANG sarebbe richiesto uno sforzo non indifferente al core di nginx (che dovrebbe chiamare waitpid() a intervalli regolari per vedere se qualcosa e' cambiato). Nei BSD sarebbe molto piu' facile, perche' kqueue() puo' rimanere in attesa di un processo oltre che di un file descriptor (bellissimo). -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [OT]: PHP critique [ERA] Re: Python e html
Ciao a tutti, mi intrometto nonostante stia soprattutto lurkando questa lista molto interessante. Sono un programmatore che aimé utilizza molto PHP e purtroppo molto poco Python, non fatemene una colpa :-) Mi piacerebbe che la discussione prendesse una maggiore profondità. Bah, 9 volte su 10 piu' profonda significa meno divertente...che noiosi che siete :) A parte il fatto che Python è molto più figo di PHP quali sono nel dettaglio i motivi tecnici che spingono molti programmatori a considerare il PHP un linguaggio inferiore? E' per natura un DSL (un linguaggio specifico per il web nel suo caso) quindi gia' partirebbe svantaggiato in un qualsiasi confronto (sebbene nessuno vieti di usarlo in altri contesti). Non fa dell'eleganza il suo punto di forza (a meno che non vieni dal perl, ma a quel punto diventerebbe talmente elegante da farti schifo comunque ;) Manca di alcuni costrutti, ma non essendo un linguaggio nato ad oggetti mi sento di perdonarlo (a maggior ragione che ancora la stragrande maggioranza delle applicazioni php sono scritte in procedurale). Basta per definirlo un linguaggio merdoso ? Secondo me no, ho visto codice php bellissimo e codice python orripilante (scritto da me). Torniamo al punto gia' ribadito che e' il programmatore il fulcro della questione. A questo aggiungo lo spirito di un linguaggio. Python e PHP hanno uno 'spirito' diverso. Io programmo in C la maggior parte del tempo, se qualcuno mi dice che ho sbagliato una funzione o c'e' un leak abbasso la testa e correggo (e mi stringo anche un po' il cilicio), ma se qualcuno mi dice che una funzione non e' elegante rialzo la testa e gli sputo in un occhio, perche' non ha colto lo 'spirito' del C. Lo stesso discorso si applica a qualsiasi linguaggio. Se ho scritto python in modo non elegante ricevero' una gangbang di sputi (scusate per la mia vena poetica, a volte mi faccio schifo da solo) E se ce ne sono, quali possono essere le cose che python potrebbe invidiare a PHP? che e' stato pensato fin dall'inizio per essere deployato subito e senza smazzi. La sua architettura e' di una semplicita' disarmante: allochi l'interprete all'inizio (quando parte il server), e per ogni richiesta si crea un nuovo ambiente che poi viene distrutto alla fine. Semplicemente perfetto (se programmi in stateless), una noia e un limite inaudito se vuoi scrivere applicazioni di nuova concezione. Il risultato e' che subito dopo la sua nascita la stragrande maggioranza dei provider (anche low-cost) lo supportava, e in un modo tale per cui chi era abituato a CGI si ritrovava ad usare le stesse tecniche di deploy ma con le performance aumentate a dismisura. Negli altri ambienti la soluzione e' sempre stata il server dedicato, e quindi spendere di piu' e fare i sistemisti. Le cose ultimamente sono cambiate da questo punto di vista, ma resta il fatto che deployare applicazioni php ha sempre una curva d'apprendimento meno ripida degli altri. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [OT]: PHP critique [ERA] Re: Python e html
2011/12/6 Matteo Magni mat...@magni.me Perl e' caos. Ma in quel caos c'e' del genio. Cacchio, questa me la tatuo... -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
