Language:
switch to room list switch to menu My folders
Go to page: 1 [2] 3 4 5 6 ... Last
[#] Fri Jul 10 2009 11:35:16 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

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.



[#] Fri Jul 10 2009 15:48:50 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Mono ought to be thought of as the .net counterpart to Wine -- simply as a way of running Windows software on Linux. Deliberately building up the .net ecosystem is stupid. (Of course, if Miguel is an MS-paid mole, as I've long been saying he is, it makes sense.)

[#] Fri Jul 10 2009 16:40:14 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Monochrome, by contrast, ought to be thought of as Aahz's boss.

[#] Fri Jul 10 2009 17:21:20 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Fri Jul 10 2009 22:47:55 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

On the other hand, Silverlight's #1 banner account -- Major League Baseball -- switched back to Flash because Silverlight was causing too many problems.

[#] Sat Jul 11 2009 10:20:37 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Microsofts aproach in destroying java by just creating something else which


Reports of Java's destruction are greatly exaggerated.

[#] Sat Jul 11 2009 11:51:42 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

This is true. Java is still the 'lingua franca' of business logic, having replaced COBOL in this role. People developing in .NET are typically those who would have used "whatever Microsoft is selling" anyway.

[#] Sat Jul 11 2009 14:02:33 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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...



[#] Sat Jul 11 2009 22:42:03 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I can't see how switching entire environments from java to .net could possibly be better if you factor in the transition costs.
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.

[#] Sun Jul 12 2009 08:35:59 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Thu Jul 16 2009 14:39:35 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So there. I finally did it.
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.
frikkin amazing.
The problem is that even the cit client to citserver does a keepalive every 30 seconds.
any way to shut that off?

[#] Thu Jul 16 2009 15:07:07 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

well, I recompiled the cit client with S_KEEPALIVE set to 3600. I guess I'll see if the server hangs up on me in that time.

I just don't want tons of unnecessary proxy hits to show up on the proxy logs just for the keepalives.

[#] Thu Jul 16 2009 15:38:17 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

well, that didn't work, the server hung up on me after about 20 minutes. :-(

[#] Fri Jul 17 2009 08:36:34 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

There's a watchdog timer that is expecting those keepalives you disabled.
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.

[#] Fri Jul 17 2009 09:51:27 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

okay, cool. will do.

[#] Fri Jul 17 2009 10:55:12 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I decided to put "horrible hack" into google code search and the first thing that came up?
http://www.google.com/codesearch?hl=en&lr=&q=horrible+hack&sbtn=Search

Google is evil, now that we can see their own commentary, we know it to be true. :-)

[#] Fri Jul 17 2009 11:25:55 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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:

&str[0];

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)[0]; as a consequence.

[#] Fri Jul 17 2009 11:27:42 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Why would you ever use &str[0] instead of simply str ?

[#] Fri Jul 17 2009 11:31:30 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


std::string str;
str = "some value";

const char* char_pointer = str.c_str();

char* writable_char_pointer = &str[0];

It's for the 'writable' char pointer that I might use &str[0]. 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[0] trick lets you do it.

[#] Fri Jul 17 2009 11:37:00 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Or, let me see if I can demonstrate it another way:

void unsafe_fn()
{
char* buffer = 0;
buffer = new char[25];

some_unsafe_throwing_fn( buffer );

delete[] buffer;
}

void safe_fn()
{
std::string buffer;
buffer.resize( 25 );

some_unsafe_throwing_fn( &buffer[0] );
}

With 'unsafe_fn()', if some_unsafe_throwing_fn throws an exception, you'll leak
memory.

with 'safe_fn', if some_unsafe_throwing_fn throws an exception, the memory within
buffer will become deallocated automatically. No leaks.

Go to page: 1 [2] 3 4 5 6 ... Last