Language:
switch to room list switch to menu My folders
Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last
[#] Mon Sep 15 2014 00:41:17 EDT from ax25 @ Uncensored

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

Sig, if you have programmed in most any other language before, Python should be a breeze.  Much of what you learned should carry over.



[#] Mon Sep 15 2014 09:54:51 EDT from fleeb @ Uncensored

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


Yeah, that ease-of-learning makes Python a strong language. I think other scripting languages fail compared to Python, feature-for-feature, although some folks feel its whitespace requirements add pedantry to the language.

[#] Mon Sep 15 2014 12:30:05 EDT from LoanShark @ Uncensored

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


The whitespace thing makes Python a little less maintainable, a little harder to refactor and move code around.


That code block was probably properly indented when it was first written, but after your move, with no other syntactic cues to catch that you didn't format it properly... meh.

[#] Mon Sep 15 2014 12:32:14 EDT from fleeb @ Uncensored

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


Braces and parenthesis FTW!

[#] Mon Sep 15 2014 12:34:26 EDT from LoanShark @ Uncensored

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


(especially(parenthesis))

[#] Tue Sep 16 2014 19:38:44 EDT from LoanShark @ Uncensored

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


Why, oh why must IntelliJ's rebase/merge window be MODAL?!?

Batshit insane.

[#] Wed Sep 17 2014 08:54:09 EDT from fleeb @ Uncensored

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


Lazy programming.

[#] Wed Sep 17 2014 15:10:35 EDT from IGnatius T Foobar @ Uncensored

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

Esp. in posix oses, one would approach working with a network socket

like one would approach working with a file handle. And operations
that flush output to a file handle would naturally be expected to flush

output out a network socket.

Setting out to learn sockets programming without reading the Stevens book is dangerous.

Even more dangerous, however, is the newb who sees the behavior of TCP stacks discarding data on close, and instead of simply modifying his program to wait for an acknowledgement from the other end, decides to write his own "better than TCP" alternative.

[#] Wed Sep 17 2014 20:13:01 EDT from Sig @ Uncensored

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

The last programming I did was in Turbo Pascal in 1995, and it was not exactly a stunning success; so much so that I concluded I simply wasn't capable of programming. I'm still having fun with python; I'm almost done with the codecademy stream. I might finish that tonight if I can talk the kids into watching a movie or something. I had all sorts of plans for my Beaglebone Black, but at the moment it is just running an instance of ipython so I can have access to my notebooks on whichever computer I feel like using.

[#] Thu Sep 18 2014 04:53:11 EDT from fleeb @ Uncensored

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


IG:

I've been working on a project for my company that involves some HTTP transfers.
Another person working within the company is working on an almost identical project on behalf of the government, meaning that the government will keep all of that code. I was hired specifically to allow my company to keep the code that we're writing, potentially writing a patent or two for it.

The other guy is frustrated that the cannot just 'flush the socket' when sending data over TCP/IP. He doesn't want to 'write a protocol' because 'protocols are inherently difficult'.

He considers prepending TCP output with a size and waiting for acknowledgement enough of a protocol that he doesn't want to risk doing it.

So, instead, he relies on calling using a TCP shutdown message to help indicate that the packet is done, and waits for the other end to close. Which, I suppose, will work but... it seems like a very brittle approach when a very simplistic protocol isn't actually that difficult to accomplish.

[#] Thu Sep 18 2014 07:19:10 EDT from IGnatius T Foobar @ Uncensored

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


Apache has a "lingering close" socket function which does something similar.
LoanShark wrote a similar version for WebCit, and it's been in its current state for a decade and a half without breaking.

[ http://tinyurl.com/wc-ling-close ] if you want to take a peek at our implementation.

[#] Thu Sep 18 2014 18:42:14 EDT from LoanShark @ Uncensored

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

2014-09-16 19:38 from LoanShark @uncnsrd

Why, oh why must IntelliJ's rebase/merge window be MODAL?!?

Batshit insane.

Apparently it also causes IntelliJ to spin and eat 100% CPU until you finish your merge. I had to leave it in the modal overnight (grr) because shit was complicated. So I couldn't access my windows for unrelated projects that were not involved in the merge... (durrr)

[#] Thu Sep 18 2014 18:43:22 EDT from LoanShark @ Uncensored

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

Even more dangerous, however, is the newb who sees the behavior of TCP

stacks discarding data on close, and instead of simply modifying his
program to wait for an acknowledgement from the other end, decides to

write his own "better than TCP" alternative.

You're onto something here. What happens if the acknowledgement is discarded on close.

[#] Thu Sep 18 2014 18:44:38 EDT from LoanShark @ Uncensored

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

The other guy is frustrated that the cannot just 'flush the socket'
when sending data over TCP/IP. He doesn't want to 'write a protocol'

because 'protocols are inherently difficult'.

What a dingus. It's a good thing he's working on the goobermint side--also no surprise ;-)

[#] Thu Sep 18 2014 18:53:18 EDT from LoanShark @ Uncensored

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

Apache has a "lingering close" socket function which does something
similar.
LoanShark wrote a similar version for WebCit, and it's been in its
current state for a decade and a half without breaking.

Whoa. Forgot about that. Not sure if current versions of Apache still do it that way...

I'm still waiting for SO_MALINGER to fix the problem.

[#] Thu Sep 18 2014 20:03:19 EDT from IGnatius T Foobar @ Uncensored

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

Whoa. Forgot about that. Not sure if current versions of Apache still

do it that way...

Not gonna bother looking at their code, but I'll bet it's still there and gets called when HTTP/1.0 is in use and/or when "Connection: close" is specified.
Otherwise the server socket hangs out and the client will close when it damn well feels like it!

WebCit doesn't implement "Connection: keep-alive" in order to keep the code path simple, so the lingering close code will forever be in a state of "don't f***ing touch this; LoanShark got it right and you can't make it better"

[#] Thu Sep 18 2014 21:51:55 EDT from fleeb @ Uncensored

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

Hrm... are you not at risk of a malicious attack where someone consumes all your accepts?  I thought you might timeout and drop the connection, but if you aren't...?



[#] Thu Sep 18 2014 21:53:54 EDT from fleeb @ Uncensored

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

 

Wed Sep 17 2014 20:13:01 EDT from Sig @ Uncensored
The last programming I did was in Turbo Pascal in 1995, and it was not exactly a stunning success; so much so that I concluded I simply wasn't capable of programming.

Good programming stands on a mountain of failure.  A good programmer is someone who has failed in just about every way imaginable, but didn't give up.



[#] Fri Sep 19 2014 19:10:58 EDT from LoanShark @ Uncensored

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

Not gonna bother looking at their code, but I'll bet it's still there


nginx thinks they are smart enough to identify protocol states where it's not needed ;)

http://mailman.nginx.org/pipermail/nginx-devel/2011-July/001016.html

[#] Fri Sep 19 2014 23:55:42 EDT from Sig @ Uncensored

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

Good programming stands on a mountain of failure.  A good programmer
is someone who has failed in just about every way imaginable, but
didn't give up.


Perhaps, but so does terrible programming. Regardless, it amuses.

Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last