massiv-crap Mailing List for Massively multiplayer game middleware

On Wednesday 30 October 2002 15:46, Petr Tovarys wrote:

> Me osobne je to jedno, ja mam cas  zitra kdykoli. Tech 15:30 by mi
> vyhovovalo lepe.

Ok, nejak to snad preziju. Prijdu nekdy po 15:30, kdy presne to vam zatim=
=20
nepovim, snad ne moc pozde.

-- Stoupik

> > > On Tuesday 29 October 2002 19:23, Petr Tovarys wrote:
> > >
> > > > > Asi by nejaka schuzka byt mela, ale ve ctvrtek asi budu schuzovat
> > ohledne
> > > > > diplomky, jeste presne nevim kdy. Takze nevim. Co patek?
> > > >
> > > > Patek ok, kdekoli kdykoli (i kdyz dostat se na ms na 9:00 rano by
bylo
> > > > docela drsne ;-)
> > >
> > > Prave jsem dohodl schuzi ohledne diplomky na ctvrtek 9:00, takze by to
> slo
> > i
> > > ve ctvrtek odpoledne. Nejak se dohodni s Markem a oznam mi termin.
> >
> > Ja mam shodou okolnosti rovnez schuzku kvuli diplomce na 12:30 v ELABu,
> > takze by mi vyhovovalo, kdyby se schuzka konala nekde v MENZE rekneme po
> 14
> > h, nebo alespon kdyby tam byl Boovie od 14 h, ostatni (prakticky jenom
> > Stepan) by mohli prijit pozdeji.
>
> Budete-li o to stat, mohlo by se to jeste posunout na 15:30, nebot bych
mohl
> jit na seminar z PGR.


Me osobne je to jedno, ja mam cas  zitra kdykoli. Tech 15:30 by mi
vyhovovalo lepe.

Petr

----- Original Message -----
From: "Marek Vondrak" <mvo...@ce...>
To: "MASSIV-DEVEL" <mas...@li...>
Sent: Wednesday, October 30, 2002 1:39 PM
Subject: Re: [Massiv-devel] schuze


> > On Tuesday 29 October 2002 19:23, Petr Tovarys wrote:
> >
> > > > Asi by nejaka schuzka byt mela, ale ve ctvrtek asi budu schuzovat
> ohledne
> > > > diplomky, jeste presne nevim kdy. Takze nevim. Co patek?
> > >
> > > Patek ok, kdekoli kdykoli (i kdyz dostat se na ms na 9:00 rano by bylo
> > > docela drsne ;-)
> >
> > Prave jsem dohodl schuzi ohledne diplomky na ctvrtek 9:00, takze by to
slo
> i
> > ve ctvrtek odpoledne. Nejak se dohodni s Markem a oznam mi termin.
>
> Ja mam shodou okolnosti rovnez schuzku kvuli diplomce na 12:30 v ELABu,
> takze by mi vyhovovalo, kdyby se schuzka konala nekde v MENZE rekneme po
14
> h, nebo alespon kdyby tam byl Boovie od 14 h, ostatni (prakticky jenom
> Stepan) by mohli prijit pozdeji.

Budete-li o to stat, mohlo by se to jeste posunout na 15:30, nebot bych mohl
jit na seminar z PGR.
-- Markoid

On Tuesday 29 October 2002 17:59, Stepan Vondrak wrote:

> Viz attachements, opravte si to prosim, sam uz to delat nebudu. Davejte=
 si
> na to priste bacha.
>
> V tom massiv.conf jsou ty taby asi ok, jestli to spravne chapu?

Fakt se omlouvam:
1) blbne nam tu sit, takze vam tedle blbej mail prisel nejmene 3x
2) attachnul jsem jine 2 ze 3 souboru nez jsem chtel - misto 'diff' tam m=
el=20
byt 'tabs'. Jsou v techto souborech:
=2E/core/net/arch/unix/serveraddress_unix.cpp
=2E/core/net/net.h
=2E/core/net/checksum_impl.h
=2E/core/test/massiv.conf (pravdepodobne umyslne a ok)
=2E/core/test/test_sockets.cpp
=2E/core/thread/arch/unix/thread_unix.cpp
=2E/core/thread/arch/unix/thread_unix.h
=2E/core/thread/arch/win32/thread_win32.cpp
=2E/core/thread/arch/win32/thread_win32.h
=2E/core/thread/thread.h

