Language:
switch to room list switch to menu My folders
Go to page: First ... 51 52 53 54 [55] 56 57 58 59 ... Last
[#] Mon Mar 22 2010 00:16:35 EDT from guest @ Uncensored

Subject: probando

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

probando



[#] Sun Mar 28 2010 23:54:21 EDT from ariadrianto @ Uncensored

Subject: Hosting and Internal Citadel Mail Server

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

Hi All,

I've very excited using citadel. This is the best and very easy to install email server in Ubuntu that i've ever done.

I just wondering about my case, and I still cannot solve right now. I want citadel as pull and sending email server, for head office email account only. and let my hosting domain take other email account.

I've hosting domain : myari.com (for example). and email account that I create : a@myari.com, b@myari.com, c@myari.com. "a" and "b" email account are in head office, and "c" is outside (branch in other city).

My Citadel has already installed on internal office.

  • When I create citadel using : myari.com. I can pull and sending email over citadel... But.. I can't send to "c" account, because there's no user "c" at citadel head office.

When I used mdaemon or any other email server, I usually using "myari2.com" as virtual server. I can't do that on citadel, there's always rejected message that there's no myari2.com domain.  I can't push branch / outside directly connect to citadel server. Because of our bandwith limitation.

Thanks In advice(s).

 

Best Rgds,

Ari Adrianto

 



[#] Sun Mar 28 2010 23:56:11 EDT from ariadrianto @ Uncensored

Subject: Hosting and Internal Citadel Mail Server

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

Ups... sorry..

Wrong room.

Just ignore this...

 

Ari

Sun Mar 28 2010 11:54:21 PM EDT from ariadrianto @ Uncensored Subject: Hosting and Internal Citadel Mail Server

Hi All,

I've very excited using citadel. This is the best and very easy to install email server in Ubuntu that i've ever done.

I just wondering about my case, and I still cannot solve right now. I want citadel as pull and sending email server, for head office email account only. and let my hosting domain take other email account.

I've hosting domain : myari.com (for example). and email account that I create : a@myari.com, b@myari.com, c@myari.com. "a" and "b" email account are in head office, and "c" is outside (branch in other city).

My Citadel has already installed on internal office.

  • When I create citadel using : myari.com. I can pull and sending email over citadel... But.. I can't send to "c" account, because there's no user "c" at citadel head office.

When I used mdaemon or any other email server, I usually using "myari2.com" as virtual server. I can't do that on citadel, there's always rejected message that there's no myari2.com domain.  I can't push branch / outside directly connect to citadel server. Because of our bandwith limitation.

Thanks In advice(s).

 

Best Rgds,

Ari Adrianto

 


 



[#] Mon Mar 29 2010 00:36:04 EDT from Harbard @ Uncensored

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

Damn, we missed a chance to flame someone for posting in the wrong room.  I should have been checking all day with my phone.....



[#] Wed Mar 31 2010 19:30:38 EDT from LoanShark @ Uncensored

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

Here's a Java trick, unanticipated by the language designers, that will
make the purists groan:

public <T> Enumeration<T> enumerate(String queryName,
ParamSetter paramSetter) {

// set up params omitted for clarity

return q.getResultCursor();
}

Traditionally, in the java.lang apis for instance, methods like this
would be declared "public Enumeration<?> ..." instead. However,
declaring it with a type parameter allows the compiler to use type
inference... and one aspect of type intference is that the resolution of
the <T> parameter is defaulted to the expected type of the lvalue, all
things being equal; so you can write this without a cast:

MyDTO foo = enumerate("query", ...);

... and MyDTO is inferred from context.

Google uses this trick throughout their Collections api, just to save
typing. My usage above is for database queries, and requires
@SuppressWarnings("unchecked")
on the implementation side,
shortcircuits strict type checking and makes the purists cringe, but
why not? The type checking was already runtime anyway, so why pass the
Class<T> parameter.

[#] Wed Mar 31 2010 19:57:37 EDT from Ford II @ Uncensored

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

I don't get it entirely.
oh, are you saying that even though you're not explicitly casting, the compiler is, because it matches the <T> for MyDTO or something like that?
The thing I think I get is that the compiler is doing an implicit cast for you and it's unchecked so it throws the warning, whereas if you had used <?> you'd have to explicitly cast it.
Is it that unexpected that the compiler pick an instance (wrong word I know) of Enumeration<> that fits the thing on the left side of the =?

[#] Wed Mar 31 2010 20:09:57 EDT from LoanShark @ Uncensored

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


because you used <T> T you don't have to explicitly cast, but you may have to provide <T> if type inference can't figure it out for you. In most cases, it can figure it out.

Actually there is a typo in my example, I meant Enumeration<MyDTO> foo = enumerate(...). <T> = MyDTO is inferred from the type signature Enumeration<MyDTO>.


Incidentally, the warning only appears when the compiler is parsing enumerate(); it doesn't appear every time you *call* enumerate(). So you only need one @suppresswarnings, in this example. In other examples (creating an empty collection) you don't even need @suppresswarnings at all, because there are no unchecked conversions.

There is a syntax for binding <T> to the method invocation if the type inference isn't able to figure it out: it acts sort of like a cast, but the semantics are a little different - type safety is still enforced, and it's only a hint:

Enumeration<MyDTO> foo = object.<MyDTO> enumerate() is the syntax.

[#] Thu Apr 01 2010 11:07:41 EDT from LoanShark @ Uncensored

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


so basically, the object.<T> enumerate(args); syntax is used for overload resolution I think.

[#] Thu Apr 01 2010 20:22:42 EDT from LoanShark @ Uncensored

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


More examples of this syntax,

public <T> T getBeanByName(String s) { ... return bean; }

Enables you to castless assign, like this:

Mybean b = getBeanByName("Mybean");

and chain like this:


foo.<Mybean> getBeanByName("Mybean").someCallOnMybean();

Eliminates parenthetical cast syntax.

[#] Sun Apr 04 2010 20:23:14 EDT from Ford II @ Uncensored

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

Fair enough. I have yet to find enough usefulness for templates to go that way, but good to know.

[#] Wed Apr 07 2010 04:21:14 EDT from dothebart @ Uncensored

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

[#] Wed Apr 07 2010 21:00:58 EDT from IGnatius T Foobar @ Uncensored

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

The once and forever champion? ;)

[#] Sat Apr 10 2010 07:55:21 EDT from dothebart @ Uncensored

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

funky shit:

https://support.mozilla.com/en-US/forum/1/479557

 

 

 

100KB limit in firefox browser only:

form enctype="multipart/form-data" action="uploads.php" method="POST"

No Limit:

form enctype="multipart/form-data" method="POST" action="uploads.php"

 

 



[#] Sat Apr 10 2010 15:21:50 EDT from IGnatius T Foobar @ Uncensored

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

That's an inexcusably stupid bug.



[#] Sun Apr 11 2010 14:18:34 EDT from LoanShark @ Uncensored

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


aren't they all?

[#] Sun Apr 11 2010 15:04:01 EDT from Ford II @ Uncensored

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

why is that dumb. Isn't the default method GET?
uploading 4gig in the url is dumb.

[#] Sun Apr 11 2010 15:05:28 EDT from Ford II @ Uncensored

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

oh osrry misread, I thought the POST was missing from the second one.
Yeah, that's insanely dumb.

[#] Mon Apr 12 2010 17:45:03 EDT from LoanShark @ Uncensored

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


The author of this blogroll is a prime example of someone who Just Doesn't Get It.

http://jacobsantos.com/2006/general/dont-advocate-subclasses/




This guy seriously doesn't understand syntactic sugar (If he thinks inner classes would bloat PHP's execution model), nor closures (if he thinks they're just a way to implement namespaces). I might add, it displays a serious lack of imagination and intelligence to say, "I don't need X... because I can't think of a reason to use X."

And that's a big part of what I don't like about PHP: it wasn't designed by people that had a languages background.

[#] Tue Apr 13 2010 11:43:20 EDT from IGnatius T Foobar @ Uncensored

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

Clue me in here, what is the definition of "syntactic sugar" ? Isn't the purpose of inner classes to restrict their scope so that they are only visible within the containing class? (This is where I tend to fall a little short of insight, being a mere tinkerer instead of a professional developer.)

The problem with PHP is that it wasn't really *designed* in the first place.
It was a neat hack that someone developed at one point, and was useful enough that it evolved into a language platform.

Go to page: First ... 51 52 53 54 [55] 56 57 58 59 ... Last