The contents of the address bar, or whether the buttons are hilighted, is not "changing the widgets".
If it was something like the Microsoft Office toolbar, where the actual widgets changed depending on the context, so you actually got different *widgets* depending on the site you were on, maybe.
And the bookmarks definitely don't change.
This is just breaking the user interface because it's cool, which Apple does on occasion.
The only thing tab-specific in the toolbar is the contents of the location widget.
Everything else is fixed in both location and appearance, and does not change from tab to tab. If you had different tools available depending on the site, or if the bookmarks were context-sensitive based on the site, then I could see them being part of the tab.
They're no more tab-specific than the Windows menu bar. You can't say it makes sense on the Mac and doesn't make sense on Windows.
The toolbar and bookmark bar are ALSO logically above the tab bar in the hierarchy. They do not change: the content of one toolbar widget, the location box, changes... but the rest of the widgets are fixed and the location box itself is fixed. They should be above the tab bar.
So, no, it makes no sense from the Mac side either.
If you set this up as a power-over-ethernet device, you could have it powered from a PoE capable switch with only one wire going into it, no need to plug it into the wall.
This doesn't work on Windows, alas, even if you patch the property list. The tab bar does move from the title bar to the right location, but it doesn't work as a tab bar...
The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match.
But the D import file can't directly include any of the complex C macros in any case, right? SO the translator could use the C compiler itself to perform the translation... I had to do something similar for mapping C header files to Forth source code some years back.
I hate this, it completely breaks the framing model of tabs. The tab is supposed to frame the content that is contained in the tab. My toolbar ad bookmarks are NOT part of the bloody tab, you idiots, don't put them "inside" the tab frame.
Idiots.
I haven't installed it yet, because I'm using my computer for actual work (hey, Apple, why do I need to replace safari, or reboot my computer, just to try out a demo of a new program?), and I was hoping that this was an option. I guess not.
What kind of logic is this? "I don't know anything about X, therefore X must be a scourge upon the earth."
Well, it's not the logic in the article you're referencing, so my guess is that it's reductio ad absurdum.
Getting back to the logic in the article itself... if it was open source, then he would likely have been able to find it by searching the web. He tried to find links to it, failed, so it's a reasonable assumption that it's not open source. He obviously doesn't like the idea that it's proprietary. Perhaps you have a different opinion there. Which is also reasonable. In any case I don't see anything wrong with the logic.
And for each discovery action, the investigator has to go back to the judge. Which takes time, and for each step, there's more chance that the information necessary for following the next step will be lost.
This significantly raises the cost of discovery, and decreases the probability of success.
Which probably means more costs for any people they do eventually find, of course, but that's another story.
You don't know who you're getting the files from, so neither does Joe Schmo from the RIAA.
You don't know who's getting your files, so neither does Joe Schmo from the RIAA.
OneSwarm uses the "communist cell" model, where nobody knows anyone except their immediate neighbors, *and* they don't know who's requested or provided any file that's going through their node.
And at the top level of the collective are a bunch of drummers in nanobar tunnels under Puget Sound... oh, sorry, I'm channeling Neil Stephenson again.
Hmm, I see what you're getting at. When I've dealt with this in the past, I've written a C program that included the #include file and wrote out a file in the target language (in my case it was Forth). For example:
#include <sys/ioctl.h>
ioctl_dump() {
printf("const int SIOCADDRT = 0x%04X;\n", SIOCADDRT);
printf("const int SIOCDELRT = 0x%04X;\n", SIOCDELRT);
printf("const int SIOCRTMSG = 0x%04X;\n", SIOCRTMSG); //... }
Obviously you'd use automated initial generation of this table, but once it's done it would be portable, because you would be using a full C parser.:)
What I mean is that instead of converting the C header files to D header files, you would create a C wrapper for anything that's a macro that's called from D. That way the D code never has to deal with the results of the macro preprocessing. Yes, you'd have to have a set of declarations for the C code, but those should be based on the public API rather than the internals of the include file... and should be platform-independent.
I'm not saying that there wouldn't ever be any need to modify these D declarations, just that it seemed really odd to be in a situation where you care about the details of a macro expansion.
Top Tracks 1. Simon & Garfunkel - The Sound of Silence 2. Tears for Fears - Everybody Wants To Rule The World 3. Yasunori Mitsuda - Another Telmina 4. Joe Hisaishi - River Side 5. Air - Alpha Beta Gaga 6. Led Zeppelin - Going to California 6. Jeff Wahl - Linus and Lucy 8. Joe Hisaishi - Summer 9. djpretzel - Zelda 64 Pachelbel's Ganon OC ReMix 10. Berlin Chamber Orchestra, Peter Wohlert - Brandenburg Concerto No.6 in B flat major
Take a $40 handheld computer, add a free eBook software package. Handhelds don't have enough screen space to display more than one application at a time, so they're not distracting. I've been reading eBooks on my PDA since 2000... including yours, Cory.
The only problem is that the people making PDAs haven't twigged to the fact that they really CAN sell PDAs so they're cost-competitive with high school calculators, for a profit, and get the kind of early-adopter lock-in from high-school sales that Apple used to have. Palm was heading that way with the Zire but got confused about the business they were in and decided they had to compete head-to-head with Microsoft. That's not how they beat Microsoft in the '90s, so why they thought switching to a losing business model was a good idea, I can't imagine.
They can get more cooperation from skype, to be sure, and when they do criminals will switch to private and distributed encrypted channels. These will be outlawed, and they'll have to use steganography to hide.
Meanwhile physical surveillance will be improved to the point where the unencrypted channel from the mouth to the handset and from the handset to the ear will be the easy target... but the legal residue of the effort to outlaw crypto will leave us in a situation where only the outlaws are safe using it.
I didn't suggest that Darwin by itself was a particularly good BSD for the desktop. I said that OS X is. Yes, that involves a bunch of stuff that isn't part of BSD, but that's true regardless of whether you're running Cocoa, NeXTstep, Gnome, KDE, or code written for raw Xlib:
And "broad hardware support" isn't the same as "superior hardware support". Linux is a jack-of-all-trades, it provides acceptable performance and consistent behavior on a variety of platforms, but Jack of all trades is master of none. For the hardware that OS X runs on, it provides better hardware support than Linux. That's true for just about any UNIX workstation vendor... they are simply able to focus their resources better. Which is the whole point of saying, as the OP did, that the Mac is a UNIX workstation.
Why would you try to use the header files from FreeBSD on Linux? The point of standard headers is that code can be written to an abstract interface exposed by the header files. When you move from one platform to another, the code works, even though the expansion of the macros is different, because the code does not make assumptions about how those macros are expanded.
Someone else suggested that you're trying to avoid redundant calls from D to C, but I suspect that you would in the long run end up with a faster and cleaner system by bypassing the stdio overhead completely, and calling read(), write(), and so on directly. The C runtime has an awful lot of historical baggage that you shouldn't need to carry over to D.
What happens when someone wants to use D on a platform that uses a glibc alternative, like uClibc? Do they have to hand-hack a new runtime?
Ah, performance vs portability, a common tradeoff.
Still, a portable runtime for the first pass (like the first stage gcc build) would seem to be a reasonable path, particularly on the Mac where Apple has been known to make significant changes in include files across versions.
High profile hasn't been a problem
on
Linked In Or Out?
·
· Score: 1
When I google myself, the first reference to my name is in the early '80s, in the SF-LOVERS mailing list. I have a pretty high profile, online, and I haven't found it to be a problem. In fact it's probably better that people looking for me don't think I'm an exotic photographer in San Francisco (though I dare say he's got a more interesting life than I do... I have to admit envying the other Peter da Silva). I'm also occasionally mistaken for Dan Silva (creator of Deluxe Paint) and another James da Silva (creator of Amanda).
Interesting. I was referring to several posts I'd read some years back about the performance overhead of Mach messages and how Apple was eliminating them. My google-fu is inadequate to bring that back up, and possibly it referred only to certain kinds of messages where the overhead was a problem.
Slashdot Mirror
The contents of the address bar, or whether the buttons are hilighted, is not "changing the widgets".
If it was something like the Microsoft Office toolbar, where the actual widgets changed depending on the context, so you actually got different *widgets* depending on the site you were on, maybe.
And the bookmarks definitely don't change.
This is just breaking the user interface because it's cool, which Apple does on occasion.
The only thing tab-specific in the toolbar is the contents of the location widget.
Everything else is fixed in both location and appearance, and does not change from tab to tab. If you had different tools available depending on the site, or if the bookmarks were context-sensitive based on the site, then I could see them being part of the tab.
They're no more tab-specific than the Windows menu bar. You can't say it makes sense on the Mac and doesn't make sense on Windows.
Friend, I'm on a Mac.
The toolbar and bookmark bar are ALSO logically above the tab bar in the hierarchy. They do not change: the content of one toolbar widget, the location box, changes... but the rest of the widgets are fixed and the location box itself is fixed. They should be above the tab bar.
So, no, it makes no sense from the Mac side either.
Ack, that's a hard website to find product on.
I think people are missing the point of this.
If you set this up as a power-over-ethernet device, you could have it powered from a PoE capable switch with only one wire going into it, no need to plug it into the wall.
The pelagic argosy sights land. Repeat. The pelagic argosy sights land. Groups to follow. 25. 16. 44. 44. 25. 16. 48. 37...
You, sir, are the reason they put warning labels on toothpicks. :)
Here's how to turn tabs-on-top off on Mac: Disable "Tabs on Top" Feature in Safari 4 Public Beta
This doesn't work on Windows, alas, even if you patch the property list. The tab bar does move from the title bar to the right location, but it doesn't work as a tab bar...
I'm more interested in a version that supports PoE.
The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match.
But the D import file can't directly include any of the complex C macros in any case, right? SO the translator could use the C compiler itself to perform the translation... I had to do something similar for mapping C header files to Forth source code some years back.
Chrome has the bloody tabs on top too.
I hate this, it completely breaks the framing model of tabs. The tab is supposed to frame the content that is contained in the tab. My toolbar ad bookmarks are NOT part of the bloody tab, you idiots, don't put them "inside" the tab frame.
Idiots.
I haven't installed it yet, because I'm using my computer for actual work (hey, Apple, why do I need to replace safari, or reboot my computer, just to try out a demo of a new program?), and I was hoping that this was an option. I guess not.
What kind of logic is this? "I don't know anything about X, therefore X must be a scourge upon the earth."
Well, it's not the logic in the article you're referencing, so my guess is that it's reductio ad absurdum.
Getting back to the logic in the article itself... if it was open source, then he would likely have been able to find it by searching the web. He tried to find links to it, failed, so it's a reasonable assumption that it's not open source. He obviously doesn't like the idea that it's proprietary. Perhaps you have a different opinion there. Which is also reasonable. In any case I don't see anything wrong with the logic.
And for each discovery action, the investigator has to go back to the judge. Which takes time, and for each step, there's more chance that the information necessary for following the next step will be lost.
This significantly raises the cost of discovery, and decreases the probability of success.
Which probably means more costs for any people they do eventually find, of course, but that's another story.
NOOOOOOOOOOOOO!
F*** you, Google, now everyone's going to start using this f***ed up idea.
You don't know who you're getting the files from, so neither does Joe Schmo from the RIAA.
You don't know who's getting your files, so neither does Joe Schmo from the RIAA.
OneSwarm uses the "communist cell" model, where nobody knows anyone except their immediate neighbors, *and* they don't know who's requested or provided any file that's going through their node.
And at the top level of the collective are a bunch of drummers in nanobar tunnels under Puget Sound... oh, sorry, I'm channeling Neil Stephenson again.
Hmm, I see what you're getting at. When I've dealt with this in the past, I've written a C program that included the #include file and wrote out a file in the target language (in my case it was Forth). For example:
Obviously you'd use automated initial generation of this table, but once it's done it would be portable, because you would be using a full C parser. :)
OK, I think we're talking at cross purposes.
What I mean is that instead of converting the C header files to D header files, you would create a C wrapper for anything that's a macro that's called from D. That way the D code never has to deal with the results of the macro preprocessing. Yes, you'd have to have a set of declarations for the C code, but those should be based on the public API rather than the internals of the include file... and should be platform-independent.
I'm not saying that there wouldn't ever be any need to modify these D declarations, just that it seemed really odd to be in a situation where you care about the details of a macro expansion.
Top Tracks
1. Simon & Garfunkel - The Sound of Silence
2. Tears for Fears - Everybody Wants To Rule The World
3. Yasunori Mitsuda - Another Telmina
4. Joe Hisaishi - River Side
5. Air - Alpha Beta Gaga
6. Led Zeppelin - Going to California
6. Jeff Wahl - Linus and Lucy
8. Joe Hisaishi - Summer
9. djpretzel - Zelda 64 Pachelbel's Ganon OC ReMix
10. Berlin Chamber Orchestra, Peter Wohlert - Brandenburg Concerto No.6 in B flat major
Oh the embarrassment.
Take a $40 handheld computer, add a free eBook software package. Handhelds don't have enough screen space to display more than one application at a time, so they're not distracting. I've been reading eBooks on my PDA since 2000... including yours, Cory.
The only problem is that the people making PDAs haven't twigged to the fact that they really CAN sell PDAs so they're cost-competitive with high school calculators, for a profit, and get the kind of early-adopter lock-in from high-school sales that Apple used to have. Palm was heading that way with the Zire but got confused about the business they were in and decided they had to compete head-to-head with Microsoft. That's not how they beat Microsoft in the '90s, so why they thought switching to a losing business model was a good idea, I can't imagine.
They can get more cooperation from skype, to be sure, and when they do criminals will switch to private and distributed encrypted channels. These will be outlawed, and they'll have to use steganography to hide.
Meanwhile physical surveillance will be improved to the point where the unencrypted channel from the mouth to the handset and from the handset to the ear will be the easy target... but the legal residue of the effort to outlaw crypto will leave us in a situation where only the outlaws are safe using it.
I didn't suggest that Darwin by itself was a particularly good BSD for the desktop. I said that OS X is. Yes, that involves a bunch of stuff that isn't part of BSD, but that's true regardless of whether you're running Cocoa, NeXTstep, Gnome, KDE, or code written for raw Xlib:
And "broad hardware support" isn't the same as "superior hardware support". Linux is a jack-of-all-trades, it provides acceptable performance and consistent behavior on a variety of platforms, but Jack of all trades is master of none. For the hardware that OS X runs on, it provides better hardware support than Linux. That's true for just about any UNIX workstation vendor... they are simply able to focus their resources better. Which is the whole point of saying, as the OP did, that the Mac is a UNIX workstation.
Why would you try to use the header files from FreeBSD on Linux? The point of standard headers is that code can be written to an abstract interface exposed by the header files. When you move from one platform to another, the code works, even though the expansion of the macros is different, because the code does not make assumptions about how those macros are expanded.
Someone else suggested that you're trying to avoid redundant calls from D to C, but I suspect that you would in the long run end up with a faster and cleaner system by bypassing the stdio overhead completely, and calling read(), write(), and so on directly. The C runtime has an awful lot of historical baggage that you shouldn't need to carry over to D.
What happens when someone wants to use D on a platform that uses a glibc alternative, like uClibc? Do they have to hand-hack a new runtime?
Ah, performance vs portability, a common tradeoff.
Still, a portable runtime for the first pass (like the first stage gcc build) would seem to be a reasonable path, particularly on the Mac where Apple has been known to make significant changes in include files across versions.
When I google myself, the first reference to my name is in the early '80s, in the SF-LOVERS mailing list. I have a pretty high profile, online, and I haven't found it to be a problem. In fact it's probably better that people looking for me don't think I'm an exotic photographer in San Francisco (though I dare say he's got a more interesting life than I do... I have to admit envying the other Peter da Silva). I'm also occasionally mistaken for Dan Silva (creator of Deluxe Paint) and another James da Silva (creator of Amanda).
Interesting. I was referring to several posts I'd read some years back about the performance overhead of Mach messages and how Apple was eliminating them. My google-fu is inadequate to bring that back up, and possibly it referred only to certain kinds of messages where the overhead was a problem.