First off, thank you for the feedback.
the documentation says:
2.1. Decision: PasBuild Multi-Module Layout
+-- docs/ # Documentation
¦ +-- opdf-specification.adoc
¦ +-- analysis.adoc
¦ +-- implementation-plan.adoc
¦ +-- design-decisions.adoc
¦ +-- progress.adoc
but, the above tree does NOT match the current docs directory.
That decision document was/is a living document. A lot of it was written before I even wrote the first line of code. Then as I implemented things, some design choices changed, as I learned more or thought of future proofing. So I documented those ideas/changes as I went.
The only missing document from that list is the
implementation-plan.adoc. And that was more of a personal To Do List, ticking things off as I go. Once I had my initial MVP in place, that document wasn't needed any more and got deleted.
where it says:
TypeID Word (65K) Cardinal (4B) Large projects with generics may need 100K+ type IDs
The "Cardinal (4B)" should be "Cardinal (4GB)". This would it make consistent with previous lines in the same group of changes.
No, it's correct, but I can see the confusion, so I just updated it.
RecSize: Word is 16-bit unsigned, max value 65,535 — so max
record size of 64KB. Cardinal is 32-bit unsigned, max ~4.29 billion —
so max record size of 4GB. Both annotations are accurate.
TypeID: The values are mathematically correct — Word gives 65,535
possible IDs (~65K), and Cardinal gives ~4.29 billion. However, the
annotation
Cardinal (4B) is ambiguous. In a size/storage context, "B"
typically means Bytes, so 4B reads as "4 Bytes" — which is actually
the storage size of a Cardinal, not its range. The intent was
"4 Billion IDs", but a reader could easily misread its meaning.
I've just updated it to ~4.3 billion.
consider changing:
set Count = 10
to
set Count := 10
for consistency with the Pascal language and eliminate the apparent boolean ambiguity. Strictly speaking assignment and equality are not the same thing
It is a fair point that in Pascal
= and
:=carry distinct meanings, and I can see why
set Count = 10 might read
as an equality test at first glance.
That said, I think the
set prefix already shifts the developer into
"debugger command" rather than "Pascal expression" territory, and
=follows the convention used by most debuggers (GDB, LLDB, PDB).
Switching to
:= would be a half-step towards Pascal syntax without
quite getting there — you would still be missing the trailing
semicolon, and
set itself has no equivalent in the language.
Precedent from other debuggers:
- GDB: set variable Count = 10
- LLDB: expr Count = 10
- PDB: Count = 10
question: how are array items set ?
set only handles
tcPrimitive and
tcEnum types at the moment. Anything
else falls through to the
else branch with "type not supported for assignment".
It is planned though, I just haven't gotten there yet. I've made a not of your other suggestions for
set too.
Expression-condition breakpoints (e.g., break foo.pas:N if I > 100 and J < 5)
aren't parentheses required to separate the boolean sub-expressions, i.e, (I > 100) and (J < 5) ?
Pascal operator precedence already resolves this unambiguously. In Pascal, relational
operators (>, <, =, etc.) bind more tightly than and/or, so I > 100 and J < 5 is parsed
as (I > 100) and (J < 5) without parentheses.
The whole thing seems to be very well thought out. I'm looking forward to playing with the Windows version.
Thank you - a lot of effort has gone into the design process. Hopefully you don't have to wait too much longer. :-)
Recent
