Re: Reading web pages

2012-01-19 Thread Bystroushaak

You can always use my module:
  https://github.com/Bystroushaak/DHTTPClient

On 19.1.2012 20:24, Timon Gehr wrote:

On 01/19/2012 04:30 PM, Xan xan wrote:

Hi,

I want to simply code a script to get the url as string in D 2.0.
I have this code:

//D 2.0
//gdmd-4.6
import std.stdio, std.string, std.conv, std.stream;
import std.socket, std.socketstream;

int main(string [] args)
{
if (args.length< 2) {
writeln("Usage:");
writeln(" ./aranya {,, ...}");
return 0;
}
else {
foreach (a; args[1..$]) {
Socket sock = new TcpSocket(new InternetAddress(a, 80));
scope(exit) sock.close();
Stream ss = new SocketStream(sock);
ss.writeString("GET" ~ a ~ " HTTP/1.1\r\n");
writeln(ss);
}
return 0;
}
}


but when I use it, I receive:
$ ./aranya http://www.google.com
std.socket.AddressException@../../../src/libphobos/std/socket.d(697):
Unable to resolve host 'http://www.google.com'

What fails?

Thanks in advance,
Xan.


The protocol specification is part of the get request.

./aranaya www.google.com

seems to actually connect to google. (it still does not work fully, I
get back 400 Bad Request, but maybe you can figure it out)


Re: Switch and break

2012-01-19 Thread Jonathan M Davis
On Friday, January 20, 2012 00:38:49 Era Scarecrow wrote:
> Personal experience in a program (not a language) is that having certain
> options on automatically usually is more of an annoyance, than manually
> turning them on. With that said, having explicit fall through sounds more
> useful than explicit breaking. However people coming form C and C++, the
> switch statement changes would be enough to cause their own bugs and
> perhaps discouragement.

The general rule with D is that C/C++ code must either compile as D code and 
have the same semantics, or it must not compile as D code. There are a few 
places where that isn't true (e.g. parameters which are static arrays are 
passed as values in D but not C), but it's fairly rare. So, aside from the 
fact that it would break lots of D code, making it so that fallthrough was 
explicit and breaking wasn't wouldn't be acceptable. Not to mention, most 
programmers would be confused by D's switch if it worked that way, since most 
languages went with implicit fallthrough (presumably because that's what C 
did). So, making it explicit for both seems like a good way to go.

> The true use in fallthrough, would be if you wanted more than one option to
> trigger a specific block of code. An example could be with flags, Unix
> flags have somewhat of a standard, so a program that defined it's own flags
> may later add secondary flags for compatibility purposes.
> 
> switch(i) {
> case 2:
> case 3:
> case 5:
> case 7:
> printf("%d is a prime between 1 and 10", i);
> break;
> default:
> printf("%d is not a prime between 1 and 10", i);
> }

That actually still triggers implicit fallthrough. -w disallows implicit 
fallthrough only in cases where a case statement has code in it.

- Jonathan M Davis


Re: Switch and break

2012-01-19 Thread H. S. Teoh
On Thu, Jan 19, 2012 at 07:19:07PM -0500, Jonathan M Davis wrote:
[...]
> Personally, I always compile with -w and have increasingly come to
> agree with Walter's thinking on this. I've long believed that
> responsible programmers don't commit code with warnings in it. And if
> warnings are never acceptable, then why are they warnings instead of
> errors? The only case where I think that warnings can be useful is if
> it's for something that you know needs to be fixed but which you don't
> need to fix right away as you're editing code. But considering how
> many programmers leave warnings in (I've never understood why aside
> from laziness), having them just creates problems IMHO.
[...]

The root cause of it is probably laziness, or being forced to check in
code at 5am for a deadline mandated by things beyond your control. And
once this happens, it just perpetuates itself. The poor sods who inherit
the initial bad code say, well this code generates warnings, but we
don't know what it does and we don't dare to touch it 'cos we don't
wanna break stuff that isn't our responsibility in the first place. And
then people get used to it: "This project always compiles with warnings,
it still works (sortof) so we don't care anymore". Which leads to the
sad state that many (most?) commercial projects find themselves in -
warnings everywhere and nobody bats an eyelid.