Pokud vam to prijde vickrat, tak to nejak tak ignorujte

-- Stoupik

On Wednesday 30 October 2002 10:15, Petr Tovarys wrote:

> Me by se docela libily i ty terminy rano od 9, at to mame
> vsechno rychle z krku, a soucasne by stejny termin mohl
> zustat, kdyz by se mela schuze konat u Tumy.

Taky bych preferoval terminy rano, jinak je celej den v pr...
Den kdykoliv.

-- Stoupik

Cus, prunik pravidelnych terminu, pokud jsem to nepopletl:

boovie, stoupik, markoid, marekus:

po      19+ (prilis pozde?)
st 9+   17+ (ne v troji)
ct 9-12 17-19 (upper limits by marekus)
pa 9+   17+ (ne v troji)

Kdyz se prida octa, tak zbyde

po 19+
st 18+

Ale s octou to neni jiste, bo mozna budet menit kolej,
takze se jeho moznosti mozna rozsiri.
Od hafa zadne terminy nejsou.
Taky jste se pry nejak domlouvali na mesicnich schuzkach
s Tumou, tak co s nima?
Me by se docela libily i ty terminy rano od 9, at to mame
vsechno rychle z krku, a soucasne by stejny termin mohl
zustat, kdyz by se mela schuze konat u Tumy.


Petr

Viz attachements, opravte si to prosim, sam uz to delat nebudu. Davejte s=
i na=20
to priste bacha.

V tom massiv.conf jsou ty taby asi ok, jestli to spravne chapu?

-- Stoupik

> From: "Stepan Vondrak" <st...@mi...>
> 
> 
> > - set_x() metody, konstruktory: pojmenovavat parametry napriklad 'the_x'
> nebo
> > 'new_x'.
> > - Ostatni parametry a member promenne pojmenovavat radsi i vic opisne, aby
> > bylo jasne, co jsou zac. Napriklad 'destination_archivation_id' nebo
> > 'event_archivation_id' - proste aby bylo jasne, ceho ze id tadle promenna
> je.
> > Nerecyklovat promenne jenom proto, ze maji stejny typ (a pak jim davat nic
> > neriklajici jmena - treba 'pom', ze :-)
> 
> 
> Member s prefixem m_xxx na druhou stranu jsou bezpecnejsi rozhodne vice nez
> to co se ted pouziva v massivu this->neco = neco nebo if( neco ) then
> this->neco().
> Taky se mi zda vice intuitivnejsi class A { int size() { return m_size; }
> int m_size; }
> nez class A{ int size() { return self_size; } int self_size; }
> Jen chci rict ze prefix m_ dava jasnou presne
> definovanou konvecni, ktera usnadnuje kolize a cteni kodu, naproti tomu
> pravidla ktera pises jsou takova "jak kdo jak kdy".
> Ale je to spis otazka zvyku...

Rozhodne jsem proti m_xxx, znamenalo by to zasadni zmenu codestyle a uz kdysi bylo dohodnuto v podstate to, co Stepan ted psal (tak by to tedy melo byt).
Co se vsak tyce parametru typu "const int" a podobnych nesmyslu, s tim nesouhlasim, nebot to je zbytecne a jenom to zbytecne zneprehlednuje kod. Naopak rozlisovani const a neconst metod a "const Class &" a "Class &" samozrejme smysl ma.

-- Markoid

> From: Marek Svantner <msv...@se...>
> Pokud jde o to pakovani udp paketu do 1 zpravy, tak vyssi vrstve by se
> to mohlo
> hodit, kdyz by chtela treba prenest nejakou skupinu objektu naraz, nebo
> ne? Net
> to ale bude umet delat i sam, to mam v planu.


Zatim vubec nevidim k cemu by se to mohlo hodit. Objekty z replikacnich
a migracnich skupin jsou automaticky prenaseny dohromady, na urovni
SystemMessage. Navic po udp se asi budou prenaset pouze replikace,
a spojovani udp paketu z jineho duvodu nez zabraneni malych
udp paketu (coz bude delat network) me nenapada.


