Zice "eroare de compilare in evaluator". E bug, mesajul asta trebuie sa fie doar pentru erori in evaluatorul problemei.

BTW: se recomanda sa dai si un link la job-ul cu probleme.

Nu poti sa folosesti jrun pe windows, nici macar alte unix-uri, doar linux. Face niste chestii foarte scarboase si non-portabile.

Ferestrele negre pe care le-ai vazut probabil ca erau cu putty.

Presupun ca in timp de concurs inseamna ca ai fost la stele live? E posibil ca evaluatorul live de la stelele informaticii sa fi fost mai rapid (alt hardware).

Poate ar trebui adjustata limita de timp pentru infoarena? Stie cineva ce configuratie avea evaluatorul de la stele?

ce se intampla exact daca imi scrie "Killed by signal 11(SIGSEGV)"?    

RTFM

Killed by signal: Cea mai frecventa eroare cand ai un bug in program. Cand un program incalca anumite conventii in UNIX acel program primeste un "semnal" care de cele mai multe ori il opreste. Cateva semnale comune:

    * 11(SIGSEGV): Segmentation fault. Asta in 99% din cazuri inseamna ca ai probleme cu accesul la memorie. Ai iesit din limitele unui vector, ai facut stack overflow, etc.
    * 8(SIGFPE): Floating point error. Cauza cel mai frecvent de impartiri la 0.

Am facut upgrade la SMF 1.1.4, speram sa nu apara probleme. Nu ar trebui sa existe nici un fel de modificari vizibile.

Mircea, Mort: Daca apar probleme ./svn-switch-stable si se resolva.

De ce ai vrea sa retrimiti o sursa?

Borland e mort. Lasa-l sa se odihneasca in pace.

Du-te si invata orice altceva, dar nu asta.

S-a discutat destul de mult asupra acestei propuneri la sedinta din 28/10. Mie personal discutia nu mi s-a parut foarte productiva; ar fi mai eficiem sa discutam in continuare pe forum (aici). Rezumatul sedintei:

1) Vali nu este de acord, si considera ca ar fi mai bine sa scriem documentatie pentru infoarena2. De asemenea a ridicat problema ca sunt mai multi oameni dispusi sa invete PHP decat python.

Consider ca am raspuns adecvat la asta in IAP. Nu vreau sa ma repet si nu am nimic de adaugat.

2) Silviu si Cristi au ridicat problema ca nu avem suficienti oameni pentru a duce infoarena3 la capat, si ca avem nevoie de un mod de atrage alti oameni. S-au propus diverse idei blue-sky de a motiva programatori.

Eu cred ca suntem destui oameni in interiorul echipei, si ca nu este neaparat nevoie de un program special de adus oameni. Daca cineva doreste sa ne ajute, poate sa ne contacteze si sa trimita patch-uri. Problema de a aduna programatori pentru ceva open-source este foarte foarte dificila si nu cred ca poate fi rezolvata complet. There is no silver bullet here.

Silviu si Cristi pot continua sa se gandeasca la un mod de a aduce oameni pentru development. Ar fi grozav daca ar gasi o solutie, dar eu sunt foarte pesimist. Este un proiect oarecum independent de IAP3.

Nu avem un plan complet de la cap la coada pentru infoarena3, si nu cred ca putem face un astfel de plan. IAP3 este deja prea mare si nu vreau sa mai adaug. Vreau doar sa aprobam ideea de rescriere si sa cadem de acord ca are sens sa alocam resurse pentru acest proiect. Mai exact:

• Declaram ca Infoarena2 e in maintenance-only mode.
• Inchidem wiki-ul din hackers (sau il declaram obsolete).
• Incepem sa bagam chestii de infoarena3 pe wiki in infoarena.ro/development
• Facem clean-up in tichete, si punem tichete de IA3.
• Incepem sa punem responsabili pe tichete (see IAP).
• Eu continui sa lucrez la demo-ul in python.
• Mircea scrie un document complet de cerinte, cu bullet-point-uri.
• Cine are timp si e interesat de python poate sa faca un demo.

Mi se pare foarte OK ce zice Buru sa justificam voturile. Este o idee foarte buna.

Suntem doar o mana de oameni, nu o democratie salbatica. Este foarte posibil sa ne intelegem si sa ajungem oarecum la un oarecare consens pe IAP-uri. Este mai bine asa decat sa ne batem in numarul de voturi.

Ideea de inteligenta nativa este eronata si foarte daunatoare. Work is life

Din pacate olimpiadele incurajeaza fix ideea asta de inteligenta nativa, mai ales cu problemele "de idee". Multe dintre ele sunt complet artificiale, creeate fix pentru o anumita solutie. Majoritatea nu au aplicatii practice si nici implicatii interesante. Sunt bune doar pentru adunat puncte cu care poti sa pretinzi performanta fara munca.

Mie imi placeau foarte mult in liceu .

