mirror of
https://github.com/kuhyx/WUT_Computer_Science.git
synced 2026-11-10 22:47:09 +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
35 lines
1.6 KiB
TeX
35 lines
1.6 KiB
TeX
\section{Introduction}
|
|
ALL TEXT SURROUNDED BY [] LIKE \cite{lab3 Manual} SHOULD BE CLICKABLE AND LEAD
|
|
EITHER TO WEBPAGE OR PLACE IN THIS DOCUMENT \\
|
|
The goal of the laboratory was to create three scenarios using config file and
|
|
then investigate how those scenarios played out. \\
|
|
Scenario 1: 2 Processes \\
|
|
Scenario 2: 5 Processes \\
|
|
Scenario 3: 10 Processes \\
|
|
We had to get to know how the schedulers work, how they switch. \cite{lab3
|
|
Manual}
|
|
\paragraph{First come first serve}
|
|
We used First come first serve algorithm $\rightarrow$ This algorithm simply executes the process which
|
|
arrived first. The process that requests CPU as a first process gets the CPU
|
|
first. It is easy to implement and understand. We just use Queue data structure
|
|
and we pick processes from the head of the queue and new procesess are added at
|
|
the tail of the queue. \cite{First come first serve}
|
|
\begin{figure}[H]
|
|
\caption{First come first serve example graphic from
|
|
\href{https://www.geeksforgeeks.org/program-for-fcfs-cpu-scheduling-set-1/}{[Geeks for
|
|
Geeks]}}
|
|
\includegraphics[width=\textwidth]{FCFS}
|
|
\end{figure}
|
|
\paragraph{Other algorithms} \cite{Other scheduling algorithms}
|
|
\begin{enumerate}
|
|
\item Shortest-Job-Next - Executes first processes that will take least
|
|
time to finish
|
|
\item Priority Scheduling - Each process gets assigned a prority and we
|
|
execute them from the process with highest priority to the
|
|
process with lowest prority
|
|
\item Round Robin Scheduling - We give each process a constant time to
|
|
execute, after this time expires regardless whether process
|
|
finished or not we go to another process untill all of them are
|
|
finished
|
|
\end{enumerate}
|