Enlightened
-
Another quality Samsung software release:
-
@morowhat said in Enlightened:
poettering
-
/rm -rf'd
-
It's a way better rapper than Siri, though.
-
@hungrier -3/11 no Cortana
-
@rhywden "Let's beat Google at all their services simultaneously" is not a good strategy for anyone, much less a company like Samsung that has never produced one decent line of code. It's a bit like if those Vatican City guards tried to invade Russia.
-
@rhywden time for some anti-trust lawsuit?
On the S8, the only useful advantage Bixby has over the Google Assistant is always-on hotword support, but only because Samsung purposefully limited the Google Assistant. On many phones the "OK Google" hotword works all the time,
-
Oh, and the best part:
We've had it confirmed that the solution that our TV guys have been testing works. It would need to be installed by an approved Samsung engineer, so please contact our TV Support teams so they can arrange a suitable appointment for you.
They really done goofed.
edit: Browsing through the forum thread on the Samsung site:
I managed to get an engineer and he came out this evening, plugged a USB stick in, no joy, now TV has gone back to workshop to be looked at. No Idea how long it will be away. Hoping it won't get fixed so I can take it back to retailer.
Is anyone surprised that the "solution" isn't one? Also, yeah, a "certified engineer" is really necessary to plug in a USB stick...
-
@rhywden but all tests passed - my Excel says so!
-
F2 infosec conference had a talk about Tizen this week:
(source: https://twitter.com/hkashfi/status/923862231883943937)
-
@rhywden From that article: "Samsung is aware of a small number of TVs in the UK", and then further on " get in touch with Samsung directly (1-800 SAMSUNG)"...
How, exactly?
-
@raceprouk said in Enlightened:
In VB at least, they're functions that don't return a value
Ahem. No... functions are subroutines that do return a value.
-
@anotherusername said in Enlightened:
@raceprouk said in Enlightened:
In VB at least, they're functions that don't return a value
Ahem. No... functions are subroutines that do return a value.
Ahem. No... functions return a 1-tuple and subroutines return a 0-tuple.
-
@ben_lubar said in Enlightened:
functions return a 1-tuple and subroutines return a 0-tuple
In general, the result of a subprogram can be any type, but there's a type with only one value (sometimes called
unit
orvoid
) that is produced when the subprogram only has side effects. When the language has exception semantics (i.e., isn't Go) then there's more trickery going on in the semantic level — exceptions are a different part of the result type to the normal result value, and are often treated differently (such as not actually being conveyed by actually returning a value as such) — but that's really orthogonal.Some programming languages like to give different names to kinds of subprogram based on what the result type is, but that's really an artificial distinction; the base semantics of this sort of thing doesn't need it.
-
@dkf said in Enlightened:
When the language has exception semantics (i.e., isn't Go)
Go has panic/recover/defer, which are roughly equivalent to try/catch/finally.
-
@ben_lubar said in Enlightened:
Go has panic/recover/defer, which are roughly equivalent to try/catch/finally.
Is recover an alternative to writing
if err != nil
every 5 lines?
-
@ben_lubar Better to stick with languages that only have methods.
-
@dkf said in Enlightened:
Some programming languages like to give different names to kinds of subprogram based on what the result type is
In Pascal, Functions return something and Procedures don't.
-
@bb36e said in Enlightened:
@ben_lubar said in Enlightened:
Go has panic/recover/defer, which are roughly equivalent to try/catch/finally.
Is recover an alternative to writing
if err != nil
every 5 lines?You can use panic/recover inside your library if you want to handle exceptions that way, but it's recommended that panics never leave your library's scope unless something horrible has happened that can't be recovered from.
-
@ben_lubar said in Enlightened:
panic/recover/defer, which are roughly equivalent to try/catch/finally
So you panic every time you try something? Sounds like an anxiety disorder.
@ben_lubar said in Enlightened:
Go
Yup! A disorder that causes anxiety in its victims.
-
@hardwaregeek said in Enlightened:
@ben_lubar said in Enlightened:
panic/recover/defer, which are roughly equivalent to try/catch/finally
So you panic every time you try something? Sounds like an anxiety disorder.
@ben_lubar said in Enlightened:
Go
Yup! A disorder that causes anxiety in its victims.
Ok, panic is more like throw and recover has to be inside a finally, but still.
-
Rust also has no exceptions and uses panics. Except Rust's panics are truly unrecoverable (for the most part), so people never use them unless they literally have no other choice (which makes Rust programs crash less). Also, they managed to reduce manual error check boilerplate to one character.
-
@gąska said in Enlightened:
Rust also has no exceptions and uses panics. Except Rust's panics are truly unrecoverable (for the most part)
Which means that they won't be using them for handling errors originating in the OS. Which makes writing good I/O code irritating.
-
@dkf Well, no, not really; Rust's exception handling model is to return a
Result<T, E>
instead of returning aT
. And then you canunwrap
orexpect
to force a panic if it's an error, or use amatch
statement or theis_err
method.panic
s are used in a state that it can't expect to recover from;Result
s are when it can. I prefer it to exceptions. You actually can catch an unwinding panic if it's in a separate thread that you still have the handle to.
-
@pie_flavor said in Enlightened:
I prefer it to exceptions.
They're pretty much equivalent at the level of semantics; in a language like Java or C#, all methods effectively return a
Result<…>
but hide that they do. The semantics of exceptions is actually really quite well-defined (and couples into the concepts of monads that the Haskell crowd like). The low-level rendering of what to do with it is a little different, but that's in the area of compiler output and as long as it is correct w.r.t. the language semantics and is reasonably fast, the exact instruction sequence is not hugely interesting.As has been previously noted, I'm on a team writing an optimising compiler. Exception handling is one of the things we think about quite a lot…
-
@dkf the main difference is whether you want to be annoyed at compile time or at runtime when you forget to handle an error. Go and Rust pick compile time, C# and Java pick runtime.
-
@dkf Well, the problem with exceptions is that if you have them, that's all you have. A recoverable error, like int-parsing, does not need some big complicated stack trace which takes up way too much processing; all you need is the error type. With Rust, you have the Result pattern meaning you can easily pattern-match your way out and never need to unwind; with C# you have the try-out pattern, meaning you can use return values as your error states and out parameters as your return values; with Java you have nothing except the echoing of your CPU's pleas for mercy.
-
@pie_flavor said in Enlightened:
with Java you have nothing except the echoing of your CPU's pleas for mercy.
With JavaScript you have at least three different incompatible error handling methods.
-
-
@ben_lubar said in Enlightened:
With JavaScript you have at least three different incompatible error handling methods.
Specially fun if you forget to resolve or reject your promises.
-
@swayde said in Enlightened:
@ben_lubar said in Enlightened:
Java
With java you always get both. Fucking checked exceptions.
@SuppressWarnings("unchecked") public class Throw { public interface UncheckedVoid { void run() throws Throwable; } public <T extends Throwable> void v(Throwable t) throws T { throw (T) t; } public <T extends Throwable, V> V t(Throwable t) throws T { throw (T) t; } public <T extends Throwable, V> V unchecked(Callable<V> c) throws T { try { return c.call(); } catch (Throwable t) { throw (T) t; } } public <T extends Throwable> void uncheckedV(UncheckedVoid v) throws T { try { v.run(); } catch (Throwable t) { throw (T) t; } } }
Never deal with checked exceptions again!
-
@pie_flavor I'm happily not coding java anymore.
But I did consider than. Iirc it ruins the stack trace when you actually get an exception.
-
@scholrlea said in Enlightened:
@cursorkeys said in Enlightened:
Also, lack of beavers.
You're just walking right into this one, aren't you?
Is there a joke there that I'm ing?
-
@swayde said in Enlightened:
@pie_flavor I'm happily not coding java anymore.
But I did consider than. Iirc it ruins the stack trace when you actually get an exception.Only for the outermost exception. If you have code that will check the inner exception(s) as well, then you can get as far into the stack trace as you like:
try { doSomethingThatThrows(); } catch(Throwable t) { Throwable tt = t; while(tt != null) { tt.printStackTrace(); tt = tt.getCause(); } }
-
@djls45 Prolly the second definition of 'beaver' on UD.
-
@swayde said in Enlightened:
@pie_flavor I'm happily not coding java anymore.
But I did consider than. Iirc it ruins the stack trace when you actually get an exception.No, the exception keeps going. Java fills in the stack trace when the exception is constructed, not when it's thrown, and this isn't modifying it.
-
@pie_flavor said in Enlightened:
A recoverable error, like int-parsing, does not need some big complicated stack trace which takes up way too much processing; all you need is the error type.
Let's just skip to the chase here, and say that the real issue is that a failure can be a recoverable in some circumstances and not others. (Interactions with the OS have a nasty habit of being like that.) Or sometimes they are potentially recoverable using higher-level application logic, but not in the low-level context where they're encountered, yet if the code doesn't handle the cases, the stack trace is intensely useful in debugging. It's a tricky trade-off as it depends on whether you value local concerns, global concerns or system-creation concerns most. (Long experience makes me think that making programmers productive is the best sustainable plan.)
FWIW, if one does whole-program optimisation, it is possible to not generate the stack trace at all when it wouldn't be used, making exceptions enormously cheaper. I don't think that that's something that is frequently done at the moment — link-time optimisation is well known for being crazy-expensive — but it is one of the more interesting options for speeding up exception-heavy programming languages.
-
@pie_flavor said in Enlightened:
Java fills in the stack trace when the exception is constructed
Strictly, it calls the exception's
fillInStackTrace()
method in the constructor, which is the sole truly expensive part of building and throwing an exception. You can call this at another time as well if you want to use a different stack trace, or you can override it to not fill in the stack trace at all if you're mad enough to want to use exceptions for flow control (and I've just read about a use-case where this even made sense; it was something to do with lock management and AOP).
-
Oh, it's that time of year for another error result vs exception fight.
-
@dkf What the fuck are you talking about and why are you doing it in this thread.
-
@blakeyrat If it really bothers you that much, flag the initiating post for jeffing to another thread.
-
-
@djls45 Yes everybody is a dick, forcing me to ignore threads I really do want to keep track of by filling them up with the most BORING conversations imaginable by man, and therefore EVERYBODY OTHER THAN THE DICKS has to do work to fix things. That makes perfect logical sense.
Hey I have a better idea: why don't people STOP BEING DICKS and spend the 0.1 seconds it takes to hit the "new topic" button, what the fuck is wrong with you dicks. Or, just a thought, maybe not have 50,000 post conversations about fucking exception handling! Because that's the most boring thing to talk about ever!
-
-
@blakeyrat said in Enlightened:
Because that's the most boring thing to talk about ever!
I take it you haven't seen the ginger beer thread about food product labelling regulations in the EU
-
@blakeyrat said in Enlightened:
@djls45 Yes everybody is a dick, forcing me to ignore threads I really do want to keep track of by filling them up with the most BORING conversations imaginable by man, and therefore EVERYBODY OTHER THAN THE DICKS has to do work to fix things. That makes perfect logical sense.
You know what's even more boring than arguing about exceptions? Your rants.
-
@timebandit said in Enlightened:
@blakeyrat said in Enlightened:
STOP BEING DICKS
STOP ASSUMING OUR GENDER !!!
NOT ALL DICKS ARE MEN
-
@jaloopa said in Enlightened:
@timebandit said in Enlightened:
@blakeyrat said in Enlightened:
STOP BEING DICKS
STOP ASSUMING OUR GENDER !!!
NOT ALL DICKS ARE MEN
#NotAllDicks
-
@bb36e said in Enlightened:
@blakeyrat said in Enlightened:
Because that's the most boring thing to talk about ever!
I take it you haven't seen the ginger beer thread about food product labelling regulations in the EU
It's got a nice picture at the end, though.
-
@dkf said in Enlightened:
FWIW, if one does whole-program optimisation, it is possible to not generate the stack trace at all when it wouldn't be used, making exceptions enormously cheaper. I don't think that that's something that is frequently done at the moment — link-time optimisation is well known for being crazy-expensive — but it is one of the more interesting options for speeding up exception-heavy programming languages.
This seems like one of those "pick a better algorithm" times where if exception handling is a performance problem then you have bigger problems.