<rqou>
I have just created a "PT_SUBTYPE_INDICATION_AMBIG_WTF" parse tree node type
<rqou>
forgive me father for i have sinned :P
<qu1j0t3>
rqou: sounds good
<qu1j0t3>
rqou: Names should be descriptive A11!!!!! would maintain this code again
<rqou>
it is indeed descriptive :P
<rqou>
parsing this part of VHDL is hard
azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg_work has joined ##openfpga
<rqou>
man subtype_indication is the worst part of VHDL
<cyrozap>
Chinese company name of the day: ZERO Research Institute
<rqou>
hrm, it seems all possible subtype_indications with record_constraints that don't have "weird" (i know what i mean :P ) array_constraints will parse as a name with something in parens
oeuf has quit [Read error: Connection reset by peer]
pie_ has quit [Ping timeout: 240 seconds]
oeuf has joined ##openfpga
cosmobird has joined ##openfpga
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/vyMgW
<openfpga-github>
yosys/master 088f9c9 Clifford Wolf: Fix verilog pre-processor for multi-level relative includes
<rqou>
interesting, fixed (in an ugly) way my reduce/reduce conflict
<rqou>
was actually a "mysterious conflict" after all
<rqou>
interestingly not one that IELR resolves
<rqou>
hrm, it's not the classic LALR(1) conflict
<rqou>
whatever going to fix real problems first :P
<rqou>
hrm, my grammar now contains "| slice_name _after_slice_limited_array_constraint" as a rule
<rqou>
i'm not sure how terrible i should feel about this
digshadow has joined ##openfpga
<rqou>
this is the grammar rule that wraps a slice_name into a PT_SUBTYPE_INDICATION_AMBIG_WTF
<rqou>
"iii(jjj(foo1(open),foo2(open)(open),foo3(0 to 2),foo4(0 to 2, 1 to 3),foo5(0 to 2)(1 to 3),foo6(bar),foo7(bar, baz),foo8(bar range baz'qux),foo9(bar range baz'qux, zzz range www'xxx),foo10(bar range baz'qux)(open)))" is a legitimate subtype_indication, i swear :P
<rqou>
hrm
<rqou>
$ grep -i hack vhdl_parser.y | wc -l
<rqou>
15
<rqou>
is this good or bad? :P
<rqou>
i also have a nice 22 shift/reduce confllicts, which is interesting
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou>
hrm, I do need beyond LR(1) lookahead
<rqou>
whelp, sticking to GLR it is (for now at least)
amclain has quit [Quit: Leaving]
Hootch has joined ##openfpga
Hootch_Work has joined ##openfpga
Hootch has quit [Ping timeout: 260 seconds]
cosmobird has quit [Remote host closed the connection]
<rqou>
it turns out accidentally adding an empty rule in just the wrong place gives me 128 shift/reduce conflicts (up from 23)
cr1901_modern has quit [Read error: Connection reset by peer]
Bike has quit [Quit: sleep]
<rqou>
useless declaration of the day: "type t is protected end protected;"
<whitequark>
rqou: are you using menhir yet
<rqou>
um, no
<rqou>
why?
<rqou>
>OCaml
<rqou>
i need a C/C++ output :P
<whitequark>
because menhir is like the only parser generator that actually helps you instead of giving you nasty garbage about conflicts
<rqou>
helps you how?
<whitequark>
it provides you an example of the input that causes the ambiguity
<rqou>
ah ok
<whitequark>
and it also has "inline rules" that help you resolve r/r conflicts without blowing up the grammar
<rqou>
i might give that a try later
<whitequark>
as well as higher-order rules etc
<rqou>
i actually have no r/r conflicts right now
<whitequark>
rust also has lalrpop, which is actually modelled over menhir to a degree
<whitequark>
but it's very immature
<rqou>
actually i don't know if menhir will work
<rqou>
i definitely have some rules that require more than 1 lookahead token
<rqou>
i'm currently cheating by using GLR mode
<rqou>
unless it has automatic lookahead reducing (which is theoretically possible)?
<whitequark>
it doesn't, but you could tell it what to expand
<rqou>
expand?
<rqou>
i was referring to the automatic conversion of LR(k > 1) grammars into LR(1) grammars, which is theoretically possible because they have the same recognition power
<rqou>
wow the third-party vhdl highlighter for sublime text is garbage
<rqou>
maybe i should rewrite that too? :P
<whitequark>
yes
<rqou>
arrgh there is ambiguity again
X-Scale has quit [Read error: Connection reset by peer]
<oeuf>
rqou: how goeth the vhdl
<oeuf>
why is my nick french
<rqou>
chugging along slowly
oeuf is now known as egg|coffee|egg
<egg|coffee|egg>
rqou: it's theoretically possible, but is it practical/useful?
<rqou>
er, what?
<rqou>
converting LR(k) to LR(1)?
<rqou>
i don't know how actually useful that is
<rqou>
signs you're neck deep in VHDL: "postponed a <= guarded transport b;"
<rqou>
(i don't even know what this does, but the grammar definitely allows it)
<rqou>
I heard you like keywords: "postponed with asdf select a guarded transport <= b when c, d when e;"
<egg|coffee|egg>
rqou: you know, people complain (or used to complain, now they don't have anything to complain about) Ada being verbose, but this is something else O_o
<rqou>
postponed, guarded, and transport do <stuff i don't understand affecting how signals propagate information> :P
<egg|coffee|egg>
rqou: in Ada 2005 iirc the longest keyword sequence was in "type T1 is not null access protected function return T2;"
<egg|coffee|egg>
like, you could argue not null access is too verbose, that's mostly because they did the classical mistake of nullable by default, but the rest is pretty clear (protected is a tasking thing)
egg|coffee|egg is now known as egg|egg
<egg|egg>
rqou: well unique sequence that is; you could repeat "not null access protected function return" as many times as you want, with functions returning anonymous accesses to functions returning.... but then that's a rather mad thing to do
<rqou>
wait, ada has first-class functions?
<egg|egg>
so, Ada 83 didn't have pointers to subprograms, because of a confused Ichbiah, and that contributed to not making it very popular
<egg|egg>
but Ada 95 remedied to that, and 2005 allowed to use them in even more contexts (that took time, because they're memory-safe unless they use Unchecked_Whatever)
<egg|egg>
rqou: also there's operator overloading done properly :-p
<egg|egg>
(sadly no pass-by-name, so you can't overload "and then" and "or else")
<egg|egg>
(those are admittedly clumsy keywords, but such cute keyword reuse
<egg|egg>
)
<rqou>
wow ada is surprisingly modern
<egg|egg>
it was, yes
<egg|egg>
also a tasking system that works well with modern architectures (and didn't back when everything was single-processor)
<egg|egg>
I think go has the same sort of tasking system?
<egg|egg>
rqou: so, it's memory-safe, but it's before ownership semantics were really figured out; so the way it works is that every time you declare an access type it has its pool, and it allocates in that pool; when the access type goes out of scope it's all deallocated. That sounds awful (and to a large extent you do have to do Unchecked_Deallocation), but it's not *that* bad because you tend shove generics everywhere, which
<egg|egg>
will spawn their pools on instantiation
<egg|egg>
rqou: now in 2005 there technically is ownership, with coextensions; those are variant records parameterised on an anonymous access, and in that case the lifetime of the access is the lifetime of the object; it's a bit of an incidental feature, but it's there :-p
scrts has joined ##openfpga
fpgacraft2_ has joined ##openfpga
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2_ is now known as fpgacraft2
<egg|egg>
rqou: well I guess controlled types (which give you the ability to do thing on initialization, finalization, and right after assignment) allow for ownership to a large extent, but they were introduced with OO in 95, and because it was the 90s, they work via OO, which makes them cumbersome
<rqou>
hrm, the VHDL spec doesn't say for certain that begin/end must match in a generate_statement_body
<rqou>
i mean, it's parseable either way, but...
<egg|egg>
rqou: what do you mean? (what's a generate statement, too :-p)
<rqou>
generate_statement_body ::= [ block_declarative_part begin ] { concurrent_statement } [ end [ alternative_label ] ; ]
<rqou>
ada probably doesn't have this
<rqou>
anyways, note that both the part that contains begin and the part that contains end are in square brackets []
<egg|egg>
rqou: .... WTF?! VHDL has non-parenthesis brackets?
<rqou>
er, the square brackets are part of the EBNF
<rqou>
they mean "this part is optional"
<egg|egg>
ah
<egg|egg>
ok
<rqou>
(it does have square brackets, exclusively for function signatures)
<egg|egg>
... WTF
<egg|egg>
like... what's the point of having the keywordy Ada syntax if you're going to throw in bracket salad >_>
<rqou>
anyways, the grammar rule says the "begin" part and "end" part are optional independently
<egg|egg>
rqou: huh.
<rqou>
and the text doesn't seem to say that that isn't the case
<rqou>
although i'm going to assume for now that's what they meant?
<rqou>
my favorite part of VHDL is the << >> brackets
<egg|egg>
O_o
<rqou>
totally serious btw
<egg|egg>
what
<rqou>
in vhdl 2008 somebody felt the need to graft in a way to pierce hierarchies
<egg|egg>
like, Ada is keywordy and all, but a nice thing is that they have () and that's it
<rqou>
i'm assuming they also couldn't get their parser to work or something, so they added a totally unique set of brackets :P
<egg|egg>
you don't get nonsense of [](){} << this is an empty lambda in C++ btw
<rqou>
vhdl hasn't used {} yet
<rqou>
so that's how they can graft in the next feature :P
<egg|egg>
~barf~
<egg|egg>
rqou: like, Ada has <>, but those aren't brackets, box is its own token
<rqou>
oh VHDL has box too :P
<egg|egg>
... can you put box inside << >>
<rqou>
no
<rqou>
<< >> has very specific syntax inside it
<egg|egg>
rqou: wait, actually <<Stuff>> is a label in Ada, for goto. so there's that.
<egg|egg>
<<Hell>> goto Hell;
<rqou>
you use it like this in vhdl: "<< signal .tb.uut.o_n : std_logic >>"
<egg|egg>
so that's a declaration?
<rqou>
no, it's an object
<rqou>
it's "i poked into this other block and pulled the signal out"
<egg|egg>
...
<rqou>
(imagine hardware) without having to add an extra wire throughout the hierarchy for the wire
<egg|egg>
couldn't they have figured out some meaningful set of keywords rather than a bracket salad
<rqou>
that's why i jokingly said that it seems <major vendor> couldn't fix their parser either :P
<egg|egg>
rqou: oooh it's awful Special characters may be used to move up the hierarchy ^ and to root the path in a package @ . Some examples:
<rqou>
yeah exactly why i said that some vendor probably couldn't make their parser work :P
<egg|egg>
I mean I don't know how hard it is to parse, it's just awful in terms of design, wrt the preexisting stuff
<rqou>
although the feature itself is hugely useful
<egg|egg>
rqou: why are they using inout as its own reserved word instead of Ada's in out O_o
<egg|egg>
they spawn reserved words by the dozen, and then they still manage to end up with a <@^> salad
<rqou>
dude why do you have to keep asking me? i didn't design this :P
<egg|egg>
you're parsing it though, maybe there's an obvious ambiguity that would arise from in out :-p
<rqou>
afaik no there isn't
<rqou>
egg|egg: you do realize VHDL is "design by vendor" right? :P
<egg|egg>
rqou: what does that entail?
<rqou>
it's like "design by committee" but worse :P
<egg|egg>
rqou: well, Ada is designed by a committee I guess? (or rather by a working group of a joint technical committee, or rather by a rapporteur group of that WG)
<egg|egg>
(a working group *of a subcommittee* of a joint technical commitee)
<pointfree>
Ideally I would want to do some logic minimization based on the status of the UDB array's logic lines...at run-time.
<pointfree>
How to do this without requiring sequential logic, that is the question.
<pointfree>
Thinking about an algorithm to *schedule UDB time* The UDB array as parallelism... and scheduling UDB time as swapping out logic that won't be used. The topic of 'scheduling' space is called (de)fragmentation.
<pointfree>
All we wanted was more UDB's.
<pointfree>
(this is just a daydream right now)
<balrog>
pointfree: I expect PSoC 7 with more UDBs
<balrog>
that way you have 4/6 and 3/5/7
<balrog>
the former ones more focused on hardware efficiency, the latter on programmability
<pointfree>
It would follow a naming pattern
<pointfree>
The whitequark irc logger jumbles the order of my messages when I send several lines at once (in rapid succession). Maybe I would need a delay after each line or the irc logger is polling too slow.
<balrog>
why would the logger be polling?
<balrog>
pointfree: can you pastebin your messages?
<pointfree>
sometimes I do that here but I don't always want to make people click a link to see my irc messages.
<pointfree>
Maybe the logger needs a higher precision timestamp.
<balrog>
pointfree: can you just pastebin what you're seeing?
<balrog>
I want to see if it's a server or logger problem
<whitequark>
you can hover the times in the logger and see the actual primary key values, which are sequential, meaning the rows were inserted in exactly that order
<pointfree>
I
<pointfree>
working!
<pointfree>
it's
<pointfree>
think
<whitequark>
no it isn't
<whitequark>
compare the first two lines from our clients with the first two lines in the highlighted region
<whitequark>
2nd line in irssi: 17:58 < pointfree> All we wanted was more UDB's.
<whitequark>
2nd line in logger: 17:58 <pointfree> Ideally I would want to do some logic minimization based on the status of the UDB array's logic lines...at run-time.
<whitequark>
so... does this mean that IRC will actually throw out of order messages at me?
<whitequark>
actually, wait, I know what happens here.
<pie_>
whitequark, i thought irc does let out of order happen
<pie_>
i dont think it timestamps messages?
<pie_>
ive had people see messages swapped due to lag
<azonenberg>
I believe ordering is enforced from one user but not between users?
<azonenberg>
but not sure
<pie_>
i dont think irc does any kind of integrity enforcement
<whitequark>
I've figured it out
<whitequark>
it's not related to irc
<pie_>
idk if wrapping it in ssl does anything
<whitequark>
it's related to the way my logger works
<whitequark>
and yes, increasing timestamp resolution would help
<whitequark>
uuuuunfortunately that would take about six hours of babysitting the database through migration and I'm thoroughly unmotivated to do that
<pie_>
azonenberg, if theres no enforement i can see it being hard but not impossible to swap mesage order fro a single user
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vySvJ
<openfpga-github>
openfpga/master e7139ad Andrew Zonenberg: Initial version of pmod-gpdevboard