Commit graph

180 commits

Author SHA1 Message Date
a34d718247
Create README.md 2024-04-05 00:37:53 +02:00
aba6e10a18 Fix wrong json property name 2024-04-04 23:41:38 +02:00
3f84e1d831 Adapt to new bot structure 2024-04-04 23:25:47 +02:00
ff7e08ada9
Update README.md 2024-03-28 18:13:59 +01:00
72f6cd30d0
Merge pull request #27 from LucaSforza/domande-appello-gennaio-2024
domande che non stavano nel bot dell'appello di gennaio 2024
2024-02-02 14:01:35 +01:00
LucaSforza
455bb6bbaa domande che non stavano nel bot dell'appello di gennaio 2024 2024-02-02 13:26:17 +01:00
85f938173d Fix bot giving error in any question 2024-01-31 13:01:37 +01:00
df7ac5b33d Remove useless import 2024-01-31 12:54:40 +01:00
256f03b3a3 Remove webBaseUrl variable (unused) 2024-01-31 12:54:17 +01:00
63d4683bb2 Remove docker network from compose 2024-01-31 12:51:17 +01:00
a38357d7e7 Switch from webserver to telegram inputfile 2024-01-31 12:49:28 +01:00
ea3ff8aba8 add network to docker compose 2024-01-31 05:07:21 +01:00
fcea7b4a31 Add Traefik labels to docker compose 2024-01-31 04:58:34 +01:00
4d56d71aa2 Add so1_new 2024-01-31 04:56:46 +01:00
e4998d433d Add local images support ...finally! 2024-01-31 04:56:23 +01:00
276ae8af2e Add JSON support ...finally! 2024-01-31 03:24:59 +01:00
391862b3fb Fix images syntax in so1.txt 2024-01-22 17:37:30 +01:00
2b5339ec92 Fix denial of service bug, empty questions handling and images handling 2024-01-22 17:36:52 +01:00
5b626f09a4
Update unive message 2024-01-22 00:02:08 +01:00
6f7f2432dd Merge branch 'gpelisset-main' 2024-01-21 14:52:03 +01:00
07daa07cf2 Move SendToEveryone on its own Thread 2024-01-21 14:51:44 +01:00
53857456ed Fix so1.txt ending with two empty lines 2024-01-21 14:51:44 +01:00
f62b15bca2 Fix bot considering empty lines 2024-01-21 14:51:44 +01:00
LucaSforza
d35b46206a aggiunta un ultima domanda che mi era sfuggita 2024-01-21 14:51:44 +01:00
LucaSforza
f820abf32b aggiunta nuove domande prese da esami precedenti trovati su telegram 2024-01-21 14:51:38 +01:00
0120b74d90 Move SendToEveryone on its own Thread 2024-01-21 14:12:10 +01:00
8870edf3a8 Fix so1.txt ending with two empty lines 2024-01-21 14:05:16 +01:00
582b21e1b3 Fix bot considering empty lines 2024-01-21 14:04:20 +01:00
62269e7d67
Merge pull request #25 from LucaSforza/nuove-domande
aggiunta nuove domande prese da esami precedenti trovati su telegram
2024-01-21 13:31:55 +01:00
LucaSforza
36007e5e84 aggiunta un ultima domanda che mi era sfuggita 2024-01-21 12:47:36 +01:00
LucaSforza
35c45ea4b5 aggiunta nuove domande prese da esami precedenti trovati su telegram 2024-01-21 12:33:13 +01:00
gpelisset
8d946ced84
Merge pull request #1 from gpelisset/new-brach
Merge con cambiamenti
2024-01-20 18:57:03 +01:00
gp
3fd89253b2 fixups after questions review 2024-01-20 18:52:40 +01:00
gp
32e08eb505 Marcato come UNSAFE la domanda 2 e cambiato risposta. La disabilitazione delle interruzioni non impedisce la creazione di nuove interruzioni, ma semplicamente impedisce che esse vengano gestite. Quindi e' falso dire che la disabilitazione delle interruzioni impedisce la creazione di nuove interruzioni. Quindi dovrebbe essere la risposta 1. Al tempo stesso non e' chiaro cosa voglia dire che La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core. Volendo, su ogni processore, si possono disabilitare le interruzioni, e quindi dire che 'La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core' e' falso. Forse intendeva dire che La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core per garantire la mutua esclusione.... In questo caso sarebbe vera. Quello che pero' e' certo e' che la 1 e' falsa.
Cambiato risposta domanda 5. Dire che 'Il translation lookaside buffer permette di accedere direttamente al contenuto degli indirizzi di memoria virtuali usati più di recente'  e' falso dato che gli unici dati presenti nel TLB sono delle associazioni (page_number: frame_number) e non c'e' assolutamente nulla relativo al contenuto dei frame. Viceversa dire che 'Il translation lookaside buffer è una particolare cache, ma non è completamente trasparente al sistema operativo' e' vero visto che ad ogni process switch ne va fatto il flush
                                Aggiunto parte mancante della domanda 16
                                Aggiunto commento alla domanda 20 (lo posso anche rimuovere). Ma qualora avessimo due processi A e B che si scambiano messaggi e due altri processi C e D che si scambiano messaggi e e' assurdo pensare che se A esegue un receive bloccante anche le receive di C si blocchino.
                                Commento sulla domanda 22. E' vero che 'il data rate confronta le velocità di 2 diversi dispositivi di I/O'. Si veda vd. gruppo 5 di slide, slide 11.
                                Aggiunto commento alla domanda 24. Nel caso di un mode switch non c'e' alcun motivo per cui lo hardware context debba essere salvato
                                Cambiato risposta 25. In slide 67 del 5 blocco di slide, e' scritto esplicitamente che 'si passa dalla parte nuova alla vecchia per scorrimento' ma 'quando un blocco viene referenziato, lo si sposta all’inizio dello stack'. Quindi, a "scendere" effettivamente si procede per scorrimento, ma a salire no. Al contrario, la quattro ('L'algoritmo di sostituzione basato su frequenza a 2 segmenti della page cache può non avere buone performance quando un settore viene acceduto spesso, ma tra il primo accesso e quelli successivi ci sono N accessi ad altri settori, diversi tra loro, con N pari alla dimensione del segmento nuovo') e' vera.
                                Aggiunto UNSAFE alla 64. Qualora lo scheduler esegua per primo il processo numero 0, e qualora esso superi il while piu' esterno prima che p1 venga eseguito, ecco che p0 e' entrato nella sezione critica. Quindi e' falso dire che 'Nell'algoritmo di Dekker, se la variabile turn è inizializzata ad 1, allora il processo 1 sarà sicuramente il primo ad entrare nella sezione critica nella prima iterazione'. Purtroppo anche tutte le altre risposte sono sbagliate
                                Aggiunto UNSAFE alla 106. In generale, su una architettura CISC (ad esempio x86) non e' vero che gli opeandi devono essere cariacati nei registri. Ad esempio addq (%rax), %rbx aggiunge un valore (il quale si trova in memoria) puntato dal registro %rax al contenuto del registro %rbx. Qualora invece ci restringessimo ad una architettura RISC, quanto affermato nella domanda sarebbe vero. Va quindi cambiata la domanda essendo piu' espliciti su CISC e RISC?
