Fr Jul 10 2009 11:11:59 EDT von LoanShark @ Uncensored
And Python sux0rs. Anyway, the Sun JVM implementation is now *fully* gpl'd and available as an "openjava" (or something like that) package in Fedora 10/11.
but... they're a little late to the game.
they 've missed it ... lets say by 2 years.
Microsofts aproach in destroying java by just creating something else which is "better" did it in the end. Thats one of the core arguments out of that article (without even talking about it) if you know how Microsoft works and how their fud works.
The Icasa "they won't sue us" article is just right in time by the way.
but.. hey... have a look at the recent past...
If you fool me... shame on you. If you fool me twice, shame on me.
Unless there is a juristicaly proven certificate (or microsoft donating its patents to for example the ISO...) I won't use mono.
Monochrome, by contrast, ought to be thought of as Aahz's boss.
en contraire to wine, mono isn't just doing an api wrapper.
its implementing a whole compiler and interpreter infrastructure that m$ did; and is obviously using patents here, while wine did just implement the API themselves, this goes way beyond.
And I in person, are realy against the adoption of that.
M$ saying "we won't sue you" is just an indicator for me, that they would indeed be able to sue, and will do once mono gained enough market share.
Btw, it seems as if the silverlight thing caught on well for example at an indian youtube counterpart, since indian users seem to largely depend on silverlight.
Microsofts aproach in destroying java by just creating something else which
Reports of Java's destruction are greatly exaggerated.
I know quiet some who say that they switched from java to .net and its better for them.
I think for desktop applications its better, since java looks like an alien everywhere...
You basiaclly have to write from scratch and learn an entirely new development system and language.
And if you were never a windows weenie, there's a lot to learn.
exact. its probably them, who would have decided to write a program for windows in java. And once they don't do it in java but c-carpet, they will do asp.net stuff to if they have to do s.th.
It took a lot of fighting but I got the text client to compile on solaris, because I figure running the cit client at home makes the actual typing lag, but if I run the client locally, it's all snappy and then only the server messages go over the network.
So it works. I'm on my sun machine with no access to the internet, I have a reverse ssh tunnel going to my desktop where my sshh client makes a persistent socket to my machine at home, which then forwards the connetion to uncensored.citadel.org.
and it works.
The problem is that even the cit client to citserver does a keepalive every 30 seconds.
any way to shut that off?
I just don't want tons of unnecessary proxy hits to show up on the proxy logs just for the keepalives.
On Uncensored it's set to 900 seconds (15 minutes). So if you want to stay logged in during the day without too much idle traffic, you might consider setting S_KEEPALIVE To 870 seconds (14 minutes and 30 seconds) or less.
Google is evil, now that we can see their own commentary, we know it to be true. :-)
Heh, the STLStringResizeUninitialized function is done 'the correct way'... I'm guessing there's some other non-open-source code within Google where they're doing something really, really foul.
Their 'string_as_array' function, though, could be done in a way that's more clear:
I use that technique quite a lot for my work, and it is portable across at least three or four different compilers that I've used. According to Josuttis, it should work across all compilers for std::string, even though it's not explicitly stated as legal within the standard.
Google's way looks right, too, but just doesn't seem as appealing to me as mine.
But then, they're working with a pointer to a string. That has to add a layer of weirdness. It's probably closer to &(*str); as a consequence.
str = "some value";
const char* char_pointer = str.c_str();
char* writable_char_pointer = &str;
It's for the 'writable' char pointer that I might use &str. It's not entirely the right thing to do, but for std::string and std::vector, it lets you create a kind of memory-managed buffer.
Imagine a buffer that, when it goes out of scope, it's deallocated. That's effectively what std::vector and std::string give you... it's just that you don't have a normal way to access the buffer directly. But, that &str trick lets you do it.
char* buffer = 0;
buffer = new char;
some_unsafe_throwing_fn( buffer );
buffer.resize( 25 );
some_unsafe_throwing_fn( &buffer );
With 'unsafe_fn()', if some_unsafe_throwing_fn throws an exception, you'll leak
with 'safe_fn', if some_unsafe_throwing_fn throws an exception, the memory within
buffer will become deallocated automatically. No leaks.