<felix_>
rqou: a few months after the bkl got nuked (or at least partially nuked), a friend did some network related kernel debugging and found out that when you loaded the binary nvidia module, the kernel stops sending network packets for about 1.5 seconds, since the nvidia driver tried to emulate the bkl by acquiring all locks it could acquire...
<rqou>
nah I wasn't even having a problem like that
<rqou>
it was some combination of apt and (not) rebooting
* felix_
wonders if jhol's linux patches for the ice40 fpgas still need some testing, but jhol seems not to be around at the moment
<felix_>
ah, ok
<rqou>
so usual distro glue garbage
<rqou>
I think the problem was that I did a dist-upgrade twice with like a week in between
<rqou>
and didn't reboot after the first one
<felix_>
but nowadays the open source radeon stuff works well enough and i don't need much 3d acceleration under linux, so i can run my linux without binary (or out of tree) kernel drivers
<rqou>
amdgpu-pro wasn't working too great for me
<felix_>
since the open source drivers are sufficient for me, i just use them. less stuff that will eventually break ;P
<rqou>
I was under the impression that amdgpu-pro was supposed to work with the open-source kernel bits
<felix_>
i don't know if that's the current state or if it's a goal that hasn't been achieved by now
digshadow has joined ##openfpga
<balrog>
felix_: the amdgpu pro stuff is supposed to work with the open source kernel bits
<balrog>
but the open source userspace bits are working decently well
pie_ has quit [Ping timeout: 256 seconds]
m_w has joined ##openfpga
m_w has quit [Ping timeout: 260 seconds]
amclain has quit [Quit: Leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
Marex has quit [Ping timeout: 260 seconds]
Marex has joined ##openfpga
_whitelogger has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Read error: Connection reset by peer]
<davidc___>
azonenberg: I was thinking someone should implement a yosys backend that generates the game-of-life gates
<davidc___>
azonenberg: (there's a couple of different logic styles that have been done in it)
<davidc___>
azonenberg: then it just needs a PAR, and then you have the best CTF challenge!
<azonenberg>
lol yeah i was thinking about it
<azonenberg>
lol
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
<rqou>
"If a subtype indication appears as a discrete range, the subtype indication shall not contain a resolution indication."
<rqou>
so the non-LR(k) feature isn't actually allowed
<egg|egg>
rqou: btw, if you need a name (naming things is hard), Apex called the supergrammar bit that looks like Foo(Bar) "Apply" (and then the semantic analysis would figure out if it was a function call returning a pointer to an array which is implicitly dereferenced and accessed at an indexed given by another function call or whatever :D)
<rqou>
mine is currently named "_ambig_name_parens"
<egg|egg>
(Yes I think it can be that; it cannot be 2 levels of pointers, there you need to explicitly dereference)
<egg|egg>
rqou: I don't really like that name, but hey, your parser :D
<rqou>
this sounds like bikeshedding :P
<egg|egg>
good identifier choice matter!
<egg|egg>
s/.$/s!/
<egg|egg>
rqou: yup, here's an example where Foo(Bar) does 2 function calls, one dereference and one array subscript :D https://ideone.com/IxfXz2
<rqou>
aargh now i have ambiguities from only shift/reduce conflicts
<rqou>
damn these disambiguation hacks really easily break things
<rqou>
i heard you like constraints, so I put a constraint in your constraint: "foo(bar (0 to 2, 1 to 3, 2 to 4, 3 to 5)(baz (111 to 222)))"
<egg|egg>
\o/
<rqou>
i really need to start writing unit tests
<rqou>
but yeah, if i understand it correctly that example should be slicing a multidimensional array of arrays
promach has joined ##openfpga
pie_ has joined ##openfpga
<egg|egg>
rqou: yes, and perhaps doing implicit dereferences or parameterless function calls too
<rqou>
aaargh i have another conflict!
<rqou>
this is impossible to reason about
<rqou>
so, what is "foo(bar(baz (0 to 2), qux (1 to 3)))" supposed to parse to? :P
<rqou>
alright, i'm going to have to take a step back and think about this again
<egg|egg>
rqou: uh, so you have two slices there right?
<rqou>
not necessarily
<rqou>
it can be slicing foo, which is a record type
<rqou>
the type of foo is bar
<rqou>
bar has elements named baz and qux
<egg|egg>
slicing foo? how so
<rqou>
which are arrays
<rqou>
bar is a record type containing two arrays baz and qux
<rqou>
foo is of type bar
<egg|egg>
uuuh wtf
<rqou>
slicing with a subtype_indication
<egg|egg>
is it even more ambiguous than Ada or is it a bit of Ada that I didn't know :D
<rqou>
possibly even more ambiguous?
<egg|egg>
:D
<rqou>
bar can also be a multidimensional array type
<rqou>
where the indices are baz and qux
<rqou>
i think?
<egg|egg>
grammatically maybe, but indexing by arrays is not going to pass semantic analysis
<rqou>
but it's indexing with a type
<rqou>
baz and qux can be integers with ranges
<rqou>
we're selecting a smaller subrange
<egg|egg>
wait, you can implicitly declare a subtype in vhdl?
<rqou>
i think so??
<egg|egg>
and that's the syntax for it?
<egg|egg>
WTF-
<rqou>
er, maybe not
<rqou>
there is a range_constraint
<rqou>
but it requires the "range" keyword
<rqou>
ok, i need to take a step back and think about this again
<egg|egg>
afaict range_constraint occurs only in type declarations in Ada?
<rqou>
i've probably confused myself at this point
<egg|egg>
rqou: so in Ada you can only form a qualified_expression with a subtype_mark, which is a fancy name for a name. You don't use a subtype_indication, which is [null_exclusion] subtype_mark [constraint] (where constraint can be a range_constraint)
<egg|egg>
i.e. Positive'(2) is ok, Positive range 2 .. 4'(2) is ungrammatical
<rqou>
this isn't a qualified_expression
<rqou>
this should eventually parse as a slice_name
<rqou>
slice_name ::= prefix ( discrete_range )
<rqou>
discrete_range ::= discrete_subtype_indication | range
<egg|egg>
rqou: I mean some of these interpretations are clearly wrong even without context right
<rqou>
i'm not sure, that's the problem
<egg|egg>
you can't actually have your index_constraint have things with index constraints in there
<egg|egg>
you don't index by arrays
<rqou>
hrm
<rqou>
i guess i'm also used to high-level languages where you can footgun yourself that way
<egg|egg>
I think that VHDL should have something like 4.1.2:4 {expected type (slice discrete_range) [partial]} The expected type for the discrete_range of a slice is the index type of the array type.
<rqou>
the phrase "expected type" doesn't appear in the LRM at all
<rqou>
so it's all hidden somewhere in the prose
<egg|egg>
rqou: not really a question of high vs. low level but rather of how much they like statically typed all the things
<rqou>
um, even C++ can index by an array i believe?
<egg|egg>
rqou: the stuff between { is probably an annotation, I'm looking at the AARM
<egg|egg>
well operator[] is a bona fide operator
<egg|egg>
so you can shove whatever you want in there
<rqou>
hrm, possibly even C can (not saying it produces a useful answer though)
<rqou>
if you put an array in [] can't the array coerce to an int?
<egg|egg>
well C has no arrays to speak of :-p
<rqou>
yeah it does?
<egg|egg>
sort of, but they're pointers
<rqou>
not quite
<egg|egg>
you can do index[array] in C, yes
<rqou>
most of the time yes
<rqou>
right, that stupid trick
<rqou>
so you can index by array :P
<egg|egg>
yes
<egg|egg>
but this is not C
<egg|egg>
sometimes the Ada people got a bit stupid about not being C (it never had a continue because C had), but it's a whole lot saner
<egg|egg>
continue would have been easy to do with keyword reuse too if you wanted: goto end of loop; :D
<egg|egg>
rqou: I mean it does say discrete_range in Slices, right?
<rqou>
yes
<egg|egg>
yeah, so it's a discrete_subtype_indication
<egg|egg>
now the RM grammar drops the discrete
<egg|egg>
but you actually need to indicate a discrete subtype if you want it to make sense
<rqou>
it does eventually, but not in a standardized way
<rqou>
hrm, so 35 vhdl grammar rules use (
<nats`>
any python addict here ?
<rqou>
actual_part
<rqou>
aggregate
<rqou>
array_constraint
<rqou>
attribute_name
<rqou>
block_specification
<rqou>
block_statement
<rqou>
entity_aspect
<rqou>
enumeration_type_definition
<rqou>
formal_part
<rqou>
function_call
<nats`>
oO
<rqou>
function_specification
<rqou>
generic_clause
<rqou>
generic_map_aspect
<rqou>
group_declaration
<rqou>
group_template_declaration
<rqou>
index_constraint
<rqou>
indexed_name
<rqou>
instantiated_unit
<rqou>
interface_function_specification
<rqou>
interface_package_generic_map_aspect
<rqou>
interface_procedure_specification
<egg|egg>
O_o so much grammar
<rqou>
pathname_element
<rqou>
port_clause
<rqou>
port_map_aspect
<rqou>
primary
<rqou>
procedure_call
<rqou>
procedure_specification
<rqou>
process_statement
<rqou>
qualified_expression
<rqou>
record_constraint
<rqou>
resolution_indication
<rqou>
slice_name
<rqou>
subprogram_header
<rqou>
type_conversion
<rqou>
unbounded_array_definition
<egg|egg>
rqou: but the RM doesn't do things like /discrete_/subtype_indication (which means subtype_indication, but you're really semantically looking for a discrete one, so you know that's not going to be an array) ?
<rqou>
vhdl has that
<egg|egg>
ok, so you could use that to split *your* rule for subtype_indication
<rqou>
anyways, a number of these rules have obvious context preceding them, so i'm going to prune those first
<egg|egg>
to exclude the ones that *must* be indiscrete
<rqou>
e.g. block_statement has a parenthesis that must be preceded by the "block" keyword
<egg|egg>
nats`: also since we were talking grammars and you mentioned python, why does python have an elif when its else is followed by a colon? else if wouldn't be ambiguous (and wouldn't require infinite lookahead either)
<nats`>
egg|egg I'm far from being a language designer :D
<nats`>
barely user so I'll not be able to asnwer
<nats`>
anyway I'm trying to parse CSV with python while ignoring multiple delimiter block
<nats`>
it's boring
<rqou>
so only 18 grammar rules don't have "obvious" context for the open paren
<rqou>
actual_part
<rqou>
aggregate
<rqou>
array_constraint
<rqou>
attribute_name
<rqou>
block_specification
<rqou>
enumeration_type_definition
<rqou>
formal_part
<rqou>
function_call
<rqou>
index_constraint
<rqou>
indexed_name
<rqou>
pathname_element
<rqou>
primary
<rqou>
procedure_call
<rqou>
qualified_expression
<rqou>
record_constraint
<rqou>
resolution_indication
<rqou>
slice_name
<rqou>
type_conversion
<rqou>
guess what? most of these are the ones i've been having trouble with!
<rqou>
but yeah, maybe i need to do some paring down of what my grammar rules accept
<rqou>
right now it's basically "any bullshit the ebnf says"
<egg|egg>
rqou: yeah, you can't sanely ignore all the italics
<rqou>
yeah, especially italics for "name"
<rqou>
that's what i spent over a month trying to understand :P
<egg|egg>
the grammar as written is not for parsing, it's for documenting, and then the parser writers go in the parser mines
<rqou>
"name" can be basically any bullshit you want otherwise
<egg|egg>
preeetty much yes
<rqou>
'a'.'b''c."e"'f? sure! :P
<rqou>
er, wait
<rqou>
yeah
<rqou>
i think that's compliant with the ebnf :P
<egg|egg>
not sure about .'b' and ."e"?
<rqou>
suffix ::=
<rqou>
simple_name
<rqou>
| character_literal
<egg|egg>
:D
<rqou>
| operator_symbol
<rqou>
| all
<rqou>
so yes :P
<rqou>
but you can't actually chain these
<egg|egg>
yeah sure that's clearly nonsense
<rqou>
holy shit my parser is actually currently accepting that :P
<rqou>
alright, i'm going to yak shave a bit and write a python tool that looks up which rules reference which other rules
<rqou>
i've already manually converted the ebnf into a .dot file
<egg|egg>
hmmm, I think for my Python question the answer is "it's not LALR(1) if you want to prevent else before else if"
<egg|egg>
you need to look ahead two tokens :-p
<rqou>
yeah nobody cares about that :P
<rqou>
LALR(k) for any finite k is about the same as LALR(1)
<rqou>
if you look really carefully there's lots of arrows pointing into "expression" and "name" :P
<rqou>
also "subtype_indication"
<rqou>
the giant row of "stuff" in the middle-right-hand-side is various types of statements
<rqou>
also, interestingly, despite notes that GLR parsers are harder to debug, i'm currently finding that it helps to find my grammar ambiguities much better than the normal LALR parser
<rqou>
the normal LALR parser will just do "herp derp, a shift/reduce conflict? just pick the first one"
<rqou>
whereas the GLR parser will still try both cases and then abort on ambiguities
<rqou>
thanks Prof. Hilfinger :P
* egg|egg
didn't know about GLR
<rqou>
GLR is basically "run multiple LR parsers in parallel"
<egg|egg>
but then I'm not a computer scientist, so I don't know anything about parsing or compiling anyway :D
<rqou>
this is possible because LR parsers are state machines
<rqou>
so instead of storing "state" you can store "set of states"
<rqou>
the bison GLR parser has this comment in it: /* C GLR parser skeleton written by Paul Hilfinger. */
<rqou>
Paul Hilfinger is a rather infamous professor here at UC Berkeley
<rqou>
who teaches (among other classes) compilers :P
<egg|egg>
rqou: so I was screwing around with a parser generator, it turns out that this syntax for else if statements and expressions is unambiguous an parsed by a LALR(1) parser (I didn't say it was good) https://hastebin.com/ekesuradag.vbs
<rqou>
sure?
<egg|egg>
and it doesn't require an elsif :-p
<rqou>
looks legit enough
* egg|egg
finds the word elsif/elif ugly
<rqou>
herp derp i can code a breadth-first-search :P
<egg|egg>
rqou: ?
<rqou>
>has a CS degree
<rqou>
>still messes up breath-first-search
<rqou>
:P
<egg|egg>
well, those trivial things can be very tricky
<egg|egg>
I would *never* trust a bisection I wrote without unit tests
<rqou>
and now after yak shaving i forgot what i was originally debugging :P
<rqou>
gaaah my grammar has too many _almost_<foo> rules
<rqou>
where one random bit has been chopped out
<rqou>
anyways, i was trying to get discrete_range and discrete_subtype_indication to parse less shit
<rqou>
i think i'm going to start by rereading the entire chapter on types again
<rqou>
(like i spent a month reading the chapter on names/expressions)
<egg|egg>
rqou: I mean you can't actually parse discrete_subtype_indication right
<rqou>
it currently has a conflict
<egg|egg>
but what you can do is parse possibly_discrete_subtype_indication, and definitely_indiscrete_subtype_indication :D
<rqou>
it has a conflict with the rule "_ambig_name_parens"
<egg|egg>
:D
<rqou>
which is "_one_or_more_expressions"
<rqou>
which is what you probably expect it to be
<rqou>
wait a sec
<rqou>
a discrete_range can only be a **discrete_**subtype_indication
<rqou>
if i'm reading it right that means the constraint can _only_ be a range_constraint
<rqou>
it can't even be an array or record constraint?
<egg|egg>
well, in Ada {type of a discrete_range} The type of a discrete_range is the type of the subtype defined by the subtype_indication, or the type of the range. {expected type (index_constraint discrete_range) [partial]} For an index_constraint, each discrete_range shall resolve to be of the type of the corresponding index.
<egg|egg>
so yes, it's just that? you can't have a range of arrays can you?
<rqou>
hrm, so the part on "slice names" says "The prefix of a slice shall be appropriate for a one-dimensional array object."
<rqou>
so let me see what the part on arrays says
<egg|egg>
In Ada it says "The prefix of a slice shall resolve to denote a one-dimensional array (after any implicit dereference).
<egg|egg>
"
<egg|egg>
which is a bit more precise than "appropriate"
<egg|egg>
it shan't be inappropriate for a 1d array, "Fucking_Array" is not appropriate for a 1d array :-p
<rqou>
hrm "discrete range: A range whose bounds are of a discrete type. (5.3.2.1, 5.3.2.2)"
<rqou>
"discrete type: An enumeration type or an integer type. Each value of a discrete type has a position number that is an integer value. Indexing and iteration rules use values of discrete types. (5.2.1)"
<rqou>
so stupid fuckery isn't allowed
<rqou>
whelp, refactoring time
<egg|egg>
rqou: so afaict it's going to be either Some_Array(1 .. 17), Some_Array(Positive), or Some_Array(Positive range 1 .. 17) ? Not even sure about the second one
<rqou>
i believe that's allowed
<rqou>
but that's not ambiguous, so whatever
<egg|egg>
essentially the only thing you can do is qualify what type of range you have
<egg|egg>
that matters because enums
<rqou>
yeah you can't do stupid shit and put an array in it :P
<rqou>
wow the ebnf is useless
<egg|egg>
it's documentation, not something you feed to a parser
<rqou>
iirc some students tried it years ago and got hundreds of shift/reduce and reduce/reduce conflicts
<egg|egg>
well yeah :D
<egg|egg>
the grammar as written requires most of the semantic analysis :-p
<rqou>
the grammar isn't even normative :P
<rqou>
it's listed as informative only
<egg|egg>
huh?
<egg|egg>
it looks normative in Ada
<rqou>
the VHDL Annex C with the EBNF is explicitly informative
<rqou>
although there are snippets spread throughout that are normative
<egg|egg>
that's ridiculous :-p
<egg|egg>
rqou: yes, I think Some_Array(Positive) makes sense, because what you can do is subtype Small_Number is Positive range 1 .. 8; and then you can say Some_Array(Small_Number) for an array indexed by a larger Positive range
<rqou>
although now i have "vhdl_parser.y: warning: 39 rules useless in grammar [-Wother]" :P
* egg|egg
considers the possibility of food
<rqou>
well, it's 4:30 in the morning for me :P
* rqou
is not good at circadian rhythms :P :P
<egg|egg>
it's 13:37 here
<egg|egg>
is anyone on IRC good at it though
<rqou>
hrm, as i go and add external names i'm going to have to add back support for the full subtype_indication
<rqou>
with all the constraints and everything
<rqou>
but hopefully with fewer conflicts this time
<rqou>
also, i love rules "logical_name ::= identifier" and "simple_name ::= identifier"
<egg|egg>
:D
<egg|egg>
again, this grammar is there to document
<egg|egg>
if they wanted to shove a parser in the standard they'd have done that (and it would be a shitty standard because nobody would be able to read it to write actual code)
<rqou>
hrm, I think I still need a GLR parser for the way I defined the "dunno, parentheses" rule
<rqou>
a function call that doesn't have a => will become a "dunno, parentheses"
<rqou>
but a function call that has at least one => is definitely a function call
<rqou>
this requires potentially infinite lookahead to determine
<egg|egg>
rqou: can't it be a => from an aggregate?
<rqou>
I don't think so, because a function call needs the function name
<egg|egg>
hmm
<rqou>
an aggregate definitely isn't preceded by a name
<rqou>
I think?
<rqou>
I think passing an aggregate to a function requires an extra set of parentheses?
<egg|egg>
right, it can be qualified so Cat'(Tail => Black, Legs => White) but there's a ' so that's fine
<egg|egg>
and yes, if you make it unqualified you need (())
<whitequark>
expressions = any sort of computation
<whitequark>
(there's let, which is a bit weird, but i shuffle it under the "expression" for now)
<whitequark>
so in rust you can do f(if a { b } else { c })
<whitequark>
and in ruby also
<pie_>
you guys think this will run on my spartan 3an starter kit or basys 2? https://www.sump.org/projects/analyzer/ 'cause in that case i guess there isnt much of a point to getting one of those 5$ chinese logic analyzers
<whitequark>
egg|egg: CL isn't a functional language, Scheme is
<whitequark>
pie_: 256Ksamples
<whitequark>
cheap chinese LAs can transmit indefinitely if you have the USB bandwidth
<whitequark>
thats one major difference
<egg|egg>
whitequark: right, I see from the grammar the control structures are expressions
<pie_>
hm. i guess.
<whitequark>
another is how expensive it's to kill one
<pie_>
yeah good point i was thinking about that
<whitequark>
also it's just plain inconvenient
<whitequark>
*but* the sump thing could be super convenient if you want to analyze the *on-fpga* circuits
<whitequark>
egg|egg: ruby is... "functional"
<balrog>
the cheap chinese LAs are usually original Saleae Logic clones
<egg|egg>
these quotes scare me
<egg|egg>
or is it the ellipsis
<balrog>
(FX2 with some driver circuitry)
<whitequark>
theres no precise definition of a functional language
<balrog>
the newer Saleae hardware is a lot more complex
<whitequark>
what i usually use is ADTs plus recursive processing of data structures plus first-class functions
<whitequark>
by that logic, it's not really functional
<whitequark>
however if your definition is "has map and reduce" and "is reasonably convenient to use with immutable data structures" then ruby is functional
<egg|egg>
whitequark: so essentially rust takes the C thing of having many statements be expression ; and applies it to most types of fancy statements too?
<whitequark>
it's somewhere in the same general direction as common lisp
<whitequark>
yeah, definitely *more* functional than python
<pie_>
yeah fx2lp
<whitequark>
balrog: I have a better saleae clone
<whitequark>
they actually redesigned it from scratch on a better fpga
<balrog>
whitequark: yeah, those are saleae 16 clones
<whitequark>
yep
<balrog>
which have the fpga
<whitequark>
"mcupro"
<balrog>
that product is also discontinued
<balrog>
all of the current line has some analog sampling capability
<whitequark>
egg|egg: (rust) yes
<whitequark>
so all control flow can return something*
<whitequark>
* except loops but loops are currently being extended to do so
<whitequark>
f(match ...) etc
eduardo has joined ##openfpga
eduardo has quit [Ping timeout: 256 seconds]
promach has quit [Quit: Leaving]
<cr1901_modern>
what is the syntax "f(match ...)"?
<whitequark>
just demonstrating that you can use match as an expression
<cr1901_modern>
Oh, okay. Yea, match as an expression is pretty cool
eduardo has joined ##openfpga
eduardo has quit [Ping timeout: 268 seconds]
amclain has joined ##openfpga
digshadow1 has quit [Ping timeout: 240 seconds]
eduardo has joined ##openfpga
digshadow has joined ##openfpga
eduardo has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
eduardo has joined ##openfpga
eduardo has quit [Ping timeout: 260 seconds]
<rqou>
whitequark: Python managed to hit the "LL(1) but not LALR(1)" case?
<rqou>
"A LL(1) grammar with symbols that have both empty and non-empty derivations is also a LALR(1) grammar. A LL(1) grammar with symbols that have only the empty derivation may or may not be LALR(1)."
<rqou>
do you have an example of the not-LALR(1) case?
<whitequark>
don't know, don't care
<whitequark>
I think it's LL(1) to allow handwritten RDPs
<whitequark>
pathfinder is a GPU-based font rasterizer that's actually meaningful and works and is fast
<whitequark>
and it's rather far from trivial
<whitequark>
also needs GL4.3+, which means that probably most low- and middle-end hardware today is SOL
<whitequark>
also all macOS-based systems
<whitequark>
(pathfinder does paper over that to work on most 2011+ systems, but when it does, you lose indirect rendering, so it's not pertinent to our discussion back then)
<qu1j0t3>
nice link. /me has followed Raph's work since Kuro5hin days
eduardo has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
<cr1901_modern>
indirect rendering?
<whitequark>
opengl is a network-transparent protocol
Hootch has quit [Quit: Leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<cr1901_modern>
whitequark: I don't know what "indirect rendering" means, tbh
<whitequark>
google it?
<cr1901_modern>
Fair enough, I didn't actually expect a decent answer if I googled (there was a decent answer). But no excuse for me not doing it first (I suppose :P).
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou>
hrm, rereading the spec i think "selected_name" is actually allowed in a number of places where i currently have "identifier"
<rqou>
woot S/R conflicts all over again!
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou>
i think i'll keep GLR mode enabled for now and see if i can fix conflicts later