On 14-7-2011 5:48, Dr.Smith wrote:
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.listen(10);
string webpage = "index.html";
Socket currSock;
uint bytes
While the following D program runs without compiler error, it seems unable to
serve a web page. Is there a better way?
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.liste
On 7/14/2011 12:24 AM, Trass3r wrote:
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] :
Don't know it this is the right answer or a possible bug but it does
the trick:
void h() { import std.stdio; write("h()"); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(
On 7/14/2011 12:24 AM, Trass3r wrote:
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] :
Don't know it this is the right answer or a possible bug but it does
the trick:
void h() { import std.stdio; write("h()"); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(
On 2011-07-14 01:17, David Nadlinger wrote:
Currently, no memory can be allocated at all during garbage collection
runs, which is where destructors are usually called.
David
That explains it. Do you know when this feature will be available, if
at all?
Here is another interesting case, where I
On 7/14/11 1:11 AM, Loopback wrote:
Now the program calls Runtime.terminate, which is supposed to take
care of the memory garbage and etc. This does not work. The terminate
function call throws an Error, "Memory Allocation Failure".
This failure originates in the 'Foo' destructor, which in turn c
On 2011-07-14 01:11, Loopback wrote:
Hello!
I've been working on a project where I had to do all memory handling
explicitly because no destructors were called. When I got too tired
of the explicit memory handling I decided to trace what was causing
this error. After hours of code stripping I had
Hello!
I've been working on a project where I had to do all memory handling
explicitly because no destructors were called. When I got too tired
of the explicit memory handling I decided to trace what was causing
this error. After hours of code stripping I had gotten myself a
small concrete sample
2011/7/13 Jesse Phillips :
> shd Wrote:
>> 2011/7/13 Jesse Phillips :
>> > You say no to libraries
>>
>> That's not true! I'm not sure how did you came up to this conclusions,
>> but i love libraries for applications same as command-line programs
>> (like ffmpeg) for GUI apps.
>
> It comes from, "a
2011/7/13 Dmitry Olshansky
> Time ago I thought of something more like tag based file system, where
> filetypes and e.g. date of modification are just that - one of myriad of
> tags, besides any additional that are user/system defined.
> Though I have never reached any more or less complete desig
On Wed, 13 Jul 2011 11:32:50 -0400, Daniel Murphy
wrote:
"Andrej Mitrovic" wrote in message
news:mailman.1607.1310570915.14074.digitalmars-d-le...@puremagic.com...
Thanks! I've literally lost an entire day once when I was just
starting using D and C together and had a calling convention mis
shd Wrote:
> 2011/7/13 Jesse Phillips :
> > You say no to libraries
>
> That's not true! I'm not sure how did you came up to this conclusions,
> but i love libraries for applications same as command-line programs
> (like ffmpeg) for GUI apps.
It comes from, "and APIs are not what i'd love to wor
"Andrej Mitrovic" wrote in message
news:mailman.1607.1310570915.14074.digitalmars-d-le...@puremagic.com...
> Thanks! I've literally lost an entire day once when I was just
> starting using D and C together and had a calling convention mismatch.
> :x
It's worse than just calling conventions - try
I've seen this error before...
*searches memory and old code*
Here you go: http://d.puremagic.com/issues/show_bug.cgi?id=3051
I think this is yet another issue.
The inner template argument is not something on the stack but it is a
template argument.
Am 13.07.2011, 16:58 Uhr, schrieb Tyro[a.c.edwards] :
Don't know it this is the right answer or a possible bug but it does the
trick:
void h() { import std.stdio; write("h()"); }
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(typeof(&f) g = &f)
{
On 7/13/11, Daniel Murphy wrote:
> "Andrej Mitrovic" wrote in message
> news:mailman.1569.1310506439.14074.digitalmars-d-le...@puremagic.com...
>> Is this going to be fixed any time soon? Allowing callbacks with D
>> calling convention where a C callback is expected should be an error,
>> and thi
"Andrej Mitrovic" wrote in message
news:mailman.1569.1310506439.14074.digitalmars-d-le...@puremagic.com...
> Is this going to be fixed any time soon? Allowing callbacks with D
> calling convention where a C callback is expected should be an error,
> and this is like the 10th time I've ran into th
On 7/13/2011 11:35 PM, Trass3r wrote:
Am 13.07.2011, 16:02 Uhr, schrieb Steven Schveighoffer
:
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
g();
}
}
As a workaround, is there a reason you need blub to be parameterized?
I mean, f is alr
Am 13.07.2011, 16:02 Uhr, schrieb Steven Schveighoffer
:
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
g();
}
}
As a workaround, is there a reason you need blub to be parameterized? I
m
On Tue, 12 Jul 2011 09:06:56 -0400, Trass3r wrote:
Is this a bug? If not, how do you make it work?
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
}
}
void main()
{
Bla b = new Bla();
b.blub();
On 12.07.2011 15:06, Trass3r wrote:
Is this a bug? If not, how do you make it work?
void h() {}
class Bla
{
mixin wrap!h;
}
mixin template wrap(alias f)
{
void blub(alias g = f)()
{
}
}
void main()
{
Bla b = new Bla();
b.blub();
}
test.d(18): Error: template instance cannot use local 'f' as
Anybody an idea?
On 13.07.2011 15:39, shd wrote:
I hope i didn't bored you too much with my imagination because there
is something more i don't like. Directory hierarchy :) It's not
D-related though.
Understanding a risk of going completely OT: you are not alone on this
one :)
Time ago I thought of something m
2011/7/13 Jesse Phillips :
> After reading Kagamin's response, I'm not sure I understand you still. You
> want to have code reuse, you want to have run-time and compile-time
> configuration, but you don't want to make use of the
> technologies/techniques/patterns which facilitate these.
I'm not
2011/7/13 Kagamin :
> Hmm... If you have
> wrappers/gl/guiImpl/...
> and
> wrappers/what/guiImpl/...
> and conditionally add them to includes
> for example
> with -I wrappers/gl you should be able to import guiImpl; and use
> guiImpl.Window. If it's -I wrappers/what, guiImpl.Window is still
> gui
Steven Schveighoffer Wrote:
> On Tue, 12 Jul 2011 11:07:57 -0400, Kagamin wrote:
>
> > Steven Schveighoffer Wrote:
> >
> >> Yes, but this is getting into territory where the false positive rate
> >> might get high.
> >
> > I bet it will be difficult to find a real-world example of this false
>
shd Wrote:
> 2011/7/12 Kagamin :
> > You want an IOC container like Unity?
> exactly
> > And you want the interface-to-class mapping to be configurable externally
> > rather than version out these classes directly in source?
> > like
> > version(UseGL)
> > {
> > �static import wrappers.gl;
> >
27 matches
Mail list logo
