Merge branch 'main' of github.com:corneliusdavid/1BRC-Delphi into main

Author: corneliusdavid

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# How to contribute
+
+
+## Formatting
+
+All entries should be formatted using the `Ctr-D` shortcut for both Lazarus and Delphi entries.
+
+## Folder name for the entry
+
+As mentioned on the `REAME.md` file, the name of the folder for the entry should be composed of your first initial followed by your preferred last name.
+
+For example, using _Gustavo Carreno_ for the name, the folder would be `entries/gcarreno`.
+
+## Name of the executable binary
+
+The executable binary follows the same rules has the entry folder above.
+
+## Placement of the executable binary
+
+The executable binary should be placed under a folder named `bin` below the root folder of this repository.
+
+This folder is not present on the repository and is being ignored from the `.gitignore`.
+
+## Commit Messages
+
+(Originally from the [Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/index.html))
+
+### Message Structure
+
+A commit messages consists of three distinct parts separated by a blank line: the title, an optional body and an optional footer.
+
+The layout looks like this:
+```
+type: subject
+
+body
+
+footer
+```
+
+The title consists of the type of the message and subject.
+
+### The Type
+
+The type is contained within the title and can be one of these types:
+
+* feat: a new feature
+* fix: a bug fix
+* docs: changes to documentation
+* style: formatting, missing semi colons, etc; no code change
+* refactor: refactoring production code
+* test: adding tests, refactoring test; no production code change
+* chore: updating build tasks, package manager configs, etc; no production code change
+
+### The Subject
+
+Subjects should be no greater than 50 characters, should begin with a capital letter and do not end with a period.
+
+Use an imperative tone to describe what a commit does, rather than what it did. For example, use change; not changed or changes.
+The Body
+
+Not all commits are complex enough to warrant a body, therefore it is optional and only used when a commit requires a bit of explanation and context. Use the body to explain the what and why of a commit, not the how.
+
+When writing a body, the blank line between the title and the body is required and you should limit the length of each line to no more than 72 characters.
+
+### The Footer
+
+The footer is optional and is used to reference issue tracker IDs.
+
+### Example Commit Message
+
+```
+feat: Summarise changes in around 50 characters or less
+
+More detailed explanatory text, if necessary. Wrap it to about 72
+characters or so. In some contexts, the first line is treated as the
+subject of the commit and the rest of the text as the body. The
+blank line separating the summary from the body is critical (unless
+you omit the body entirely); various tools like `log`, `shortlog`
+and `rebase` can get confused if you run the two together.
+
+Explain the problem that this commit is solving. Focus on why you
+are making this change as opposed to how (the code explains that).
+Are there side effects or other non intuitive consequences of this
+change? Here's the place to explain them.
+
+Further paragraphs come after blank lines.
+
+ - Bullet points are okay, too
+
+ - Typically a hyphen or asterisk is used for the bullet, preceded
+   by a single space, with blank lines in between, but conventions
+   vary here
+
+If you use an issue tracker, put references to them at the bottom,
+like this:
+
+Resolves: #123
+See also: #456, #789
+```

README.md

@@ -125,9 +125,13 @@ In order to verify the official output, we are providing the [source code](./bas
 You can verify the generated `measurements.txt` with a `SHA256` utility:
 
 **Linux**
-```bash
+```console
 $ sha256sum ./data/measurements.txt
 ```
+**Windows (Command Line)**
+```console
+C:> CertUtil -hashfile .\data\measurements.txt SHA256
+```
 **Windows (PowerShell)**
 ```powershell
 Get-FileHash .\data\measurements.txt -Algorithm SHA256
@@ -156,6 +160,7 @@ These are the results from running all entries into the challenge on my personal
 ## Evaluating Results
 Each contender is run 10 times in a row for both `SSD` and `HDD` using `hyperfine` for the time taking. \
 The mean value of the 10 runs is the result for that contender and will be added to the results table above. \
+The min and max values are discarded and the remaining 8 values are then used to calculate the average. \
 The exact same `measurements.txt` file is used for evaluating all contenders.
 
 ## Prize

baseline/Lazarus/src/baseline.lpi

@@ -112,6 +112,11 @@
       <OtherUnitFiles Value="../../Common"/>
       <UnitOutputDirectory Value="../../../bin/lib/$(TargetCPU)-$(TargetOS)"/>
     </SearchPaths>
+    <Linking>
+      <Debugging>
+        <DebugInfoType Value="dsDwarf2Set"/>
+      </Debugging>
+    </Linking>
   </CompilerOptions>
   <Debugging>
     <Exceptions Count="3">

entries/entries.json.example

@@ -7,7 +7,19 @@
     "input-hdd": "{...}1brc-ObjectPascal/data/measurements-1_000_000_000.txt",
     "hyperfine": "hyperfine -w 1 -r 10 -N -n '[[name]]' --export-json '[[results-json]]' '[[entry]]'",
     "lazbuild": "{...}FreePascal_3.0/lazarus/lazbuild",
+    "output-hash": "0000000000000000000000000000000000000000000000000000000000000000",
     "entries": [
+        {
+            "name": "Official Baseline",
+            "notes": "Beeing the last of all",
+            "compiler": "fpc",
+            "entry-folder": "../baseline/Lazarus/src",
+            "entry-binary": "baseline",
+            "lpi": "baseline.lpi",
+            "has-release": true,
+            "threads": 1,
+            "run-params": "-i [[input]]"
+        },
         {
             "name": "Gustavo Carreno",
             "notes": "Using 30 threads",

entries/ikelaiah/README.md

@@ -6,8 +6,10 @@ The approach I implemented here is simplistic.
 
 - Sequentially read the measurement file.
 - Populate a `TDictionary` with station names, min, max, count and sum; without storing all the temperature measurements.
+- Avoided [StrUtil.SplitString](https://www.freepascal.org/docs-html/rtl/strutils/splitstring.html), used [`Pos()`](https://www.freepascal.org/docs-html/rtl/system/pos.html) and [`Copy()`](https://www.freepascal.org/docs-html/rtl/system/copy.html) instead.
 - Use a custom comparer to sort the station and temperature statistics in a `TStringList`.
-- Display the sorted measurements using a simple for loop.
+- Use the rounding method as provided in the `baseline.lpr` (or the `README.md` from 1brc-ObjectPascal).
+- Display the sorted measurements using a simple `for` loop.
 
 ## Getting Started
 
@@ -17,7 +19,7 @@ The approach I implemented here is simplistic.
 
 ### Compiling
 
-* Open `OneBRC.lpi` using Lazarus. 
+* Open `OneBRC.lpi` using Lazarus.
 * Hit `Ctrl + F9` to compile.
 
 ### Running the executable

entries/ikelaiah/src/OneBRC.lpr

@@ -22,10 +22,9 @@
 {$mode objfpc}{$H+}{$J-}{$modeSwitch advancedRecords}
 {$codepage utf8}
 
-
 uses
   {$IFDEF UNIX}
-  cthreads,
+  cmem, cthreads,
   {$ENDIF}
   Classes,
   SysUtils,

entries/ikelaiah/src/stopwatch.pas

@@ -53,11 +53,10 @@ procedure DisplayTimer;
   seconds := elapsedMilliseconds div 1000;
   milliseconds := elapsedMilliseconds mod 1000;
 
-  WriteLn;
   WriteLn('------------------------------');
   WriteLn('Elapsed time: ', hours, ' hours ', minutes, ' minutes ',
     seconds, ' seconds ', milliseconds, ' milliseconds');
-  //WriteLn('Elapsed time: ', (endTime - startTime), ' ms');
+  WriteLn('------------------------------');
 end;