<whitequark>
azonenberg: btw I merged the "image request" in solvespace
<whitequark>
now you can do what you wanted to do
promach has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
Bike has joined ##openfpga
promach has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<azonenberg>
whitequark: :)
digshadow has joined ##openfpga
promach has joined ##openfpga
qu1j0t3 has quit [*.net *.split]
indy has quit [*.net *.split]
nurelin has quit [*.net *.split]
indy_ has joined ##openfpga
nurelin has joined ##openfpga
qu1j0t3 has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
lain__ has joined ##openfpga
lain has quit [Disconnected by services]
lain__ is now known as lain
felix__ has joined ##openfpga
felix_ has quit [Read error: Connection reset by peer]
felix__ is now known as felix_
_whitelogger has joined ##openfpga
pie_ has quit [Ping timeout: 246 seconds]
Hootch has joined ##openfpga
Bike has quit [Quit: u]
<nats`>
azonenberg clocking board is assembled
<nats`>
working on the software :)
<nats`>
will soon be able to test all of that on my tektro
<nats`>
(in parallel my design for the sampler is being rechecked by a RF guru :))
<rqou>
hrm, i just changed my parser to a canonical LR parser for testing and ended up with 213 shift/reduce conflicts and 138 reduce/reduce conflicts :P
<rqou>
fortunately(?) i'm currently testing with a GLR parser, which essentially operates "above" the canonical LR/LALR/IELR distinction
<rqou>
WOOT I THINK I CAN PARSE ALL VHDL NAMES/EXPRESSIONS!
<rqou>
now refactoring time
<egg|zzz|egg>
rqou: congratulations :-\
<egg|zzz|egg>
uh s/\\/p/
* egg|zzz|egg
not good at smileys today apparently
<rqou>
i do have reduce/reduce conflicts, which is scary
<rqou>
GLR is hiding them for now I think?
<egg|zzz|egg>
ah, so you can't quite parse them yet? :-p
<rqou>
but GLR can also expose extra ambiguities
<rqou>
no, i can definitely parse them
<rqou>
but certain inputs can possibly crash the parser until i go and sort this out as part of the refactoring
<rqou>
GLR is magic
<rqou>
it basically says "run multiple copies of a LR parser in parallel until all but one hit a syntax error"
<rqou>
the problem happens when more than one copy *doesn't* hit a syntax error
<rqou>
then they could have potentially generated different parse trees
<egg|zzz|egg>
but can't that approach get really costly by spawning absurd amounts of parsers?
<rqou>
i believe there is a proof that ideally it should be no more than O(n^3) in the size of the input
<rqou>
but yes, the bison generated output can take exponential time
<egg|zzz|egg>
bison, menhir... parser things have weird names :-p
<rqou>
afaik because LR parsers are finite state machines GLR can use the NFA trick
<rqou>
basically instead of storing a normal "current state" you can just store a set of "all current states"
<rqou>
hrm, IELR mode fixes a good number of my conflicts, so at least some of them come from hitting LALR limitations
<egg|zzz|egg>
IELR?
<rqou>
IELR is a subvariant of LR parsers
<rqou>
i dont' have too good an understanding what is happening here, but
<rqou>
basically a "canonical" LR parser can take a very huge number of states
<rqou>
a LR parser basically has a stack of "stuff that has been parsed incompletely"
<rqou>
and a set of future input tokens
<rqou>
and a finite state machine
<rqou>
and basically at each step some function of "contents of stack" + "future tokens" + "current FSM state" can be used to make a decision:
<rqou>
"shift" the next token onto the stack
<rqou>
or "reduce" some tokens already on the stack with a new token
<rqou>
and in addition a FSM state transition can happen
promach has quit [Ping timeout: 256 seconds]
<rqou>
LALR gets limited in (afaik) "how much stuff on the stack" is used to make these decisions
<rqou>
so the parser can get in a state where it "forgot" some information about how it got to the current point and thus hits an ambiguity that didn't originally exist
<rqou>
IELR is a way to detect when this happened and produce duplicate states so that this problem does not occur any more
<rqou>
IELR is better than canonical LR because it only does so where it is necessary
<rqou>
so tables don't become as large
<rqou>
hopefully that made some sense?
<rqou>
woot, fixed my reduce/reduce conflicts (herp derp)
<rqou>
now i just have 12 shift/reduce conflicts :P
<rqou>
so i'm pretty sure my shift/reduce conflicts are harmless, but i don't have a clear idea how to explain why
<rqou>
woot implemented all the easy (e.g. not useful) sequential statements :P
_whitelogger has joined ##openfpga
promach has joined ##openfpga
pie_ has joined ##openfpga
egg|zzz|egg has quit [Read error: Connection reset by peer]
promach has quit [Quit: Leaving]
Bike has joined ##openfpga
pie_ has quit [Quit: Leaving]
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
Hootch has quit [Quit: Leaving]
jeandet has joined ##openfpga
jeandet has quit [Quit: Leaving]
<whitequark>
azonenberg: I'm about to add support for per-monitor DPI in solvespace and ugh.
<whitequark>
(I'm actually not 100% certain this will even work on Gtk/Linux)
<azonenberg>
oh?
<azonenberg>
and well the big issue for me with such things is window managers
<azonenberg>
imagine a 40" 4k next to a 24" 1080p
<azonenberg>
you can't have an L-shaped window
<azonenberg>
so UI elements try to flow off the display etc
<whitequark>
Windows scales windows
<whitequark>
in software
<whitequark>
so it renders at (whichever part has the most area) and then downscales or upscales
<whitequark>
the application then only knows about the monitor where it has the most area, correspondingly
<azonenberg>
Can you turn that off?
<azonenberg>
And explicitly query each display for DPI, portions of the logical screen they cover, etc
<whitequark>
good luck convincing anyone to write software for that
<whitequark>
I certainly wouldn't
<whitequark>
but also, it's not like there's a fundamental problem; you can query for the positions of monitors on the surface, and position of your window there
<azonenberg>
what i meant is, can you turn it off per window