AFAIR its been around for since before Xcode being called Xcode.
Comes at a price, though. mm files compile a lot slower then either cpp, c or m. They also tend to crash the compiler in certain situations (seems like the error reporting for mm files is semi broken at least for template related errors).
Still, easily good enough for writing gui adapters with simultaneous access to cocoa and the main c++ app.
I understand Adobe's gotta keep adding "features" so they can keep making money, Well, that may be part of why stopping 64-Carbon may have been a good idea in the long run. In order to go 64-bit, Adobe was investing time into carbon where the more difficult cocoa port would have included 64 bit pretty much for free.
Taken from the Adobe- 64-bit FAQ: The Photoshop team began working on porting Photoshop to Cocoa as soon as Apple announced 64-bit support in Carbon was no longer part of their plans. If this is true, Adobe wasn't even woring on a cocoa port before. I would have expected Adobe to put some more effort into their flagship product in the mac. Their FAQ does sound like they would simply never have made the port unless forced by apple.
but I don't think Mac users should get too upset that they won't have a 64-bit version for a few months. A few months for a cocoa port of that size? Hardly.
I simply could put the Carbon calls into the C++ classes. I'm still okay, 32-bit carbon is still around, but yeah now I have been working on those icky little.m files. I hope you know that in.mm files you can mix C++ with cocoa?
it's impossible for a would-be stealth system to counter good timing-attacks.
Okay, please tell me what such an attack consists of.
One possible method is using an instruction that is emulated (traps) when in a WM, wheras it is directly executed in normal mode and therefore *much* faster.
Another quite dated approach (seen in delivered apps at the time) is using self modifying code. The trick was to write to some executable place ahead of the executing instruction with no flushes. If the modified function gets executed before the cache gets flushed (making the code modification effective), there most likely was no trap (eg breakpoints) called in between.
but all you really have to do do is send an actual 0 or 1 instead, right? Using 0/1 outputs for meaningful nets requires using a pulsed network. So instead of a single state (0/1) you'll work with trains of such values per neuron.
The trouble of recurrent processes in artificial networks is mostly due to the lack of loops and feedback Jup. Recurrent & continuously adapting & pulsed networks are turing capable. Imagine the capabilities:-)
This would be a flaw in topology Using a computer system with no loops or decisions would be quite boring, don't you think? Same with those nets. The pulsed feedback enables:
Among other things such a networks can find mappings from the input that are abstracting to a stable & relevant representation, as needed for the next layer. They can also make decisions, attract attention, etc.
It's fairly hard to program & analyze these beasts though. Almost as difficult as understanding the real brain.
have been looking for information about how an individual human neuron works for a while Same here. Tricky topic. Complex with tons of subtle details and misrepresentations; rapidly advancing area.
the value/weights thing does seem to be more or less correct Nope. Its describing one essential attribute but insufficient for brain style computation. The technical reasoning for it use is simplicity and the fire-rate analogy.
In the brain all higher level functions are recurrent and can process multiple competing "ideas" concurrently. One essential capability is the detection of time concurrency (ie: inputs firing at the same time instance have a strongly different effect from inputs firing in an alternating fashion). The simplistic fire-rate models (the continuous valued output is interpreted as the rate or likelihood of firing) is incapable of modeling that.
If you wana know more, read Rolls&Deco, 2002: Neuronal Neuroscience of Vision or simply google for "synchronous firing".
At least this point is no obstacle. Darwin has been booting on BIOS machines for quite a while. Its not as nice nor incorporated into the MacOSX GUI-toolset. But no real problem if desired.
> Yeah, that's the same kind of attitude that came from Macintosh zealots like you a few years ago, Yeah, sure. Where did I mention Apple?
> when you were seriously arguing. Are you allways attacking straw men in discussions?
To repeat, you claimed that >... it's what the platforms actually offer to real-world programmers today: > Linux: Linux kernel, X.org, and Mono.
Now I don't seem to live in your real-world, but in mineprogrammers using Mono on Linux exist but are few and far between. There also is only a minor fraction of applications talking directly to X or the kernel itself. As far as I'm concerned people use C++, KDE or Gnome and tons of calls to standard libs (read not M$ infested bull).
Therefore rounding 1.0 to 1 is ideal since the number is just a likely to be a little smaller as it is to being a little bigger. This really depends on where you get your numbers from:-)
Consider numbers actually consisting of three parts. The integral part to where you wana round, the known fractional part that you base your rounding on and a third part of following unknown digits. The last part is usually consisting of all zeroes for monetary values. So your number is:
xxx.yyzzz....
So in your example 1.0 is actually 1.0zzz with z representing unknown digits. Which means that rounding 1.0 to 1 is NOT exact when talking about natural numbers. Same goes for 1.5zzz, where rounding up may be more precise if those z are nonzero.
Bankers rounding is cute and nice for quite a few applications, but it *can* also introduce a bias of its own, depending on what you do. I hope you see now, why MarkusQ has a point.
You would use this only to guard very short sections. If the sections were long, this optimization matter much, anyway. If they are *very* short, eg insert an element into a list, even busy waiting would do. A short sleep timeout obviously wouldn't hurt for cases where multiple threads keep using this section.
So all you care for is shrink wrap software and all that small or big software producers needed patents to produce them? Oh, sure, no further questions...
> I found that the old spatial way of "organizing" things in the old MacOS quickly broke down when you started dealing with a large group of files.
Yup, thats one task where column view is superior. Still the spatial way of placing icons has pros for the common (and task wise essential) way of arranging the stuff you actually work on. If you work on big projects shared among multiple people, spatial plainly doesn't work. If you work on your own stuff, it has unmatched benefits.
I really like column view but it's a real pitty that spatial was effectively dropped.
> The first thing I do with any new Mac I get is turn desktop mounting off.
Go for that. It makes sense. Nothing to do with spatial organisation, though.
> It was a spiffy metaphor at the time
It still is. I use it a lot on the desktop, which seems the only place where it still works reliably. Pretty much any corner of my desktop serves it's dedicated to roughy related material, in an organisation that probably no one would get, other then me. But this way I never have to search for these, they are where it feels natural for them to be...
>..., and the icon view is simply there for the sake of the warm fuzzy feeling it gives old Mac heads.
I somehow get the impression that you are missing the point.
While I do like the column view and also occasionally use the tre view, since X.0 I pretty much stoped using the old style icon view. Which is for a single reason. In macos9 an Icon would stay where it is. When you put it top right into it's folder, it'll be there the next time you have that window open. Which means, you can arrange the file icons in whatever order/placement makes sense to you and rely on having it there. No need to scan long sorted lists or in many times even the name of the file. Like in the good old physical desktop metaphor. Its my desk and my screwdriver is where I placed it.
This is pretty much still broken in 10.3, unless you stop using column view, altogether. But column view is also nice...
Since I have to choose, I use column view. But the old style view had a certain extra which plainly can not be matched by anything enforcing a specific icon arangement (or simply regularly fooling up the placment).
Kinda sorted is much better then unorganized, but can't really match your personal way of organizing things.
> I complain about the menu bar in all confidence that it won't be changed.
Thats fine, then:-) Actually I have to admit that the menu bar does look kinda strange on a huge screen...
> I find it amusing that you don't use menu keyboard shortcuts, but you use cmd-2/cmd-3 to switch the finder view instead of using the 'chicklet' button in the window !
I harldy ever try to remember shortcuts. Maybe 50 overall. So I use mostly functions from the menu. On a frequency scale mostly shortcuts, though.
> What's up with that, is it because the button moves, like the guy in the article was complaining about ?
I never noticed. Somehow cute visual bug:-)
> I just actually use the shortcuts and toolbar a lot myself, Again I'm opposite, but I don't have a problem with toolbars, either:-)
As for the visual change from brushed to aqua, I think this is due to the HIG policy to have brushed appearance in apps that either represent some sort of hardware (or virtual hardware like an alarm clock), or that have a side bar (like the finder in this case). I'd agree that it would be more consistent to ignore HIG in this case and keep one or the other.
Weird. What is apple thinking? Of course all the ports are closed. Still this is not what I'd want to be default in particular for the majority of users who practically never need to open their own ports, anyway...
Power users use keyboard shortcuts anyway, I guess.
I gota 30" and I still favor the menu bar where it is on the mac:-)
and "not near the data" is generally a bad place to put controls.
For palettes this would be wherever you put them. For the menu the IMHO more import issue is consistency. Having to locate a particular menu that is placed incosistently can be a noticable time waster.
I mean, really, why is a user switching back and forth between the two types of Finder views? Nobody does that,
Me. A lot. cmd-2 / cmd-3 toggles old style tree view to next style column view. I like that a lot. So I hope no one at apple listens to you:-)
I really think you refer to an old, outdated, "not meant to be used unless unavoidable" API that due to compatibility issues you really shouldn't have used, anyway.
DisplayConfigX is a shareware tool I wrote to configure display timings and resolutions. It includes a test screen feature which supports full screen for obvious reasons. I never had to ask Apple, just google:-)
I wouldn't expect too much from automatic vectorisation. While I love Altivec (it's fun to use even where not really needed:-) its still quite a challenge to optimize code automagically. This is somewhat harder then normal (fixed point) optimizers.
First floats are unlike ints in that the precise result is much more delicate to get exact. Think NANs, denormalized numbers and such. Altivec isn't meant to get those right, rather to fly when excat IEEE isn't needed. Next is loop unrolling which plainly explodes using SIMD. The G5 has a longer pipeline to fill and Altivec operates on 4 floats (or ints or 8 int16 or 16 int8...) so the loop to unroll better be long. But the hardest part is that many exensive loops are not linear. Still a simple target would be big matrices (one row vs one column, so one is vertical in memory). Just recently to met someone calculating a matrix multiplication column first (ouch), which the compiler couldn't even have seen. And lets not forget about alignment (1 cycle store if you know its aligned, 5 if you don't).
Ah, and by the way, not ALL people who do know how to write such optimizations are on the x86 platform:-) There are probably more though...
I just stumbled over this fact today and was stunned, too:-(
Obviously transitioning all libs to 64 bit takes quite some effort (and for Cocoa and Objective-C this is pretty much Apple only), but this still means that even in Tiger my Apps can't keep all the data around.
Doh.
Maybe it doesn't matter much for DBs and some other Areas where 64 addresses are useful, for scientific data visualizers this is very bad news indeed. Of course I could handle the data the way Apple recommends, but then again that more cumbersome than what I do now (unmapping as soon as it's not absolutely required any more).
Let's hope Apple is quick porting Cocoa to 64 bit, too. 2006? After Longhorn? Double doh...
Daran
Slashdot Mirror
AFAIR its been around for since before Xcode being called Xcode.
Comes at a price, though. mm files compile a lot slower then either cpp, c or m. They also tend to crash the compiler in certain situations (seems like the error reporting for mm files is semi broken at least for template related errors).
Still, easily good enough for writing gui adapters with simultaneous access to cocoa and the main c++ app.
The Photoshop team
began working on porting Photoshop to Cocoa as soon as Apple announced 64-bit support
in Carbon was no longer part of their plans. If this is true, Adobe wasn't even woring on a cocoa port before. I would have expected Adobe to put some more effort into their flagship product in the mac. Their FAQ does sound like they would simply never have made the port unless forced by apple. but I don't think Mac users should get too upset that they won't have a 64-bit version for a few months. A few months for a cocoa port of that size? Hardly.
One possible method is using an instruction that is emulated (traps) when in a WM, wheras it is directly executed in normal mode and therefore *much* faster.
Another quite dated approach (seen in delivered apps at the time) is using self modifying code. The trick was to write to some executable place ahead of the executing instruction with no flushes. If the modified function gets executed before the cache gets flushed (making the code modification effective), there most likely was no trap (eg breakpoints) called in between.
Sure there was 1MB Sticks that would fit the same Motherboard as 256MB ones?
yeah, this is riding this silly thing to death. I know. You know. And I also know that you know;-)
- associating independent concurrent ideas (synchrony)
- conveying relevance (structural feedback)
- keeping state (local recurrent feedback)
- competition among ideas (local inhibition)
- shifting attention (large scale enhancement)
etc
Among other things such a networks can find mappings from the input that are abstracting to a stable & relevant representation, as needed for the next layer. They can also make decisions, attract attention, etc.
It's fairly hard to program & analyze these beasts though. Almost as difficult as understanding the real brain.
In the brain all higher level functions are recurrent and can process multiple competing "ideas" concurrently. One essential capability is the detection of time concurrency (ie: inputs firing at the same time instance have a strongly different effect from inputs firing in an alternating fashion). The simplistic fire-rate models (the continuous valued output is interpreted as the rate or likelihood of firing) is incapable of modeling that.
If you wana know more, read Rolls&Deco, 2002: Neuronal Neuroscience of Vision or simply google for "synchronous firing".
> Too bad Apple broke support for it in OS X.
Out of curiosity, what has broken?
Daran
At least this point is no obstacle. Darwin has been booting on BIOS machines for quite a while. Its not as nice nor incorporated into the MacOSX GUI-toolset. But no real problem if desired.
> Yeah, that's the same kind of attitude that came from Macintosh zealots like you a few years ago,
... it's what the platforms actually offer to real-world programmers today:
Yeah, sure. Where did I mention Apple?
> when you were seriously arguing.
Are you allways attacking straw men in discussions?
To repeat, you claimed that
>
> Linux: Linux kernel, X.org, and Mono.
Now I don't seem to live in your real-world, but in mineprogrammers using Mono on Linux exist but are few and far between. There also is only a minor fraction of applications talking directly to X or the kernel itself. As far as I'm concerned people use C++, KDE or Gnome and tons of calls to standard libs (read not M$ infested bull).
Now who is the zealot?
> ... it's what the platforms actually offer to real-world programmers today:
> Linux: Linux kernel, X.org, and Mono.
Three words: LOL.
Therefore rounding 1.0 to 1 is ideal since the number is just a likely to be a little smaller as it is to being a little bigger.
This really depends on where you get your numbers from:-)
Consider numbers actually consisting of three parts. The integral part to where you wana round, the known fractional part that you base your rounding on and a third part of following unknown digits. The last part is usually consisting of all zeroes for monetary values. So your number is:
xxx.yyzzz....
So in your example 1.0 is actually 1.0zzz with z representing unknown digits. Which means that rounding 1.0 to 1 is NOT exact when talking about natural numbers. Same goes for 1.5zzz, where rounding up may be more precise if those z are nonzero.
Bankers rounding is cute and nice for quite a few applications, but it *can* also introduce a bias of its own, depending on what you do. I hope you see now, why MarkusQ has a point.
Greetz,
Daran
You would use this only to guard very short sections. If the sections were long, this optimization matter much, anyway. If they are *very* short, eg insert an element into a list, even busy waiting would do. A short sleep timeout obviously wouldn't hurt for cases where multiple threads keep using this section.
So all you care for is shrink wrap software and all that small or big software producers needed patents to produce them? Oh, sure, no further questions...
Daran
> I found that the old spatial way of "organizing" things in the old MacOS quickly broke down when you started dealing with a large group of files.
..., and the icon view is simply there for the sake of the warm fuzzy feeling it gives old Mac heads.
Yup, thats one task where column view is superior. Still the spatial way of placing icons has pros for the common (and task wise essential) way of arranging the stuff you actually work on. If you work on big projects shared among multiple people, spatial plainly doesn't work. If you work on your own stuff, it has unmatched benefits.
I really like column view but it's a real pitty that spatial was effectively dropped.
> The first thing I do with any new Mac I get is turn desktop mounting off.
Go for that. It makes sense. Nothing to do with spatial organisation, though.
> It was a spiffy metaphor at the time
It still is. I use it a lot on the desktop, which seems the only place where it still works reliably. Pretty much any corner of my desktop serves it's dedicated to roughy related material, in an organisation that probably no one would get, other then me. But this way I never have to search for these, they are where it feels natural for them to be...
>
Thx:-)
I somehow get the impression that you are missing the point.
While I do like the column view and also occasionally use the tre view, since X.0 I pretty much stoped using the old style icon view. Which is for a single reason. In macos9 an Icon would stay where it is. When you put it top right into it's folder, it'll be there the next time you have that window open. Which means, you can arrange the file icons in whatever order/placement makes sense to you and rely on having it there. No need to scan long sorted lists or in many times even the name of the file. Like in the good old physical desktop metaphor. Its my desk and my screwdriver is where I placed it.
This is pretty much still broken in 10.3, unless you stop using column view, altogether. But column view is also nice...
Since I have to choose, I use column view. But the old style view had a certain extra which plainly can not be matched by anything enforcing a specific icon arangement (or simply regularly fooling up the placment).
Kinda sorted is much better then unorganized, but can't really match your personal way of organizing things.
Greetz,
Daran
> I complain about the menu bar in all confidence that it won't be changed.
Thats fine, then:-) Actually I have to admit that the menu bar does look kinda strange on a huge screen...
> I find it amusing that you don't use menu keyboard shortcuts, but you use cmd-2/cmd-3 to switch the finder view instead of using the 'chicklet' button in the window !
I harldy ever try to remember shortcuts. Maybe 50 overall. So I use mostly functions from the menu. On a frequency scale mostly shortcuts, though.
> What's up with that, is it because the button moves, like the guy in the article was complaining about ?
I never noticed. Somehow cute visual bug:-)
> I just actually use the shortcuts and toolbar a lot myself,
Again I'm opposite, but I don't have a problem with toolbars, either:-)
As for the visual change from brushed to aqua, I think this is due to the HIG policy to have brushed appearance in apps that either represent some sort of hardware (or virtual hardware like an alarm clock), or that have a side bar (like the finder in this case). I'd agree that it would be more consistent to ignore HIG in this case and keep one or the other.
Greetz,
Daran
I just double check and you are right:-(
Weird. What is apple thinking? Of course all the ports are closed. Still this is not what I'd want to be default in particular for the majority of users who practically never need to open their own ports, anyway...
Greetz,
Daran
Tried uControl?
I gota 30" and I still favor the menu bar where it is on the mac:-)
For palettes this would be wherever you put them. For the menu the IMHO more import issue is consistency. Having to locate a particular menu that is placed incosistently can be a noticable time waster.
Me. A lot. cmd-2 / cmd-3 toggles old style tree view to next style column view. I like that a lot. So I hope no one at apple listens to you:-)
Greetz,
Daran
> Or start listening on a network socket (the OS X firewall is not on by defailt).
AFAIK it is on by default. Which really is a Good Thing(TM).
Daran
I really think you refer to an old, outdated, "not meant to be used unless unavoidable" API that due to compatibility issues you really shouldn't have used, anyway.
DisplayConfigX is a shareware tool I wrote to configure display timings and resolutions. It includes a test screen feature which supports full screen for obvious reasons. I never had to ask Apple, just google:-)
Harald
I wouldn't expect too much from automatic vectorisation. While I love Altivec (it's fun to use even where not really needed:-) its still quite a challenge to optimize code automagically. This is somewhat harder then normal (fixed point) optimizers.
First floats are unlike ints in that the precise result is much more delicate to get exact. Think NANs, denormalized numbers and such. Altivec isn't meant to get those right, rather to fly when excat IEEE isn't needed. Next is loop unrolling which plainly explodes using SIMD. The G5 has a longer pipeline to fill and Altivec operates on 4 floats (or ints or 8 int16 or 16 int8...) so the loop to unroll better be long. But the hardest part is that many exensive loops are not linear. Still a simple target would be big matrices (one row vs one column, so one is vertical in memory). Just recently to met someone calculating a matrix multiplication column first (ouch), which the compiler couldn't even have seen. And lets not forget about alignment (1 cycle store if you know its aligned, 5 if you don't).
Ah, and by the way, not ALL people who do know how to write such optimizations are on the x86 platform:-) There are probably more though...
Daran
I just stumbled over this fact today and was stunned, too:-( Obviously transitioning all libs to 64 bit takes quite some effort (and for Cocoa and Objective-C this is pretty much Apple only), but this still means that even in Tiger my Apps can't keep all the data around. Doh. Maybe it doesn't matter much for DBs and some other Areas where 64 addresses are useful, for scientific data visualizers this is very bad news indeed. Of course I could handle the data the way Apple recommends, but then again that more cumbersome than what I do now (unmapping as soon as it's not absolutely required any more). Let's hope Apple is quick porting Cocoa to 64 bit, too. 2006? After Longhorn? Double doh... Daran