2015-09-11 10:29 GMT+02:00 Marek Nožka :
> Ahoj
>
> Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
> Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou
> soutěžit
> o nejlepší algoritmus
V tom se asi neshodneme. Nespatřuji nic špatného na tom napsat si vlastní TCP
protokol založený na socketu z stdlib.
Zastávám názor, že je dobré rozumět a učit se věci pěkně odspodu. Ono i to
Django nebo Flask takto vznikl. Na začátku nebylo nic a potom byl framework.
Uvedu vlastní zkušenost. V
2015-09-29 16:28 GMT+02:00 Pavel Schön :
> Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni
> zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro
> studijni a vyukove ucely, pokud se nepletu.
Obzvlast pro vyukove ucely je skutecne vhodne vybrat
Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni
zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro
studijni a vyukove ucely, pokud se nepletu.
Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast
neresi vypadky spojen
Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav
zámků zachován? Co se stane, když klient požádá o acquire a musí čekat,
protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť,
spojení se ukončí a recv() vrátí prázdný řetězec?
Když už řešit zamykání takhle síťov
Psal jsem to tehdy, pisu to i ted - tohle reseni je naprosto nevhodne,
nema zadne reseni konkurentniho pristupu. Neni thread safe napriklad,
coz ho naprosto diskvalifikuje jako implementace zamku. Nehlede na to,
ze je to reimplementace kola.
Honza Král
E-Mail: honza.k...@gmail.com
Phone: +420 606
Ahoj,
dovolim si navrhnout pure python reseni na strane serveru zalozene na
threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
Ve zkratce:
- na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje
Moc, moc dík, za vyčerpávající odpověď.
Marek
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python
Visit: http://www.py.cz
2015-09-16 9:56 GMT+02:00 Marek Nožka :
> On Wed, 16 Sep 2015 09:37:41 +0200 Petr Viktorin wrote
> to Konference PyCZ :
>
>> ale neměl bys zapomenout na to, že *učíš*
>> lidi používat HTTP. Nauč je to prosím správně.
>
> ... právě proto se ptám. Díky všem za poučení, budu se tím řídit.
Když to te
Ahoj,
Petr byl rychlejší. Rozdíl mezi GET, PUT, POST, atd. je v tom, že je přesně
ve specifikaci řečeno, co může nebo nemůže způsobit, např. opakovaným
zavoláním.
> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
PATCH, etc.
To není úplně přesné. HTTP je protokol a má svo
On Wed, 16 Sep 2015 09:37:41 +0200 Petr Viktorin wrote
to Konference PyCZ :
> ale neměl bys zapomenout na to, že *učíš*
> lidi používat HTTP. Nauč je to prosím správně.
... právě proto se ptám. Díky všem za poučení, budu se tím řídit.
Marek
___
Python
2015-09-16 7:45 GMT+02:00 Petr Blahos :
> Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k
> němu
> nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak měl
> kdysi takové
> to přednačítání odkazů...
Je psáno [1], že GET nemá měnit stav, a spousta nástrojů
Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k
němu
nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak měl
kdysi takové
to přednačítání odkazů...
--
Petr
2015-09-15 22:33 GMT+02:00 Ales Zoulek :
> Technicky rozdil mezi PUT a GET je minimalni. Je ale
Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce
odpovidala tomu HTTP "slovesu".
Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST) by
nemel menit vnitrni stav serveru, pouze ten stav cist.
HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DEL
Ahoj
On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek
wrote to Konference PyCZ :
> Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
> musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o samotném
> blbém HTTP, když už ne o RESTu.
To je právě to, co nechápu. Po
> No...já měl v úmyslu použít spíš, "něco jako REST". Počítám spíš s tím, že
> se bude používat jen GET a požadavky budou jako součást URL: ///
> Nebo tak nějak. Jak bys to udělal ty?
Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
musíš použít i něco jiného než GET, pokud s
On Fri, 11 Sep 2015 08:47:33 + Ales Zoulek wrote
to Konference PyCZ :
> Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl, ze
> implementacne bude lehci 2). Tak jak tak se zda rozumny, aby studenti
> nepsali vlastniho rest klienta a dostali se zadanim i malou knihovnu, ktera
>
On Fri, 11 Sep 2015 14:29:36 +0200 Hynek Fabian
wrote to Konference PyCZ :
> Ja jsem asi moc ovlivnenej corewars, ale nejak mi unika k cemu by tam
> sitova komunikace byla. Stacilo by kdyby klienti uploadnuli modul,
> simulator si vsechny naimporti, projede a vyhodi vysledek (vitezove,
> resp. za
On Fri, 11 Sep 2015 11:05:48 +0200 Honza Javorek
wrote to Konference PyCZ :
> Pokud bude REST API tim nejlepsim zpusobem jak to udelat (coz nemusi byt),
> tak bych to udelal nejak takto:
No...já měl v úmyslu použít spíš, "něco jako REST". Počítám spíš s tím, že
se bude používat jen GET a požadav
Ja jsem asi moc ovlivnenej corewars, ale nejak mi unika k cemu by tam
sitova komunikace byla. Stacilo by kdyby klienti uploadnuli modul,
simulator si vsechny naimporti, projede a vyhodi vysledek (vitezove,
resp. zaznam tahu). Na to staci blbej sitovej share.
On 09/11/2015 11:05 AM, Honza Javorek
Pokud bude REST API tim nejlepsim zpusobem jak to udelat (coz nemusi byt),
tak bych to udelal nejak takto:
- hrac udela POST na nejake URL, to mu vrati HTTP kod 202, nejakou odpoved
a Location hlavicku, v niz bude odkaz na URL s vysledkem
- hrac dela nasledne polling na vysledkovem URL, kde se obj
Ahoj,
jednotlivy hraci se budou nejak ovlinovat? (Napr pokud robot R1 stoji na
poli 3,4 nemuze na nej R2)
Pokud ne, proc proste kazdy student nekomunikuje se serverem samostatne
podle, server si vsechny tahy nahraje zobrazi vysledky az kdyz vsichni
tudenti poslou sve tahy?
Pokud ale opravdu musi
Na tohle se hodí websocket, lze to provozovat i ve Flasku. Nebo rovnou použit
něco jiného, např. ZeroMQ.
Petr Messner
11. 9. 2015 v 10:29, Marek Nožka :
> Ahoj
>
> Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> vymyslel(okoukal), že si budeme hrát na Roboty. Bude to
Ahoj
Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou soutěžit
o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
Na s
24 matches
Mail list logo