Chiar daca avem mai mult de 4 IAP-uri nu vad ce sens are sa avem o sectiune speciala pentru ele. Pot fi puse la gramada in proiecte,idei. Deja sunt mult prea multe sectiuni.

Si ar trebui linkat topicu' din paginile de wiki.

De e avem inca o sectiune de forum, pentru doar 4 topic-uri? Nu e deloc bine.

Astea ar trebui puse ori la feedback ori la proiecte, idei.

Probabil trebuie rescrise explicatiile, dar nu o sa ii ajuti pe cei ce nu citesc atent.

Daca explici clar atunci fix pe cei ce nu citesc atent o sa-i ajuti. Cine sapa prin documentatie intelege oricum.

Nu este prima data cand apare confuzia asta. Cred ca este o problema reala si nu putem sa raspundem doar cu RTFM (oricat de satisfacator ar fi). Trebuie analizate si eventual rescrise explicatiile din macro-urile de inregistrare.

Nu mai stiu daca s-a mai zis, dar pe mine ma deranjeaza ca o problema este evaluata de 2 ori daca ea apartine la 2 grupe de varsta diferite... si in afara de asta, mai e nasol ca apari in ambele clasamente...

Acum o sursa este trimisa la un task pentru o anumita runda. Daca vrei sa trimiti la mai multe runde trebuie sa trimiti de mai multe ori. Si mie mi se pare confuz. Poti sa explici in detaliu ce ai vrea sa se intample cu problemele care apartin de mai multe runde?

Pentru ca numele fisierelor in unix sunt case-sensitive. Tu ai scris "Adunare.out".

Ar merge puse toate ca sectiuni principale. Flat is better than nested.

Ar trebui mutate aici topic-urile existente de teme. Eventual redeschise.

Nu exista limita de caractere pe o linie dintr-un fisier. Latimea default a unui terminal este in general de 80 de caractere. Probabil ca ce vrei tu este:

Cod:

printf("% 80s\n", "hello");
printf("% 80s\n", "world");

Go RTFM!

Un numar intra 0 si 16 poate fi bagat in jumatate de byte; iar 16 numere incap foarte frumos in (16 * 4) = 64 biti. Poti sa encodezi destul de simplu si rapid starea puzzle-ului intr-un long long si sa pui long long in map. BTW, sigur nu vrei set?

Alternativ iti faci un struct si implementezi operator de comparare pe struct. Un typedef aici nu ajunge, array-urile au semnificatii dubioase cand sunt puse ca parametri.

Este ok sa punet si feature request-uri; atat timp cat nu sunt prea "blue-sky". Ideea ar fi sa facem o lista de cerinte minime pentru site care nu trebuie sa ne scape. Ce vreau eu da la infoarena3:

• Sintaxa de textila revizuita si bine documentata. Sa fie mai logica interpretarea de bold/italic etc.
• Sa poti sa pui un macro in bold sau intr-un span.
• Comentariu la orice revizie de wiki (get "revert", "spelling")
• Diff intre oricare 2 versiuni.
• Move si delete cu istorie, accesibile tuturor.
• Atasamente cu istorie ca in wiki, accesibile tuturor.
• Editare pe paragraf ca in wikipedia; sa nu dai scroll mereu.

E pascalu' jegos si face prea multe syscall-uri.

Am marit limita de walltime si acum iei 100, cu 2.8 secunde timp

Am bagat si o reeevaluare pe alte surse care luau wall time limit exceeded si s-ar putea sa fie evaluatorul un pic ocupat. Probabil ca multe surse nu o sa castige puncte oricum.

Mult mult prea mult video. De ce nu mai e la moda textul?

Mesajul evaluatorului este foarte clar; main trebuie sa returneze int.

Desi e acceptat de multe compilatiare void main nu a fost niciodata parte din C/C++ standard.

Se declara ori int main(int argc, char **argv) ori int main() ori int main(void).

Faza cu void in paranteze e pentru C unde daca o functie nu are nici un fel de parametri atunci poti sa trimiti orice. E o chestie foarte veche si nu sunt sigur daca inca merge (poate sa fie disabled by default).

Citeam si eu pagina si mi-a venit in gand RCS cand am ajuns la partea asta. E destul de usor de folosit, dupa parerea mea, daca te obisnuiesti cu el... face un fisier de tip svn in care sunt pastrate toate fisierele si se poate interactiona prin system() cu el destul de dragut... bine, nu stiu daca e o practica foarte buna, dar merita sa incercati vreo cateva minute folosirea lui.

RCS e o chestie foarte veche; din care au aparut ulterior CVS si apoi SVN. Cu svn se poate interactiona folosind librarii speciale si stie chestii care sunt altfel greu de implementat corect: rename/move/copy/delete/restore inclusiv pe directoare. Si ai putea sa iei chestii din wiki pe disc (teste, evaluatoare etc.) ca se le manipulezi frumos.