I have to say I like Walter's approach. If something is serious enough
to be a warning, it should really be an error. The programmer should be
made to fix it. If he *wants* to do something dangerous, give him a way
to *explicitly* override the error. Potentially dangerous things should
never be implicit. The default behaviour should always err on the safe
side---as Andrei so poignantly points out in his book.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and 
Linus Torvalds claims to be trying to take over the world. -- Anonymous


Re: Switch and break

2012-01-19 Thread Era Scarecrow
== Quote from Derek (ddparn...@bigpond.com)'s article
> I use a language that enables the coder to choose to use fall through or
> not. By default, falling through is disabled, so to produce the D effect
> one can code ...
>   switch i do
>   case 1 then
>   writeln("You wrote 1")
>fallthru
>   case 2 then
>   writeln("You wrote 2")
>fallthru
>   case 3 then
>   writeln("You wrote 3")
>fallthru
>   else case then
>   writeln("I said: 1 or 2 or 3!")
>  end switch

 Personal experience in a program (not a language) is that having certain 
options
on automatically usually is more of an annoyance, than manually turning them on.
With that said, having explicit fall through sounds more useful than explicit
breaking. However people coming form C and C++, the switch statement changes 
would
be enough to cause their own bugs and perhaps discouragement.

 The true use in fallthrough, would be if you wanted more than one option to
trigger a specific block of code. An example could be with flags, Unix flags 
have
somewhat of a standard, so a program that defined it's own flags may later add
secondary flags for compatibility purposes.

switch(i) {
  case 2:
  case 3:
  case 5:
  case 7:
printf("%d is a prime between 1 and 10", i);
break;
  default:
printf("%d is not a prime between 1 and 10", i);
}


Re: Reading web pages

2012-01-19 Thread Kapps
The host is www.google.com - http is only a web protocol. The DNS lookup 
is independent of HTTP, and thus should not include it. Note that you're 
also missing a space after the GET. Also, in terms of the example given, 
some servers won't like you not using the Host header, some won't like 
the GET being an absolute path instead of relative (but the two combined 
should make most accept it). There's a CURL wrapper added, and a higher 
level version should be available within the next release or two, you 
make want to look into that.


On 19/01/2012 9:30 AM, Xan xan wrote:

Hi,

I want to simply code a script to get the url as string in D 2.0.
I have this code:

//D 2.0
//gdmd-4.6
import std.stdio, std.string, std.conv, std.stream;
import std.socket, std.socketstream;

int main(string [] args)
{
 if (args.length<  2) {
writeln("Usage:");
writeln("   ./aranya {,, ...}");
return 0;
}
else {
foreach (a; args[1..$]) {
Socket sock = new TcpSocket(new InternetAddress(a, 80));
scope(exit) sock.close();
Stream ss = new SocketStream(sock);
ss.writeString("GET" ~ a ~ " HTTP/1.1\r\n");
writeln(ss);
}
return 0;
}
}


but when I use it, I receive:
$ ./aranya http://www.google.com
std.socket.AddressException@../../../src/libphobos/std/socket.d(697):
Unable to resolve host 'http://www.google.com'

What fails?

Thanks in advance,
Xan.




Re: Switch and break

2012-01-19 Thread Jonathan M Davis
On Friday, January 20, 2012 01:03:21 Matej Nanut wrote:
> I like the error DMD (-w) gives in this situation a lot. It has saved
> me precious minutes of debugging on more than one occasion. :)
> 
> And I never liked ‘warning:’s anyway. If something is dangerous enough
> to warrant a warning, the compiler may just as well enforce it in the
> language and be done with it.

That's pretty much Walter's take on it. He doesn't believe in warnings. Either 
something is an error or it's not. I'm pretty sure that he only added them 
because of complaints. And when he did, it was with -w - which makes them 
errors rather than displaying warnings but not preventing compilation as is 
normal with most compilers. It wasn't until after he got a bunch more 
complaints that he capitulated and added -wi which then makes dmd act like 
most compilers on the planet and display warnings without stopping 
compilation.

