mirror of
https://github.com/kuhyx/WUT_Computer_Science.git
synced 2026-11-11 16:53:56 +01:00
Krzysztof kuhy Rudnicki
ffa5dad02a
The 250-line cap applies to prose too, and the reports were the worst
offenders -- ENUME's projectA.tex alone was 1,876 lines. Each is now a
preamble plus one \input{} per section, which is how a long LaTeX document is
normally organised; not one byte of prose was rewritten.
"The PDF is unchanged" is checked by a script rather than by eye, because
hashing the PDF cannot work: pdflatex stamps a /CreationDate and an /ID into
every build, so two runs of the SAME source already differ. tex_fingerprint.sh
compares what a reader sees instead -- page count plus a hash of the extracted
text -- and it is stable across rebuilds of untouched sources, which is the
property that makes it usable as a gate.
It earned its keep immediately. Both ECOTE reports quote an example LaTeX
document inside an lstlisting block, so \end{document} appears in the middle
of the file; splitting on the FIRST one stranded everything after it. Same
page count, different text, caught automatically. EOPSY lab3 exposed a second
bug: a \section{} title that runs onto the next line.
Result: 19 .tex over the cap -> 1. The survivor,
ELAC/.../03-building-nfa-...tex, is 418 lines of consecutive tikz figures
with no subsection to split on and needs a hand-placed boundary.
Verified: 29 splits across two passes (section, then subsection for the
pieces still over), every one reporting `unchanged` from
scripts/tex_fingerprint.sh --check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0172dj34FDpao6wsix8ZuCzE
34 lines
1.3 KiB
TeX
34 lines
1.3 KiB
TeX
\section{Finishing comments}
|
|
We runned all the processes, get to know scheduling, get to know first come
|
|
first served algorithm. \\
|
|
There are upsides and downsides of first come first served algorithm:
|
|
\\
|
|
Upsides:
|
|
\begin{itemize}
|
|
\item It is easy to implement
|
|
\item It is easy to understand
|
|
\end{itemize}
|
|
Downsides:
|
|
\begin{itemize}
|
|
\item It is very inefficient (Last experiment with 10 processes barely
|
|
acknowledged existence of the 5th one)
|
|
\item High average wait time (Imagine 1000 processes and how long we
|
|
would have to wait)
|
|
\end{itemize}
|
|
Using pretty much any other algorithm we could get better results \cite{First
|
|
come first serve}
|
|
\begin{figure}[H]
|
|
\caption{\href{https://commons.wikimedia.org/wiki/File:Process_states.svg}{[Process
|
|
states and how they switch from wikimedia]}}
|
|
\includegraphics[width=\textwidth]{procestates}
|
|
\end{figure}
|
|
|
|
\begin{thebibliography}{9}
|
|
\bibitem{lab3 Manual} Manual in the laboratory 3 files.
|
|
\bibitem{First come first serve}
|
|
\href{https://www.studytonight.com/operating-system/first-come-first-serve}{[https://www.studytonight.com/operating-system/first-come-first-serve]}
|
|
\bibitem{Other scheduling algorithms}
|
|
\href{https://www.tutorialspoint.com/operating_system/os_process_scheduling_algorithms.htm}{[Tutorials
|
|
point process scheduling algorithms]}
|
|
\end{thebibliography}
|