Unfortunately, for clean-room reverse engineering to work there must be an abstraction layer betwen the team doing the reverse engineering to write up protocol specifics and the team doing the implementation. Otherwise it is possible to argue contamination.
This will compile just fine. Remember that List != List in C#, even when you substitute for , since the first is [].List and the second is [].List`1, with runtime binding to
What are you talking about? You have one returning an int and the other returning a void. That is why I asked. Guesing you meant to return an int in the second one as well, so not as excited as I was when I first saw it.
Tom, guaranteed finalizers lead to issues. Example:
gcroot ->... some path 1... -> A { B { "I am a DB connection to localhost:3361" } }
gcroot ->... some path 2... -> B
You get rid of last pointer to A and run the finalizer. In your finalizer you decide to clean up B. But you have no way to know whether B is pointed to by another object.
You could make the argument that you should not clean up objects outside of their own finalizer. But then what are you cleaning up? Any change to state external to the object can screw something up due to an unexpected gcroot path, and any change to state internal to the object should not matter at all. I can see the argument that you could have resources that you never shared outside of the closure of the object you are finalizing but do you really want that enforced at compile-time? Otherwise you lose the memory-safety that having a GC guarantees you.
I am not saying this cannot be done, but simply arguing that not having it is a terrible flaw is not productive either. There were good reasons behind making the choice to have Finalizers not be guaranteed in JVM (and CLR for that matter).
Not sure I agree with your statement about no "jvm" that can handle multiple programs at once. Simply implement a classloader (provided you know what you are doing, and know how to avoid leaking types), and fork a thread to run each [entry].main(args) in the context of their own classloader. If you implement a classloader heirarchy you can avoid having to load the JRE classes more than once. When the thread exits, dump the classloader. Did I miss some important constraints here?
The one caveat to this is that different processor architectures have different performane characteristics, so while the base code will run (sans JS-JIT, which is architecture dependent), likely memory mangement and arithmetic would be recoded for performance reasons.
You can hide it so only the tabs are visible at any given point of time - though you would have to make an extra click to access any of the functionality. That said, pixel-wise it is not using that much more space than the default menu + 2x toolbar that office applications typically started out with on modest-sized displays.
The funny thing is, as soon as that OS gets a commanding marketshare, the floodgates will open, and its manufacturer will be sued into oblivion (or at least into creating dozens of "ballot" screens)
They do not replace the right context menu in all cases - but I would imagine that MS would simply use the old click-(tap)-and-hold paradigm they had since the stylus days for alternate-click.
Given that the Ribbon works with Alt-based mnemonics, and provides quite a bit of visual feedback (which is better than the old menu system because you have nice tooltip-style popups, rather than trying to scrounge around for the underlining of a character) and are just as customizable as toolbars and menu bars (in the Office suite of applications, at least) I am having a hard time grasping what features of the interface itself (menus and toolbars) have been removed. The only one I can think of is moving and docking the toolbars.
I dunno about that - the PDF spec, with its multitude of Turing-complete runtimes, ability to hide absolutely arbtrary byte streams, have access to the filesystem and ability to *invoke commands outside of the PDF viewer* is a pretty big security hole. You must be thinking of some of the ISO PDF variants which omit these "features."
When there are more than 15, metadata is hidden, since a lot of it involves doing "deep" file inspection which can be slow. That said, they could have made size always visible since that it part of the FS metadata and is generally fast to access regardless of what is selected - like they do with the number of items.
You can enable the Run command in the Start Menu settings. However, it is likely that they noticed that most of thier users never use it - and a fair number can use the searchbox as a pseudo-Run.
You can also enable Network in the Start Menu settings.
Yes they did remove them from the default. I doubt many non "power" users were actively using either (maybe Network, but that is a stretch, and the new idea is for that group to be using Homegroup instead - and yes, Homegroup sucks, quite hard, in its current incarnation), and "power" users should be capable of right clicking in the taskbar, hitting "Properties," navigating to the "Start Menu" tab and hitting the "Customize" button.
I cannot speak for Southwest, since I do not remember how it works with GDS, but American at least offers its tickets through the GDS system - though they do not pay commissions.
One thing to consider, though, is that since people coming to their site from Kayak/ITA-powered searches can go directly to the flight that was found, the traffic is much more likely to do a booking than a general search for "flights" yielding an American or Southewest ad on Google. At that point, Google or Kayak can start demanding a toll for that traffic (lead-generation price), with the stick being that they would instead shunt that traffic to competitors' flights instead. And since Google and Kayak have a lot of eyeballs, it is a no-brainer for the airlines to pay for lead generation.
The problem with your query is that ITA (and the other GDS systems) have to query the individual airline systems to get at the rates - and caching is not effective except as at a "best effort/guess" basis, because rates change dynamically according to algorithms known only to the airlines themselves. That is why, as one gets closer to the date, the cost for any given ticket (same flight/seat-class) increases. This makes it completely ineffective to do a search like you suggest - you would only be able to get the engine's best guess, and it would only be applicable for a given day, or would not be applicable to any given day, but be an average for all days.
Keep in mind, to do a single flight search across the various GDS' that Expedia is connected to, for example, takes on the order of 15 seconds. To answer your queries would require doing either all 68808 searches for round-trip, or 712 (if you are doing single flights and trying to manually connect them) searches. And that data would only be valid for a rather short interval of time, since flights can be sold out at any time, as as a flight gets closer to being sold out, ticket prices for that flight rise automatically.
Google buying ITA will not magically improve this. The airlines realized that they are holding all the cards right now, which means that the little battle-of-wills they have going on between them and the GDSes is heavily skewed towards the airlines. There is a reason there is no longer any money to be made in commissions selling flights through GDS; lead generation is where money is being made (or dynamic packaging, but that is a completely different beast altogether), and that is where I imagine Google is going to go - which is why Kayak was so vocal about this move, since it would, in effect, be cutting them out of the equation - it used to be Kayak buys adwords for particular destinations, generates the search and collects lead generation fees from the airlines by forward to their (or some OTA) site. What Google proposes to do now is skip the first step - granted they will be losing adword revenue if their organic results increase in quality - but will be gaining lead-generation revenue, which likely offsets it, since the traffic funnel is much more qualified than the adword traffic may have been.
Sorry for the ramble/stream-of-consciousness; been a bit frustrated with GDS systems over the past week, having to rewrite a fair bit of interfacing code.
Slashdot Mirror
Extra points when the same road is Route X North, and Route Y South for some stretches.
The way you describe it, it sounds like their gui designer was purged some time ago.
Unfortunately, for clean-room reverse engineering to work there must be an abstraction layer betwen the team doing the reverse engineering to write up protocol specifics and the team doing the implementation. Otherwise it is possible to argue contamination.
The story was DRMed until now.
'1234'? That's the password on my luggage!
This will compile just fine. Remember that List != List in C#, even when you substitute for , since the first is [].List and the second is [].List`1, with runtime binding to
int myProperty(){ return mp; }
void myProperty(int i){ mp = i; }
What are you talking about? You have one returning an int and the other returning a void. That is why I asked. Guesing you meant to return an int in the second one as well, so not as excited as I was when I first saw it.
Tom, guaranteed finalizers lead to issues. Example:
gcroot -> ... some path 1 ... -> A { B { "I am a DB connection to localhost:3361" } } ... some path 2 ... -> B
gcroot ->
You get rid of last pointer to A and run the finalizer. In your finalizer you decide to clean up B. But you have no way to know whether B is pointed to by another object.
You could make the argument that you should not clean up objects outside of their own finalizer. But then what are you cleaning up? Any change to state external to the object can screw something up due to an unexpected gcroot path, and any change to state internal to the object should not matter at all. I can see the argument that you could have resources that you never shared outside of the closure of the object you are finalizing but do you really want that enforced at compile-time? Otherwise you lose the memory-safety that having a GC guarantees you.
I am not saying this cannot be done, but simply arguing that not having it is a terrible flaw is not productive either. There were good reasons behind making the choice to have Finalizers not be guaranteed in JVM (and CLR for that matter).
Aside: @ /. : WTB <pre> tag support.
Language features in general are great until you have to code with other people.
Lack of them is no substitude for good conventions and process when working on a team.
So, I am curious, how do you deal with exceptions without SmartPointers? Or do you wrap every function block in a try{}/catch{throw} block?
Not sure I agree with your statement about no "jvm" that can handle multiple programs at once. Simply implement a classloader (provided you know what you are doing, and know how to avoid leaking types), and fork a thread to run each [entry].main(args) in the context of their own classloader. If you implement a classloader heirarchy you can avoid having to load the JRE classes more than once. When the thread exits, dump the classloader. Did I miss some important constraints here?
+1. That is the single greatest switch in existence.
Since when can Java do method return overloading?
The one caveat to this is that different processor architectures have different performane characteristics, so while the base code will run (sans JS-JIT, which is architecture dependent), likely memory mangement and arithmetic would be recoded for performance reasons.
You must be confused. Clearly PJ is Watson v0.1
You can hide it so only the tabs are visible at any given point of time - though you would have to make an extra click to access any of the functionality. That said, pixel-wise it is not using that much more space than the default menu + 2x toolbar that office applications typically started out with on modest-sized displays.
The funny thing is, as soon as that OS gets a commanding marketshare, the floodgates will open, and its manufacturer will be sued into oblivion (or at least into creating dozens of "ballot" screens)
They do not replace the right context menu in all cases - but I would imagine that MS would simply use the old click-(tap)-and-hold paradigm they had since the stylus days for alternate-click.
Given that the Ribbon works with Alt-based mnemonics, and provides quite a bit of visual feedback (which is better than the old menu system because you have nice tooltip-style popups, rather than trying to scrounge around for the underlining of a character) and are just as customizable as toolbars and menu bars (in the Office suite of applications, at least) I am having a hard time grasping what features of the interface itself (menus and toolbars) have been removed. The only one I can think of is moving and docking the toolbars.
I dunno about that - the PDF spec, with its multitude of Turing-complete runtimes, ability to hide absolutely arbtrary byte streams, have access to the filesystem and ability to *invoke commands outside of the PDF viewer* is a pretty big security hole. You must be thinking of some of the ISO PDF variants which omit these "features."
When there are more than 15, metadata is hidden, since a lot of it involves doing "deep" file inspection which can be slow. That said, they could have made size always visible since that it part of the FS metadata and is generally fast to access regardless of what is selected - like they do with the number of items.
You can enable the Run command in the Start Menu settings. However, it is likely that they noticed that most of thier users never use it - and a fair number can use the searchbox as a pseudo-Run.
You can also enable Network in the Start Menu settings.
Yes they did remove them from the default. I doubt many non "power" users were actively using either (maybe Network, but that is a stretch, and the new idea is for that group to be using Homegroup instead - and yes, Homegroup sucks, quite hard, in its current incarnation), and "power" users should be capable of right clicking in the taskbar, hitting "Properties," navigating to the "Start Menu" tab and hitting the "Customize" button.
Given that most of windows OS services are in a userland server process (csrss.exe), one could argue they are already doing that.
I cannot speak for Southwest, since I do not remember how it works with GDS, but American at least offers its tickets through the GDS system - though they do not pay commissions.
One thing to consider, though, is that since people coming to their site from Kayak/ITA-powered searches can go directly to the flight that was found, the traffic is much more likely to do a booking than a general search for "flights" yielding an American or Southewest ad on Google. At that point, Google or Kayak can start demanding a toll for that traffic (lead-generation price), with the stick being that they would instead shunt that traffic to competitors' flights instead. And since Google and Kayak have a lot of eyeballs, it is a no-brainer for the airlines to pay for lead generation.
The problem with your query is that ITA (and the other GDS systems) have to query the individual airline systems to get at the rates - and caching is not effective except as at a "best effort/guess" basis, because rates change dynamically according to algorithms known only to the airlines themselves. That is why, as one gets closer to the date, the cost for any given ticket (same flight/seat-class) increases. This makes it completely ineffective to do a search like you suggest - you would only be able to get the engine's best guess, and it would only be applicable for a given day, or would not be applicable to any given day, but be an average for all days.
Keep in mind, to do a single flight search across the various GDS' that Expedia is connected to, for example, takes on the order of 15 seconds. To answer your queries would require doing either all 68808 searches for round-trip, or 712 (if you are doing single flights and trying to manually connect them) searches. And that data would only be valid for a rather short interval of time, since flights can be sold out at any time, as as a flight gets closer to being sold out, ticket prices for that flight rise automatically.
Google buying ITA will not magically improve this. The airlines realized that they are holding all the cards right now, which means that the little battle-of-wills they have going on between them and the GDSes is heavily skewed towards the airlines. There is a reason there is no longer any money to be made in commissions selling flights through GDS; lead generation is where money is being made (or dynamic packaging, but that is a completely different beast altogether), and that is where I imagine Google is going to go - which is why Kayak was so vocal about this move, since it would, in effect, be cutting them out of the equation - it used to be Kayak buys adwords for particular destinations, generates the search and collects lead generation fees from the airlines by forward to their (or some OTA) site. What Google proposes to do now is skip the first step - granted they will be losing adword revenue if their organic results increase in quality - but will be gaining lead-generation revenue, which likely offsets it, since the traffic funnel is much more qualified than the adword traffic may have been.
Sorry for the ramble/stream-of-consciousness; been a bit frustrated with GDS systems over the past week, having to rewrite a fair bit of interfacing code.