> Tag u locku je typ odesilane zpravy - nekolik jich ma vyhrazenych net,
> vyssi vrstvy
> si definuji sve typy jako NET_MIN_USER_MESSAGE + neco. Akorat nevim,
> jestli o to ty vyssi vrstvy zrovna nejak stojej... :)


Aha, no zatim o to nestoji :-) Na urovni SystemMessage si delam
identifikace zprav sam, a nevim jestli ma smysl tohle patlat dohromady
s networkem, asi ne.


Petr

Ten network interface se mi teda moc nelibi.
- Co to je u tech locku ten UInt32 tag? Vsechny parametry, ktere jsou
jasne popsane jsou, ale tendle nejasny popsan neni :) (nebo sem si nevsim)

- Proc tam je flazik tcp_send_immediately? Pokud uz tam ma byt, proc
je jen u tcp a ne u udp?

- Proc se zavadel Network::StreamType, ktery jsem zacal pouzivat, kdyz
vlastne
nikde neni pouzivan v networku?
Nemel by interface spis byt

NetOBuffer * lock( Streamtype type );
void unlock( NetObuffer * buffer );
?
TCP a UDP OBuffery stejne nedavaji zadny interface, ktery by
byl vyssim vrstvam k uzitku. Zatim je rozliseni na TCP a UDP pro vyssi
vrstvy
jen kvuli tomu, aby to poznal network::unlock(). Spis bych dal typ do
netobufferu, zda je to tcp nebo udp a unlock si to testne sam.

-Pro se o pakovani unreliable bufferu do jedne zpravy ma starat vyssi
vrstva?
Resp. tak jsem to pochopil z toho flush & flush allowed.
Pakovani by mela podle me delat network vrstva sama - pri posilani zjistit,
zda
na stejny node jde vice udp zprav a ty spojit do jednoho udp paketu podle
velikosti.


Petr

From: "Stepan Vondrak" <st...@mi...>


> - set_x() metody, konstruktory: pojmenovavat parametry napriklad 'the_x'
nebo
> 'new_x'.
> - Ostatni parametry a member promenne pojmenovavat radsi i vic opisne, aby
> bylo jasne, co jsou zac. Napriklad 'destination_archivation_id' nebo
> 'event_archivation_id' - proste aby bylo jasne, ceho ze id tadle promenna
je.
> Nerecyklovat promenne jenom proto, ze maji stejny typ (a pak jim davat nic
> neriklajici jmena - treba 'pom', ze :-)


Member s prefixem m_xxx na druhou stranu jsou bezpecnejsi rozhodne vice nez
to co se ted pouziva v massivu this->neco = neco nebo if( neco ) then
this->neco().
Taky se mi zda vice intuitivnejsi class A { int size() { return m_size; }
int m_size; }
nez class A{ int size() { return self_size; } int self_size; }
Jen chci rict ze prefix m_ dava jasnou presne
definovanou konvecni, ktera usnadnuje kolize a cteni kodu, naproti tomu
pravidla ktera pises jsou takova "jak kdo jak kdy".
Ale je to spis otazka zvyku...


Petr

On Sunday 20 October 2002 21:49, Petr Tovarys wrote:

> s proemnnymi tridy apod., napriklad klasika
> nejaka_funkce()
> {
> ArchivationId arch_id; // pere se s this->archivation_id
> if( archivation_id =3D=3D arch_id )
> {...}
> }
> No todle mozna neni best priklad, ale vite co myslim.
>
> , nebo klasicky
> funkce set_x( int _x ) { x =3D _x; }
> oz se objevuje casto pri takovych malych tridach
> s operatory a funkcemi set(), get().
>
> Tak jestli by se nehodily nejake prefixy na member promenne?
> Co ted pisu mimo massiv, tak jsem se naucil psat
> member promenne s prefixem m_ a docela se mi to libi,
> a preci jen lze kod cist lepe (zvlast kdyz tam je arch_id
> a archivation_id, ale to se obecne tyka pridavani ci zkracovani
> jmen, aby se nepraly s member promenyma).
> Tak napiste co si o tom myslite, je to jen navrh, takze nemusite
> hned psat sproste maily (ze M. :)

