|
ucs-2 supremacy
|
#
?
May 19, 2016 18:20
|
|
|
|
| # ? Jun 12, 2024 00:30 |
|
|
Well, that one's entirely on the Unicode consortium Unicode consortium in the late 80s/early 90s: "It is absolutely possible to assign a code for every single glyph from every single human writing system in common use to a point in a 16-bit code point space. We are linguists, so you should trust us because we are experts in this field" NT and Java development teams: "OK! Well, we're programmers and not linguists, so let's trust the experts. From this day forth, characters from every realm of this earth shall be encoded as 16-bit quantities. This data type shall be used throughout our new systems, which will be universal and legacy-free!" Unicode consortium a few years later: haha j/k  NT and Java development teams: 
|
|
#
?
May 19, 2016 18:26
|
|
|
also Qt
|
|
#
?
May 19, 2016 18:39
|
|
|
Symbolic Butt posted:ruby itself is not that bad imo but holy poo poo rails missing instance var: nil missing array element: nil missing hash element: nil yep let's blame rails here
|
|
#
?
May 19, 2016 18:47
|
|
|
FamDav posted:I'm going to call out into the void for a tef/monococqc paper dump TLA+ book is online 
|
|
#
?
May 19, 2016 18:48
|
|
|
tef posted:missing array element: nil eh at least people seem to use the fetch method instead tef posted:missing instance var: nil ok this one is specially bad because people treat it as a feature and make it part of bespoke ruby idioms  tef posted:yep let's blame rails here sure, it's ruby's fault for starting the habit but rails went crazy beyond imo. old rails has the hardest ORM system to debug because of this poo poo
|
|
#
?
May 19, 2016 19:45
|
|
|
also ruby is very bad
|
|
#
?
May 19, 2016 19:49
|
|
|
CRIP EATIN BREAD posted:also ruby is very bad
|
|
#
?
May 19, 2016 19:59
|
|
|
thankfully ruby is dead as hell
|
|
#
?
May 19, 2016 19:59
|
|
|
CRIP EATIN BREAD posted:also ruby is very bad
|
|
#
?
May 19, 2016 20:12
|
|
|
CPColin posted:It's 8 bits, so -128 to 127. I'm guessing they went, "Well all our other primitives are signed, so it'd be weird if byte were unsigned." The only difference would have been that widening conversions wouldn't do sign extension, right? I think we would have all gotten over it. Maybe if they'd added a special operator that does the "& 0xff" for you, it wouldn't have been such a big deal. it's a bit of a gotcha. apart from actual byte arrays the jvm and the underlying hardware operate in terms of ints anyways. so there's no reason to write "byte" rather than "int" ever pretty much
|
|
#
?
May 19, 2016 20:21
|
|
|
Shaggar posted:thankfully ruby is dead as hell it's the new legacy java except a thousand times shittier
|
|
#
?
May 19, 2016 20:41
|
|
|
James Gosling posted:Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple.
|
|
#
?
May 19, 2016 20:41
|
|
|
Max Facetime posted:it's a bit of a gotcha. apart from actual byte arrays the jvm and the underlying hardware operate in terms of ints anyways. so there's no reason to write "byte" rather than "int" ever pretty much assuming you never do anything involving actual bytes anywhere, sure
|
|
#
?
May 19, 2016 20:42
|
|
|
i spent all my professional time with C processing byte streams and packing/organizing data in a custom file format. i cant imagine there's any C dev that doesnt know whats going on with unsigned values.
|
|
#
?
May 19, 2016 21:03
|
|
|
lol
|
|
#
?
May 19, 2016 21:06
|
|
|
i want to copy an 8-bit integer to a 32-bit int in order to operate on it byte b; int x = b & 0x000000FF; such elegance also don't forget to use logical shift >>> everywhere instead of arithmetic shift >> because right shifting with sign extension is a thing that people want to do ever Thankfully at least there's Byte.toUnsignedInt() in Java 8 but yeah this poo poo is inexcusable. Like I'd actually prefer to have some sort of "make byte behave in a non idiotic way" pragma at the top of every translation unit from now until forever more over this poo poo show.
|
|
#
?
May 19, 2016 21:07
|
|
|
Bloody posted:assuming you never do anything involving actual bytes anywhere, sure even then. ByteArrayOutputStream takes single bytes as ints and gives out a byte array. ByteArrayInputStream takes a byte array and gives out single bytes in ints. and that's all you need for arrays of bytes
|
|
#
?
May 19, 2016 21:13
|
|
|
love baos and bais
|
|
#
?
May 19, 2016 21:15
|
|
|
I want to leave my current job and getting some kind of rails job instead... doesn't sound that bad compared to now I guess 
|
|
#
?
May 19, 2016 21:16
|
|
|
u want asp.net 4.X or asp.net core
|
|
#
?
May 19, 2016 21:18
|
|
|
Mr Dog posted:also don't forget to use logical shift >>> everywhere instead of arithmetic shift >> x >> 32 is -1 if x is negative, and 0 if x is positive or 0. There's uses for that.
|
|
#
?
May 20, 2016 00:45
|
|
|
Shaggar posted:u want asp.net 4.X
|
|
#
?
May 20, 2016 01:08
|
|
|
Zemyla posted:x >> 32 is -1 if x is negative, and 0 if x is positive or 0. There's uses for that. i can see absolutely no reason to ever do that instead of the perfectly clear "x < 0 ? -1 : 0"
|
|
#
?
May 20, 2016 01:31
|
|
|
he's not wrong, but you could s/un// and it'd be even more true. even with c's insane promotion rules signed numbers are way more complicated than unsigned
|
|
#
?
May 20, 2016 01:47
|
|
|
Shaggar posted:thankfully ruby is dead as hell except for chef! also the 10xer here loving loooooves ruby and it makes me want to stand on his desk and take a poo poo on his keyboard
|
|
#
?
May 20, 2016 02:49
|
|
|
JewKiller 3000 posted:i can see absolutely no reason to ever do that instead of the perfectly clear "x < 0 ? -1 : 0" Not branching is a good thing, especially on embedded systems that don't have branch prediction.
|
|
#
?
May 20, 2016 04:01
|
|
|
flushing a three stage pipeline isn't typically too disastrous and shift ops can be surprisingly hosed on a lot of embedded platforms. for example, the msp430 cannot shift, it can only rotate, so x >> 5 results in five rotate right instructions. byte aligned shifts will optimize to address offsets when optimizations are enabled at least. also int32 >> 32 magically turning into just the sign seems extremely unlikely in c
|
|
#
?
May 20, 2016 04:21
|
|
|
Probably better off either masking for the most significant bit and finding a way to make that useful on its own or doing something that would set the sign bit in the status register and masking that out if you're properly desperate and the status register layout happens to be just right
|
|
#
?
May 20, 2016 04:24
|
|
|
if you're assuming a naive implementation the java semantics require a branch anyway. no major processors turn large shifts into sign fills, they all mod by width if you're not assuming a naive implementation then it is pretty easy to make either of those branchless even with a non-constant shift
|
|
#
?
May 20, 2016 06:37
|
|
|
Zemyla posted:Not branching is a good thing, especially on embedded systems that don't have branch prediction. sufficiently smart compiler etc
|
|
#
?
May 20, 2016 07:33
|
|
|
Mr Dog posted:Unicode consortium in the late 80s/early 90s: "It is absolutely possible to assign a code for every single glyph from every single human writing system in common use to a point in a 16-bit code point space. We are linguists, so you should trust us because we are experts in this field" meanwhile in 2016, "It is absolutely possible to assign a code for every single glyph from every single human writing system in common use to a point in a 1,114,112 code point space" and other people literally look at all of the extra space in Unicode and say "hey, we should use all of this extra space for something! no reason not to!" CRIP EATIN BREAD posted:utf-16 is a blight utf-16 is also the main reason why we can never extend Unicode to more than 1,114,112 code points
|
|
#
?
May 20, 2016 08:22
|
|
|
Bloody posted:flushing a three stage pipeline isn't typically too disastrous and shift ops can be surprisingly hosed on a lot of embedded platforms. for example, the msp430 cannot shift, it can only rotate, so x >> 5 results in five rotate right instructions. byte aligned shifts will optimize to address offsets when optimizations are enabled at least. shifting the number of bits that is the same as the width is undefined behavior
|
|
#
?
May 20, 2016 15:32
|
|
|
i spent a week debugging an issue because of that 
|
|
#
?
May 20, 2016 15:32
|
|
|
CRIP EATIN BREAD posted:shifting the number of bits that is the same as the width is undefined behavior yeah that's kind of what i figured but wasn't willing to commit to it in that post
|
|
#
?
May 20, 2016 15:35
|
|
|
FamDav posted:I'm going to call out into the void for a tef/monococqc paper dump dunno what you're looking for, but the typical way to learn coq these days is Software Foundations https://www.cis.upenn.edu/~bcpierce/sf/current/index.html
|
|
#
?
May 20, 2016 16:03
|
|
|
Mr Dog posted:it's even stupider than that because char is unsigned And char doesn't necessarily represent a character (surrogate pairs).
|
|
#
?
May 20, 2016 19:04
|
|
|
i'm gonna learn elm
|
|
#
?
May 20, 2016 22:08
|
|
|
good, its very good
|
|
#
?
May 20, 2016 22:29
|
|
|
|
| # ? Jun 12, 2024 00:30 |
|
|
crazypenguin posted:dunno what you're looking for, but the typical way to learn coq these days is Software Foundations I was mostly interested in seeing if anyone more educated than I had recommendations beyond what id found. our service scheduler is growing in complexity as we extend it, and I'm interested in using something like tla+ for formal verification of behavior.
|
|
#
?
May 20, 2016 23:17
|
|