Personally, I always compile with -w and have increasingly come to agree with 
Walter's thinking on this. I've long believed that responsible programmers 
don't commit code with warnings in it. And if warnings are never acceptable, 
then why are they warnings instead of errors? The only case where I think that 
warnings can be useful is if it's for something that you know needs to be fixed 
but which you don't need to fix right away as you're editing code. But 
considering how many programmers leave warnings in (I've never understood why 
aside from laziness), having them just creates problems IMHO.

IMHO, anything which is definitively a problem should be an error, and anything 
that _might_ be a problem should be left up to lint-like tools.

The only real advantage of -w over having no warnings at this point is that it 
gives us a way to phase in errors.

- Jonathan M Davis


Re: Switch and break

2012-01-19 Thread Matej Nanut
On 20 January 2012 00:46, Jonathan M Davis  wrote:
> On Thursday, January 19, 2012 22:10:19 Peter Alexander wrote:
>> Consistency with C and C++ mainly.
>>
>> Some people find it convenient, but it is unarguably a frequent source
>> of bugs that we could do without.
>
> I'd be _very_ annoying if you couldn't do fall-through with switch-statements.
> That's a major feature and important for case statements IMHO. However, making
> fallthrough be explicit as D now does (with -w anyway) is definitely an
> improvement.
>
> - Jonathan M Davis

I like the error DMD (-w) gives in this situation a lot. It has saved
me precious minutes of debugging on more than one occasion. :)

And I never liked ‘warning:’s anyway. If something is dangerous enough
to warrant a warning, the compiler may just as well enforce it in the
language and be done with it.

Matej


Re: Switch and break

2012-01-19 Thread Jonathan M Davis
On Thursday, January 19, 2012 22:10:19 Peter Alexander wrote:
> Consistency with C and C++ mainly.
> 
> Some people find it convenient, but it is unarguably a frequent source
> of bugs that we could do without.

I'd be _very_ annoying if you couldn't do fall-through with switch-statements. 
That's a major feature and important for case statements IMHO. However, making 
fallthrough be explicit as D now does (with -w anyway) is definitely an 
improvement.

- Jonathan M Davis


Re: Switch and break

2012-01-19 Thread Manfred Nowak
RenatoL wrote:

> why in D we are not obligated

This depends on how the designer wants the coders to think about the 
semantics of a .

If a  _always_ is an _additional_ entry into an otherwise linear 
sequence of commands, then fall-through as standard is the consequence.

If a  _always_ breaks the linear sequence of commands, then an 
implicit `break' as standard is the consequence.

Because s outside of `switche's are always additional entries 
only, one has to specify `case's as not to be s or to have a 
good reason for the different handling of `label's.

So it is up to you to show that `case's are not`label's or give a good 
reason, if you want a different handling.

-manfred
 


Re: Switch and break

2012-01-19 Thread bearophile
Timon Gehr:

> Compile with -w enabled and the compiler will complain about implicit 
> fall-through.

And eventually this specific -w behavior will be enforced even without -w, 
becoming part of D2, just like the use of "override".

Bye,
bearophile


Re: Switch and break

2012-01-19 Thread Derek

On Fri, 20 Jan 2012 08:55:06 +1100, RenatoL  wrote:


Just curious: why in D we are not obligated to use break in every
branch of a swicth structure?


a) C/C++ compatibility
b) Walter likes this construct and uses it in his code.

I use a language that enables the coder to choose to use fall through or  
not. By default, falling through is disabled, so to produce the D effect  
one can code ...


switch i with fallthru do
case 1 then
writeln("You wrote 1")
case 2 then
writeln("You wrote 2")
case 3 then
writeln("You wrote 3")
else case then
writeln("I said: 1 or 2 or 3!")
end switch

or alternatively ...

switch i do
case 1 then
writeln("You wrote 1")
 fallthru
case 2 then
writeln("You wrote 2")
 fallthru
case 3 then
writeln("You wrote 3")
 fallthru