2024-01-20 17:23:29 +01:00
9870ec28f1 Merge remote-tracking branch 'refs/remotes/origin/main' 2024-01-19 20:34:57 +01:00
0cddce0e08 Fix wrong S01 command && update welcome message 2024-01-19 20:34:20 +01:00
2f2d4fb095
Merge pull request #22 from LucaSforza/nuove-domande
aggiunta domande per SO1
2024-01-19 19:21:33 +01:00
92d544f18e set build policy to docker compose 2024-01-19 19:18:30 +01:00
ffa004f20c Add Bot/obj to gitignore 2024-01-19 19:17:34 +01:00
be5439df7d Add compiled binaries to gitignore 2024-01-19 19:10:33 +01:00
95e02d9a64 Fix bot haning when sending alerts 2024-01-19 19:06:53 +01:00
LucaSforza
0bb085e548 aggiunta domande per SO1 2024-01-19 16:25:17 +01:00
0f90b3525e
Delete .idea/.idea.so-un-bot.dir/.idea directory 2024-01-19 03:32:19 +01:00
3879937726 Update gitignore 2024-01-19 03:32:01 +01:00
8fc89fbc03 Refactor repo structure 2024-01-19 03:29:39 +01:00
36ac339086
Merge pull request #21 from NotFiliberto/patch-1
fix: empty row for diritto venezia
2024-01-17 22:16:07 +01:00
Filiberto
9b4a6c9da4
fix: empty row for diritto venezia 2024-01-17 21:49:04 +01:00
74e8795327
Merge pull request #20 from NotFiliberto/main
Add: domande diritto venezia
2024-01-12 03:28:23 +01:00
Filiberto
7082aea3d0
Add: domande diritto venezia 2024-01-06 21:57:41 +01:00
d01cf118e4
Merge pull request #19 from Samseys/patch-1
Fix Sicurezza question 1120 (pg 709)
2023-07-11 14:58:21 +02:00