He lost the difference between what it was worth to him and what he got by selling it. If this was not a loss, then he would have sold it spontaneously, which he obviously didn't.
Don't forget the taxes. If he claims this is a forced sale then he saves $300M on taxes. That could put a dent into that "loss", maybe turn it into a "win".
I have a BofA credit card in California.
I went to Seattle for the weekend and BofA blocked my credit card.
BofA is terrible.
I'm going to Europe in a few days. I called them to tell them I'm traveling. I don't have high expectations that they won't block my card again. I have other cards.
Don't know if it matters but I called the fraud related number on the statement... good luck
About 8 years... they were just replacing people's cards for the hell of it...
Did the number change? I got an unexpected card replacement around then too and noticed the number had changed. I assumed there was a security breach somewhere and it was being handled quietly,
>Or call your credit card company before you leave and say you will be traveling in country X on these days.
Tried that. They still blocked the card after my first transaction abroad.
You are making the mistake of thinking banks have processes that meet your needs, rather than their needs.
They need you to use your credit card to make the real money in fees, so their needs and your needs are aligned in this respect. Sounds more like a run of the mill screwup.
FWIW I called the **fraud related** number on my statement a few days before the trip. Maybe that increases the chance of success.
A lot of people don't travel with their phones to foreign countries because it's too damn expensive.
AT&T lets you turn international roaming on and off on a monthly basis. Last time I traveled I turned it on for one month.
It may not be as cost effective as getting a local phone or sim but its pretty damn convenient, especially if not using many minutes or MB when traveling. At least for a business trip I made to Europe a few years ago.
Actually, Apple had been working hard for years to replace it, sort of like Longhorn for Windows. They wound up using NeXT software instead. MacOS was getting quite embarrassing technically.
Yeah, I recall Apple's Copland and Gershwin projects, internal attempts at a Mac OS replacement. I also recall running MkLinux and Rhapsody, Apple's development version of Mac OS X.
I also remember the CHRP project which Apple abandoned, further delaying the arrival of that mythical piece of hardware that could run Windows or Mac OS.
Man, Apple was just so full of disappointments in the mid to late 90s. I am so glad they eventually got their sh*t together and went NeXT and Intel. I remember NeXT workstations in college, fun stuff.
A friend was visiting Asia and in one "market", on a parking garage's underground lower level, a "vendor" was offering iPads. The box looked just like a real iPad box. Inside the tablet looked just like a real iPad. However when powered up it was an Android tablet. I saw his photos, the box and tablet were good counterfeits.
Perhaps this is occurring with phones too and Cook's jobs is perhaps true for some people. They accidentally bought Android due to counterfeiting.:-)
Don't this code have the problem that you call some_work from the gui thread, and thus will block all updates of the graphics userinterface while some_work is running?
The parent objective-c UI event handler (buttonPressed) has the same constraints as the child C function (some_work). Both should do very very little themselves and/or have a background thread do the work.
Here is a Mac OS X GUI app with a window and a button implemented in objective-c (main.h, AppDelegate.h and AppDelegate.m). The button handler calls C code (Work.h and Work.c) to do some work. Note that if C++ code had been used then AppDelegate.m would have been renamed to.mm so that Xcode would compile it as Objective-C++, necessary to link properly against the C++ code it uses.
I have absolutely no compatibility problems. I strictly use objective-c for only user interface code. The core functional application code is written in c/c++. I have multiple iOS/Android apps whose core code is shared and can even be compiled with a console app under Mac OS X or Linux, I use this for regression testing and fuzzing. A headless Linux box in the closet exercises this core code. Similar story for Mac OS X and Windows.
Swift code can replace objective-c code and it matters little to me. Has zero impact on other platforms I target.
Admittedly I've ported other people's code between Windows, Mac and Linux for years and written my own code for Windows, Mac and Linux for years and as a result I am extremely aggressive about separating UI code from functional code.
For those people using some sort of cross-platform wrapper for their project, if it supports Mac OS X objective-c it will probably support Swift. Even if it takes time for the wrapper developers so what, the use of Swift is entirely optional.
case superset:
{ init superset specific stuff }/* fall through to base for common initialization */
case base:
{ init stuff common to base and superset }
break;
It's not useful at all. The times you deliberately want to fall through are vastly outnumbered by the times you don't. So rather than have a keyword to stop fall-though it makes more sense to have one that causes fall-through.
No. If going in your direction both break and fallthrough statements should be required. Assuming no statement is equivalent to break rather than fallthrough makes no sense. At least no statement being equivalent to fallthrough makes some sense.
Your code would be:
case superset:
{ init superset specific stuff }
fallthrough;
case base:
{ init stuff common to base and superset }
The result is better readability. Less lines of code. And many fewer bugs. For exactly the same functionality and execution speed.
There is no better readability. You reformatted my code incorrectly. Note in my original post the comment about the fall through was on its own line, precisely where your fallthrough statement is, intentionally where a break statement would normally be so that the lack of a break is shown to be intentional.
case superset:
{ init superset specific stuff } /* fall through to base for common initialization */
case base:
{ init stuff common to base and superset }
break;
And removing a comment hardly qualifies as one less line of code.:-)
Are you sure? Based on Apple's history, they sure don't seem to mind replacing huge parts of their infrastructure while completely deprecating the old:
Mac OS 9 to Mac OS X
Are you kidding? Mac OS classic was 16 years old, barely had cooperative multitasking and made Windows NT look good. It was embarrassingly obsolete when OS 9 was being launched and should have been replaced and deprecated years earlier. Not replacing it earlier was one of Apple's great historical failures.
... ahh... I feel better now. To end on a positive, at least it was 32-bit.
Bullshit. There is plenty wrong with plain C. For example there is no defending fall-through by default between cases in switch statements.
Actually that is a quite useful feature allowing for the sharing of code, which improves robustness. Sometimes two consecutive cases are related, maybe one a "superset" of the other. Have the superset fall into the base lets them share code.
case superset:
{ init superset specific stuff } /* fall through to base for common initialization */
case base:
{ init stuff common to base and superset }
break;
In theory but not in practice. One of the earliest, if not the first widely deployed fly-by-wire, was the F-16. The number of F-16s lost to enemy action was very small compared to those lost due to mechanical/electronics malfunction.
Yes ejection seats predate fly-by-wire but they certainly made fly-by-wire early adoption a lot easier.
Does that mean that if one of those actuators or logic board malfunctions, that it could steer a car into traffic?
Or becomes unresponsive when the key disengages, like power steering in the recent GM recall scandal? At least there steering only became difficult. They are going to have to power the system as long as the wheels are turning.
I don't see the problem. You have repeatability if the qa/remote crash report includes the randomization seed used for the remote binary. That binary and debugger info gets recreated when you recompile with the seed. It seems a minor inconvenience, although it would be disturbing to see the assembly change every debug session if one is going to that level.
Who is advocating any particular faith? I'm just pointing out that some Atheists act in a very religious like manner by believing in something without any evidence. Believing that there is no God is as much an act of faith as believing that there is. The more scientific belief is the Agnostic one, that the answer is unknown due to a lack of evidence.
What kinds of bugs do you think would manifest earlier using this technique...
The GP mentioned a randomized stack. An uninitialized variable would be one, something that often accidentally has a value that does no harm (a zero possibly).
... and why do you think that earlier manifestation of that class of bugs will outweigh the tremendous burden of chasing down all the heisenbugs that only occur on some small percentage of randomized builds?
You do realize that your argument for the status quo and not dealing with the "heisenbugs" is essentially arguing to leave a coding bug in place? Recompiling will not necessarily introduce new bugs, rather change the behavior of existing bugs.
I've seen many of the sort of bugs this recompiling technique may expose, I spent some years porting software between different architectures. Not only did we have different compilers but we had different target CPUs. It was a friggin awesome environment for exposing unnoticed bugs. Software that had run reliably under internal testing for weeks on its original platform failed immediately when run on a second platform. And it kept failing immediately after several crashing bugs were fixed. The original developers, who were actually quite skilled, looked at several of the bugs eventually found and wondered how the program ever ran at all. I've seen this repeated on multiple teams at multiple companies over the years.
Also developers working on one platform eventually learned to visit a colleague working on the "other" platform when they had a bug that was hard to reproduce. There was a good chance that a hard to manifest bug on one platform would be easier to reproduce on the other.
There is nothing like cross platform development to help shake out bugs.
This recompilation idea would seem to offer some of these same benefits. Yes it complicates reproducibility of crashes in the field but if one can get a recompilation seed with that crash dump/log its more like of dealing with an extra step not some impossible hurdle.
Plus recompiling with a different seed each time the developer does a test run at their workstation could help find bugs in the first place, reducing the occurrences of these pesky crashes in the field.
I'm not saying these proposed recompilations in the field are definitely a good idea, just that the negatives seem to be exaggerated. It looks like something interesting, worth looking into a bit more.
..would a professor of CompSci think this is a good idea, despite the hundreds of problems it *causes* with existing practices and procedures? Oh, wait.. maybe because the idea is patented and he'll get paid a lot. http://www.google.com/patents/...
As an employee of the University of California a professor is *required* to report any discovery or method that *might* be patentable to the University.
The University takes it from there, it has an office that researches viability, handles the process and then licenses the patents to "industry". With respect to licensing small local companies are given a better deal than larger internationals. As for the licensing fees collected, 50% goes to the University, 25% to the department (UC Irvine's Computer Science department in this case) and 25% to the employee(s).
At least that is how it was a few years ago when I was a grad student at UC.
Well no end user deals with Visa directly. You have to go through an intermediary, usually a bank, and Paypal is one of the intermediaries you can use.
I'm referring to funding my PayPal account via VISA or ACH, as I can fund an online BitCoin wallet via VISA or ACH.
Why does your faith in G*d preclude accepting Darwin's theory of evolution as valid? Genesis tells us what G*d did, not how she did it.
Various Christian denominations and churches accept evolution, accept cosmology, accept genetics,...
Hell the Big Bang Theory was introduced by a Catholic Priest while teaching at a Catholic University.
Slashdot Mirror
He lost the difference between what it was worth to him and what he got by selling it. If this was not a loss, then he would have sold it spontaneously, which he obviously didn't.
Don't forget the taxes. If he claims this is a forced sale then he saves $300M on taxes. That could put a dent into that "loss", maybe turn it into a "win".
I have a BofA credit card in California. I went to Seattle for the weekend and BofA blocked my credit card. BofA is terrible. I'm going to Europe in a few days. I called them to tell them I'm traveling. I don't have high expectations that they won't block my card again. I have other cards.
Don't know if it matters but I called the fraud related number on the statement ... good luck
About 8 years ... they were just replacing people's cards for the hell of it ...
Did the number change? I got an unexpected card replacement around then too and noticed the number had changed. I assumed there was a security breach somewhere and it was being handled quietly,
>Or call your credit card company before you leave and say you will be traveling in country X on these days.
Tried that. They still blocked the card after my first transaction abroad. You are making the mistake of thinking banks have processes that meet your needs, rather than their needs.
They need you to use your credit card to make the real money in fees, so their needs and your needs are aligned in this respect. Sounds more like a run of the mill screwup.
FWIW I called the **fraud related** number on my statement a few days before the trip. Maybe that increases the chance of success.
A lot of people don't travel with their phones to foreign countries because it's too damn expensive.
AT&T lets you turn international roaming on and off on a monthly basis. Last time I traveled I turned it on for one month.
It may not be as cost effective as getting a local phone or sim but its pretty damn convenient, especially if not using many minutes or MB when traveling. At least for a business trip I made to Europe a few years ago.
Or call your credit card company before you leave and say you will be traveling in country X on these days.
Actually, Apple had been working hard for years to replace it, sort of like Longhorn for Windows. They wound up using NeXT software instead. MacOS was getting quite embarrassing technically.
Yeah, I recall Apple's Copland and Gershwin projects, internal attempts at a Mac OS replacement. I also recall running MkLinux and Rhapsody, Apple's development version of Mac OS X.
I also remember the CHRP project which Apple abandoned, further delaying the arrival of that mythical piece of hardware that could run Windows or Mac OS.
Man, Apple was just so full of disappointments in the mid to late 90s. I am so glad they eventually got their sh*t together and went NeXT and Intel. I remember NeXT workstations in college, fun stuff.
... Cook's jobs ...
Cook's joke.
:-)
What would Freud say about that typo?
A friend was visiting Asia and in one "market", on a parking garage's underground lower level, a "vendor" was offering iPads. The box looked just like a real iPad box. Inside the tablet looked just like a real iPad. However when powered up it was an Android tablet. I saw his photos, the box and tablet were good counterfeits.
:-)
Perhaps this is occurring with phones too and Cook's jobs is perhaps true for some people. They accidentally bought Android due to counterfeiting.
Don't this code have the problem that you call some_work from the gui thread, and thus will block all updates of the graphics userinterface while some_work is running?
The parent objective-c UI event handler (buttonPressed) has the same constraints as the child C function (some_work). Both should do very very little themselves and/or have a background thread do the work.
Here is a Mac OS X GUI app with a window and a button implemented in objective-c (main.h, AppDelegate.h and AppDelegate.m). The button handler calls C code (Work.h and Work.c) to do some work. Note that if C++ code had been used then AppDelegate.m would have been renamed to .mm so that Xcode would compile it as Objective-C++, necessary to link properly against the C++ code it uses.
// main.m
#import <Cocoa/Cocoa.h>
int main(int argc, const char * argv[]){
return NSApplicationMain(argc, argv);
}
// AppDelegate.h
#import <Cocoa/Cocoa.h>
@interface AppDelegate : NSObject <NSApplicationDelegate>
@property (assign) IBOutlet NSWindow *window;
@end
// AppDelegate.m
#import "AppDelegate.h"
#include "Work.h"
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
}
- (IBAction)buttonPressed:(id)sender {
some_work();
}
@end
// Work.h
void some_work(void);
// Work.c
#include <stdio.h>
#include "Work.h"
void some_work(void) {
FILE *fp = fopen("/tmp/work.txt", "w");
if (fp != NULL) {
fprintf(fp, "Hello World\n");
fclose(fp);
}
}
Good bye source compatibility. We hardly knew ye.
I have absolutely no compatibility problems. I strictly use objective-c for only user interface code. The core functional application code is written in c/c++. I have multiple iOS/Android apps whose core code is shared and can even be compiled with a console app under Mac OS X or Linux, I use this for regression testing and fuzzing. A headless Linux box in the closet exercises this core code. Similar story for Mac OS X and Windows.
Swift code can replace objective-c code and it matters little to me. Has zero impact on other platforms I target.
Admittedly I've ported other people's code between Windows, Mac and Linux for years and written my own code for Windows, Mac and Linux for years and as a result I am extremely aggressive about separating UI code from functional code.
For those people using some sort of cross-platform wrapper for their project, if it supports Mac OS X objective-c it will probably support Swift. Even if it takes time for the wrapper developers so what, the use of Swift is entirely optional.
case superset : /* fall through to base for common initialization */ :
{ init superset specific stuff }
case base
{ init stuff common to base and superset }
break;
It's not useful at all. The times you deliberately want to fall through are vastly outnumbered by the times you don't. So rather than have a keyword to stop fall-though it makes more sense to have one that causes fall-through.
No. If going in your direction both break and fallthrough statements should be required. Assuming no statement is equivalent to break rather than fallthrough makes no sense. At least no statement being equivalent to fallthrough makes some sense.
Your code would be:
case superset : :
{ init superset specific stuff }
fallthrough;
case base
{ init stuff common to base and superset }
The result is better readability. Less lines of code. And many fewer bugs. For exactly the same functionality and execution speed.
There is no better readability. You reformatted my code incorrectly. Note in my original post the comment about the fall through was on its own line, precisely where your fallthrough statement is, intentionally where a break statement would normally be so that the lack of a break is shown to be intentional.
:
/* fall through to base for common initialization */ :
:-)
case superset
{ init superset specific stuff }
case base
{ init stuff common to base and superset }
break;
And removing a comment hardly qualifies as one less line of code.
Are you sure? Based on Apple's history, they sure don't seem to mind replacing huge parts of their infrastructure while completely deprecating the old:
Mac OS 9 to Mac OS X
Are you kidding? Mac OS classic was 16 years old, barely had cooperative multitasking and made Windows NT look good. It was embarrassingly obsolete when OS 9 was being launched and should have been replaced and deprecated years earlier. Not replacing it earlier was one of Apple's great historical failures.
... ahh ... I feel better now. To end on a positive, at least it was 32-bit.
Bullshit. There is plenty wrong with plain C. For example there is no defending fall-through by default between cases in switch statements.
Actually that is a quite useful feature allowing for the sharing of code, which improves robustness. Sometimes two consecutive cases are related, maybe one a "superset" of the other. Have the superset fall into the base lets them share code.
:
/* fall through to base for common initialization */ :
case superset
{ init superset specific stuff }
case base
{ init stuff common to base and superset }
break;
They also had people shooting at them...
In theory but not in practice. One of the earliest, if not the first widely deployed fly-by-wire, was the F-16. The number of F-16s lost to enemy action was very small compared to those lost due to mechanical/electronics malfunction.
Yes ejection seats predate fly-by-wire but they certainly made fly-by-wire early adoption a lot easier.
Does that mean that if one of those actuators or logic board malfunctions, that it could steer a car into traffic?
Or becomes unresponsive when the key disengages, like power steering in the recent GM recall scandal? At least there steering only became difficult. They are going to have to power the system as long as the wheels are turning.
I'm pretty sure designers of fly-by-wire airplanes have already solved the problem. ;-)
Yes, they had ejection seats for the first couple of decades of fly-by-wire. ;-)
I don't see the problem. You have repeatability if the qa/remote crash report includes the randomization seed used for the remote binary. That binary and debugger info gets recreated when you recompile with the seed. It seems a minor inconvenience, although it would be disturbing to see the assembly change every debug session if one is going to that level.
I mean how the costs don't outweight the benefits. Dammit, I always proof-read what i think I wrote, not what I actually wrote.
Me too. That is when I bother to proofread. :-)
Who is advocating any particular faith? I'm just pointing out that some Atheists act in a very religious like manner by believing in something without any evidence. Believing that there is no God is as much an act of faith as believing that there is. The more scientific belief is the Agnostic one, that the answer is unknown due to a lack of evidence.
What kinds of bugs do you think would manifest earlier using this technique ...
The GP mentioned a randomized stack. An uninitialized variable would be one, something that often accidentally has a value that does no harm (a zero possibly).
... and why do you think that earlier manifestation of that class of bugs will outweigh the tremendous burden of chasing down all the heisenbugs that only occur on some small percentage of randomized builds?
You do realize that your argument for the status quo and not dealing with the "heisenbugs" is essentially arguing to leave a coding bug in place? Recompiling will not necessarily introduce new bugs, rather change the behavior of existing bugs.
I've seen many of the sort of bugs this recompiling technique may expose, I spent some years porting software between different architectures. Not only did we have different compilers but we had different target CPUs. It was a friggin awesome environment for exposing unnoticed bugs. Software that had run reliably under internal testing for weeks on its original platform failed immediately when run on a second platform. And it kept failing immediately after several crashing bugs were fixed. The original developers, who were actually quite skilled, looked at several of the bugs eventually found and wondered how the program ever ran at all. I've seen this repeated on multiple teams at multiple companies over the years.
Also developers working on one platform eventually learned to visit a colleague working on the "other" platform when they had a bug that was hard to reproduce. There was a good chance that a hard to manifest bug on one platform would be easier to reproduce on the other.
There is nothing like cross platform development to help shake out bugs.
This recompilation idea would seem to offer some of these same benefits. Yes it complicates reproducibility of crashes in the field but if one can get a recompilation seed with that crash dump/log its more like of dealing with an extra step not some impossible hurdle.
Plus recompiling with a different seed each time the developer does a test run at their workstation could help find bugs in the first place, reducing the occurrences of these pesky crashes in the field.
I'm not saying these proposed recompilations in the field are definitely a good idea, just that the negatives seem to be exaggerated. It looks like something interesting, worth looking into a bit more.
..would a professor of CompSci think this is a good idea, despite the hundreds of problems it *causes* with existing practices and procedures? Oh, wait.. maybe because the idea is patented and he'll get paid a lot.
http://www.google.com/patents/...
As an employee of the University of California a professor is *required* to report any discovery or method that *might* be patentable to the University.
The University takes it from there, it has an office that researches viability, handles the process and then licenses the patents to "industry". With respect to licensing small local companies are given a better deal than larger internationals. As for the licensing fees collected, 50% goes to the University, 25% to the department (UC Irvine's Computer Science department in this case) and 25% to the employee(s).
At least that is how it was a few years ago when I was a grad student at UC.
Well no end user deals with Visa directly. You have to go through an intermediary, usually a bank, and Paypal is one of the intermediaries you can use.
I'm referring to funding my PayPal account via VISA or ACH, as I can fund an online BitCoin wallet via VISA or ACH.
Why does your faith in G*d preclude accepting Darwin's theory of evolution as valid? Genesis tells us what G*d did, not how she did it.
Various Christian denominations and churches accept evolution, accept cosmology, accept genetics, ...
Hell the Big Bang Theory was introduced by a Catholic Priest while teaching at a Catholic University.