else case then
writeln("I said: 1 or 2 or 3!")
end switch


--
Derek Parnell
Melbourne, Australia


Re: Switch and break

2012-01-19 Thread RenatoL
>Compile with -w enabled and the compiler will complain about
implicit
fall-through. You can use goto case/goto default for explicit fall-
through.<

This gives a little relief


Re: Switch and break

2012-01-19 Thread Timon Gehr

On 01/19/2012 10:55 PM, RenatoL wrote:

Just curious: why in D we are not obligated to use break in every
branch of a swicth structure? That is:
switch (i)
{
case 1:
writeln("You wrote 1");
case 2:
writeln("You wrote 2");
case 3:
writeln("You wrote 3");
default:
writeln("I said: 1 or 2 or 3!");
 }

is good in D, while, for example, similar code in C# is incorrect
and if you want to play with fall through you have to make some
trick. Again this behaviour of D seems a bit buggy, to me. Are
there design reasons?


Compile with -w enabled and the compiler will complain about implicit 
fall-through. You can use goto case/goto default for explicit fall-through.


Re: Switch and break

2012-01-19 Thread Peter Alexander

On 19/01/12 9:55 PM, RenatoL wrote:

Just curious: why in D we are not obligated to use break in every
branch of a swicth structure? That is:
switch (i)
{
case 1:
writeln("You wrote 1");
case 2:
writeln("You wrote 2");
case 3:
writeln("You wrote 3");
default:
writeln("I said: 1 or 2 or 3!");
 }

is good in D, while, for example, similar code in C# is incorrect
and if you want to play with fall through you have to make some
trick. Again this behaviour of D seems a bit buggy, to me. Are
there design reasons?


Consistency with C and C++ mainly.

Some people find it convenient, but it is unarguably a frequent source 
of bugs that we could do without.




Switch and break

2012-01-19 Thread RenatoL
Just curious: why in D we are not obligated to use break in every
branch of a swicth structure? That is:
switch (i)
{
case 1:
writeln("You wrote 1");
case 2:
writeln("You wrote 2");
case 3:
writeln("You wrote 3");
default:
writeln("I said: 1 or 2 or 3!");
}

is good in D, while, for example, similar code in C# is incorrect
and if you want to play with fall through you have to make some
trick. Again this behaviour of D seems a bit buggy, to me. Are
there design reasons?


Changes for newer version...

2012-01-19 Thread Era Scarecrow
 Been a bit out of it for a while, but finding enough tools at my disposal I 
feel I can work on/convert a project now.

 I happen to have one of the first printing books (without the name on the 
cover), and although it may be worth millions in a few years, apparently 
there's been enough changes that certain features are not familiar in the 
discussions.

 So I need to ask since I don't see any obvious pages that describe it. What 
are the changes to D2, since the book's release? What has externally changed? 
(Internal implementation of features need not be mentioned if it's transparent 
to the programmer and user).


Re: Reading web pages

2012-01-19 Thread Timon Gehr

On 01/19/2012 04:30 PM, Xan xan wrote:

Hi,

I want to simply code a script to get the url as string in D 2.0.
I have this code:

//D 2.0
//gdmd-4.6
import std.stdio, std.string, std.conv, std.stream;
import std.socket, std.socketstream;

int main(string [] args)
{
 if (args.length<  2) {
writeln("Usage:");
writeln("   ./aranya {,, ...}");
return 0;
}
else {
foreach (a; args[1..$]) {
Socket sock = new TcpSocket(new InternetAddress(a, 80));
scope(exit) sock.close();
Stream ss = new SocketStream(sock);
ss.writeString("GET" ~ a ~ " HTTP/1.1\r\n");
writeln(ss);
}
return 0;
}
}


but when I use it, I receive:
$ ./aranya http://www.google.com
std.socket.AddressException@../../../src/libphobos/std/socket.d(697):
Unable to resolve host 'http://www.google.com'

What fails?

Thanks in advance,
Xan.


The protocol specification is part of the get request.

./aranaya www.google.com

