The idea in that construct is to let the first error handler continue to the second, so that the freeing code does not need to be duplicated. Breaking the freeing code into functions is a bit heavy solution, having to pass them all the variables to be freed and so on, and it would only increase the amount of code.
A function longer than a screenfull is too long, I never have such.
The example was in __plain C__. And besides, exceptions are worthless in a non-garbage collected language. (Ugly kludges in C++ don't count as proper GC.) You have to catch them at every point to free stuff, and the nested structures become even uglier than gotos.
It may seem like a cheat at first sight, but the haskell approach to IO/global state is really elegant infact, and stays within the boundaries of a purely functional language. Most other functional programming languages do use a cheat, and are thus impure (and strict instead of lazy).
What haskell infact lets you do with its IO monad is construct instructions for a separate IO interpreter (that is not pure) within the Haskell runtime. It is a kind of DSL (domain-specific language), a concept that is used a lot in Haskell programs.
What the type signature
putStr:: String -> IO ()
can be interpreted to mean is that putStr is a function that given a string returns instructions for IO interpreter on how to print it out, without returning other value (()=void).
The bad thing about AOP is that it adds lots of side effects to function calls and can thus make the program very hard to reason about. This is completely orthogonal to (purely) functional programming that intends to remove side effects thus making it easier to reason about programs.
Functional programming: f(1) == f(1) always, with no other effects to "global state" etc.
Imperative programming without AOP: f(1) != f(1) necessarily at every point of the code, as the function can access globals. It can also change the global state, so its effect is more than returning its value; it can have side effets.
Imperative programming with AOP: Same as above, plus the side effects may happen somewhere unrelated to the definition of f itself.
CO-OPs are designed to be businesses by the people, for the people, without engaging in the communist-like practice of merging everything under the government's umbrella.
Hate to nitpick, but that's actually a socialist-like practice, instead of a communist. In socialism, the government controls all means of production, in communism, the community controls means of production (and the government is abolished).
Merging everything under the government's umbrella might be considered "scientific socialism" as proposed by Marx, although some Marxists reject this claim. It certainly is part of Leninist socialism, though.
But, talking of Co-ops, that's how things would likely be run in Libertarian socialism, or in a real (anarcho-) communist society. Remember: communism is a stateless, classless society; "communist state" is an oxymoron.
Yes it is. Ever head of LaTeX? Many journals in the more tech-savvy fields (maths/cs/physics/engineering) want camera ready documents using their provided LaTeX document class.
The important speed and scalability issues have nothing to do with Haskell, but the use of an advanced O(n^2) merging algorithm for everything.
Monotone does not provide anything close to such a thing, and thus no cherry picking. Arch provide both stupid and star merge, which again makes it more complex to use.
Darcs uses an O(n^2) merge algorithm. It's slower than a stupid three-way merge, but also does the Right Thing, always working single changesets/patches and not diffs between revisions. There are also some other problems with Web gets being slow that isn't inherent, but just a poor implementation.
GObject is an abomination. No-one in their right mind would us it. It is not easy to do OO in C, but there are a lot more convenient ways than GObject.
If autopackage is anything like autoconf, it won't help at all. It will work on just one distro and be broken on others.
I've said this many times, and in my opinion autoconf is totally wrong a solution to a problem. The proper solution would have been a package database database and library of wrappers or macros of common incompatibilities between flavours of *nix (syscalls, libc). As it stands, lots of redundant work is done by maintaining an -- often broken -- autoconf script for each package. I for one will never make autoconf a dependency -- only a discouraged option. It must always be possible to edit a Makefile.
Who cares about M$? Installing software on Windows is a lot of work, having to manually leech (or *shudder* by) the software and click through dozens of dialogs. apt-get is easy, and I have seldom had any problems with it.
Which brings me to the question, why would any free software author bother with autopackage when all decent distros provide mechanisms such as apt-get? And what about non-x86 architechtures. In my view autopackage support is _wasted time_. Any self-respecting user of my software already uses Debian, something based on it or another distro with a good package collection. Why would they want to use to something less convenient? Non-free software OTOH is irrelevant.
It's all relative. Perhaps 64kbps WMA sounds the same as a CD with as crappy DACs as found on most mp3 players and those crappy earbuds bundled with them. Now, switch to even half-decent hardware and you immediately hear the difference.
Firefly certainly didn't have the annoying full screen face switches, and if there was any swaying, it was much toned down from half-screen bounces of BSG that you can't but take notice of. I liked Firefly, and would have gladly seen it to be continued. (B5 is still the best sci-fi series ever, though.)
No, it's just the indoor scenes that are really annoying. Spaceships don't sail stormy seas. Real people don't zoom others faces to cover all of their field of vision during conversation and then switch to other heads without transition phase.
I hope the fire the cameraman at least. Judging from all the swaying, he's apparently drunk all the time at work.
I also don't like the cheap soap opera-esque quick switching between face shots. A few seconds of one face at full screen and then switch to another and then back. Very annoying.
Patches themselves do vary at least when a merger patch is needed (conflict). But this could be stored as a patch to the patch. It might even be possible to verify that the stored changes are correct.
"Anarcho-capitalism" is not anarchism. It is an oxymoron. Anti-capitalism has been central to anarchism alwaysds since its conception in the 19th century.
I think you're still confusing "property" and "personal possessions". Anarchists oppose property, but most believe in the right to personal possessions. Property is something that you may "own" although you do not use it yourself or need. Property is something that tends to generate more property, and more power. And that's why it's theft. For example, if you "own" an apartment building you can demand rent from its tenants and thus live as a freeloading capitalist parasite.
Respect for personal possessions means that nobody is allowed to go pillaging the house you current live in (if it isn't too big for you alone given the housing situation). But you do not "own" the house. When you report that you have moved out, or you haven't been using it in a (reasonable) while, anyone can move in. This is anarchism.
> There are a number of us who'd rather have an elevator than no elevator at all, and others who think that the involvement of any government in the operation of the elevator is a very bad idea.
And some who think that the involment of corporations in the operation of an elevator is even worse an idea than the involment of governments.
Slashdot Mirror
The idea in that construct is to let the first error handler continue to the second, so that the freeing code does not need to be duplicated. Breaking the freeing code into functions is a bit heavy solution, having to pass them all the variables to be freed and so on, and it would only increase the amount of code.
A function longer than a screenfull is too long, I never have such.
The example was in __plain C__. And besides, exceptions are worthless in a non-garbage collected language. (Ugly kludges in C++ don't count as proper GC.) You have to catch them at every point to free stuff, and the nested structures become even uglier than gotos.
It may seem like a cheat at first sight, but the haskell approach to IO/global state is really elegant infact, and stays within the boundaries of a purely functional language. Most other functional programming languages do use a cheat, and are thus impure (and strict instead of lazy).
:: String -> IO ()
What haskell infact lets you do with its IO monad is construct instructions for a separate IO interpreter (that is not pure) within the Haskell runtime. It is a kind of DSL (domain-specific language), a concept that is used a lot in Haskell programs.
What the type signature
putStr
can be interpreted to mean is that putStr is a function that given a string returns instructions for IO interpreter on how to print it out, without returning other value (()=void).
The bad thing about AOP is that it adds lots of side effects to function calls and can thus make the program very hard to reason about. This is completely orthogonal to (purely) functional programming that intends to remove side effects thus making it easier to reason about programs.
Functional programming: f(1) == f(1) always, with no other effects to "global state" etc.
Imperative programming without AOP: f(1) != f(1) necessarily at every point of the code, as the function can access globals. It can also change the global state, so its effect is more than returning its value; it can have side effets.
Imperative programming with AOP: Same as above, plus the side effects may happen somewhere unrelated to the definition of f itself.
Plain C:
....
void foo()
{
do some thing
if(error)
goto err1;
do something more;
if(error)
goto err2;
return;
err2:
free stuff
err1:
free more stuff
}
For anything else I shun goto.
> Electronic typesetting is not cheap,
Yes it is. Ever head of LaTeX? Many journals in the more tech-savvy fields (maths/cs/physics/engineering) want camera ready documents using their provided LaTeX document class.
The important speed and scalability issues have nothing to do with Haskell, but the use of an advanced O(n^2) merging algorithm for everything.
Monotone does not provide anything close to such a thing, and thus no cherry picking. Arch provide both stupid and star merge, which again makes it more complex to use.
Darcs uses an O(n^2) merge algorithm. It's slower than a stupid three-way merge, but also does the Right Thing, always working single changesets/patches and not diffs between revisions. There are also some other problems with Web gets being slow that isn't inherent, but just a poor implementation.
GObject is an abomination. No-one in their right mind would us it. It is not easy to do OO in C, but there are a lot more convenient ways than GObject.
If autopackage is anything like autoconf, it won't help at all. It will work on just one distro and be broken on others.
I've said this many times, and in my opinion autoconf is totally wrong a solution to a problem. The proper solution would have been a package database database and library of wrappers or macros of common incompatibilities between flavours of *nix (syscalls, libc). As it stands, lots of redundant work is done by maintaining an -- often broken -- autoconf script for each package. I for one will never make autoconf a dependency -- only a discouraged option. It must always be possible to edit a Makefile.
> Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example.
Yes they are. apt-get install is infinitely easier and more convenient.
Who cares about M$? Installing software on Windows is a lot of work, having to manually leech (or *shudder* by) the software and click through dozens of dialogs. apt-get is easy, and I have seldom had any problems with it.
Which brings me to the question, why would any free software author bother with autopackage when all decent distros provide mechanisms such as apt-get? And what about non-x86 architechtures. In my view autopackage support is _wasted time_. Any self-respecting user of my software already uses Debian, something based on it or another distro with a good package collection. Why would they want to use to something less convenient? Non-free software OTOH is irrelevant.
It's all relative. Perhaps 64kbps WMA sounds the same as a CD with as crappy DACs as found on most mp3 players and those crappy earbuds bundled with them. Now, switch to even half-decent hardware and you immediately hear the difference.
It is only a client restricted in features.
Wife?!? This is slashdot.
> Without such notions as copyright for instance, the GPL would be impossible.
The GPL would be unnecessary. Anyone has the right to copy everything as much as they wish (as it should be) so why not release the source too.
Property is theft. -- Pierre Joseph Proudhon.
Real from the perspective of a drunken man that tries to kiss everyone he sees and has a bionic neck.
Firefly certainly didn't have the annoying full screen face switches, and if there was any swaying, it was much toned down from half-screen bounces of BSG that you can't but take notice of. I liked Firefly, and would have gladly seen it to be continued. (B5 is still the best sci-fi series ever, though.)
No, it's just the indoor scenes that are really annoying. Spaceships don't sail stormy seas. Real people don't zoom others faces to cover all of their field of vision during conversation and then switch to other heads without transition phase.
I hope the fire the cameraman at least. Judging from all the swaying, he's apparently drunk all the time at work.
I also don't like the cheap soap opera-esque quick switching between face shots. A few seconds of one face at full screen and then switch to another and then back. Very annoying.
Patches themselves do vary at least when a merger patch is needed (conflict). But this could be stored as a patch to the patch. It might even be possible to verify that the stored changes are correct.
"Anarcho-capitalism" is not anarchism. It is an oxymoron. Anti-capitalism has been central to anarchism alwaysds since its conception in the 19th century.
I think you're still confusing "property" and "personal possessions". Anarchists oppose property, but most believe in the right to personal possessions. Property is something that you may "own" although you do not use it yourself or need. Property is something that tends to generate more property, and more power. And that's why it's theft. For example, if you "own" an apartment building you can demand rent from its tenants and thus live as a freeloading capitalist parasite.
Respect for personal possessions means that nobody is allowed to go pillaging the house you current live in (if it isn't too big for you alone given the housing situation). But you do not "own" the house. When you report that you have moved out, or you haven't been using it in a (reasonable) while, anyone can move in. This is anarchism.
> There are a number of us who'd rather have an elevator than no elevator at all, and others who think that the involvement of any government in the operation of the elevator is a very bad idea.
And some who think that the involment of corporations in the operation of an elevator is even worse an idea than the involment of governments.