Re: toString multiple overrides
On Friday, February 10, 2012 22:41:20 Ellery Newcomer wrote:
> dmd 2.057
>
> Two mixin templates, each define toString, mix them in to your class and ..
>
> Error: function test.X.T2!().toString multiple overrides of same function
>
> So this behavior is new, but is it sensical?
>
>
> Sample code:
>
> mixin template T1(){
> string toString(){
> return "1";
> }
> }
> mixin template T2(){
> string toString(){
> return "2";
> }
> }
> class X{
> mixin T1!() a;
> mixin T2!() b;
> }
>
> void main(){
> }
And why _wouldn't_ that be an error? You have to identical function
signatures.
class X
{
string toString() { return "1"; }
string toString() { r eturn "2"; }
}
isn't legal. What's the difference between that and your mixins?
And can template mixins mixin virtual functions? Normally, templated functions
can't be virtual (template mixins are instantiated regardless, so they might
be virtual when mixed into classes - I'm not sure). And if template mixins
aren't virtual, then _both_ mixins should be illegal, since Object already
have a virtual toString in it.
Regardless, I don't see how you could think that your code would be legal.
- Jonathan M Davis
Re: DLL Injection
Everything works perfectly if I write the DLL in C++ (and I've never had any errors with C++ DLL's before that are similar to this one). If I remove the cast line and MessageBox()'s in the D version, then I still get the error.
toString multiple overrides
dmd 2.057
Two mixin templates, each define toString, mix them in to your class and ..
Error: function test.X.T2!().toString multiple overrides of same function
So this behavior is new, but is it sensical?
Sample code:
mixin template T1(){
string toString(){
return "1";
}
}
mixin template T2(){
string toString(){
return "2";
}
}
class X{
mixin T1!() a;
mixin T2!() b;
}
void main(){
}
Re: dmd thrashes fedora
On 02/11/2012 12:16 AM, Ellery Newcomer wrote: On 02/10/2012 01:59 PM, Timon Gehr wrote: I seem to have more RAM than you. The behavior is apparently caused by a Phobos bug: That is likely. The code is a dustmite reduction, so I don't really care what the error is, just that it shouldn't be killing my computer. ulimit -v seems to fix it nicely enough (if you don't mind that the only output is Error: out of memory) Think this issue is bugzilla worthy? Probably yes.
Re: dmd thrashes fedora
On 02/10/2012 01:59 PM, Timon Gehr wrote: I seem to have more RAM than you. The behavior is apparently caused by a Phobos bug: That is likely. The code is a dustmite reduction, so I don't really care what the error is, just that it shouldn't be killing my computer. ulimit -v seems to fix it nicely enough (if you don't mind that the only output is Error: out of memory) Think this issue is bugzilla worthy?
Re: Arrays - Inserting and moving data
On Friday, February 10, 2012 13:32:56 Marco Leise wrote: > I know that feeling. I had no exposure to functional programming and > options like chain never come to my head. Although "map" is a concept that > I made friends with early. It would benefit your programming in general to learn a functional programming language and become reasonably proficient in it, even if you don't intend to program in it normally. It'll increase the number of tools in your programming toolbox and improve your programming in other programming languages. It's something that not enough programmers get sufficient exposure to IMHO. - Jonathan M Davis
Re: Socket: The connection was reset
On Fri, Feb 10, 2012, at 07:44 PM, nrgyzer wrote:
> Yep, thanks... but I already checked out the return value and the problem
> is "If the socket is blocking, receive waits until there is data to be
> received.". The following
> socket blocks and the server doesn't respond:
>
> while(true) {
>
> Socket cs = s.accept();
> ubyte[] header;
> ubyte[1] buffer;
> while (cs.receive(buffer)) header ~= buffer;
>
> cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello World");
> cs.close();
>
> }
>
> cs.receive() blocks (because no more data is available) - cs.sendTo() and
> cs.close() isn't called, because cs.receive() waits for more data. I can
> solve the problem by using
> non-blocking sockets:
>
> while(true) {
>
> Socket cs = s.accept();
> cs.blocking(false);
> ubyte[] header;
> ubyte[1] buffer;
> while (cs.receive(buffer)) header ~= buffer;
>
> cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello World");
> cs.close();
>
> }
>
> But... how can I make sure that I got all data sent by the
> client/browser?
It depends on the protocol. In HTTP you should check if the receive buffer
contains CRLF CRLF:
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Example_session
Re: Signature conditions
On Fri, Feb 10, 2012 at 08:53:58PM +0100, Timon Gehr wrote:
> On 02/10/2012 07:50 PM, H. S. Teoh wrote:
[...]
> >On that note, I discovered that if you want signature constraints on
> >a derived class, the syntax is unbearably ugly:
> >
> > class Derived(T)
> > if (/* conditions */)
> > : Base
> > {
> > ...
> > }
> >
> >I would have expected the syntax to be like this instead:
> >
> > class Derived(T) : Base
> > if (/* conditions */)
> > {
> > ...
> > }
[...]
> It makes more sense as it is. Consider the instantiation
> 'Derived!int' and the condition 'is(typeof(T)==class)'.
Well, to me, the "if" condition should apply to the entire class
specification "class Derived(T) : Base", and not just to Derived(T). For
example, something like this wouldn't be in a logical sequence:
class Derived(T)
if (is(Base!T ...))
: Base!T
{
...
}
since you'll want the condition to restrict what values Base!T can take
on. This would be more readable:
class Derived(T) : Base!T
if (is(Base!T ...))
{
...
}
T
--
"I'm running Windows '98."
"Yes."
"My computer isn't working now."
"Yes, you already said that."
-- User-Friendly
Re: dmd thrashes fedora
On 02/10/2012 08:38 PM, Ellery Newcomer wrote: when I run dmd -gc -oftopo topo.d multi_index.d replace.d on the contents of http://personal.utulsa.edu/~ellery-newcomer/bad.zip in fedora 16 x86_64 with dmd 2.057 64 bit dmd starts thrashing like there is no tomorrow and generally locks up my entire system. Can anyone confirm this behavior? I seem to have more RAM than you. The behavior is apparently caused by a Phobos bug: /usr/include/d/dmd/phobos/std/functional.d(185): Error: template instance std.functional.binaryFunImpl!(pred,parm1Name,parm2Name).Body!(dchar,string) recursive expansion
Re: Signature conditions
On 02/10/2012 07:50 PM, H. S. Teoh wrote:
On Fri, Feb 10, 2012 at 07:36:38PM +0100, David Nadlinger wrote:
On 2/10/12 7:35 PM, David Nadlinger wrote:
class(T) if (__traits(compiles, { std.utf.decode(T.init); } )) { … }
(untested, you might have to return the value from the delegate to
avoid an expression-without-effect error)
Works for me. Thanks!!
On that note, I discovered that if you want signature constraints on a
derived class, the syntax is unbearably ugly:
class Derived(T)
if (/* conditions */)
: Base
{
...
}
I would have expected the syntax to be like this instead:
class Derived(T) : Base
if (/* conditions */)
{
...
}
But this doesn't compile.
T
It makes more sense as it is. Consider the instantiation 'Derived!int'
and the condition 'is(typeof(T)==class)'.
Re: Immutable immutable strings??
On 02/10/2012 07:10 PM, Marco Leise wrote: Am 10.02.2012, 19:07 Uhr, schrieb H. S. Teoh : I'm not sure whether the following a compiler/language bug or a Phobos bug, but it's definitely some kind of bug: auto s = "abc"; immutable t = "def"; writeln(typeid(s)); // immutable(char)[] writeln(typeid(t)); // immutable(immutable(char)[]) // (what is this supposed to mean?!) That is supposed to mean that you can neither modify the values of the characters in the array nor the array itself: immutable(char[]) does already say that. t[1] = 'a'; // immutable(char) t.length = 2; // immutable(...[]) It is a runtime bug, and has been discussed before, but I am not sure if it has been filed (probably yes). A similar bug has recently been fixed for the compiler's internal formatting exposed through error messages/.stringof: http://d.puremagic.com/issues/show_bug.cgi?id=6941
Re: Immutable immutable strings??
On 02/10/12 19:22, H. S. Teoh wrote: > On Fri, Feb 10, 2012 at 07:17:22PM +0100, Artur Skawina wrote: >> On 02/10/12 19:07, H. S. Teoh wrote: >>> I'm not sure whether the following a compiler/language bug or a Phobos >>> bug, but it's definitely some kind of bug: >>> >>> auto s = "abc"; >>> immutable t = "def"; >>> >>> writeln(typeid(s)); // immutable(char)[] >>> writeln(typeid(t)); // immutable(immutable(char)[]) >>> // (what is this supposed to mean?!) >> >> The array itself is immutable, not just the elements. > > I see. > > >>> char ch = 'c'; >>> bool b = canFind(s, ch);// OK >>> bool c = canFind(t, ch);// Compile error?? >>> >>> The compile error is: >>> >>> test.d:11: Error: template std.algorithm.canFind(alias pred = "a == >>> b",Range,V) if (is(typeof(find!(pred)(range,value does not match any >>> function template declaration >>> test.d:11: Error: template std.algorithm.canFind(alias pred = "a == >>> b",Range,V) if (is(typeof(find!(pred)(range,value cannot deduce >>> template function from argument types !()(immutable(char[]),char) >>> >>> Can somebody explain what's going on here? >> >> FWIW, it compiles fine here. > [...] > > Is it a Phobos bug that got fixed recently? I'm still using gdc-4.6. No idea, i'm using gcc version 4.6.3 20120106 (prerelease gdc 0.31 - r748:ab99d67f04c2, using dmd 2.057) artur
Re: Socket: The connection was reset
Yep, thanks... but I already checked out the return value and the problem is
"If the socket is blocking, receive waits until there is data to be received.".
The following
socket blocks and the server doesn't respond:
while(true) {
Socket cs = s.accept();
ubyte[] header;
ubyte[1] buffer;
while (cs.receive(buffer)) header ~= buffer;
cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello World");
cs.close();
}
cs.receive() blocks (because no more data is available) - cs.sendTo() and
cs.close() isn't called, because cs.receive() waits for more data. I can solve
the problem by using
non-blocking sockets:
while(true) {
Socket cs = s.accept();
cs.blocking(false);
ubyte[] header;
ubyte[1] buffer;
while (cs.receive(buffer)) header ~= buffer;
cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello World");
cs.close();
}
But... how can I make sure that I got all data sent by the client/browser?
== Auszug aus DNewbie (r...@myopera.com)'s Artikel
> nrgyzer,
> please check the return value of 'receive'.
> http://dlang.org/phobos/std_socket.html#receive
> On Fri, Feb 10, 2012, at 02:06 PM, nrgyzer wrote:
> > Works perfectly, thanks :)
> > But... how can I read the complete HTTP-header? When I try the following:
> >
> > string header;
> > ubyte[1024] buffer;
> > while (cs.receive(buffer)) header ~= buffer;
> >
> > ... it works as long as the header doesn't have a length like 1024, 2048,
> > 3072... Otherwise cs.receive() blocks forever and the server doesn't
> > respond
> > anything. Is there any solution how to prevent/solve this problem?
> >
> >
> > == Auszug aus DNewbie (r...@myopera.com)'s Artikel
> > > Try this
> > > while(true) {
> > > Socket cs = s.accept();
> > > cs.receive(new byte[1024]);
> > > cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello
> > World");
> > > cs.close();
> > > }
> > > On Thu, Feb 9, 2012, at 07:31 PM, Nrgyzer wrote:
> > > > Hi guys,
> > > >
> > > > I wrote the following few lines:
> > > >
> > > > private {
> > > >
> > > > import std.socket;
> > > >
> > > > }
> > > >
> > > > void main() {
> > > >
> > > > Socket s = new TcpSocket();
> > > > s.bind(new InternetAddress(80));
> > > > s.listen(0);
> > > >
> > > > while(true) {
> > > >
> > > > Socket cs = s.accept();
> > > > cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length:
> > > > 11\r\n\r\nHello
> > World");
> > > > cs.close();
> > > >
> > > > }
> > > >
> > > > s.close();
> > > >
> > > > }
> > > >
> > > > The code compiles successfully and I also the server also responses with
> > > > "Hello World", but when I reload the page I sometimes get the following
> > > > error (Firefox): "The
> > > > connection was reset" - I also often get the same error in other
> > > > browsers. Is there anything wrong with the code?
> > > >
> > > > Thanks in advance!
> > > >
> >
> >
dmd thrashes fedora
when I run dmd -gc -oftopo topo.d multi_index.d replace.d on the contents of http://personal.utulsa.edu/~ellery-newcomer/bad.zip in fedora 16 x86_64 with dmd 2.057 64 bit dmd starts thrashing like there is no tomorrow and generally locks up my entire system. Can anyone confirm this behavior?
Re: Socket: The connection was reset
nrgyzer,
please check the return value of 'receive'.
http://dlang.org/phobos/std_socket.html#receive
On Fri, Feb 10, 2012, at 02:06 PM, nrgyzer wrote:
> Works perfectly, thanks :)
> But... how can I read the complete HTTP-header? When I try the following:
>
> string header;
> ubyte[1024] buffer;
> while (cs.receive(buffer)) header ~= buffer;
>
> ... it works as long as the header doesn't have a length like 1024, 2048,
> 3072... Otherwise cs.receive() blocks forever and the server doesn't
> respond
> anything. Is there any solution how to prevent/solve this problem?
>
>
> == Auszug aus DNewbie (r...@myopera.com)'s Artikel
> > Try this
> > while(true) {
> > Socket cs = s.accept();
> > cs.receive(new byte[1024]);
> > cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello
> World");
> > cs.close();
> > }
> > On Thu, Feb 9, 2012, at 07:31 PM, Nrgyzer wrote:
> > > Hi guys,
> > >
> > > I wrote the following few lines:
> > >
> > > private {
> > >
> > > import std.socket;
> > >
> > > }
> > >
> > > void main() {
> > >
> > > Socket s = new TcpSocket();
> > > s.bind(new InternetAddress(80));
> > > s.listen(0);
> > >
> > > while(true) {
> > >
> > > Socket cs = s.accept();
> > > cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello
> World");
> > > cs.close();
> > >
> > > }
> > >
> > > s.close();
> > >
> > > }
> > >
> > > The code compiles successfully and I also the server also responses with
> > > "Hello World", but when I reload the page I sometimes get the following
> > > error (Firefox): "The
> > > connection was reset" - I also often get the same error in other
> > > browsers. Is there anything wrong with the code?
> > >
> > > Thanks in advance!
> > >
>
>
--
D
Re: Signature conditions
On Fri, Feb 10, 2012 at 07:36:38PM +0100, David Nadlinger wrote:
> On 2/10/12 7:35 PM, David Nadlinger wrote:
> >class(T) if (__traits(compiles, { std.utf.decode(T.init); } )) { … }
>
> (untested, you might have to return the value from the delegate to
> avoid an expression-without-effect error)
Works for me. Thanks!!
On that note, I discovered that if you want signature constraints on a
derived class, the syntax is unbearably ugly:
class Derived(T)
if (/* conditions */)
: Base
{
...
}
I would have expected the syntax to be like this instead:
class Derived(T) : Base
if (/* conditions */)
{
...
}
But this doesn't compile.
T
--
If Java had true garbage collection, most programs would delete themselves upon
execution. -- Robert Sewell
Re: Signature conditions
On 2/10/12 7:35 PM, David Nadlinger wrote:
class(T) if (__traits(compiles, { std.utf.decode(T.init); } )) { … }
(untested, you might have to return the value from the delegate to avoid
an expression-without-effect error)
Re: Signature conditions
On 2/10/12 7:28 PM, H. S. Teoh wrote:
I'm trying to write a parametrized class with a type parameter whose
existence depends on whether std.utf.decode() exists for that type.
What's the syntax to do this?
class(T) if (__traits(compiles, { std.utf.decode(T.init); } )) { … }
David
Bug? taskPool.map() with bufSize and writeln() gets stuck
Ubuntu 11.10 64-bit dmd.
The following program gets stuck during the writeln() call.
- The foo() call alone works fine.
- The program works fine when there is no writeln() call nor foo() call.
All elements get processed in that case and the results are ignored.
Am I using taskPool.map incorrectly or is this a bug?
import std.stdio;
import std.parallelism;
import core.thread;
int func(int i)
{
writeln("processing ", i);
return i;
}
void main()
{
auto results = taskPool.map!func([1,2,3,4,5,6,7,8], 2);
writeln(results); // <-- Gets stuck
foo(results); // this works fine
}
void foo(R)(R range)
{
for ( ; !range.empty; range.popFront()) {
writeln(range.front);
}
}
Thank you,
Ali
Signature conditions
I'm trying to write a parametrized class with a type parameter whose
existence depends on whether std.utf.decode() exists for that type.
What's the syntax to do this?
class C(T)
if ( /* ??? exists(decode(T)...?) */ )
{ ... }
Thanks!
T
--
It is not the employer who pays the wages. Employers only handle the
money. It is the customer who pays the wages. -- Henry Ford
Re: Immutable immutable strings??
On Fri, Feb 10, 2012 at 07:17:22PM +0100, Artur Skawina wrote: > On 02/10/12 19:07, H. S. Teoh wrote: > > I'm not sure whether the following a compiler/language bug or a Phobos > > bug, but it's definitely some kind of bug: > > > > auto s = "abc"; > > immutable t = "def"; > > > > writeln(typeid(s)); // immutable(char)[] > > writeln(typeid(t)); // immutable(immutable(char)[]) > > // (what is this supposed to mean?!) > > The array itself is immutable, not just the elements. I see. > > char ch = 'c'; > > bool b = canFind(s, ch);// OK > > bool c = canFind(t, ch);// Compile error?? > > > > The compile error is: > > > > test.d:11: Error: template std.algorithm.canFind(alias pred = "a == > > b",Range,V) if (is(typeof(find!(pred)(range,value does not match any > > function template declaration > > test.d:11: Error: template std.algorithm.canFind(alias pred = "a == > > b",Range,V) if (is(typeof(find!(pred)(range,value cannot deduce > > template function from argument types !()(immutable(char[]),char) > > > > Can somebody explain what's going on here? > > FWIW, it compiles fine here. [...] Is it a Phobos bug that got fixed recently? I'm still using gdc-4.6. T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
Re: Immutable immutable strings??
On 02/10/12 19:07, H. S. Teoh wrote: > I'm not sure whether the following a compiler/language bug or a Phobos > bug, but it's definitely some kind of bug: > > auto s = "abc"; > immutable t = "def"; > > writeln(typeid(s)); // immutable(char)[] > writeln(typeid(t)); // immutable(immutable(char)[]) > // (what is this supposed to mean?!) The array itself is immutable, not just the elements. > char ch = 'c'; > bool b = canFind(s, ch);// OK > bool c = canFind(t, ch);// Compile error?? > > The compile error is: > > test.d:11: Error: template std.algorithm.canFind(alias pred = "a == > b",Range,V) if (is(typeof(find!(pred)(range,value does not match any > function template declaration > test.d:11: Error: template std.algorithm.canFind(alias pred = "a == > b",Range,V) if (is(typeof(find!(pred)(range,value cannot deduce template > function from argument types !()(immutable(char[]),char) > > Can somebody explain what's going on here? FWIW, it compiles fine here. artur
Re: Immutable immutable strings??
Am 10.02.2012, 19:07 Uhr, schrieb H. S. Teoh : I'm not sure whether the following a compiler/language bug or a Phobos bug, but it's definitely some kind of bug: auto s = "abc"; immutable t = "def"; writeln(typeid(s)); // immutable(char)[] writeln(typeid(t)); // immutable(immutable(char)[]) // (what is this supposed to mean?!) That is supposed to mean that you can neither modify the values of the characters in the array nor the array itself: t[1] = 'a'; // immutable(char) t.length = 2; // immutable(...[])
Immutable immutable strings??
I'm not sure whether the following a compiler/language bug or a Phobos bug, but it's definitely some kind of bug: auto s = "abc"; immutable t = "def"; writeln(typeid(s)); // immutable(char)[] writeln(typeid(t)); // immutable(immutable(char)[]) // (what is this supposed to mean?!) char ch = 'c'; bool b = canFind(s, ch);// OK bool c = canFind(t, ch);// Compile error?? The compile error is: test.d:11: Error: template std.algorithm.canFind(alias pred = "a == b",Range,V) if (is(typeof(find!(pred)(range,value does not match any function template declaration test.d:11: Error: template std.algorithm.canFind(alias pred = "a == b",Range,V) if (is(typeof(find!(pred)(range,value cannot deduce template function from argument types !()(immutable(char[]),char) Can somebody explain what's going on here? T -- There are two ways to write error-free programs; only the third one works.
Re: Compiler error with static vars/functions
On Fri, Feb 10, 2012 at 04:38:12PM +0100, Artur Skawina wrote:
> On 02/10/12 16:18, Don Clugston wrote:
> > On 10/02/12 16:08, Artur Skawina wrote:
[...]
> >> No, having non-lower case filenames would just lead to problems.
> >> Like different modules being imported depending on the filesystem
> >> being used, or the user's locale settings.
> >
> > I don't think it's possible without deliberate sabotage. You can't
> > have two files with names differing only in case on Windows. And
> > module declarations acts as a check anyway.
>
> What if you have two modules in the import path, eg a "thread"
> provided by some library and another "Thread" elsewhere? Now "import
> Thread;" will do different things depending on the filesystem on which
> "Thread.d" resides. It simply can't work, it would be great if no
> filesystem tried to muck with the case, but unfortunately they do.
> The compiler should probably enforce module names to be plain ascii
> and lower case every filename before trying to access it. Having
> mixed-case *module* names makes sense, just not the filenames.
[...]
Currently the following code works:
// Б.d
string Ж() {
return "Жаба";
}
// main.d
import std.stdio;
import Б;
void main() {
auto Ш = Ж();
writeln(Ш);
}
Now, this is on a Linux system with UTF-8 locale. I've no idea what
would happen if this was attempted on a non-UTF8 locale, or on a
filesystem that doesn't support UTF-8 filenames, say on Windows. If the
UTF-8 of a particular module name just *happens* to be binary-equal to
another module name in the native system encoding (non-UTF8), then we
could have a rather nasty problem.
T
--
GEEK = Gatherer of Extremely Enlightening Knowledge
Re: Compiler error with static vars/functions
On 02/10/12 16:18, Don Clugston wrote: > On 10/02/12 16:08, Artur Skawina wrote: >> On 02/10/12 15:18, Don Clugston wrote: >>> On 09/02/12 23:03, Jonathan M Davis wrote: On Thursday, February 09, 2012 14:45:43 bearophile wrote: > Jonathan M Davis: >> Normally, it's considered good practice to give modules names which are >> all lowercase (particularly since some OSes aren't case-sensitive for >> file operations). >>> >>> That's just a Walter thing, and it's bollocks. There's no need to use all >>> lower case. >> >> No, having non-lower case filenames would just lead to problems. Like >> different >> modules being imported depending on the filesystem being used, or the user's >> locale settings. > > I don't think it's possible without deliberate sabotage. You can't have two > files with names differing only in case on Windows. And module declarations > acts as a check anyway. What if you have two modules in the import path, eg a "thread" provided by some library and another "Thread" elsewhere? Now "import Thread;" will do different things depending on the filesystem on which "Thread.d" resides. It simply can't work, it would be great if no filesystem tried to muck with the case, but unfortunately they do. The compiler should probably enforce module names to be plain ascii and lower case every filename before trying to access it. Having mixed-case *module* names makes sense, just not the filenames. artur
Re: Compiler error with static vars/functions
On 10/02/12 16:08, Artur Skawina wrote: On 02/10/12 15:18, Don Clugston wrote: On 09/02/12 23:03, Jonathan M Davis wrote: On Thursday, February 09, 2012 14:45:43 bearophile wrote: Jonathan M Davis: Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations). That's just a Walter thing, and it's bollocks. There's no need to use all lower case. No, having non-lower case filenames would just lead to problems. Like different modules being imported depending on the filesystem being used, or the user's locale settings. I don't think it's possible without deliberate sabotage. You can't have two files with names differing only in case on Windows. And module declarations acts as a check anyway. The D community is a *lot* of experience with mixed case names. No problems have ever been reported.
Re: Compiler error with static vars/functions
On Fri, Feb 10, 2012 at 04:08:36PM +0100, Artur Skawina wrote: > On 02/10/12 15:18, Don Clugston wrote: > > On 09/02/12 23:03, Jonathan M Davis wrote: > >> On Thursday, February 09, 2012 14:45:43 bearophile wrote: > >>> Jonathan M Davis: > Normally, it's considered good practice to give modules names > which are all lowercase (particularly since some OSes aren't > case-sensitive for file operations). > > > > That's just a Walter thing, and it's bollocks. There's no need to > > use all lower case. > > No, having non-lower case filenames would just lead to problems. Like > different modules being imported depending on the filesystem being > used, or the user's locale settings. There's no need for upper and > mixed case module file names. [...] The real problem is that some OSes have case-insensitive filesystems. T -- It's amazing how careful choice of punctuation can leave you hanging:
Re: Compiler error with static vars/functions
On 02/10/12 15:18, Don Clugston wrote: > On 09/02/12 23:03, Jonathan M Davis wrote: >> On Thursday, February 09, 2012 14:45:43 bearophile wrote: >>> Jonathan M Davis: Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations). > > That's just a Walter thing, and it's bollocks. There's no need to use all > lower case. No, having non-lower case filenames would just lead to problems. Like different modules being imported depending on the filesystem being used, or the user's locale settings. There's no need for upper and mixed case module file names. artur
Re: Compiler error with static vars/functions
On 09/02/12 23:03, Jonathan M Davis wrote: On Thursday, February 09, 2012 14:45:43 bearophile wrote: Jonathan M Davis: Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations). That's just a Walter thing, and it's bollocks. There's no need to use all lower case. That's just a fragile work-around for a module system design problem that I didn't like from the first day I've seen D. I'll take a look in Bugzilla if there is already something on this. What design problem? The only design problem I see is the fact that some OSes were badly designed to be case insensitive when dealing with files, and that's not a D issue. - Jonathan M Davis You can argue this either way. There are not many use cases for having two files differing only in case.
Re: Socket: The connection was reset
Works perfectly, thanks :)
But... how can I read the complete HTTP-header? When I try the following:
string header;
ubyte[1024] buffer;
while (cs.receive(buffer)) header ~= buffer;
... it works as long as the header doesn't have a length like 1024, 2048,
3072... Otherwise cs.receive() blocks forever and the server doesn't respond
anything. Is there any solution how to prevent/solve this problem?
== Auszug aus DNewbie (r...@myopera.com)'s Artikel
> Try this
> while(true) {
> Socket cs = s.accept();
> cs.receive(new byte[1024]);
> cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello
World");
> cs.close();
> }
> On Thu, Feb 9, 2012, at 07:31 PM, Nrgyzer wrote:
> > Hi guys,
> >
> > I wrote the following few lines:
> >
> > private {
> >
> > import std.socket;
> >
> > }
> >
> > void main() {
> >
> > Socket s = new TcpSocket();
> > s.bind(new InternetAddress(80));
> > s.listen(0);
> >
> > while(true) {
> >
> > Socket cs = s.accept();
> > cs.sendTo("HTTP/1.1 200 OK\r\nContent-Length: 11\r\n\r\nHello
World");
> > cs.close();
> >
> > }
> >
> > s.close();
> >
> > }
> >
> > The code compiles successfully and I also the server also responses with
> > "Hello World", but when I reload the page I sometimes get the following
> > error (Firefox): "The
> > connection was reset" - I also often get the same error in other
> > browsers. Is there anything wrong with the code?
> >
> > Thanks in advance!
> >
Re: What should do a D lint?
Am 04.02.2012, 18:37 Uhr, schrieb bioinfornatics
:
hi,
What should do a D lint?
- check if in code the are no mixin between space / tab for indent
- check indent (4 spaces as default)
complete the list
Do you want to collect ideas or advertise the use of 4 spaces for
indentation? Look, i would add something to your list, if I didn't have
the feeling that you have the wrong intentions with the indentions. I
recently set my tab width to 3 - it is still readable and in D I often
have deep nesting. I indent with tabs and often let that follow a stream
of spaces for alignment (on long parameter lists). I'm not sure at all if
a lint tool should care about whitespace so much, or if this is better
left to an auto-formatter. Can you make this code pass?:
fooObject.callMethod(loongPaaraameter,
1234567890 + somehting * 10,
flagA | flagB);
Ok, here is something to add to the list:
- check useless or redundant modifiers on symbols:
@safe:
const Bar foo() const {} => redundant modifier, foo() is already
'const', did you mean: const(Bar) foo() const ?
@safe int x() { return 0; } => redundant modifier, x() is already '@safe'
void very_pure() pure pure pure {} => redundant modifier, very_pure() is
already 'pure'
- It is common to use enums as constants. This is ill-advised for arrays,
because they can't just be loaded as a constant into some CPU register.
Instead a new array instance is created everywhere they are used. So
instead of enum, use immutable for arrays.
- Some poeple also think it would be good to warn about implicit
conversions between chars and integer types, or signed and unsigned
Re: Arrays - Inserting and moving data
Am 09.02.2012, 22:03 Uhr, schrieb MattCodr : On Thursday, 9 February 2012 at 19:49:43 UTC, Timon Gehr wrote: Note that this code does the same, but is more efficient if you don't actually need the array: Yes I know, In fact I need re-think the way I code with this new features of D, like ranges for example. Thanks, Matheus. I know that feeling. I had no exposure to functional programming and options like chain never come to my head. Although "map" is a concept that I made friends with early.
Re: DLL Injection
Well if I change the DLL_PROCESS_ATTACH case to this:
case DLL_PROCESS_ATTACH:
MessageBoxA(null, "Injected!", "DLL", MB_OK);
g_hInst = hInstance;
dll_process_attach(hInstance, true);
try
{
*cast(int*)0x12FE6C = 1337;
}
catch(Exception e)
{
MessageBoxA(null, "Exception!", "DLL", MB_OK);
}
MessageBoxA(null, "Finished!", "DLL", MB_OK);
break;
then I get the "Injected!" and "Finished!" MessageBox()s popping
up, but not the "Exception!", so yes the code does get past the
cast line (but still crashes). The same thing happens even if I
remove the try/catch block and the cast line altogether.
I changed my post-mortem debugger from the default Dr. Watson to
Visual Studio's just-in-time debugger, and after it displays
"Finished!", I get an unhandled win32 exception in the injected
process.
And yer, I would normally use WriteProcessMemory() for something
this trivial, but I want to eventually do some more advanced
stuff.
Re: A GUI library to begin with
On Thu, 09 Feb 2012 21:25:28 +0100 "Damian Ziemba" wrote: > I see hope in Andrej researches about wxPHP and bringing it to D. It seems he is doing great job to re-vive wxD. Kudos to him!! > As for now, I would use GtkD ;-) We'll use wxD. ;) Sincerely, Gour -- All living bodies subsist on food grains, which are produced from rains. Rains are produced by performance of yajña [sacrifice], and yajña is born of prescribed duties. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