seems to actually connect to google. (it still does not work fully, I 
get back 400 Bad Request, but maybe you can figure it out)


Re: tdpl: function literals versus delegate lierals

2012-01-19 Thread Manfred Nowak
bearophile wrote:

> instead of SIMDs added

Most delevopers at the same time like to turf their old errors and are 
keen to do something knew.

-manfred 


Reading web pages

2012-01-19 Thread Xan xan
Hi,

I want to simply code a script to get the url as string in D 2.0.
I have this code:

//D 2.0
//gdmd-4.6
import std.stdio, std.string, std.conv, std.stream;
import std.socket, std.socketstream;

int main(string [] args)
{
if (args.length < 2) {
writeln("Usage:");
writeln("   ./aranya {, , ...}");
return 0;
}
else {
foreach (a; args[1..$]) {
Socket sock = new TcpSocket(new InternetAddress(a, 80));
scope(exit) sock.close();
Stream ss = new SocketStream(sock);
ss.writeString("GET" ~ a ~ " HTTP/1.1\r\n");
writeln(ss);
}
return 0;
}
}


but when I use it, I receive:
$ ./aranya http://www.google.com
std.socket.AddressException@../../../src/libphobos/std/socket.d(697):
Unable to resolve host 'http://www.google.com'

What fails?

Thanks in advance,
Xan.


Re: tdpl: function literals versus delegate lierals

2012-01-19 Thread bearophile
Timon Gehr:

> I am not very happy about this particular quirk of is expressions:

I'd like to see is expressions a bit re-designed instead of SIMDs added to DMD 
:-|

Bye,
bearophile


Re: tdpl: function literals versus delegate lierals

2012-01-19 Thread Timon Gehr

On 01/19/2012 05:41 PM, Jerome BENOIT wrote:

Hello List:

On my box, the following D source, inspired by the subsection 5.6.1 of
tDpl,
does not work as expected:

-
// adhoc_06.d

import std.stdio;

unittest {
// Tersest, most convenient code
auto f = (int i) {};
writeln(typeid(f));
assert(is(f == function));
}

void main() {}
-

I get:

void delegate()
core.exception.AssertError@adhoc_06.d(7): unittest failure


According to the book, the assertion is true and f is a function
but not a literal.

What is going wrong ?

Thanks in advance,
Jerome


Many things, actually. You are looking at both an error in TDPL and a 
compiler bug. The compiler bug is already fixed in git head and will not 
exist in the next release. See 
http://d.puremagic.com/issues/show_bug.cgi?id=3235


In the line:

auto f = (int i) {};

f is deduced as void delegate(int) pure nothrow @safe instead of as void 
function(int) pure nothrow @safe. This is the compiler bug that has been 
fixed.



In the line:

assert(is(f == function));

TDPL contains an error. Is expressions can be used to query some 
properties of types. If an involved type is not a well-formed type the 
result is false. Since f is a variable and not a type, the is expression 
yields false. is(T == function) tests whether or not T is a function 
type. Therefore, the line should actually read is(typeof(*f)==function), 
as f is a function pointer.


I am not very happy about this particular quirk of is expressions:

void delegate() dg; // declares a delegate
void function() fp; // declares a function _pointer_

assert( is(typeof(dg) == delegate));
assert(!is(typeof(fp) == function)); // the is expression tests whether 
it is a function, not whether it is a function pointer

assert(is(typeof(*fp) == function));

You may want to use std.traits.IsFunctionPointer and 
std.traits.IsDelegate instead.




tdpl: function literals versus delegate lierals

2012-01-19 Thread Jerome BENOIT

Hello List:

On my box, the following D source, inspired by the subsection 5.6.1 of tDpl,
does not work as expected:

-
// adhoc_06.d

import std.stdio;

unittest {
// Tersest, most convenient code
auto f = (int i) {};
writeln(typeid(f));
assert(is(f == function));
}

void main() {}
-

I get:

void delegate()
core.exception.AssertError@adhoc_06.d(7): unittest failure


According to the book, the assertion is true and f is a function
but not a literal.

What is going wrong ?

Thanks in advance,
Jerome