Osobne to nemam vubec rad a myslim, ze se spis hodi resit tydle problemy=20
jinak, mj.:

- set_x() metody, konstruktory: pojmenovavat parametry napriklad 'the_x' =
nebo=20
'new_x'.
- Ostatni parametry a member promenne pojmenovavat radsi i vic opisne, ab=
y=20
bylo jasne, co jsou zac. Napriklad 'destination_archivation_id' nebo=20
'event_archivation_id' - proste aby bylo jasne, ceho ze id tadle promenna=
 je.=20
Nerecyklovat promenne jenom proto, ze maji stejny typ (a pak jim davat ni=
c=20
neriklajici jmena - treba 'pom', ze :-)

Radsi bych byl, kdyby nikdo nikdy nezkracoval jmena promennych/funkci jen=
om=20
proto, aby je oddelil (v praci mame zkracovani zakazano globalne, ja bych=
=20
osobne proti 'dest_arch_id' a 'event_arch_id' nic nemel, ale mit zaroven=20
'archivation_id' a 'arch_id' je dost hrozne.

-- Stoupik

On Tue, 22 Oct 2002, Petr Tovarys wrote:

>
> Custe, bylste uz nekdo na zapise?
> Jak se zapisuje projekt?
> Koukal jsem totiz, ze ted z projektu udelali
> dve dvousemestralni zapocty,
> jeden s kodem prg027 a druhy prg023.
> Ma se ted zapsat prg027 a v pristem semestru
> opet prg027 a tedy dvakrat do indexu?


Tak uz jsem to pochopil.

"Pøedmìty PRG027 Zápoèet k projektu, PRG023 Projekt a PRG028 Mimoøádné
ohodnocení projektu si lze zapsat kdykoliv podle potøeby, nikoli pouze v
období zápisu vymezeném v harmonogramu akademického roku, jako je tomu u
vìt¹iny ostatních pøedmìtù."

Petr

Custe, bylste uz nekdo na zapise?
Jak se zapisuje projekt?
Koukal jsem totiz, ze ted z projektu udelali
dve dvousemestralni zapocty,
jeden s kodem prg027 a druhy prg023.
Ma se ted zapsat prg027 a v pristem semestru
opet prg027 a tedy dvakrat do indexu?

Petr

Caues,
Jiz jsem se o tom trochu zminoval stepanovi, ze by se
hodilo (aspon pro me), rozlisovani member promennych versus
promennych na zasobniku a parametru.
uz se mi to stalo casto, a ted se mi to stava porad, protoze
zpracovavam komunikacni zpravy, a promenne z nich se perou
s proemnnymi tridy apod., napriklad klasika
nejaka_funkce()
{
ArchivationId arch_id; // pere se s this->archivation_id
if( archivation_id == arch_id )
{...}
}
No todle mozna neni best priklad, ale vite co myslim.

, nebo klasicky
funkce set_x( int _x ) { x = _x; }
oz se objevuje casto pri takovych malych tridach
s operatory a funkcemi set(), get().

Tak jestli by se nehodily nejake prefixy na member promenne?
Co ted pisu mimo massiv, tak jsem se naucil psat
member promenne s prefixem m_ a docela se mi to libi,
a preci jen lze kod cist lepe (zvlast kdyz tam je arch_id
a archivation_id, ale to se obecne tyka pridavani ci zkracovani
jmen, aby se nepraly s member promenyma).
Tak napiste co si o tom myslite, je to jen navrh, takze nemusite
hned psat sproste maily (ze M. :)


Petr

> To Markoid & Stepan:
> Mate nejake hodiny (u Stepana asi trapny dotaz :-D
> tady v troji nebo v menze? Aby se daly pripadne resit mensi
> veci v jadru, do kterych stejne nikdo jiny nevidi,
> a pres maily neco resit moc nejde.

Stepan si nezapisuje nic, ja poskrovnu. V utery jsem k sehnani v menze.
-- Markoid

Flamewar ahoy!

On Monday 14 October 2002 13:00, Marek Vondrak wrote:

> Samozrejme zase s nakejma blbejma omegabot, ze? Jak jinak...

Projekt?

> Jakej je prosimte rozdil v tom jak pracujes na projektu o zkouskovem, o
> prazdninach a tedka?

No ze treba tedka na tom delam?

> Jses blb?

Myslim ze ne. Ty jsi nebo proc se ptas?

Sorry pro ostatni. Uznavam, skocit na takhle pitomej flamebait je fakt la=
me.=20
Priste se pokusim to ignorovat.

-- Stoupik

----- Original Message -----
From: "Stepan Vondrak" <st...@mi...>
To: <mas...@li...>
Sent: Monday, October 14, 2002 9:19 AM
Subject: Re: Re[2]: [Massiv-crap] dalsi schuza


> On Sunday 13 October 2002 22:01, Ondrej Pecta wrote:
>
> > Ted jsem si to precetl, muzu tam v tech 18.00 byt. Pocitam s tim.
> > I kdyz by se mi to hodilo vic hned po ty vycislitelnosti, jak jsme
> > mluvili.
>
> Vzhledem k tomu, ze Marek Svantner psal zhruba totez, doporucil bych vam
sejit
> se uz o neco driv (vy dva) a prodiskutovat sit, aby se na vlastni schuzce
> projednavali uz veci globalnejsi (pokud teda mate o cem diskutovat).
>
> -- Stoupik

Me by se to hodilo rovnez driv, takze pokud by se oficialni zacatek
posunulu, nebudu proti.

-- Markoid

>
> Tim upresnit/zmenit jsem myslel "piste pripominky kdy by se to hodilo".
Nebo
> zase sourceforge blbne a nedostal jsem od vas zadnou odpoved kvuliva nemu?

Na spoustu organizacnich veci ohledne spravy objektu jsem rovnez nedostal
zadne odpovedi, tak nejanci.

>
> Pondeli 14.10. 18:00 Troja.
>
> A napiste aspon "ok" pokud to nejak berete navedomi, jinak tam proste
> nepojedu, protoze prace mam vic nez dost.

Samozrejme zase s nakejma blbejma omegabot, ze? Jak jinak...
Jakej je prosimte rozdil v tom jak pracujes na projektu o zkouskovem, o
prazdninach a tedka?
Jses blb?

-- Markoid

On Sunday 13 October 2002 22:01, Ondrej Pecta wrote:

> Ted jsem si to precetl, muzu tam v tech 18.00 byt. Pocitam s tim.
> I kdyz by se mi to hodilo vic hned po ty vycislitelnosti, jak jsme
> mluvili.

Vzhledem k tomu, ze Marek Svantner psal zhruba totez, doporucil bych vam =
sejit=20
se uz o neco driv (vy dva) a prodiskutovat sit, aby se na vlastni schuzce=
=20
projednavali uz veci globalnejsi (pokud teda mate o cem diskutovat).

-- Stoupik

Hello Stepan,

Sunday, October 13, 2002, 5:58:12 PM, you wrote:

SV> On Thursday 10 October 2002 16:20, Stepan Vondrak wrote:

>> Pristi tyden by se mela konat schuzka za ucasti vsech clenu. Na te minule
>> jsme se predbezne dohodli na pondelku odpoledne v Troji. Chtelo by to
>> upresnit/zmenit a tak.

SV> Tim upresnit/zmenit jsem myslel "piste pripominky kdy by se to hodilo". Nebo 
SV> zase sourceforge blbne a nedostal jsem od vas zadnou odpoved kvuliva nemu? 
SV> Rad bych tomu veril. Takze moci velkeho Stoupika:

SV> Pondeli 14.10. 18:00 Troja.

SV> A napiste aspon "ok" pokud to nejak berete navedomi, jinak tam proste 
SV> nepojedu, protoze prace mam vic nez dost.


SV> -- Stoupik


SV> -------------------------------------------------------
SV> This sf.net email is sponsored by:ThinkGeek
SV> Welcome to geek heaven.
SV> http://thinkgeek.com/sf
SV> _______________________________________________
SV> Massiv-crap mailing list
SV> Mas...@li...
SV> https://lists.sourceforge.net/lists/listinfo/massiv-crap

Ted jsem si to precetl, muzu tam v tech 18.00 byt. Pocitam s tim.
I kdyz by se mi to hodilo vic hned po ty vycislitelnosti, jak jsme
mluvili.
Octa

-- 
Best regards,
 Ondrej                            mailto:oc...@ma...

On Thursday 10 October 2002 16:20, Stepan Vondrak wrote:

> Pristi tyden by se mela konat schuzka za ucasti vsech clenu. Na te minule
> jsme se predbezne dohodli na pondelku odpoledne v Troji. Chtelo by to
> upresnit/zmenit a tak.

Tim upresnit/zmenit jsem myslel "piste pripominky kdy by se to hodilo". Nebo 
zase sourceforge blbne a nedostal jsem od vas zadnou odpoved kvuliva nemu? 
Rad bych tomu veril. Takze moci velkeho Stoupika:

Pondeli 14.10. 18:00 Troja.

A napiste aspon "ok" pokud to nejak berete navedomi, jinak tam proste 
nepojedu, protoze prace mam vic nez dost.


-- Stoupik

From: "Stepan Vondrak"

> Pristi tyden by se mela konat schuzka za ucasti vsech clenu. Na te minule
jsme
> se predbezne dohodli na pondelku odpoledne v Troji. Chtelo by to
> upresnit/zmenit a tak.


Asi odted nebudu na inetu, bo zatim nevim jak jsou na tom laby na koleji.
V nedeli brnknu stepanovi jak jste se dohodli.
Skusim pripravit nejdulezitejsi veci k reseni pres vikend (coz neznamena ze
si
je nemusite pripravit vy :-)
Na aktualni maily odepisu az zas budu funkcni (snad do tydne).

Petr

Caute soudruzi

Pristi tyden by se mela konat schuzka za ucasti vsech clenu. Na te minule=
 jsme=20
se predbezne dohodli na pondelku odpoledne v Troji. Chtelo by to=20
upresnit/zmenit a tak.

Temata jsou ruzna, hlavne probrat a vyresit soucasne nejasnosti, viz. spo=
usta=20
Petrovych mailu jak v massiv-devel tak massiv-crap.

-- Stoupik

> > Jak bude fungovat pripojovani klientu. Pridelovani NodeId
> > klientu. Zastupny objekt klienta (jak pozna ze se klient
> > odpojil, jak se klient dozvi kde je). Jak zarucit, aby client
> > nemohl poslanim spatne message dostat system do nekonzistentniho
> > stavu (ala premapovavani objekt id pri serializaci). A dalsich 100
> 
> Tohle musi resit Stepan s tebou, nebot ostatni clenove teamu do toho
> nevidi.


Protoze se zatim nevi jak to bude vubec fungovat, tak do toho
taky nema nikdo co videt, protoze neni do ceho. Prave od toho to je,
aby to nekdo navrh. Ja jsem sice psal drive male pojednani
jak vypadaji problemy, ale to je tak vsechno, mel to byt odrazovy
mustek pro nekoho, kdo to pekne vyresi do zdarneho konce.
To ze mam na starosti lokalizacni protokol, neznamena ze musim
vymyslet celou komunikaci mezi nody, aby me za ni pak nekdo sepsul
ze nefunguje, ala neustale kecy o nepotrebe hacku na object
pointerech, o ktere jsem vyblil snad uz 10 mailu a stale nic.

Tato high-level komunikace, spolu s konexemi mezi nody
je jadrem massivu, a mel by do ni videt kazdy clen tymu
(do logiky, ne do implementace),
a kazdy prispet svym navrhem, jak by to melo fungovat.
Napriklad citace z meho mailu 16.7.2002
"Zde posilam novejsi versi komunikace mezi Nody.
Ke stare versi ani k migracnimu protokolu jsem nedostal zadne
pripominky (ani odpovedi na otazky)". Na odpovedi na novou
versi se radeji ani nedivam.
Tady nejde o wraper na sokety nebo test z generalizace pri
dedicnosti ala megalomansky filesystem, ale o logiku
celeho jadra massivu, jednu z nejdulezitejsich casti dle meho.
Az budu v Praze tak na nejblizsich schuzkach se bude resit pouze
tyto veci a veci shrnute v commnucation.txt (zvlaste vety koncici
otaznickem), bo bez nich to pude tezko.


Petr