<rqou>
why is this legal vhdl and when would i use this? "main_name[foo, bar, baz, qux return asdf]'attrib(arg1 + arg2)"
<egg|zzz|egg>
O_o
<egg|zzz|egg>
rqou: I most certainly have no idea, I can tell you that [] isn't a thing in Ada and that's all :-p
<egg|zzz|egg>
also I should sleep
<rqou>
in VHDL [] is for function signatures
<egg|zzz|egg>
I am sleeping and using TCMP >_>
<rqou>
so apparently what you can do is to take a name of an overloaded function, disambiguate it with a signature, select an attribute of it, and then give an argument to that attribute
<rqou>
dude VHDL has so many weird features that i've _never_ seen used
<rqou>
first you have "A resolution function is a function that defines how the values of multiple sources of a given signal are to be resolved into a single value for that signal."
<egg|zzz|egg>
and it's not enough like Ada that I can say anything useful apparently :-p
<rqou>
and then you can attach resolution functions to subtypes
<rqou>
and then you can attach them to array and record subtypes as well
<rqou>
and you can attach different resolution functions to each element of a record
<egg|zzz|egg>
what does attach mean
<rqou>
basically just that when you use the subtype the resolution function will be used to resolve conflicts
<rqou>
basically "stores some metadata in the compiler somewhere" :P
<rqou>
unfortunately the way it's defined seems to make it very hard to feed the grammar into LALR(1) parser generators
<pie_>
uh
<pie_>
um
<rqou>
VHDL is not as a whole LALR(1) to start with
* pie_
runs away
<openfpga-github>
[yosys] azonenberg pushed 2 new commits to master: https://git.io/vyEXv
<openfpga-github>
yosys/master c855353 Clifford Wolf: Improve smt2 encodings of assert/assume/cover, better wire_smt2 help msg
<openfpga-github>
yosys/master a6ca282 Clifford Wolf: Add write_aiger $anyseq support
<rqou>
but i believe it should be possible to parse a superset of VHDL as LALR(1)
<rqou>
and then "fix it up" in a real programming language
<egg|zzz|egg>
rqou: actually I don't know how to disambiguate the return type in Ada
<egg|zzz|egg>
though it's hard to make an eggsample where it is ambiguous
<rqou>
i have never seen a single case where i had to use any one of these features :P
<rqou>
but i'm trying to make an actually complete parser
<rqou>
not an ad-hoc mess that works most of the time
<egg|zzz|egg>
(just shove a type_mark on the ambiguous thing)
<rqou>
the way VHDL works leads to all sorts of fun though
<rqou>
e.g. "foo(bar)"
<rqou>
what is that?
<rqou>
well, it could be a function call
<rqou>
it could be two function calls
<rqou>
it could be an indexed name
<rqou>
it could be a slice name
<egg|zzz|egg>
that can be anything
<egg|zzz|egg>
same in ada
<egg|zzz|egg>
the only bracket is parentheses
<egg|zzz|egg>
that can be array access, it can be array access with implicit dereference, it can be function call (with implicit dereference), it can be anything \o/
<egg|zzz|egg>
foo can be an array and bar a parameterless function
<egg|zzz|egg>
hell, maybe that's part of something that's not an expression, and then you might be instantiating a generic
<egg|zzz|egg>
rqou: there's at least one thing with parentheses that it's not though: it's not a qualified expression
<egg|zzz|egg>
missing the '
<rqou>
sure
<egg|zzz|egg>
but yeah, it's fun to parse :D
<rqou>
if by fun you mean "nearly impossible"
<egg|zzz|egg>
you pretty much have to do a semantic analysis before you have any clue what's going on
<rqou>
i spent about a month just trying to mentally understand what was possible
<egg|zzz|egg>
if I have a statement that's Foo(Bar); I can fill pages of things it can do
<rqou>
vs what the grammar says is possible but actually isn't
<rqou>
e.g. the grammar says you can do a'b'c'd'e'f'g'h'i
<rqou>
which you can't even lex properly
<egg|zzz|egg>
contrary to e.g. C++, it doesn't try to resolve too many things at the parsing stage, so you don't run afoul of things like the most vexing parse
<rqou>
but semantically you can never do that because you can't attach custom attributes to an attribute
<egg|zzz|egg>
but it does mean that writing a parser is hell
<rqou>
you can only attach attributes to a "thing"
<rqou>
not an attribute
<egg|zzz|egg>
... does VHDL have a thing called a thing? O_o
<rqou>
no, i just made that up
<egg|zzz|egg>
aw
<rqou>
to represent an object/signal/variable/whatever
<egg|zzz|egg>
now I want a HDL whose RM has that concept
<rqou>
although you actually _can_ chain attributes
<rqou>
but only the built-in ones
<rqou>
which aren't single letters
<rqou>
i actually have a ghdl crasher that i created while testing this
<rqou>
i still need to see if it was fixed and possibly file a bug
<egg|zzz|egg>
right, but that's a fairly special thing, you don't want to depend on token length at the parsing stage
<egg|zzz|egg>
so a'b'c'd'e'f'g'h'i should merrily parse and then fuck up at semantic analysis
<rqou>
in this case i don't care because i don't want to have to try and get the lexer to understand when i have a chain of attributes and when i have a character literal
<egg|zzz|egg>
but more interesting is what you do to Foo(Bar); you can't parse it fully (with the grammar from the RM) until you semantically analyze it
<rqou>
yeah i know that
<rqou>
i'm not even at this stage yet
<egg|zzz|egg>
so you need to build a grammar that you can actually parse :D
<rqou>
i'm trying to make a parser that actually starts with a parser generator rather than a hand-rolled recursive descent thing
<rqou>
so i'm currently accepting (hopefully) a superset of the actual grammar
<egg|zzz|egg>
and then, with the semantic analysis, turn that into the actual thing you want :D
<egg|zzz|egg>
rqou: yes, that's what you should do, because you can't do anything else
<rqou>
and then there will be a second stage of semantic analysis written in a real programming language rather than a parser generator
<egg|zzz|egg>
yup
<rqou>
you can do a ghdl-style "hand-rolled recursive descent parser written in ada that does parsing and semantic analysis at the same time"
<egg|zzz|egg>
it's delightfully ambiguous to parse, but tbh that makes it very pleasant to write >_>
<egg|zzz|egg>
rqou: no but that's nuts
<egg|zzz|egg>
also because you want to split that for e.g. editing
<egg|zzz|egg>
if you can just-parse, you can have your formatter run with that
<rqou>
oh sublime text's syntax highlighter sucks too :P
<rqou>
(for VHDL)
<egg|zzz|egg>
and complete missing bits of the super-grammar
<egg|zzz|egg>
phl's pretty printer did that
<egg|zzz|egg>
it was the best pretty printer :D
<rqou>
i'm not even close to being at that point
<egg|zzz|egg>
and then you could run the semantic analysis, but that was separate
<rqou>
you do realize that at this point i barely have a "compilers 101" parser
<egg|zzz|egg>
rqou: that was really fun, because you could type things like type is record and it would format the whole thing and fill in the blanks
<rqou>
at this point i can only parse identifiers and binary operators
<egg|zzz|egg>
type [Identifier] is record [Stuff I don't remember] end record;
<egg|zzz|egg>
:D
<rqou>
so basically "compilers 101"
<rqou>
granted i also had that part months ago
<egg|zzz|egg>
wow compilers 101 is a shit class :-p
<rqou>
followed by a long time of "understanding wtf you can actually do"
<egg|zzz|egg>
rqou: but yeah, I agree with the approach
<rqou>
nah, identifiers and binary operators was like project 1 for me in compilers :P
<egg|zzz|egg>
also good bloody luck with all that :-p
<openfpga-github>
[logtools] azonenberg pushed 2 new commits to master: https://git.io/vyE17
<cyrozap>
Oh, wow, I wasn't aware that existed. That sounds like it would really help me with a piece of software I'm debugging.
scrts has quit [Ping timeout: 256 seconds]
<pie_>
ooh what
<pie_>
or is this rr again :D
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<openfpga-github>
[logtools] azonenberg pushed 1 new commit to master: https://git.io/vyuTB
<openfpga-github>
logtools/master e466698 Andrew Zonenberg: More work on LogDebugTrace pretty-printing. Still no way to turn off trace messages separately from debug.
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
<rqou>
offtopic: i just noticed a rather "interesting" comment in the bison-generated glr output
<rqou>
/* C GLR parser skeleton written by Paul Hilfinger. */
<rqou>
now I'm even more glad I avoided having to take compilers from Prof. Hilfinger :P :P
pie_ has quit [Ping timeout: 256 seconds]
<openfpga-github>
[logtools] azonenberg pushed 1 new commit to master: https://git.io/vyuIe
<openfpga-github>
logtools/master 5b1cfa9 Andrew Zonenberg: Fixed LogDebugTrace printing :: twice
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Read error: Connection reset by peer]
<whitequark>
I never understood why people dislike pdfs
<whitequark>
give me pdf or give me death. html cannot be archived easily and it's far harder to view
<egg|zzz|egg>
yeah, it's just that this one is slow to load
<rqou>
my only "dislike" is that right now i seem to be having some poor interaction between pdf.js and e10s
<rqou>
where a pdf can freeze the entire browser for minutes
<egg|zzz|egg>
whitequark: also, 1962 publication mentioning frequency adjustments to keep up with UT2 (back then they used UT2 rather than UT1) http://sci-hub.cc/10.1109/proc.1964.3384
<egg|zzz|egg>
all hail sci-hub btw >_>
<rqou>
i've never really needed to use sci-hub, but apparently it's because my school was nice and privileged and fancy :P :P
<egg|zzz|egg>
even when I had access to things via ETHZ sci-hub was just more convenient
<egg|zzz|egg>
ETHZ has access to a lot of stuff
<egg|zzz|egg>
but when I'm at home I don't want to set up VPN madness to ethz
<rqou>
UCB has a proxy .pac file that automatically sets up a VPN for you
<rqou>
but they finally revoked my access to taht
<egg|zzz|egg>
sometimes I had to ssh into an ETHZ machine and download it by lynx
<rqou>
i still have ssh access to a machine on the UCB network
<egg|zzz|egg>
turns out most journal sites look like crap on lynx
<egg|zzz|egg>
who would have though
<egg|zzz|egg>
s/$/t
<rqou>
i also have fully legit access to download resources by physically going to the library and using their computers
<jn__>
ssh -D ftw
<egg|zzz|egg>
rqou: yeah, but then I need to get out! and walk! and take the tram!
* egg|zzz|egg
actually doesn't live very far from there, zurich is a small city
<rqou>
lol i only need to walk
<rqou>
but still too much work :P
<egg|zzz|egg>
I could do it by walking too
<openfpga-github>
[logtools] azonenberg pushed 3 new commits to master: https://git.io/vyumP
<openfpga-github>
logtools/master a0efde1 Andrew Zonenberg: Initial implementation of filters for LogDebugTrace
<openfpga-github>
logtools/master ad35060 Andrew Zonenberg: Refactoring: Moved m_min_severity to LogSink base class
<openfpga-github>
logtools/master 9c48311 Andrew Zonenberg: Fixed LogDebugTrace handling of global functions
scrts has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<egg|zzz|egg>
whitequark: btw, I really like your logger; it's probably the best way I have of looking at my backlog, as far as Unicode support goes (since instead of reinventing rendering text ~ahem Hexchat~ it just lets the browser do it)
<egg|zzz|egg>
e.g. my lycosid smiley looks right there °o̤o̤°
<rqou>
egg|zzz|egg: so idk how close you live to ETHZ campus, but this is my route to the campus library: https://goo.gl/maps/zuQ2oy78DtC2
<rqou>
because i'm still trying to pretend to be a student rather than trying to be a "real adult" :P
<egg|zzz|egg>
in hexchat the combining diaereses are shifted to the side
<whitequark>
egg|zzz|egg: nice
digshadow has joined ##openfpga
<egg|zzz|egg>
rqou: D: why am I seeing american units
<rqou>
because google thinks it's smarter than you?
<egg|zzz|egg>
ack even the scale is in light-nanoseconds >_>
<rqou>
because freedom isn't divisible by 10! :P :P
<egg|zzz|egg>
so 0.7 mi is a tad more than a km?
<rqou>
yeah that sounds about right
<egg|zzz|egg>
in my case it's 1.8 km
<rqou>
huh for some reason when i look at europe google maps still shows me freedom units
<egg|zzz|egg>
so I walk 500 m to the nearest tram stop instead
_whitelogger has joined ##openfpga
<egg|zzz|egg>
rqou: busses everywhere too
digshadow has quit [Quit: Leaving.]
<egg|zzz|egg>
you can go to mountainpasses in the middle of nowhere by bus
<rqou>
but that benefits poor people, and we can't have that! :P
<egg|zzz|egg>
rqou: also it shows me sane units in the US, I think you link just had too much freedom to it
<rqou>
probably
digshadow has joined ##openfpga
<rqou>
am i looking at it wrong or is ETHZ really small?
<egg|zzz|egg>
half the city in that area is ETHZ buildings really
<egg|zzz|egg>
the main building is just the main building
<rqou>
oh so it's not just the pink area
<egg|zzz|egg>
the other half of the city is university zurich buildings :D
<egg|zzz|egg>
we don't have a campus as such, it's just in town
<egg|zzz|egg>
well there's the campus for the physicists on the mountain
<egg|zzz|egg>
rqou: note how viet wiktionary lists 6 pronunciation for every entry
<egg|zzz|egg>
north, middle, south, and three places were they speak weirdly :D
<rqou>
lool
<rqou>
well cantonese technically has that too
<rqou>
but there is a relatively-clearly-defined prestige dialect
<egg|zzz|egg>
literary viet is the northern one
<egg|zzz|egg>
in songs they speak northern
<egg|zzz|egg>
which sounds really weird to me :-p
<egg|zzz|egg>
"wait how do you have all these [z] where do they come from"
<egg|zzz|egg>
there are no [z] in the south, they turn to [j]
kuldeep has joined ##openfpga
<rqou>
huh i just looked at the wikipedia article again and noticed that even though vietnamese has implosives it doesn't simultaneously have the "normal" version as well
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
<rqou>
wow the "Vietnamese phonology" wikipedia page is nice and confusing
<egg|zzz|egg>
:D
<rqou>
with all sorts of "Hanoi" and "Saigon" notes everywhere :P
kuldeep has quit [Remote host closed the connection]
<egg|zzz|egg>
rqou: and even that's oversimplified
<egg|zzz|egg>
because you'd have to say something about Hue
<egg|zzz|egg>
and then Vinh and the area
<egg|zzz|egg>
the Nam in vietnam is the same word as the 南 in nanking/nanjing (whose name is nam kinh in viet)
<rqou>
yeah i know that
<egg|zzz|egg>
Bắc is also the same word as Běi, though that doesn't sound quite as close :-p
<rqou>
it kinda matches cantonese pronunciation
<rqou>
because cantonese didn't lose final stops on syllables like mandarin did
<egg|zzz|egg>
iirc cantonese has even more tones than viet?
<egg|zzz|egg>
southern have 2 indistinguishable because fuck that, and also condensate many consonants into [j] for the same reason :D
<egg|zzz|egg>
whitequark: oh fun fact, there is the sound ы in viet (in fact it's in my name, that's the ư in Nam Phương), so I can actually pronounce that :-p
<rqou>
hrm, i'm curious: is IPA (international phonetic alphabet) taught in schools in europe?
<rqou>
or did you learn it yourself somehow?
<egg|zzz|egg>
I don't think western european languages have that? but turkish does
<whitequark>
egg|zzz|egg: huh
<egg|zzz|egg>
rqou: it's used in school
<egg|zzz|egg>
though not taught in its mad entirety
<rqou>
hmm better than in the US
<egg|zzz|egg>
but the bits that matter to distinguish french bits from other french bits are used, yes
<rqou>
the US for the most part does not teach IPA at all
<egg|zzz|egg>
rqou: yes the phonetic stuff used by merriam webster is an abomination
<rqou>
instead using various ad-hoc english-specific phonetic stuff
<egg|zzz|egg>
all glory to the OED
<egg|zzz|egg>
(dictionary flamewars!)
<rqou>
i learned IPA by taking a linguistics elective
<egg|zzz|egg>
yeah it's really useful when you end up trying to say things about pronunciation on IRC
<egg|zzz|egg>
that came out more specific-sounding that it was meant
<rqou>
you mean IPA symbols are useful for more than flipping english text upside-down? :P
<egg|zzz|egg>
:D
<egg|zzz|egg>
there is that too
<rqou>
whitequark: i'm curious how you're supposed to tell the difference between ы and the soft sign if your font is crappy :P
<rqou>
just don't have a crappy font?
<whitequark>
rqou: wait what
<whitequark>
they aren't similar
<whitequark>
i mean, there's no ı letter in russian
<rqou>
ы can look like Ь followed by І
<egg|zzz|egg>
whitequark: ı being amusingly the turkish letter for the sound denoted by ы :D
<egg|zzz|egg>
also the case transformation rules for that are madness
<rqou>
or maybe my cyrillic font just sucks
<whitequark>
rqou: there's no I.
<whitequark>
there's an I in ukrainian but it's not dotless.
<egg|zzz|egg>
maybe Ь1 if you're naming diodes? :-p
<rqou>
yeah you're right that only exists in ukranian
<whitequark>
rqou: also there are no words that have a capital Ы
<rqou>
ah ok
<whitequark>
I mean I *guess* it could be a problem if you tried to put something in all caps but it's obvious from context anyway
<whitequark>
because a soft sign followed by a vowel doesn't make a lot of sense
<whitequark>
wait, no, it does
<whitequark>
but it's still obvious from context :p
pie_ has joined ##openfpga
<rqou>
unless you're trying to do "pattern match something you saw in a picture with the wikipedia list of cyrillic letters" :P
promach has joined ##openfpga
<rqou>
egg|zzz|egg: btw turkish dotless I is pretty famous for being an l10n issue for crappy programs
<egg|zzz|egg>
tbh it might have made sense to have a capital dotless I and a lowercase dotted i for the turks
<rqou>
but how will you flush out your "forgot to use C locale" bugs? :P
<egg|zzz|egg>
ɨıыư
<egg|zzz|egg>
wait apparently ı is [ɯ]
<egg|zzz|egg>
but then ư can be [ɯ] as well as [ɨ]
<egg|zzz|egg>
Viet: phonetic, except not really
<rqou>
eh, [ɨ] and [ɯ] are close enough anyways :P
<egg|zzz|egg>
true
<egg|zzz|egg>
rqou: does cantonese have those?
<rqou>
no
<egg|zzz|egg>
as for viet not being phonetic, I recently noticed something about the word for jackfruit
<egg|zzz|egg>
mít, pronounced [mit] in the north
<egg|zzz|egg>
I pronounce it [mɨt], which is the southern pronunciation
<egg|zzz|egg>
but that sounds like it's written mứt (jam) and in fact that's how the northerners would say mứt
<egg|zzz|egg>
but I would say [mɨk] for jam
<egg|zzz|egg>
so if a northerner says jam I understand jackfruit :D
<egg|zzz|egg>
(jackfruit jam?)
<rqou>
lol i had to look up what a jackfruit even is
<rqou>
and i have no idea what that is called in chinese :P
<egg|zzz|egg>
it's tasty :-p
<rqou>
"jam" is something completely different
<rqou>
so according to google translate jackfruit is "菠蘿蜜" in chinese
<rqou>
what's interesting is that dropping that third character then means "pineapple"
<egg|zzz|egg>
I need to enlarge my font on this client clearly
pie_ has quit [Ping timeout: 268 seconds]
<egg|zzz|egg>
ah it's readable (well I can't read CJKV but besides that) on the hadronic logger
<rqou>
the last character 蜜 means honey by itself
<egg|zzz|egg>
so pineapple honey? :D
<rqou>
apparently?
<egg|zzz|egg>
rqou: see, it's just one syllable in viet \o/ efficiency \o/
<rqou>
蜜 is also pronounced [mi] and might be cognate to some of those vietnamese words?
<rqou>
er, pronouced [mi] in mandarin
<egg|zzz|egg>
lemme try to check
<egg|zzz|egg>
rqou: the word comes either from 蔑 or 櫗
<egg|zzz|egg>
it says chữ Nôm in the wiktionary, so those might be characters of the V-only part of CJKV?
<whitequark>
nom
<rqou>
so my chinese dictionary says the first character means "to belittle" and the second character is "not in dictionary" :P
<rqou>
so apparently borrowed for their sound only
<egg|zzz|egg>
whitequark: the nom writing :D
<rqou>
wait that second character is just the first character with a wood" radical added
<rqou>
so apparently not and that's probably a native vietnamese word
<egg|zzz|egg>
when it comes from chinese it says chữ Hán
Hootch has joined ##openfpga
<egg|zzz|egg>
rqou: so apparently chữ Nôm does a lot of "take a chinese radical for the semantics, take a chinese character for the phonetics, glue them together"
<egg|zzz|egg>
that doesn't reduce stroke count >_>
<egg|zzz|egg>
that's how you get 𬖾
<rqou>
i mean, a decent number of native chinese characters are constructed that way too
<rqou>
welcome to CJKV, the land of homophones, near-homophones, and false friends everywhere :P :P
<egg|zzz|egg>
the 20-stroke 𬖾 sounds inconvenient for something that's pretty much the staple of the local cuisine
<rqou>
i mean, does it matter now that everyone uses "combining character stress test?" :P
<egg|zzz|egg>
no, nobody understands that anymore unless they learn it at university
<egg|zzz|egg>
but at some point that was what people used
<egg|zzz|egg>
basically before the french tried to get rid of the existing scholars so they could have tight control of the administration
<rqou>
hmm in vietnamese is there a "correct" order for combining diacritics?
<rqou>
or is unicode normalization supposed to "magically" sort it all out?
<egg|zzz|egg>
you mean in which order you stack them?
<rqou>
yeah
<egg|zzz|egg>
I think it doesn't matter, because you have o circumflex, a halfmoon, and o or u with a horn for letters, and the accents (for tones) are none of those characters
<egg|zzz|egg>
now as for how to do it properly in handwriting, the letter below the tone accent
<egg|zzz|egg>
including any diacritics the letter may have
<egg|zzz|egg>
rqou: that includes the dot on the i
<egg|zzz|egg>
you're supposed to write it even if there's a tone accent on there
<egg|zzz|egg>
not that fonts would do that
<rqou>
wait so you can't stack a tone mark on a vowel that itself has a diacritic?
<egg|zzz|egg>
but that's what people do in handwriting
<egg|zzz|egg>
rqou: yes you can
<egg|zzz|egg>
you have a letter (which may include a diacritic, one of horn, circumflex, or halfmoon) and you stack an optional tone mark on there
<rqou>
so in unicode the diacritic should come first, right?
<rqou>
not the tone first?
<egg|zzz|egg>
I guess?
<egg|zzz|egg>
that would make sense
<egg|zzz|egg>
note the i with an acute accent, where the dot appears nonetheless
<rqou>
otherwise it seems that you can have e.g. "a + combining half moon + combining question mark shape" != "a + combining question mark shape + combining half moon"
<egg|zzz|egg>
hmm
<rqou>
because unicode is hard :P
<egg|zzz|egg>
but in order for that to differ, wouldn't you need a GCJ?
<egg|zzz|egg>
erm CGJ
<egg|zzz|egg>
lemme check with the unicodebot
<egg|zzz|egg>
argh ắ is precomposed
<egg|zzz|egg>
ok, here it is decomposed by NFC ắ
<rqou>
so i was thinking that they should be considered equivalent
<rqou>
but a naive program will not realize that
<egg|zzz|egg>
rqou: so if I swap the order of the combining thingies, you're right, it looks wrong á̆
<egg|zzz|egg>
so... don't do that? :D
<egg|zzz|egg>
in any case I think people mostly use the precomposed forms
* rqou
files that in "unicode bugs i might need to know about someday"
<egg|zzz|egg>
I mean you just have 6 of them for each vowel
<rqou>
so what about a half-composed form? :P
<egg|zzz|egg>
(by vowel I include the diacritic that may be part of it)
<egg|zzz|egg>
rqou: well you could do that too
<egg|zzz|egg>
compose the breve onto the a, add a combining acute
<rqou>
and that should compare equal to both the fully decomposed and fully composed forms
<egg|zzz|egg>
rqou: but anyway you can NFC that back into fully composed
<egg|zzz|egg>
yup
<egg|zzz|egg>
well depends what sort of equality you want
<rqou>
but i thought there were cases where you can't blindly NFC?
<rqou>
e.g. the thing that made git have a security vulnerability on macOS
<egg|zzz|egg>
you can't blindly NFC a substring, but if you have the whole thing it should be ok?---oh security? I have no clue
<rqou>
"In addition, because HFS+ file system (Mac OS X) considers certain Unicode codepoints as ignorable; committing e.g. .g\u200cit/config, where U+200C is such an ignorable codepoint, and checking it out on HFS+ would overwrite .git/config because of this"
<rqou>
brilliant
<rqou>
apparently the git developers are better at user-friendliness than i am :P
<rqou>
i would have just said "your filesystem is broken, go f*** yourself" :P :P
<egg|zzz|egg>
<Qboid> U+200C ZERO WIDTH NON-JOINER ()
<rqou>
i also had a "fun" experience once where my friend accidentally checked in two filenames that differed only by case
<rqou>
git on windows gets _really_ confused :P
<whitequark>
I've briefly considered supporting case-sensitive filesystems on windows in solvespace
<whitequark>
but it's a pain in the ass
<rqou>
i personally would just blindly ignore windows quirks and if it doesn't work then too bad :P
<rqou>
"fooprogram requires a filesystem where filenames can contain arbitrary bytes other than 0x00 and 0x2f. other filesystems might work most of the time"
<whitequark>
that would just break solvespace if you transferred files between OSes
<whitequark>
good thing you aren't maintaining it
<egg|zzz|egg>
yeah, ignoring the fact that there are codepoints underlying things is a bad idea
<rqou>
why would anything break?
<egg|zzz|egg>
rqou: ahem UTF-16 ahem
<rqou>
but there AREN'T codepoints underlying thingsz
<rqou>
that's what python3 got wrong
<rqou>
not even on windows are there codepoints underlying things
<egg|zzz|egg>
oh goodness *hides in a bunker*
<rqou>
there are only 16-bit units
<rqou>
they don't have to form codepoints
<rqou>
broken surrogate pairs are allowed on windows
<egg|zzz|egg>
blarg
<whitequark>
rqou: nope
<whitequark>
not since vista
<whitequark>
vista+ is utf-16
<egg|zzz|egg>
\o/
<whitequark>
xp- is ucs-2
<whitequark>
I don't support xp anymore lololol
<egg|zzz|egg>
:D
<rqou>
wait so what happens when i move a filesystem with broken surrogate pairs from xp to newer-than-xp?
<rqou>
the file just becomes inaccessible?
<egg|zzz|egg>
rqou: if you insist very hard on getting fucked by the migration process, you might be
<whitequark>
rqou: dunno
<whitequark>
try it
<egg|zzz|egg>
tell us about it if you survive too
<rqou>
um, i can totally create a file "\xD800.txt" on windows 10
<rqou>
i just tried it
<whitequark>
hm, interesting
<rqou>
i thought this is why rust had to go out and invent OsStr?
<rqou>
just treat filenames as a sequence of bytes or a sequence of 16-bit units
<whitequark>
the *rest* of the API uses UTF-16
<egg|zzz|egg>
:D
<whitequark>
the *path* APIs use UCS-2
<whitequark>
that's what I misremembered
<rqou>
anyways egg|zzz|egg the reason i don't want to make a check is that i don't want my shiny new program/tool/PL annoyingly not work on some data that already exists and has previously been deemed valid
<rqou>
*cough* *cough* python3
<rqou>
i love all of the improvements in python3 except for the obsession with unicode-correctness that they seem to be slowly abandoning because as it turns out the real world isn't unicode
<rqou>
*isn't perfectly unicode
<egg|zzz|egg>
rqou: but yeah, if you want to do cross-platform things with filenames you still have to know more about them than "byte string" or "pair-of-byte string"
<egg|zzz|egg>
and whitequark seems to want to do that
<whitequark>
rqou: well them abandoning it is pretty stupid
<rqou>
so what i personally tend to do is "byte/16-bit-unit string, 0x00 and 0x2f are never valid, 0x20-0x7f are usually valid, anything else is YMMV"
<whitequark>
what they *ought* to do is to make it easier to correctly address the invalid data on API boundary
<whitequark>
however, this requires thinking about API design
* egg|zzz|egg
concurs with the quark without a colour charge
<rqou>
hence why i've been semi-seriously semi-jokingly thinking about a WTF-⑨ encoding that just blindly allows all sorts of bogus input
<whitequark>
nah
<whitequark>
just don't pretend paths are strings
<whitequark>
i.e. the rust approach
<whitequark>
paths are tokens that you can sometimes concatenate
* egg|zzz|egg
keeps hearing good things about rust
<egg|zzz|egg>
maybe I should try it out someday
<rqou>
that works until i need to perform the "somehow shove this in the user's face" operation
<whitequark>
rqou: and you can't do that with your wtf-9 encoding anyway, congrats.
<rqou>
in which case python forces me to tell it something i can't know about its encoding
<rqou>
yeah you can, just blindly shove broken bytes out stdout
<whitequark>
you put it into gtk? gtk crashes
<rqou>
well, just don't do that :P
<whitequark>
you put it onto console? the rest of your terminal is filled with mojibake
<rqou>
i don't care about that
<whitequark>
then you increase the net amount of brokenness in the world.
<rqou>
most of my terminal emulators handle it fine
<whitequark>
i suggest not writing software
<egg|zzz|egg>
you could output the bytes in hex
<egg|zzz|egg>
that's not useful mind you
<rqou>
as in they turn not-utf8 into replacement characters
<whitequark>
this is basically the On Error Resume Next approach in relation to encoding
<rqou>
i would also accept the rust approach of "the characters that weren't utf-8 just don't get printed"
<egg|zzz|egg>
whitequark: :D
<whitequark>
rqou: that's not really the rust approach though
<whitequark>
rust gives you basically two options, 1) assert the path can be converted to UTF-8, 2) replace all invalid stuff with U+FFFD
<whitequark>
(it can also bail out and tell you where the problem is, but that's rarely useful)
<rqou>
yeah i was using option 2
* egg|zzz|egg
's first language was VB6. On Error Goto Handler (which was a silly place)
<whitequark>
there's no reason you can't do the same with python
<rqou>
yeah you could do it that way too
<rqou>
although i don't really mind having the "On Error Resume Next" approach either because that's what most of the traditional unix tools tended to do
<rqou>
and most things work most of the time
<whitequark>
yes, that's why unix deserves to die
<whitequark>
nothing in it works *reliably*
<whitequark>
and once you combine enough tools that work most of the time, nothing works ever
<rqou>
so i've never had unix encoding issues give me anything worse than mojibake
<rqou>
which doesn't really matter because that's just a display issue
<jn__>
i've had a #! script break because some stupid windows program had inserted a UTF-8 byte order mark. i'm glad the first thing i did was to hexdump it :)
<rqou>
but that's just windows being stupid
<rqou>
maybe my opinions about this issue are clouded by the fact that I write/wrote a lot of "stupid random glue" code
<egg|zzz|egg>
SLS flight software? >_>
<rqou>
so the encoding brokenness is/was systemic, but python tries to force you to deal with it
<rqou>
nah, usually sysadmin/devops-style bullshit
<whitequark>
yes
<rqou>
e.g. "grab a network interface, mess with its IP address"
<whitequark>
python also doesn't give you very good tools to deal with it
<rqou>
so one such program i wrote recently (in python2+3 hybrid) basically did "open a gui, allow user to select a network adapter, capture some packets"
<rqou>
this was really "fun" because it had to work on linux and windows
<rqou>
it was using libpcap to capture packets and pyside to do gui stuff
<rqou>
so the python script didn't do much other than "shove data around"
<rqou>
now when it comes to the FFI libpcap will give you a "char *" for network device names
<rqou>
well, what type of encoding is it?
<whitequark>
also, I'm rather skeptical of all the whining about migration to python3
<rqou>
it's "hurr durr idk" encoding afaik
<whitequark>
ruby had the exact same problem with ruby1.9
<whitequark>
and they did just fine. there's no "extended support 2020" ruby 1.8 version. 1.8 died many years ago
<rqou>
iirc i just said "it's ascii. if it isn't ascii, stop giving your network adapters stupid names"
pie_ has joined ##openfpga
<rqou>
i used "bytes" to/from libpcap
<rqou>
but somehow i need to get the "bytes" to show up in the gui
<rqou>
in python2 you can "just shove them across and if mojibake shows up then too bad"
<rqou>
in python3 you have to lie and say it's ascii-or-something-herp-derp
<rqou>
in general i love python3
<whitequark>
no?
<whitequark>
that's not how you do it
<rqou>
it's just that these quirks make it really annoying
<whitequark>
there was the other ruby parsing gem, ruby_parser, which is kind of crap
<whitequark>
so I was thinking of other names
<whitequark>
and realized that it could just be a "Ruby Parser" or in other words "Parser"
<egg|iterator|egg>
:D
<whitequark>
it's actually used in one of the ruby implementations afaik
<egg|iterator|egg>
I thought some bits of the readme were missing some articles until I figured Parser was actually a name :D
<rqou>
wait Ruby has multiple implementations (that are relevant)?
<whitequark>
yes
<whitequark>
JRuby is excellent
<whitequark>
in fact it would be quite great if JRuby became *the* Ruby implementation
<whitequark>
rqou: do you know how JRuby runs C extensions?
<rqou>
wait wtf?
<whitequark>
hm?
<rqou>
how can that work?
<whitequark>
oh, you'll enjoy it.
<whitequark>
it used to actually implement a fake Ruby MRI API, but that's slow (because marshalling)
<whitequark>
so instead of that, they added a C parser and a C interpreter written in Java
<rqou>
and this works?
<whitequark>
it not only works, but it is way faster than the previous method
<whitequark>
because there's Truffle.
<whitequark>
Truffle is what happens once you observe that instead of writing a complicated compiler, with IR and everything
<whitequark>
you could instead simply write an interpreter and then partially apply it to an AST
<whitequark>
until it gets compiled down to, well, what a sophisticated compiler would produce as its output IR
<whitequark>
then you just optimize that IR as usual.
<whitequark>
this is super convenient because you have to implement deoptimizations exactly once, in Java, and then you get them in all other languages for (almost, you still have to track values) free
<whitequark>
as long as you have a Java interpreter.
<whitequark>
this actually *simplified* JRuby, it used to have a compiler of Ruby to JVM bytecode, now it doesn't.
<whitequark>
it has a Ruby interpreter and a C interpreter, and they get mashed together, inlined into each other, and so on.
<rqou>
I'm amazed that this supports enough of the ecosystem to be useful
<whitequark>
oh, it supports enough of the ecosystem that they actually removed the old method entirely
<whitequark>
fun fact: the HotSpot folks also wrote an interpreter for LLVM bitcode
<whitequark>
so now any LLVM language (like Rust!) can run on HotSpot for free
<rqou>
except for the part where every single llvm-using project I've seen has needed hacks to llvm?
<whitequark>
that's not true
<rqou>
Rust has hacks, emscripten has hacks
<whitequark>
Rust can be compiled with system LLVM, and has been for many years
<rqou>
oh? did not know that
<whitequark>
there's almost always some stack of patches on top of upstream LLVM, because the Rust release cycle is quicker than LLVM release cycle is quicker than Debian release cyle
<whitequark>
emscripten is being upstreamed into LLVM entirely
<whitequark>
the wasm backend
<egg|iterator|egg>
what's HotSpot?
<whitequark>
egg|iterator|egg: the Oracle (ex Sun) JVM
<rqou>
what about asm.js?
<whitequark>
rqou: it's the same thing as wasm
<rqou>
not quite
<whitequark>
I know
<whitequark>
from 10,000ft it's the same thing as wasm
<whitequark>
and I'm not in a mood to delve into the differences
<whitequark>
also, asm.js is completely unnecessary
<rqou>
I'm still wishing for asm.js/wasm to gain a "deallocate memory" function
<whitequark>
you don't need a separate compiler for asm.js, V8 always compiled asm.js just fine with no special casing
<rqou>
it's not "completely" unnecessary
<whitequark>
no it is
<rqou>
legacy compatibility?
<whitequark>
what?
<whitequark>
no
<rqou>
for non-wasm browsers?
<whitequark>
no, I mean asm.js offers no improvement over just js
kuldeep has quit [Read error: Connection reset by peer]
<rqou>
oh you're referring to just the special case AOT
<whitequark>
yes
<rqou>
supposedly Mozilla's AOT still benchmarks slightly faster
* whitequark
makes an indefinite gesture
<whitequark>
is that when comparing with crankshaft or turbofan?
<whitequark>
on v8 that is
<rqou>
I don't know
<whitequark>
anyway the thing is when v8 improves asm.js
<whitequark>
it improves on *all other JS code* too
<whitequark>
when mozilla's AOT improves, it's useless for the rest
<whitequark>
and most JS code doesn't run in this asm.js sandbox nor should it
<whitequark>
like on V8 you can just stick DOM manipulation in the middle of "asm.js" code
<whitequark>
and it won't regress (other than what's needed to actually manipulate DOM), and that's how it should be
kuldeep has joined ##openfpga
<egg|iterator|egg>
whitequark's gesture has positive values for some vectors and negative values for others
<whitequark>
lol
<whitequark>
I *think* V8 now actually does parse the asm.js annotation
<whitequark>
the only thing it does is enables turbofan right away
<whitequark>
but they may have removed that anyway as turbofan should be the default these days I think?
<rqou>
but Mozilla's been working on that too (optimizations in the normal non-asm case)
<rqou>
although iirc Mozilla's dom is slow
<whitequark>
so the entire asm.js thing was... a PR stunt.
<whitequark>
Mozilla felt like it was becoming neglected! oh no! time to spread misinformation
<rqou>
maybe, but emscripten is useful
<whitequark>
sure
kuldeep_ has joined ##openfpga
<rqou>
I didn't see any outright "misinformation," just an ugly kludge
kuldeep has quit [Read error: Connection reset by peer]
<whitequark>
misinformation is that the asm.js encoding is useful
<whitequark>
it's not, your compiler is just crap
<whitequark>
imagine if Mozilla told you that to make your JS fast you have to use hungarian notation on every variable.
<rqou>
no, I thought asm.js-esque annotations can make normal JS faster too?
<whitequark>
nope
<rqou>
e.g. forcing "never a float"
<whitequark>
erm, that's not an annotation
<whitequark>
that changes semantisc
<whitequark>
annotation is the "use asm" thing
<rqou>
sorry, not the annotation
<egg|iterator|egg>
hmm, perhaps pinging on float was a mistake
<rqou>
the "|0" and "+" things
<rqou>
those can actually speed up normal JS
<whitequark>
the |0 thing is somewhat more complex because the observable semantics is actually different
<whitequark>
but if you operate within a range of "normal integers" then no, in most cases it can't
<whitequark>
because it'll get typed as int anyway
<rqou>
but can the JIT reliably determine that your integer can never be a float?
<whitequark>
no? it doesn't need or have to
<rqou>
aren't integers very slightly faster?
<whitequark>
it just guesses that this slot is probably an integer, and puts an integer there
<whitequark>
then if it is ever *not* integer it deoptimizes and moves down the lattice
<rqou>
but now it has to check
<whitequark>
which is to say, it's going to use FP operations from now on
<whitequark>
nope
<whitequark>
what it does is remembers all the places where it assumed that the slot is an integer
<whitequark>
and if it puts a float into the slot, it invalidates them
<rqou>
but it has to check if it is putting a float into the slot
<whitequark>
rqou: fun fact
<whitequark>
uhm
<whitequark>
not really, it mostly doesn't
<whitequark>
it only has to do that if it doesn't know much about what it puts into the slot
<rqou>
what about when you overflow a 32-bit integer?
<whitequark>
sure, but that's not checking for a float, that's checking for overflow
<whitequark>
you have to check for overflow regardless
<rqou>
not with |0
<rqou>
doesn't that truncate?
<whitequark>
then you have to truncate.
<whitequark>
the cost of a correctly predicted branch is essentially zero
<whitequark>
and the overflow branch is very easy to predict
<whitequark>
so... meh
<whitequark>
you'll enjoy another story about annotations.
<whitequark>
so you know Java has types, right?
<whitequark>
HotSpot must be so fast because it uses those types to optimize everything!
<rqou>
but on x64 "add eax, edx" or whatever automatically truncates
<whitequark>
well no the answer is HotSpot completely throws the types away before it even starts
<whitequark>
this is, incidentally, why HotSpot is such a good dynlang runtime
<whitequark>
(add eax, edx) well, so?
<whitequark>
your thesis is "this makes computations faster"
<whitequark>
I explain why it in practice doesn't
<rqou>
no check required in certain very specific situations
<rqou>
if you're e
<rqou>
e.g. number crunching in JS
<whitequark>
if you're number crunching in JS then you want the semantics of |0, not the supposed speedup
<whitequark>
simply because getting a float back will lead to incorrect results
<rqou>
yes, sure
<whitequark>
and the supposed cost of this check is yet to be proven to exist
<rqou>
but you also get the speedup
<whitequark>
go play with v8, it has a tool that shows you exactly the assembly your code optimizes into and why
<whitequark>
this is a classic "lowlevel programmer" trap, you think you know how long it'll take the code to run because you thought about the instructions, but the intuition is wrong :p
<rqou>
I mean, sure x64 is magic
<rqou>
what about on a Cortex-A7 or similar?
<whitequark>
what *is* a problem in practice is object shape optimization and megamorphic call sites
<rqou>
those run browsers too :P
<whitequark>
so sometimes v8 would get confused about which objects have the same shapes and deoptimizes too far
kuldeep_ has quit [Read error: Connection reset by peer]
<whitequark>
and sometimes it'll see that a function is called with a bajillion different shapes and just give up on it
kuldeep_ has joined ##openfpga
<whitequark>
stupid peephole tricks? not so much
<whitequark>
(cortex-a7) dunno, does it have a branch predictor?
<rqou>
I was more thinking "we literally turned our entire game engine into a webpage" type of applications
<whitequark>
well was it written in C?
<whitequark>
then you want the semantics of |0
<rqou>
C++ presumably
egg|iterator|egg is now known as egg|stupid|egg
<whitequark>
the entire discussion above was about the case when either semantics works but |0 supposedly provides speedup
<rqou>
but for a game you want the semantics and the optimizations
<rqou>
I was more thinking "you wanted the speed and don't mind the |0 semantics"
<whitequark>
if "you wanted the speed" then write code that makes sense
<rqou>
I guess you can argue that you probably shouldn't be using JavaScript :P
<whitequark>
i.e. doesn't change types of variables or shapes of objects all the time
<whitequark>
the stupid low-level tricks are worthless
<whitequark>
also, reduce allocation, and so on
<rqou>
right, I try to do those things too, and then my housemate tells me that I forgot about <insert DOM footgun here> :P
kuldeep_ has quit [Read error: Connection reset by peer]
<rqou>
which isn't even a JS problem :P
<whitequark>
DOM is a whole separate can of worms
kuldeep_ has joined ##openfpga
<rqou>
from my discussion with my housemate I apparently discovered that for any algorithm that I come up with that interacts with the DOM, multiply at least a factor of n into the runtime :P
* rqou
doesn't use JS+DOM very often
<rqou>
anyways, back to llvm
<rqou>
so the only reason for vendoring llvm is release cycles?
<whitequark>
no
<whitequark>
some people don't bother upstreaming their patches
<whitequark>
some people (though it's rare) do genuinely need intrusive patches
<whitequark>
but having a predictable version of LLVM is the most common reason for vendoring it
<whitequark>
it can also be built in multiple ways, which can sometimes cause trouble with bindings
<rqou>
but I heard that e.g. nvptx was hugely intrusive and hacky and it got upstreamed?
<whitequark>
e.g. good luck using cffi with a static build of LLVM
<whitequark>
yes
<whitequark>
LLVM is very friendly to people upstreaming patches
<whitequark>
(it's understaffed, but friendly)
<whitequark>
there was only one person ever refused commit bit :p
<rqou>
hrm, IME llvm sucks at documenting things
<whitequark>
you have to read the code, a lot
<rqou>
whereas GCC has accumulated decades of documentation (some of which still works)
<whitequark>
and "how to write a backend" is still somewhat a black art
<whitequark>
IME GCC makes zero sense whatsoever and is mostly made from spaghetti mixed with shit
<whitequark>
documented or not it's worthless
<whitequark>
whereas in LLVM you have to do some legwork but the code actually makes sense afterwards
<rqou>
I was thinking basic systems/distro level stuff like "how are (aren't) the Rust/emscripten llvm different"
<whitequark>
oh
<whitequark>
not internals
<whitequark>
the Rust llvm is actually now the emscripten llvm
<whitequark>
because Rust has an emscripten target
<rqou>
I never bothered to invest time to learn llvm internals because the documentation that always existed on "misc junk" always gave me the impression it wouldn't be worth it
<rqou>
same with clang
<whitequark>
there's a lot to llvm internals
<whitequark>
writing a backend vs writing a frontend is basically working with two entirely different codebases
<whitequark>
vs writing an optimization pass, which is a third one
<whitequark>
writing a backend is naturally the hardest, but it only took me 2-3 weeks to get productive with it
<rqou>
I always end up it situations like "can I do <foo> with clang+llvm? idk, but the compiler driver can't and no documentation/google-able blog post definitively said I can"
<rqou>
and then I end up not bothering because I know that GCC can
<whitequark>
these days I don't even bother building GCC, because a compiler that isn't a cross-compiler is not worth wasting time on
<rqou>
I also tend to be afraid to end up with a hugely-hacked clang+llvm that I will have to somehow maintain (although GCC configure magic isn't much better)
<whitequark>
you could just upstream
<rqou>
I also don't want "now my clang somehow broke Rust's/emscripten's/Debian's" (whereas I know my hacked GCCs live in /opt)
<whitequark>
what
<whitequark>
you do realize llvm can be installed in any chosen prefix
<rqou>
some of the compiler drivers (emscripten) are/were sensitive to $PATH
<rqou>
whereas my custom GCC was always prefixed and never plain "gcc"
<rqou>
I do recall at one point emscripten dumps a somehow-modifed clang binary into PATH
<rqou>
that is just called "clang"
<rqou>
maybe this can all be summarized into "people (including me) need to write better compiler drivers and scripts that locate compilers"
<whitequark>
rqou: so I just looked at what debian does
<whitequark>
turns out they use, um, mv.
<whitequark>
given how clang/llvm use rpath... what you can do is
<rqou>
hrm, I really need to sleep now, but it sounds like everything that I want clang+llvm to do is actually possible in some (not necessarily obvious) way
<whitequark>
you simply make a symlink from /opt/fucked-up-llvm/bin/clang to $SOMEWHERE_IN_PATH/fucked-up-clang
<whitequark>
that's it
<whitequark>
you usually don't need all the other tools
<rqou>
some time in the future I might ask you about replacing my ugly GCC configure mess with clang
<rqou>
but sleep time for now
<whitequark>
sure.
<rqou>
final note: maybe my personal experience with clang+llvm was "suboptimal" because my first real exposure to that toolchain was emscripten :P
* egg|stupid|egg
likes when someone on twitter comes across Ignition!
<carl0s>
do you think it will be a huge improvement over 5LP devices? all i know it's a CortexM4 + M0+ and the USB-C connector next to the bigger post-it
<lain>
carl0s: if that's your photo, you may want to strip the EXIF, it's geotagged
<lain>
well ok, harmless I guess - it was taken at Cypress Semiconductor :3
<carl0s>
it's not mine hehe
<lain>
:)
Toastbomb has joined ##openfpga
Toastbomb has quit [Client Quit]
<pointfree>
I think the M0+ must be the analog co-processor? Maybe they'll populate all 4 banks of UDB's in the PSoC6, so we'll have 64 of them instead of just 24.
<egg|stupid|egg>
hahaha my google calendar was still in ICT >_>
<egg|stupid|egg>
good thing I noticed that before going to that meeting <_<
<carl0s>
in case of having the 64 UDBs that make it have equivalent to a small FPGA? and yes i think the M0+ will be the analog front end
carl0s has quit [Quit: Leaving]
amclain has joined ##openfpga
<azonenberg>
pointfree: so looking at the portfolio roadmap
<azonenberg>
psoc 6 is going to be M4 + M0+ dual core
<azonenberg>
and psoc 7 is going to be M7
<lain>
you know what I want? a cheap usb3 superspeed micro, either with one host and one device port (and dma to mem on both), or with an sd card interface
<azonenberg>
you know what i want? an itty bitty zynq
<lain>
cypress makes an fx3s that can talk to sd cards but it's like $22 a pop or something
<lain>
which is /absurd/
<lain>
you can get an mcu with sata and usb3 (and all docs behind nda, heh) for mad cheap, but that's sata, and I don't want sata! :P
<azonenberg>
say 15k cells of FPGA, a cortex-m7 as a hard IP block that can operate independently of the FPGA (i.e. you can power down either one)
<azonenberg>
ideally, multiple power domains within the FPGA block so you can power down subsets of it
<azonenberg>
hard IP for ethernet
<balrog>
azonenberg: how much are they changing the PSoC blocks/
<azonenberg>
bonus points if there's an integrated PHY
<whitequark>
on my chromium instance, js is about twice as fast as asm.js'd rust code
<whitequark>
ah, it doesn't actually "use asm", nevermind, that's a completely worthless comparison
Hootch has quit [Quit: Leaving]
Hootch has joined ##openfpga
digshadow has joined ##openfpga
<egg|egg>
whitequark: so there's a chance I could end up working in i18n
<egg|egg>
Unicode \o/ :-p
<whitequark>
huh, of all things?
<egg|egg>
whitequark: well the hiring process got unstuck, and I have a video call monday with the manager of YouTube here at zurich, who (from what the recruiter told me) has two things, one being i18n and the other being creator
<whitequark>
mmmh.
<egg|egg>
whitequark: oh, also, more anecdotes from the design process of Ada 2005: they considered supporting Unicode numerals in numeric literals (Perl 6-like), but the guy from japan pointed out that it was hell to give reasonable semantics to that, and that even if you had your identifiers in japanese you'd still just want to write numeric literals the normal way, so phl killed it in the end; but he had designed a really
<egg|egg>
mad system before that died
<egg|egg>
something where e.g. 1(roman numeral XII)2 would be a valid literal whose value was 100 + 120 + 2 :D
<whitequark>
ugh why
<whitequark>
unicode numeric character class is literally the least useful one
<egg|egg>
yeah
<egg|egg>
that's the conclusion they came to
<egg|egg>
so they killed it :D
<egg|egg>
also dinnertime, bbl
egg|egg is now known as egg|nomz|egg
bibor has quit [Quit: WeeChat 1.0.1]
<azonenberg>
whitequark: ping
<whitequark>
azonenberg: pong
egg|nomz|egg is now known as egg|egg
<azonenberg>
whitequark: so i'm having that "maximum number of clients reached" problem on my laptop again
<whitequark>
... which problem
<azonenberg>
i know its a handle leak with something related to the X server
<whitequark>
oh
<azonenberg>
I'm trying to figure out how to track down which app is leaking
<azonenberg>
Right now i have exactly one free client handle so i can run xrestop etc
<azonenberg>
lain, whitequark: xrestop is showing 238 clients
<lain>
hm
<azonenberg>
i see a LOT of "unknown, pid ?" entries
<azonenberg>
windows 0, GCs 2
<lain>
azonenberg: I assume you've tried this, but the first google hit on that error is someone saying none of the X tools helped, they used `lsof -U`
<azonenberg>
Well i may just have to put up with it until stretch comes out and hope that fixes it?
<azonenberg>
whats weird is
<azonenberg>
i run jessie on all of my computers
<azonenberg>
and this one laptop is the only one having problems
<azonenberg>
And i use substantially the same apps on them all
<lain>
it's the TLA implant
<lain>
:P
<azonenberg>
Very sloppy implant if it leaks handles
<whitequark>
well would competent people go work at CIA
<whitequark>
private sector pays more!
<lain>
I wish Wayland was more promising than it is
<lain>
X needs taken out back
<whitequark>
what's wrong with Wayland?
<whitequark>
lots of interest in it, lots of software already works on it
<lain>
I mean, Wayland is absolutely /better/
<whitequark>
Qt 4 and GTK 2 are slowly dying out
azonenberg_work has quit [Remote host closed the connection]
<lain>
but iirc it still doesn't support per-display dpi
<whitequark>
mmh
<azonenberg>
yeah i really want that too
<azonenberg>
and i dont mean like downsampling per display
<azonenberg>
i mean rasterizing vectors at different DPI depending on which display the fragment is on
<whitequark>
that's a nightmare for client software
<whitequark>
and not something for wayland to solve in the first place
<lain>
I'd even be ok with how windows does it - just render based on the display the majority of the window is on
<azonenberg>
> nightmare for client software
<whitequark>
like, try to actually write something that works like that
<azonenberg>
client software should deal with abstract floating point coordinates
<azonenberg>
and render to abstract floating point coordinates
<whitequark>
that doesn't work
<azonenberg>
pixels should not exist outside of the GPU driver
<whitequark>
because text looks like shit
<whitequark>
primarily
<azonenberg>
Why? Any game engine etc works that way
<whitequark>
you need hinting
<azonenberg>
If you have a sane DPI you dont even need antialiasing
<whitequark>
that's bullshit
<azonenberg>
the pixels are small enough they do it for you
<lain>
ehhh it still helps
<whitequark>
the DPI on this display is 270 and it needs antialiasing
azonenberg_work has joined ##openfpga
<qu1j0t3>
azonenberg | client software should deal with abstract floating point coordinates
<qu1j0t3>
azonenberg | and render to abstract floating point coordinates
<qu1j0t3>
Display PostScript, NeWS, etc.
<azonenberg>
OpenGL etc does this already
<qu1j0t3>
text is fine.
<azonenberg>
an OpenGL app doesn't deal with pixels until you get to fragment shaders
<azonenberg>
even in vertex shaders you work in abstract coordinates
<whitequark>
(it's a laptop)
<whitequark>
anyway, if you suggest just throwing everyone who can't afford a highdpi display under the bus wrt text rendering
<whitequark>
that's a no-go
<qu1j0t3>
even using ~1990 era rasterisers, text can work with real-valued affine transofrms just fine
<qu1j0t3>
but they're even better now
<whitequark>
azonenberg: wrong again
<whitequark>
go write a real opengl app
<whitequark>
I am (solvespace)
<whitequark>
solvespace renders text. solvespace renders raster images in the UI. solvespace renders raster images (user-provided)
<azonenberg>
whitequark: and where do you deal with pixels exactly? Mouse coordinates?
<whitequark>
that's the easier part, actually
<whitequark>
though still pretty awful
<azonenberg>
Because in an ideal world mouse coordinates would be converted to floating point app coordinates by the window manager before your app even sees them
<whitequark>
it's not even enough to have a single scale factor!
<azonenberg>
abstracting away details like spatial offsets between monitors, DPI differences between monitors, etc
<whitequark>
I have a separate scale factor for vector graphics, separate scale factor for UI raster, and on top of that I need text hinting
<azonenberg>
the pixel velocity to spatial velocity of the cursor should change
<azonenberg>
depending on which display you're on
<whitequark>
or it becomes unreadable
<whitequark>
your abstractions are useless if you want the UI to actually be usable
<azonenberg>
Hinting, aiui, is a kludge for fonts being rendered at insufficiently high DPI for vectors to work
<whitequark>
not quite
<whitequark>
there are several forms of hinting
<whitequark>
the hinting that solvespace uses is snapping text to pixel grid
<azonenberg>
If I render my fonts at 300DPI with no hinting or AA
<azonenberg>
and put that on a 300DPI display
<azonenberg>
it should look just fine
<whitequark>
I have a 300DPI display
<whitequark>
right here
<whitequark>
and no, it's not fine
<whitequark>
anyway, even if it *was* fine, I can't just disregard anyone with a 85 DPI display
<azonenberg>
In another 5-10 years
<azonenberg>
i suspect those wont exist anymore
<azonenberg>
i mean, sub-1080p is almost nonexistent now
<azonenberg>
4K will probably be standard for laptop-sized displays with 8K standard for desktop and ;arger
<azonenberg>
larger*
<azonenberg>
in the 5-10 year time frame
<whitequark>
you're in the richest country in the world with cheapest consumer goods in the world
<whitequark>
your perspective is not representative
<azonenberg>
Economies of scale, though
<azonenberg>
if you make things en masse for the american consumer, before long they're made in sufficient volume that anyone can afford them
<whitequark>
try to import something into argentina someday
<azonenberg>
might take another few years
<whitequark>
as an exercise
<whitequark>
qt5/gtk3 requiring gl was already bad enough
<whitequark>
but that was probably unavoidable, unless you wanted to just completely stagnate
<azonenberg>
There are GPUs that cant run opengl?
<azonenberg>
my geforce 2 from 2001 could do that
<azonenberg>
i think it even did vertex (but not pixel) shaders
<whitequark>
they require specific shader features
<whitequark>
when ubuntu started requiring compositing and falling back to llvmpipe
<azonenberg>
Ok so maybe you need a 12-year-old GPU instead of a 16-year-old one
<azonenberg>
That's hardly unrealistic
<whitequark>
they instantly made themselves unusable on a nontrivial part of their target segment
<whitequark>
nah
<whitequark>
talking about devices that came out the same year as unity-based ubuntu
<whitequark>
that was like '12
<whitequark>
it fell back to llvmpipe. insta-unusable
<azonenberg>
so opengl 2.x support came out with nvidia geforce 6 series cards
<azonenberg>
That's january 2005 release date
<whitequark>
netbooks
<egg|egg>
my desktop's pixel pitch has pretty much remained constant for the whole time I've had desktops
<whitequark>
i965GM was a particularly bad offender
<egg|egg>
last screen I bought was ~2 years ago
<whitequark>
but not the only one
<egg|egg>
not cheap crap either, 109 pixels per inch
<whitequark>
qu1j0t3: try to make display postscript scroll at a decent framerate someday.
<qu1j0t3>
:)
<whitequark>
so you have to rasterize client-side, which means that at least your rasterizer has to be aware of the target DPI.
<lain>
azonenberg: lol forum post re: your X error.. person worked around it by doubling the MAXCLIENTS value XD
<azonenberg>
lain: that just means the leak takes 2x as long to fail
<azonenberg>
lol
<whitequark>
this is one of those problems that looks simple as long as you're not the one solving it.
<lain>
yeah
<azonenberg>
whitequark: why do you rasterize clientside?
<azonenberg>
as long as your whole pixel pipeline is h/w accelerated you should be able to do everything in the GPU and just update transformations and geometry as it changes
<whitequark>
azonenberg: lol
<azonenberg>
that should allow 60fps on multiple 4k displays easily
<whitequark>
you *really* don't want to represent your text as millions of triangles
<azonenberg>
we're talking a text editor, not Crysis
<whitequark>
you want to render it into a texture and then copy-and-paste parts of that texture elsewhere
<lain>
text editing *in* Crysis
<whitequark>
yes, a text editor on a 4k display is not trivial to do
<lain>
3d high-impact unicode action
<egg|egg>
:D
<lain>
crawl your way through the emoji jungle
<whitequark>
seriously, try doing that someday
<whitequark>
in general rendering vector graphics through opengl is a hairy problem
<azonenberg>
whitequark: so suppose you have a texture that's say 512x512 per glyph
<whitequark>
it is *really* hard to draw antialiased lines alone in gl
<azonenberg>
thats one polygon per char
<azonenberg>
and you just render mipmaps for smaller images
<azonenberg>
down to say 64x64 which would be like a 4-point font
<whitequark>
I'm myopic, at 30 inch I don't see this display even in glasses
<egg|egg>
huh, even with glasses? O_o
* egg|egg
is myopic too, but sees his screen rather well with glasses
<whitequark>
in glasses it's usually 10-15 inch I think
<whitequark>
30 is ridiculous
<egg|egg>
also why are we using freedom units
<whitequark>
azonenberg started them
<egg|egg>
that's a twelfth of a light-nanosecond?
* lain
releases several eagles, plays national anthem
<whitequark>
azonenberg: I'm sure what you're saying works fine for you personally with your hardware and your eyes
<whitequark>
just like I'm sure that extending the same assumptions to {everyone else} is a bad idea
<egg|egg>
O_o you're 75 cm from your screen? O_o
<azonenberg>
ok fine, 15 inches - thats still ~2 mrad
<azonenberg>
i guess thats closer to how far i sit
<whitequark>
and you have clearly not even given consideration to how other people might use them
<azonenberg>
but still a 300DPI display at that distance is well beyond eye resolution
<azonenberg>
for a laptop i'd want more like 600 DPI
<azonenberg>
or 1200ish for a phone
<whitequark>
that's stupid
<whitequark>
you're going way over your power budget
<azonenberg>
basically once you reach that resolution, AA and hinting become irrelevant
<whitequark>
the difference between QHD and FHD display on this laptop cost me ~five hours of battery life
<whitequark>
16 vs 11
<whitequark>
and the amount of pixels you have to push through rises quadratically
<lain>
it's ok we just need to solve the ultracapacitor problem
<whitequark>
you lose on the link to the display, you lose on the memory bandwidth, you lose on GPU power consumption
<lain>
</snark>
<whitequark>
this is especially bad in laptops
<whitequark>
don't get me started on, say, recording video of a screen, or something like that
<whitequark>
that's not all
<whitequark>
at QHD, for example, chromium already cannot scroll without GPU rasterization, at >QHD a GPU becomes mandatory for doing *anything* with a UI
<azonenberg>
Yes but in this model, software rendering doesn't exist
<whitequark>
this means that VNC becomes infeasible
<azonenberg>
you push vectors everywhere
<whitequark>
this means that if your GPU is buggy, you're SOL
<azonenberg>
VNC would be replaced with a network transparent rendering protocol like X had
<whitequark>
and GPUs are buggy as hell
<azonenberg>
you push rendering commands and the clientside gpu rasterizes
<azonenberg>
opengl was designed client-server for a reason
<whitequark>
this works as long as you can stay in vector domain indefinitely
<whitequark>
this is not realistic
<azonenberg>
Not now, we're talking 5-10 years out
<azonenberg>
The only thing you'd still need raster data for is textures or photos
<azonenberg>
push to a texture object on the clientside GPU once
<whitequark>
so basically most compiler transformations work best on local variables
<egg|egg>
"syndicat régional des orthophonistes d'Aquitaine"
<whitequark>
the compiler can easily eliminate unused ones, reason about their mutability, etc
<whitequark>
if you have a struct though in a local, it's worse, because you have to consider that it may be used as an aggregate
<whitequark>
e.g. taken address of
<whitequark>
scalar replacement of aggregates basically breaks up a struct Point { float x, y, z; } into locals float x, y, z;
<whitequark>
if it's legal, naturally.
<whitequark>
it's one of the two most important transformations in compilers if you ask me, second after inlining alone
<egg|egg>
makes sense
<whitequark>
it can expose code to *so many* new analyses
<egg|egg>
whitequark: so then in your godbolt link we're seeing the effect of that in the giant unrolled loop, with the coords of the points that are incremented being put into xmm 0 and 1 without regard to the point they belonged to?
<whitequark>
egg|egg: yeah, every .Add invocation is compiled into an addss
<whitequark>
so all of x, y, z are combined into a single xmm register
<whitequark>
this is a transformation that generally requires the compiler to first break up the aggregate into locals
<whitequark>
then reassemble the locals into a vector
<whitequark>
(then unroll)
<whitequark>
this is because the in-memory representation of a Point may well be different from the register one
<whitequark>
e.g. I think it has padding between the floats?
<egg|egg>
I'm confused, what size are the xmm registers?
<egg|egg>
I thought 2 3 and 4 contained x in that code
<whitequark>
128-bit
<egg|egg>
but those are scalar adds, not packed?
<whitequark>
mmh let's see
<egg|egg>
I'm reading that as x being in 2 3 4, and every xmm containing one binary32
<whitequark>
oh I see, you're right
<whitequark>
so it didn't vectorize the loop
<egg|egg>
no, but it did deal with the coords independently of the structs they belonged to
<egg|egg>
since you end up having an x in 0 then a y in 1 then a z in 0 then an x in 1 etc.
<whitequark>
sure, I know, that much I verified
<whitequark>
try adding a w.
<whitequark>
it still generates some really strange code.
<egg|egg>
now it doesn't unroll anymore?
<whitequark>
oh I see what happened
<whitequark>
hm
<whitequark>
it looks like it just inlined Add verbatim
<whitequark>
but... why
<whitequark>
see this is the real problem I have with MSVC
<whitequark>
it did pack them but why did it make SO MANY SHUFFLES GOD
<egg|egg>
I would make a shuffle dance joke but it has likely been done to death
<egg|egg>
but yes, *half a page of shuffling* -four packed adds- *another half-page of shuffling*
<egg|egg>
whitequark: I wonder how the MSVC "doesn't pack" and the clang "shuffle shuffle shuffle add shuffle shuffle shuffle" approaches compare in benchmarks >_>
<whitequark>
egg|egg: um
<whitequark>
so these adds...
<whitequark>
the first three are just copies of that single point
<egg|zzz|egg>
whitequark: btw, principia progress, I have come back to a point where it's merely ridiculously buggy, and not crash-on-load :-p
<whitequark>
nice
<egg|zzz|egg>
a nice thing with that mod is that when we have a bug we can't really ignore it, and we typically get a nice stacktrace; but of course it means we're crashy :-p
<egg|zzz|egg>
(other mods throw exceptions in C# and that gets caught by the game eventually)