Re: function literals cannot be class members

[Mehrdad]

On 7/18/2011 6:21 AM, Steven Schveighoffer wrote:
I'm actually still confused at why _functions_ should be passed as 
template parameters


The beauty of alias parameters 


... the beauty?

Please excuse me my tone becomes a bit rant-y, but I was asking _why_, 
and the reason is just... beauty? IMHO, it's getting pretty darn ugly...


Templates are just that: *templates*. They're meant to avoid 
__duplication of code and/or unnecessary variation in code__, by 
providing a common style (i.e. a common *template*). Metaprogramming, 
conditional compilation, etc. are great uses of templates, since they 
avoid unnecessary duplication of code.
But using them _in lieu_ of delegates is kind of pointless -- delegates 
*already* avoid duplication of code, and aliases don't solve any 
problems here. (I'm guessing you disagree, in which case: Can you 
provide an example of a problem that they actually solve, aside from 
their "beauty"?)


Sure, they're beautiful, but they're ugly at the same time: they don't 
let the code describe itself. i.e. when you say

void Foo(alias F)() { ... }
the reader has **no idea whatsoever** what kind of "thing" F is (string? 
delegate? data type?), and it gets cryptic fast. Sure, you can document 
it, but isn't the whole point to let the code document itself? Not only 
that, it becomes absolutely /painful/ to write completely correct 
conditions for a template like this, when you can have multiple kinds of 
parameters.


If you want to be able to pass multiple parameter types, then why not 
just either use overloading or, if you're really concerned about 
duplication, let the argument type be specified as a template? That 
would remove the duplication issue.
If you're worried about simple things like "a < b", then it's because we 
shouldn't be using a string in the first place! It's painful to write

foo(delegate(a, b) { return a < b; })
but that's an easily solvable solution: Just support C#'s syntax of 
lambdas and you instead get:

foo((a, b)  =>  a < b);
which is cleaner and easy to type, and which avoids using strings for 
code. Or you can just predefine it somewhere as a lessThan template, and 
pass it as an argument. Either way, no strings.
In any case, this shouldn't be an excuse for using templates -- if 
typing something is hard, simplifying the syntax is the answer (I'm all 
for C# lambdas...), not using the template hammer to solve everything.

Re: event based timer

[maarten van damme]

Thanks but it seems way more complex then I need, I tried writing my own but
I get an acces violation error. here is my try :
http://dl.dropbox.com/u/15024434/Timer.d . Can someone spot the error? keep
in mind I don't really understand the threading model and pointers.


2011/7/19 Piotr Szturmaj 

> maarten van damme wrote:
>
>> Hi everyone,
>> for getting to know d a little bit I'm writing a simple pingpong game
>> using gtk.
>> for it to work I need to be able to do something every 0.1 seconds so I
>> was wondering if there was some kind of timer in the phobos library.
>> I've looked everywhere but couldn't find one. Is it missing and do i
>> have to write my own or have I overlooked it?
>>
>> maarten
>>
>
> There is no callback timer in Phobos. But here's my implementation of timer
> wheel I used in one of my projects: http://pastebin.com/dRRZtPVW. Feel
> free to use it if you want.
>

Re: Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/19 Jacob Carlborg :
> On 2011-07-19 16:46, Russel Winder wrote:
>>
>> There is clearly a string coupling between configuration and package
>> management.   Autoconf, Waf and SCons have to be portable across package
>> management since they are not dedicated to one scheme -- springing up as
>> they did from before package management as standard.
>
> Ok.
>
>> There are some potentially tricky issues here.  Ruby gets round it by
>> having a language specific package and build system which therefore
>> causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
>> headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
>> language packaging and platform packaging is central.  Having a D
>> language packaging system that was in some way harmonious with Apt/Deb,
>> Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
>> it would make traction a whole lot easier.  As evidence I present Java,
>> Ruby, Python, Haskell, etc.
>
> The whole point of having a D package manager is so I don't have to create
> packages for all these system specific package managers.

In my experience with gem and easy_install, it's not really practical
for the end-user. After several attempts, I always ran into problems.
Especially library-bindings in the language-specific package-manager
tends to conflict with what library is installed in the system,
causing problems. In all the cases I ended up biting the bullet and
create a OS-package for the Python/Ruby packages we're using in
production. I've later learned the experience is shared with others, I
know one company who even went back to .NET due to too much hassle
with Ruby On Rails deployments (gem), and I suppose
distribution-developers wouldn't put as much effort into packaging all
the Python and Ruby-packages they do if not others had seen problems
with per-language packagers.

Especially, if D is to gain traction and attract developers, getting
proof-of-concept applications out in the respective "app store" of the
target OS:es is quite important, which requires working with the
native packaging format.

Re: event based timer

[Daniel Murphy]

private void  function() *  callBack;

should be private void  function() callBack;

void function() is a function pointer, void function()* is a pointer to a 
function pointer.

On lines 23 and 41, you shouldn't be dereferencing callBack.  Just use 
callBack() to call the function and 'this.callBack = callBack' to set it. 

Re: event based timer

[maarten van damme]

Thanks a lot, now those errors are gone. Still it refuses to work
properly...
I have a method clockTick in Main.d and that should be called every 0.1
seconds, when I place a call to that method in a onmousenotify event(when
the mouse moves) It runs correctly apart from the odd fact I need to move my
mouse to play the game.
When I use that method in the timerclass it reaches only the lines where I
print something in the console but doesn't go any further without giving any
errors.

The complete code can be seen at:
http://dl.dropbox.com/u/15024434/d/Main.d
http://dl.dropbox.com/u/15024434/d/Timer.d
http://dl.dropbox.com/u/15024434/d/Sprite.d
http://dl.dropbox.com/u/15024434/d/Bain.d
http://dl.dropbox.com/u/15024434/d/PingPongBox.d

The code for the timer in Main.d is at line 63
clockTick method in Main.d is at line 93

2011/7/20 Daniel Murphy 

> private void  function() *  callBack;
>
> should be private void  function() callBack;
>
> void function() is a function pointer, void function()* is a pointer to a
> function pointer.
>
> On lines 23 and 41, you shouldn't be dereferencing callBack.  Just use
> callBack() to call the function and 'this.callBack = callBack' to set it.
>
>
>

Re: event based timer

[Martin Nowak]

You are aware though that in your timer, the callback is executed from  
within a different thread.
You could let the timer thread send messages as clock ticks and wait on  
them, that way risking less issues

with implicit sharing.

Martin



import std.concurrency, std.stdio;
import core.thread;

struct Timer {
private Tid clock;
private bool running;
enum Terminate { _ };
enum Ping { _ };

~this() {
stop();
}

void start(Duration duration) {
avoidMailboxSpam();
stop();
clock = spawnLinked(&runClock, thisTid, duration);
running = true;
}

void stop() {
if (running)
clock.send(Terminate._);
running = false;
}

void wait() {
receiveOnly!Ping();
}

private static void avoidMailboxSpam() {
setMaxMailboxSize(thisTid, 5, OnCrowding.throwException);
}

private static void runClock(Tid tick, Duration duration) {
bool cont = true;
size_t cnt;
try {
while (cont) {
auto timedOut = !receiveTimeout(
duration,
(Terminate) { cont = false; },
);
if (timedOut) {
writefln("  #%-5d   Ping  ", cnt++);
tick.send(Ping._);
}
}
} catch (Exception ex) {
stderr.writeln(ex.msg);
throw ex;
}
}
}

void main() {
Timer timer;
auto interval = dur!"msecs"(500);
timer.start(interval);

foreach(cnt; 0 .. 200) {
timer.wait();

// Play some pong, if it takes too long our mailbox gets flooded
Thread.sleep(interval / 2);
writefln("  Pong #%-5d", cnt);
}
timer.stop();
}


On Wed, 20 Jul 2011 09:34:39 +0200, maarten van damme  
 wrote:


Thanks but it seems way more complex then I need, I tried writing my own  
but

I get an acces violation error. here is my try :
http://dl.dropbox.com/u/15024434/Timer.d . Can someone spot the error?  
keep

in mind I don't really understand the threading model and pointers.


2011/7/19 Piotr Szturmaj 


maarten van damme wrote:





There is no callback timer in Phobos. But here's my implementation of  
timer

wheel I used in one of my projects: http://pastebin.com/dRRZtPVW. Feel
free to use it if you want.

Re: RDMD is broken on Windows7

[Kagamin]

Trass3r Wrote:

> Yep. See thread 'gtkD doesn't compile on windows' in D.learn.
> 
> "
> >> If I compile rdmd (with my patch, haven't tried the original) without
> >> -g, it crashes when trying to compile anything...
> 
> > Does this also happen if you compile it with -g and then run cv2pdb on  
> > it?
> 
> I cannot compile anything without first compiling rdmd with -g.
> Compiling rdmd with -g and running cv2pdb on it works.
> 
> It fails on the return statement in getDependencies.
> It never gets to the line after getDependencies in main.

May be, it's an exception while getting symbols? Try to disable strack trace 
generation.

Re: GitHub or dsource?

[David Nadlinger]

On 7/7/11 8:19 PM, Nick Sabalausky wrote:

[…]But DSource is better for
forums and issue tracking. So I would just use both - code hosting at github
and forums/issue-tracking at dsource.


I doubt that DSource is really the better option for issue tracking. 
First, GitHub rolled out »Issues 2.0« a few months ago, which now has 
support for assigning bugs, milestones, etc. I personally haven't used 
it for a large project yet, but Ruby on Rails switched to it (they 
previously used Lighthouse), so I suppose it is quite fit for the purpose.


Second, at least for QtD, there is a massive problem with using the 
DSource Trac instance: Spam. I don't know if this affects other projects 
as well, and you might not actually notice it that much because we 
usually hard-delete spammy tickets/changes via the admin panel, but it 
is definitely annoying.


David

Re: event based timer

[Martin Nowak]

Well, I guessed right I think. In you're main file you are using global  
//VARIABLES but in fact they are thread local.
That is each thread has it's own copy of them, so that different threads  
don't mess up each others data.

You can try the other timer approach or solve your sharing.

It would be really better if phobos had some kind of timer. The thread  
solution is really suboptimal.


On Wed, 20 Jul 2011 11:20:24 +0200, maarten van damme  
 wrote:



Thanks a lot, now those errors are gone. Still it refuses to work
properly...
I have a method clockTick in Main.d and that should be called every 0.1
seconds, when I place a call to that method in a onmousenotify event(when
the mouse moves) It runs correctly apart from the odd fact I need to  
move my

mouse to play the game.
When I use that method in the timerclass it reaches only the lines where  
I
print something in the console but doesn't go any further without giving  
any

errors.

The complete code can be seen at:
http://dl.dropbox.com/u/15024434/d/Main.d
http://dl.dropbox.com/u/15024434/d/Timer.d
http://dl.dropbox.com/u/15024434/d/Sprite.d
http://dl.dropbox.com/u/15024434/d/Bain.d
http://dl.dropbox.com/u/15024434/d/PingPongBox.d

The code for the timer in Main.d is at line 63
clockTick method in Main.d is at line 93

2011/7/20 Daniel Murphy 


private void  function() *  callBack;

should be private void  function() callBack;

void function() is a function pointer, void function()* is a pointer to  
a

function pointer.

On lines 23 and 41, you shouldn't be dereferencing callBack.  Just use
callBack() to call the function and 'this.callBack = callBack' to set  
it.

Re: event based timer

[David Nadlinger]

On 7/20/11 12:05 PM, Martin Nowak wrote:

It would be really better if phobos had some kind of timer. The thread
solution is really suboptimal.


I think a major problem when trying to implement a general-purpose 
solution is that, by its very nature, a timer depends on the event 
handling scheme used.


For example, if you wanted to use a timer on Posix to interrupt your 
potentially blocking system calls, you would use alarm() to set a 
signal-based timeout and register a signal handler for it. On the other 
hand, a typical GUI application has its own event loop to integrate 
with, for an application using non-blocking I/O, you would like to 
transparently map your timers on select()/… timeout arguments, etc.


David

Re: event based timer

[Chris Molozian]

As you're creating a Gtk app, have you considered using glib.Timer 
 or glib.Timeout 
 (depending on your 
needs)? I do almost all my Gtk development in Vala these days, so I 
haven't used them from D (so not sure if you've encountered problems 
with them).


Cheers,

Chris


On 07/20/11 10:20, maarten van damme wrote:
Thanks a lot, now those errors are gone. Still it refuses to work 
properly...
I have a method clockTick in Main.d and that should be called every 
0.1 seconds, when I place a call to that method in a onmousenotify 
event(when the mouse moves) It runs correctly apart from the odd fact 
I need to move my mouse to play the game.
When I use that method in the timerclass it reaches only the lines 
where I print something in the console but doesn't go any further 
without giving any errors.


The complete code can be seen at:
http://dl.dropbox.com/u/15024434/d/Main.d
http://dl.dropbox.com/u/15024434/d/Timer.d
http://dl.dropbox.com/u/15024434/d/Sprite.d
http://dl.dropbox.com/u/15024434/d/Bain.d
http://dl.dropbox.com/u/15024434/d/PingPongBox.d

The code for the timer in Main.d is at line 63
clockTick method in Main.d is at line 93

2011/7/20 Daniel Murphy >


private void  function() *  callBack;

should be private void  function() callBack;

void function() is a function pointer, void function()* is a
pointer to a
function pointer.

On lines 23 and 41, you shouldn't be dereferencing callBack.  Just use
callBack() to call the function and 'this.callBack = callBack' to
set it.

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-20 10:36, Ulrik Mikaelsson wrote:

In my experience with gem and easy_install, it's not really practical
for the end-user. After several attempts, I always ran into problems.
Especially library-bindings in the language-specific package-manager
tends to conflict with what library is installed in the system,
causing problems. In all the cases I ended up biting the bullet and
create a OS-package for the Python/Ruby packages we're using in
production. I've later learned the experience is shared with others, I
know one company who even went back to .NET due to too much hassle
with Ruby On Rails deployments (gem), and I suppose
distribution-developers wouldn't put as much effort into packaging all
the Python and Ruby-packages they do if not others had seen problems
with per-language packagers.


I never had this problem with Ruby or Rails. I find it very hard to 
belive that the only reason they switch back to .NET was problems with 
the package manager. I mean Ruby on Rails is the easiest platform I've 
used, just list the packages you want in a file and run "bundle" and 
everything is installed.


So what are you suggesting, that we don't have a package manager for D?


Especially, if D is to gain traction and attract developers, getting
proof-of-concept applications out in the respective "app store" of the
target OS:es is quite important, which requires working with the
native packaging format.


Linux and FreeBSD is the only platforms that have a native package 
manager. Mac OS X has macports and homebrew, none of which are installed 
by default. Windows doesn't have any package manager, as far as I know.


So you suggest that I should create, something like, six packages for 
one library just to support all platforms and package mangers. And then 
it won't even support Windows. That would probably also be in 6 
different "languages" for the package scripts.


--
/Jacob Carlborg

Re: Prototype buildsystem "Drake"

[David Nadlinger]

On 7/20/11 10:36 AM, Ulrik Mikaelsson wrote:

[…]I've later learned the experience is shared with others, I
know one company who even went back to .NET due to too much hassle
with Ruby On Rails deployments (gem), […]


Do you happen to known what issues they experienced in more detail? I'm 
curious because I personally found Rails deployment to be quite 
convenient, extending the Gemfile during development as needed, and then 
using Bundler (http://gembundler.com/) to ensure that the exact same 
versions of the dependencies are used when staging and deploying…


David

Re: event based timer

[Sean Kelly]

On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:

> Hi everyone,
> for getting to know d a little bit I'm writing a simple pingpong game using 
> gtk.
> for it to work I need to be able to do something every 0.1 seconds so I was 
> wondering if there was some kind of timer in the phobos library.
> I've looked everywhere but couldn't find one. Is it missing and do i have to 
> write my own or have I overlooked it?

void loop() {
while( true ) {
doWhatever();
Thread.sleep(dur!"msecs"(100));
}
}

spawn(&loop);


Or you could have the spawned thread send a message every 100 milliseconds, etc.

Re: event based timer

[maarten van damme]

The problem with Sean Kelly's and the message sending approach is that when
using gtk I have to call Main.run(); and it pauses then untill the windows
are all closed. when I place a loop before Main.run() I never get a window
so If I want to use some kind of timer using threads I need to use shared?
(correct me if I'm wrong)

The glib.Timeout works like a charm, Thank you chris

2011/7/20 Sean Kelly 

> On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:
>
> > Hi everyone,
> > for getting to know d a little bit I'm writing a simple pingpong game
> using gtk.
> > for it to work I need to be able to do something every 0.1 seconds so I
> was wondering if there was some kind of timer in the phobos library.
> > I've looked everywhere but couldn't find one. Is it missing and do i have
> to write my own or have I overlooked it?
>
> void loop() {
>while( true ) {
>doWhatever();
>Thread.sleep(dur!"msecs"(100));
>}
> }
>
> spawn(&loop);
>
>
> Or you could have the spawned thread send a message every 100 milliseconds,
> etc.

Re: Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

> So what are you suggesting, that we don't have a package manager for D?
I'm suggesting, I'm not likely to use it, and developing a D-specific
package manager should not accidentally exclude stand-alone building
of packages. As I said before, the build-system and packaging system
must be independent, but well integrated.

Quoting again from Russel Winder:
>> Having a D language packaging system that was in some way harmonious
>> with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy.
>> Indirectly it would make traction a whole lot easier.

Re: Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/20 David Nadlinger :
> Do you happen to known what issues they experienced in more detail? I'm
> curious because I personally found Rails deployment to be quite convenient,
> extending the Gemfile during development as needed, and then using Bundler
> (http://gembundler.com/) to ensure that the exact same versions of the
> dependencies are used when staging and deploying…

I do not know exactly what their problems was. For me, it was mainly
conflicts between OS package manager and language-specific. I recall
curl-bindings, and MySQL binding causing a lot of problems, also I
recall some graphics library depending on GTK breaking spectacularly.
Perhaps it's more polished now, or perhaps I just had bad luck.

Re: event based timer

[Sean Kelly]

Is there a timer function built into gtk?  Or can you have a separate thread 
trigger a gtk event on a timer?

On Jul 20, 2011, at 5:00 AM, maarten van damme wrote:

> The problem with Sean Kelly's and the message sending approach is that when 
> using gtk I have to call Main.run(); and it pauses then untill the windows 
> are all closed. when I place a loop before Main.run() I never get a window so 
> If I want to use some kind of timer using threads I need to use shared? 
> (correct me if I'm wrong)
> 
> The glib.Timeout works like a charm, Thank you chris
> 
> 2011/7/20 Sean Kelly 
> On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:
> 
> > Hi everyone,
> > for getting to know d a little bit I'm writing a simple pingpong game using 
> > gtk.
> > for it to work I need to be able to do something every 0.1 seconds so I was 
> > wondering if there was some kind of timer in the phobos library.
> > I've looked everywhere but couldn't find one. Is it missing and do i have 
> > to write my own or have I overlooked it?
> 
> void loop() {
>while( true ) {
>doWhatever();
>Thread.sleep(dur!"msecs"(100));
>}
> }
> 
> spawn(&loop);
> 
> 
> Or you could have the spawned thread send a message every 100 milliseconds, 
> etc.
> 

Re: RDMD is broken on Windows7

[simendsjo]

On 20.07.2011 11:52, Kagamin wrote:

Trass3r Wrote:


Yep. See thread 'gtkD doesn't compile on windows' in D.learn.

"

If I compile rdmd (with my patch, haven't tried the original) without
-g, it crashes when trying to compile anything...



Does this also happen if you compile it with -g and then run cv2pdb on
it?


I cannot compile anything without first compiling rdmd with -g.
Compiling rdmd with -g and running cv2pdb on it works.

It fails on the return statement in getDependencies.
It never gets to the line after getDependencies in main.


May be, it's an exception while getting symbols? Try to disable strack trace 
generation.


Not sure I understand what you mean.. Isn't stack trace enabled with -g?

Re: event based timer

[maarten van damme]

It turned out there was a Timer in glib and glib is a part of gtk(I think).
When you use gtkd you have acces to glib and that worked but it takes 50
procent of my cpu. (this was actually pretty strange. It worked fast and
good untill I rebooted. Now it runs prety slow)
and I don't think you can trigger a gtk event on a timer.

2011/7/20 Sean Kelly 

> Is there a timer function built into gtk?  Or can you have a separate
> thread trigger a gtk event on a timer?
>
> On Jul 20, 2011, at 5:00 AM, maarten van damme wrote:
>
> > The problem with Sean Kelly's and the message sending approach is that
> when using gtk I have to call Main.run(); and it pauses then untill the
> windows are all closed. when I place a loop before Main.run() I never get a
> window so If I want to use some kind of timer using threads I need to use
> shared? (correct me if I'm wrong)
> >
> > The glib.Timeout works like a charm, Thank you chris
> >
> > 2011/7/20 Sean Kelly 
> > On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:
> >
> > > Hi everyone,
> > > for getting to know d a little bit I'm writing a simple pingpong game
> using gtk.
> > > for it to work I need to be able to do something every 0.1 seconds so I
> was wondering if there was some kind of timer in the phobos library.
> > > I've looked everywhere but couldn't find one. Is it missing and do i
> have to write my own or have I overlooked it?
> >
> > void loop() {
> >while( true ) {
> >doWhatever();
> >Thread.sleep(dur!"msecs"(100));
> >}
> > }
> >
> > spawn(&loop);
> >
> >
> > Or you could have the spawned thread send a message every 100
> milliseconds, etc.
> >
>
>

Re: event based timer

[Piotr Szturmaj]

Martin Nowak wrote:

You are aware though that in your timer, the callback is executed from
within a different thread.


Yes. User should be aware of this different thread and should perform 
synchronization manually. Anyway, it is possible to relay callbacks to a 
queue and then one can wait for events on that queue.

(This timer class was designed to handle thousands of concurrent timers.)

Re: function literals cannot be class members

[Steven Schveighoffer]

On Wed, 20 Jul 2011 03:03:26 -0400, Mehrdad  wrote:


On 7/18/2011 6:21 AM, Steven Schveighoffer wrote:
I'm actually still confused at why _functions_ should be passed as  
template parameters


The beauty of alias parameters 


... the beauty?

Please excuse me my tone becomes a bit rant-y, but I was asking _why_,  
and the reason is just... beauty? IMHO, it's getting pretty darn ugly...


Sorry for the confusion, "the beauty of X is..."  is a figure of speech  
that really does not necessarily have to do with beauty.  It means  
something like "the good part of it".  You can substitute the word  
"benefit" for "beauty".


As in, templates may be ugly but the benefit of using alias is...

I assure you, I was not speaking of code beauty whatsoever, I was more  
speaking of it's utility and flexibility.


Templates are just that: *templates*. They're meant to avoid  
__duplication of code and/or unnecessary variation in code__, by  
providing a common style (i.e. a common *template*). Metaprogramming,  
conditional compilation, etc. are great uses of templates, since they  
avoid unnecessary duplication of code.
But using them _in lieu_ of delegates is kind of pointless -- delegates  
*already* avoid duplication of code, and aliases don't solve any  
problems here. (I'm guessing you disagree, in which case: Can you  
provide an example of a problem that they actually solve, aside from  
their "beauty"?)


Yes, the entire message that you erased for this reply was my explanation  
of why it's better.


Sure, they're beautiful, but they're ugly at the same time: they don't  
let the code describe itself. i.e. when you say

 void Foo(alias F)() { ... }
the reader has **no idea whatsoever** what kind of "thing" F is (string?  
delegate? data type?), and it gets cryptic fast. Sure, you can document  
it, but isn't the whole point to let the code document itself? Not only  
that, it becomes absolutely /painful/ to write completely correct  
conditions for a template like this, when you can have multiple kinds of  
parameters.


The problem is that the "type" of alias is described in the template  
constraints later.  It's hard to mentally associate that with the  
parameter, but it's all we have at this point.  It's almost like some  
horrible function specification syntax:


f(a, b, c) ... a: int, b: int, c:string

I.e. the requirements for the parameter are specified at a completely  
different location.  It's not something I love, but it's all we have.


If you want to be able to pass multiple parameter types, then why not  
just either use overloading or, if you're really concerned about  
duplication, let the argument type be specified as a template? That  
would remove the duplication issue.


There are other gains as well.  First, a template can optimize calls to  
that specific function, for example, a simple a < b can be inlined.   
Delegates cannot.  This is why std.algorithm.sort is (well, it should be,  
enforce is another problem) faster than the builtin array sort.  Second,  
if the delegate is pure, you'd need to overload on purity as well, so that  
doubles the overloads.  Third, even when it cannot be inlined, the code is  
specifically generated to call that function, so the call will be less  
instructions, plus the type does not have to store the delegate.


If you're worried about simple things like "a < b", then it's because we  
shouldn't be using a string in the first place! It's painful to write

 foo(delegate(a, b) { return a < b; })


That also works, the string is just a nicety that makes it easy to write  
delegate literals without having to specify too much punctuation.


but that's an easily solvable solution: Just support C#'s syntax of  
lambdas and you instead get:

 foo((a, b)  =>  a < b);
which is cleaner and easy to type, and which avoids using strings for  
code. Or you can just predefine it somewhere as a lessThan template, and  
pass it as an argument. Either way, no strings.


I think the string solution is a means to avoid augmenting the syntax to  
support something like this.  I'm not really convinced by this argument  
that we "shouldn't be using a string".  Why not?  You have brought up no  
negatives about it except that you don't like it.  Do you have any  
substantial argument against them?


In any case, this shouldn't be an excuse for using templates -- if  
typing something is hard, simplifying the syntax is the answer (I'm all  
for C# lambdas...), not using the template hammer to solve everything.


It's not an excuse, there are plenty of very good reasons to use an alias  
template parameter for a functor besides having a string functor.  I think  
if we put our heads together, we can probably come up with a good solution  
to pair this with a version that uses a stored delegate as well, for those  
cases where this doesn't work (as in the OP's example).  Such a pattern  
would be a good addition to phobos/dcollections.


-Steve

Re: std.path review: update

[Steven Schveighoffer]

On Tue, 19 Jul 2011 15:55:29 -0400, Nick Sabalausky  wrote:

If such mountings are possible, it would seem that there must be some  
way to

check the sensitivity (otherwise the OS itself would probably crap out on
it).


I've done it before, mounted a windows share on a linux box via cifs.

What happens is, everything thinks it's case sensitive (i.e. any  
user-space tools), but when you go to open a file, write a file, rename a  
file, the share performs as if it were case insensitive.


For example:

ls /mnt/winshare

File.txt

find /mnt/winshare -name FILE.TXT

No files found

touch /mnt/winshare/FILE.TXT => updates date/time on File.txt

cat /mnt/winshare/FILE.TXT => outputs File.txt

So as long as you are performing operations *blindly*, the case  
insensitivity kicks in.  For example, open a file without first searching  
for it.  But if you start reading directories, tools have no idea it's on  
a case-insensitive filesystem.



Although, at least in the case of case-insensitive mountings on posix,
doesn't that mean such paths would have both case-sensitive and
case-insensitive parts?

Ex: /mount/damnWinDrive/dir/subdir

Wouldn't the "mount/damnWinDrive" part be case-sensitive and the
"dir/subdir" part be insensitve?


Yes, actually, this is a very good point.  And there's no way for std.path  
to make that distinction.



(I'm starting to really despise case-insensitive filesystems.)


I've never understood why they have any benefits whatsoever.  The only  
reason I can think of them having any use is legacy.


-Steve

Re: event based timer

[Chris Molozian]

Yes, Gtk is built using GLib and so depends on it. Here's some example 
code I'm using in a Vala project  (sorry) that uses GLib.Timeout:


public class TimeoutEntry : Granite.Entry, Gtk.Buildable {
private static const uint DEFAULT_TIMEOUT = 300; // in ms
/**
* The timeout length in milliseconds before {@see #timed_out} signal
* is called. The value defaults to 300.
*/
public uint timeout { get; set; default = DEFAULT_TIMEOUT; }
/**
* A callback fired after {@see timeout} length of time has expired in the
* non-empty entry field.
*/
public signal void timed_out();
private bool timeout_changed = false;
construct {
// add signals and callbacks
notify["timeout"].connect(() => { timeout_changed = false; });
realize.connect(() => { GLib.Timeout.add(timeout, emit_timed_out); });
changed.connect(() => { timeout_changed = true; }); // reset timeout
}
private bool emit_timed_out() {
if (timeout_changed) {
GLib.Timeout.add(timeout, emit_timed_out);
return (timeout_changed = false);
}
if (text != "") { timed_out(); }
return !timeout_changed;
}
}


Here I'm calling the timed_out signal which will execute an associated 
callback. I'm not sure what you mean by "trigger a gtk event on a 
timer", if I understand it correctly this should be helpful 
gobject.Signals.emitv  
and have a look here: 
http://stackoverflow.com/questions/1557025/create-and-emit-gtk-signal


Hope this helps,

Chris

PS: the problems you're encountering seem less and less like problems 
with D (unless they're compiler bugs)... and more like issues with 
Gtk/GLib. The GTK IRC channel can be very (very) quiet but it might help.



On 07/20/11 14:34, maarten van damme wrote:
It turned out there was a Timer in glib and glib is a part of gtk(I 
think). When you use gtkd you have acces to glib and that worked but 
it takes 50 procent of my cpu. (this was actually pretty strange. It 
worked fast and good untill I rebooted. Now it runs prety slow)

and I don't think you can trigger a gtk event on a timer.

2011/7/20 Sean Kelly >


Is there a timer function built into gtk?  Or can you have a
separate thread trigger a gtk event on a timer?

On Jul 20, 2011, at 5:00 AM, maarten van damme wrote:

> The problem with Sean Kelly's and the message sending approach
is that when using gtk I have to call Main.run(); and it pauses
then untill the windows are all closed. when I place a loop before
Main.run() I never get a window so If I want to use some kind of
timer using threads I need to use shared? (correct me if I'm wrong)
>
> The glib.Timeout works like a charm, Thank you chris
>
> 2011/7/20 Sean Kelly mailto:s...@invisibleduck.org>>
> On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:
>
> > Hi everyone,
> > for getting to know d a little bit I'm writing a simple
pingpong game using gtk.
> > for it to work I need to be able to do something every 0.1
seconds so I was wondering if there was some kind of timer in the
phobos library.
> > I've looked everywhere but couldn't find one. Is it missing
and do i have to write my own or have I overlooked it?
>
> void loop() {
>while( true ) {
>doWhatever();
>Thread.sleep(dur!"msecs"(100));
>}
> }
>
> spawn(&loop);
>
>
> Or you could have the spawned thread send a message every 100
milliseconds, etc.
>

Re: event based timer

[Andrej Mitrovic]

At least on Windoze it's a simple case of SetTimer(hwnd, ID_TIMER, msecs, NULL);

For callbacks on Windows timeSetEvent() is ok.

Re: std.path review: update

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 14:51:06 -0400, Steven Schveighoffer wrote:

> On Mon, 18 Jul 2011 14:25:57 -0400, Lars T. Kyllingstad
>  wrote:
> 
>> On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:
> 
>>> In driveName:
>>>
>>> Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
>>> think if it does, it should specify \\servername\share as the drive)
>>
>> Yes, std.path is supposed to support UNC paths.  For instance, the
>> following works now:
>>
>>   assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar",
>>   "baz"]));
>>
>> I guess you would rather have that
>>
>>   assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));
>>
>> then?  I am not very familiar with Windows network shares; is \\foo
>> never a valid path on its own?
> 
> It is and it isn't.

Well, that certainly cleared things up. ;)


> It's *not* a normal directory, because only shares
> can be in that directory.  In other words, the point at which a UNC path
> turns into normal directory structure is after the share name.
> 
> An easy way to compare is, you can only map drive letters to shares, not
> to servers.

Then driveName() should probably return the full share path.  But, of the 
following asserts, which should pass?

assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo\bar`);
assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo`);

assert (baseName(`\\foo\bar`) == `\\foo\bar`);
assert (baseName(`\\foo\bar`) == "bar");

assert (dirName(`\\foo\bar`) == `\\foo\bar`);
assert (dirName(`\\foo\bar`) == `\\foo`);

Note that if you replace `\\foo\bar` with `c:\` in the above, the first 
assert in each pair will pass.  Same with "/" on POSIX.  Basically, that 
choice corresponds to treating `\\foo\bar` as a filesystem root.


>> As I understand it, some POSIX systems also mount network drives using
>> similar paths.  Does anyone know whether "//foo" is a valid path on
>> these systems, or does it have to bee "//foo/bar"?
> 
> Typically, linux uses URL's, i.e. smb://server/share   URL parsing is
> probably not in std.path's charter.
> 
> However, I have used a command like:
> 
> mount -t cifs //server/share /mnt/serverfiles
> 
> But this is only in very special contexts.  In general I don't think
> //foo should be considered a server path on Posix systems.

I actually got a request on the Phobos list that std.path should support 
such paths.  Furthermore, the POSIX stardard explicitly mentions "//" 
paths (though it basically says it is implementation-defined whether to 
bother dealing with them).


>>> joinPath:
>>>
>>> Does this normalize the paths?  For example:
>>>
>>> joinPath("/home/steves", "../lars") => /home/steves/../lars or
>>> /home/lars ?
>>>
>>> If so, the docs should reflect that.  If not, maybe it should :)  If
>>> it doesn't, at least the docs should state that it doesn't.
>>
>> No, it doesn't, and I don't think it should.  It is better to let the
>> user choose whether they want the overhead of normalization by calling
>> normalize() explicitly.  I will specify this in the docs.
> 
> In fact, if you do not normalize during the join, it's *more* overhead
> to normalize afterwards.  If normalization is done while joining, then
> you only build one string.  There's no need to build a non-normalized
> string, then build a normalized string based on that.
> 
> Plus the data is only iterated once.
> 
> I think it's at least worth an option, but I'm not going to hold back my
> vote based on this :)

If it doesn't turn out to be a huge undertaking, I think I'll replace 
joinPath() with a function buildPath() that takes an input range of path 
segments and joins them together, with optional normalization.  Then, 
normalize(path) can be implemented as:

buildPath(pathSplitter(path));

Does that sound sensible?


>>> pathSplitter:
>>>
>>> I think this should be a bi-directional range (no technical limitation
>>> I can think of).
>>
>> It is more of a complexity vs. benefit thing, but as you are the second
>> person to ask for this, I will look into it.  A convincing use case
>> would be nice, though. :)
> 
> Well a path is more like a stack than a queue.  You are usually
> operating more on the back side of it.  To provide back and popBack
> makes a lot of sense to me.  For example, to implement the command cd
> ../foo, you need to popBack the topmost directory.

Ok, I'll see what I can do about it. :)


>>> fcmp:
>>> "On Windows, fcmp is an alias for std.string.icmp, which yields a case
>>> insensitive comparison. On POSIX, it is an alias for
>>> std.algorithm.cmp, i.e. a case sensitive comparison."
>>>
>>> What about comparing c:/foo with c:\foo?  This isn't going to be equal
>>> with icmp.
>>
>> I am a bit unsure what to do about the comparison functions (fcmp,
>> pathCharMatch and globMatch).  Aside from the issue with directory
>> separators it is, as was pointed out by someone else, entirely possible
>> to mount case-sensitive file systems on Windows and case

Re: Next in Review Queue: The New std.path

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 16:48:29 +, Ellery Newcomer wrote:

> Looks nice.
> 
> a thought:
> alternate data streams are fringe and probably don't warrant support
> (you might look into them), but windows \\?\ paths probably should be
> supported in eg joinPath and pathSplitter

I'll look into it. :)

-Lars

Re: Next in Review Queue: The New std.path

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 20:47:20 +0200, torhu wrote:

> I didn't suggest joinPaths, because the inputs are not always paths,
> generally you join things like a path to a directory together with just
> a filename.  Maybe it's ok to call it all just 'paths', I don't know.
> But the output is commonly a path, hence buildPath.  Would be
> interesting to know what other people think, though.

See my answer to Steve.  I'm considering expanding joinPath's charter a 
bit, allowing it to take an input range of path segments and perform 
normalization while concatenating them.  buildPath would be a good name 
for this.

-Lars

Re: std.path review: update

[Steven Schveighoffer]

On Wed, 20 Jul 2011 13:36:51 -0400, Lars T. Kyllingstad  
 wrote:



On Mon, 18 Jul 2011 14:51:06 -0400, Steven Schveighoffer wrote:


On Mon, 18 Jul 2011 14:25:57 -0400, Lars T. Kyllingstad
 wrote:


On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:



In driveName:

Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
think if it does, it should specify \\servername\share as the drive)


Yes, std.path is supposed to support UNC paths.  For instance, the
following works now:

  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar",
  "baz"]));

I guess you would rather have that

  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));

then?  I am not very familiar with Windows network shares; is \\foo
never a valid path on its own?


It is and it isn't.


Well, that certainly cleared things up. ;)


It is in that if you open explorer and type in \\servername, it will give  
you a list of shares you can try.  But I don't think it's a valid *path*,  
except in explorer.  So my intuition is to declare it never a valid path.


I'm not sure how \\server interacts with the low level functions of  
Windows (such as CreateFile).  Some research/experimentation is probably  
warranted.



It's *not* a normal directory, because only shares
can be in that directory.  In other words, the point at which a UNC path
turns into normal directory structure is after the share name.

An easy way to compare is, you can only map drive letters to shares, not
to servers.


Then driveName() should probably return the full share path.  But, of the
following asserts, which should pass?

assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo\bar`);
assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo`);

assert (baseName(`\\foo\bar`) == `\\foo\bar`);
assert (baseName(`\\foo\bar`) == "bar");

assert (dirName(`\\foo\bar`) == `\\foo\bar`);
assert (dirName(`\\foo\bar`) == `\\foo`);

Note that if you replace `\\foo\bar` with `c:\` in the above, the first
assert in each pair will pass.  Same with "/" on POSIX.  Basically, that
choice corresponds to treating `\\foo\bar` as a filesystem root.


Yes, I think this sounds right (pending research/experimentation cited  
above).



As I understand it, some POSIX systems also mount network drives using
similar paths.  Does anyone know whether "//foo" is a valid path on
these systems, or does it have to bee "//foo/bar"?


Typically, linux uses URL's, i.e. smb://server/share   URL parsing is
probably not in std.path's charter.

However, I have used a command like:

mount -t cifs //server/share /mnt/serverfiles

But this is only in very special contexts.  In general I don't think
//foo should be considered a server path on Posix systems.


I actually got a request on the Phobos list that std.path should support
such paths.  Furthermore, the POSIX stardard explicitly mentions "//"
paths (though it basically says it is implementation-defined whether to
bother dealing with them).


ls //root lists the contents of /root.  I'd guess that opening //root with  
open() would simply open /root.  Given that context, they should not be  
considered to be a server path IMO.



joinPath:

Does this normalize the paths?  For example:

joinPath("/home/steves", "../lars") => /home/steves/../lars or
/home/lars ?

If so, the docs should reflect that.  If not, maybe it should :)  If
it doesn't, at least the docs should state that it doesn't.


No, it doesn't, and I don't think it should.  It is better to let the
user choose whether they want the overhead of normalization by calling
normalize() explicitly.  I will specify this in the docs.


In fact, if you do not normalize during the join, it's *more* overhead
to normalize afterwards.  If normalization is done while joining, then
you only build one string.  There's no need to build a non-normalized
string, then build a normalized string based on that.

Plus the data is only iterated once.

I think it's at least worth an option, but I'm not going to hold back my
vote based on this :)


If it doesn't turn out to be a huge undertaking, I think I'll replace
joinPath() with a function buildPath() that takes an input range of path
segments and joins them together, with optional normalization.  Then,
normalize(path) can be implemented as:

buildPath(pathSplitter(path));

Does that sound sensible?


That sounds good.

-Steve

Re: std.path review: update

[Lars T. Kyllingstad]

On Wed, 20 Jul 2011 14:16:04 -0400, Steven Schveighoffer wrote:

> I'm not sure how \\server interacts with the low level functions of
> Windows (such as CreateFile).  Some research/experimentation is probably
> warranted.

Any .NET programmers out there?  Can you please tell me what the 
following functions return?

  System.IO.Path.GetDirectoryName("\\foo\bar")
  System.IO.Path.GetPathRoot("\\foo\bar\baz")

-Lars

Re: std.path review: update

[Lars T. Kyllingstad]

On Wed, 20 Jul 2011 17:36:51 +, Lars T. Kyllingstad wrote:

> On Mon, 18 Jul 2011 14:51:06 -0400, Steven Schveighoffer wrote:
> 
>> On Mon, 18 Jul 2011 14:25:57 -0400, Lars T. Kyllingstad
>>  wrote:
>> 
>>> On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:
>> 
 In driveName:

 Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
 think if it does, it should specify \\servername\share as the drive)
>>>
>>> Yes, std.path is supposed to support UNC paths.  For instance, the
>>> following works now:
>>>
>>>   assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar",
>>>   "baz"]));
>>>
>>> I guess you would rather have that
>>>
>>>   assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));
>>>
>>> then?  I am not very familiar with Windows network shares; is \\foo
>>> never a valid path on its own?
>> 
>> It is and it isn't.
> 
> Well, that certainly cleared things up. ;)
> 
> 
>> It's *not* a normal directory, because only shares can be in that
>> directory.  In other words, the point at which a UNC path turns into
>> normal directory structure is after the share name.
>> 
>> An easy way to compare is, you can only map drive letters to shares,
>> not to servers.
> 
> Then driveName() should probably return the full share path.  But, of
> the following asserts, which should pass?
> 
> assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo\bar`); assert
> (pathSplitter(`\\foo\bar\baz`).front == `\\foo`);
> 
> assert (baseName(`\\foo\bar`) == `\\foo\bar`); assert
> (baseName(`\\foo\bar`) == "bar");
> 
> assert (dirName(`\\foo\bar`) == `\\foo\bar`); assert
> (dirName(`\\foo\bar`) == `\\foo`);
> 
> Note that if you replace `\\foo\bar` with `c:\` in the above, the first
> assert in each pair will pass.  Same with "/" on POSIX.  Basically, that
> choice corresponds to treating `\\foo\bar` as a filesystem root.
> 
> 
>>> As I understand it, some POSIX systems also mount network drives using
>>> similar paths.  Does anyone know whether "//foo" is a valid path on
>>> these systems, or does it have to bee "//foo/bar"?
>> 
>> Typically, linux uses URL's, i.e. smb://server/share   URL parsing is
>> probably not in std.path's charter.
>> 
>> However, I have used a command like:
>> 
>> mount -t cifs //server/share /mnt/serverfiles
>> 
>> But this is only in very special contexts.  In general I don't think
>> //foo should be considered a server path on Posix systems.
> 
> I actually got a request on the Phobos list that std.path should support
> such paths.  Furthermore, the POSIX stardard explicitly mentions "//"
> paths (though it basically says it is implementation-defined whether to
> bother dealing with them).
> 
> 
 joinPath:

 Does this normalize the paths?  For example:

 joinPath("/home/steves", "../lars") => /home/steves/../lars or
 /home/lars ?

 If so, the docs should reflect that.  If not, maybe it should :)  If
 it doesn't, at least the docs should state that it doesn't.
>>>
>>> No, it doesn't, and I don't think it should.  It is better to let the
>>> user choose whether they want the overhead of normalization by calling
>>> normalize() explicitly.  I will specify this in the docs.
>> 
>> In fact, if you do not normalize during the join, it's *more* overhead
>> to normalize afterwards.  If normalization is done while joining, then
>> you only build one string.  There's no need to build a non-normalized
>> string, then build a normalized string based on that.
>> 
>> Plus the data is only iterated once.
>> 
>> I think it's at least worth an option, but I'm not going to hold back
>> my vote based on this :)
> 
> If it doesn't turn out to be a huge undertaking, I think I'll replace
> joinPath() with a function buildPath() that takes an input range of path
> segments and joins them together, with optional normalization.  Then,
> normalize(path) can be implemented as:
> 
> buildPath(pathSplitter(path));
> 
> Does that sound sensible?

Actually, I realise now, it doesn't. :)  Since joinPath/buildPath needs 
to support path segments containing multiple directories, normalize would 
just be

  buildPath(path)

-Lars

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-20 12:50, David Nadlinger wrote:

On 7/20/11 10:36 AM, Ulrik Mikaelsson wrote:

[…]I've later learned the experience is shared with others, I
know one company who even went back to .NET due to too much hassle
with Ruby On Rails deployments (gem), […]


Do you happen to known what issues they experienced in more detail? I'm
curious because I personally found Rails deployment to be quite
convenient, extending the Gemfile during development as needed, and then
using Bundler (http://gembundler.com/) to ensure that the exact same
versions of the dependencies are used when staging and deploying…

David


Exactly.

--
/Jacob Carlborg

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-20 14:01, Ulrik Mikaelsson wrote:

So what are you suggesting, that we don't have a package manager for D?

I'm suggesting, I'm not likely to use it, and developing a D-specific
package manager should not accidentally exclude stand-alone building
of packages. As I said before, the build-system and packaging system
must be independent, but well integrated.


Of course, they should be independent. If I gave the impression of 
anything else, then that's a misunderstanding.



Quoting again from Russel Winder:

Having a D language packaging system that was in some way harmonious
with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy.
Indirectly it would make traction a whole lot easier.



--
/Jacob Carlborg

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-20 14:05, Ulrik Mikaelsson wrote:

2011/7/20 David Nadlinger:

Do you happen to known what issues they experienced in more detail? I'm
curious because I personally found Rails deployment to be quite convenient,
extending the Gemfile during development as needed, and then using Bundler
(http://gembundler.com/) to ensure that the exact same versions of the
dependencies are used when staging and deploying…


I do not know exactly what their problems was. For me, it was mainly
conflicts between OS package manager and language-specific. I recall
curl-bindings, and MySQL binding causing a lot of problems, also I
recall some graphics library depending on GTK breaking spectacularly.
Perhaps it's more polished now, or perhaps I just had bad luck.


What do you need curl for? Ruby has built-in support for bascially all 
curl's functionality. I haven't had any problems with using Ruby on 
Rails together with MySQL, on Linux.


--
/Jacob Carlborg

Re: std.path review: update

[Lars T. Kyllingstad]

On Tue, 19 Jul 2011 15:55:29 -0400, Nick Sabalausky wrote:

> "Lars T. Kyllingstad"  wrote in message
> news:j01trl$2ia$6...@digitalmars.com...
>> On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:
>>> In driveName:
>>>
>>> Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
>>> think if it does, it should specify \\servername\share as the drive)
>>
>> Yes, std.path is supposed to support UNC paths.  For instance, the
>> following works now:
>>
>>  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar",
>>  "baz"]));
>>
>> I guess you would rather have that
>>
>>  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));
>>
>> then?  I am not very familiar with Windows network shares; is \\foo
>> never a valid path on its own?
>>
>>
> I don't know whether or not it's "never" a valid path, but "dir
> \\server" always fails and "dir \\server\share" always works (assuming
> it exists, at least). So treating the whole thing as a drive might be
> the right thing to do. (Of course, it's completely moronic that WIndows
> works that way...)
> 
> 
>>> fcmp:
>>> "On Windows, fcmp is an alias for std.string.icmp, which yields a case
>>> insensitive comparison. On POSIX, it is an alias for
>>> std.algorithm.cmp, i.e. a case sensitive comparison."
>>>
>>> What about comparing c:/foo with c:\foo?  This isn't going to be equal
>>> with icmp.
>>
>> I am a bit unsure what to do about the comparison functions (fcmp,
>> pathCharMatch and globMatch).  Aside from the issue with directory
>> separators it is, as was pointed out by someone else, entirely possible
>> to mount case-sensitive file systems on Windows and case-insensitive
>> file systems on POSIX.  (The latter is not uncommon on OSX, I believe.)
>>  I am open to suggestions.
>>
>>
> If such mountings are possible, it would seem that there must be some
> way to check the sensitivity (otherwise the OS itself would probably
> crap out on it).

That check would probably be orders of magnitude more expensive than a 
simple string operation.


> Although, at least in the case of case-insensitive mountings on posix,
> doesn't that mean such paths would have both case-sensitive and
> case-insensitive parts?
> 
> Ex: /mount/damnWinDrive/dir/subdir
> 
> Wouldn't the "mount/damnWinDrive" part be case-sensitive and the
> "dir/subdir" part be insensitve?

Argh.


> (I'm starting to really despise case-insensitive filesystems.)

Me too.

Does anyone know whether Windows' case insensitivity is limited to ASCII? 
If not, is the filesystem Unicode-aware, or does it uses some locale 
specific codepage to compare file names?

-Lars

Re: event based timer

[maarten van damme]

If someoene feels like playing some good old pong, go here:
http://dl.dropbox.com/u/15024434/Ball.exe
Beeing so slow seemed to be a temporary problem, it works good right now.

I'm really hoping on a good timer for phobos, having to use a tird party
library for something like a timer seems kind off ridiculous coming from
java :). I've heard the c++ boost library has a timer, maybe someone can
look at it and port it to D or write one from scratch?

Other than that thanks for all the help.

Re: Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/20 Jacob Carlborg :
> What do you need curl for?
Saturating gigabit file transfers with wide support of varying
protocols, encryption and authentication schemes.

In any case, there's always going to be needs for bindings, either
because a package in other language (usually C/C++) offers more
functionality, or (not likely a problem for D) higher performance.

Re: CTFE: What limitations remain?

[Don]

dsimcha wrote:

The documentation for CTFE is outdated and specifies limitations that no
longer exist thanks to Don's massive overhaul.  For example, a big one is that
pointers now work.  What limitations that could potentially be removed still
do exist in CTFE as of 2.054?


I rewrote the documentation for CTFE, it's been in the docs on github 
for several weeks but apparently didn't get into the download???
(I went on holidays before the beta was released, so I wasn't able to 
check it).

Re: std.path review: update

[Alix Pexton]

On 20/07/2011 20:57, Lars T. Kyllingstad wrote:


Does anyone know whether Windows' case insensitivity is limited to ASCII?
If not, is the filesystem Unicode-aware, or does it uses some locale
specific codepage to compare file names?

-Lars


Wikipedia says Windows long file names are up to 255 UTF-16 characters 
(or code points, depending which article you refer to >< ) Seems 
consistent with Microsoft's approach to character encoding throughout 
the rest of the Windows API.



http://en.wikipedia.org/wiki/Long_filename


A...

Copying structs with pointers

[Peter Alexander]

Just came across this issue today. I wanted to create a typical value 
type wrapper around a heap allocated object. I even created a nice 
postblit constructor like a good D programmer.



struct Ptr
{
  private int* p;
  this(int x) { p = new int; *p = x; }
  this(this) { int x = *p; p = new int; *p = x; }
  ...
}

void main()
{
  const Ptr a = Ptr(1);
  Ptr b = a; // error
}


Problem is, this code is illegal because you can't create a non-const 
copy of a const value type that contains pointers or references (due to 
transitive const).


I can get around it in this particular instance by creating a dup 
property (like a C++ copy constructor):


struct Ptr
{
  @property const Ptr dup()
  {
return Ptr(*p);
  }
}

But it still means that my struct is non-copyable in general. For 
example, I can't fill a range with a const Ptr.


const Ptr a = Ptr(1);
Ptr[10] arr;
std.algorithm.fill(arr[], a); // error


I understand why the shallow copy isn't allowed in general (it would 
break transitive const), but as the dup property demonstrates, I am able 
to create a deep copy of Ptr without violating const-correctness -- the 
problem is that I am not able to express this using a postblit constructor.


Am I missing something? How are you supposed to define value semantics 
on structs containing pointers?

Re: Copying structs with pointers

[Jonathan M Davis]

On 2011-07-20 14:49, Peter Alexander wrote:
> Just came across this issue today. I wanted to create a typical value
> type wrapper around a heap allocated object. I even created a nice
> postblit constructor like a good D programmer.
> 
> 
> struct Ptr
> {
> private int* p;
> this(int x) { p = new int; *p = x; }
> this(this) { int x = *p; p = new int; *p = x; }
> ...
> }
> 
> void main()
> {
> const Ptr a = Ptr(1);
> Ptr b = a; // error
> }
> 
> 
> Problem is, this code is illegal because you can't create a non-const
> copy of a const value type that contains pointers or references (due to
> transitive const).
> 
> I can get around it in this particular instance by creating a dup
> property (like a C++ copy constructor):
> 
> struct Ptr
> {
> @property const Ptr dup()
> {
> return Ptr(*p);
> }
> }
> 
> But it still means that my struct is non-copyable in general. For
> example, I can't fill a range with a const Ptr.
> 
> const Ptr a = Ptr(1);
> Ptr[10] arr;
> std.algorithm.fill(arr[], a); // error
> 
> 
> I understand why the shallow copy isn't allowed in general (it would
> break transitive const), but as the dup property demonstrates, I am able
> to create a deep copy of Ptr without violating const-correctness -- the
> problem is that I am not able to express this using a postblit constructor.
> 
> Am I missing something? How are you supposed to define value semantics
> on structs containing pointers?

Postblit doesn't work with const or immutable right now: 
http://d.puremagic.com/issues/show_bug.cgi?id=4867

- Jonathan M Davis

Re: Copying structs with pointers

[Peter Alexander]

On 20/07/11 11:06 PM, Jonathan M Davis wrote:

Postblit doesn't work with const or immutable right now:
http://d.puremagic.com/issues/show_bug.cgi?id=4867


Is that the issue though? I believe it's a deeper issue.

An example:

struct Ptr
{
  int* p;
  this(int x) { p = new int; *p = x; }
  this(this) { /+ do nothing +/ } // (!!!)
  const int get() { return *p; }
  void set(int x) { *p = x; }
}

void main()
{
  const Ptr a = Ptr(1);
  Ptr b = a; // shallow copy! const removed!
  b.set(2);
  assert(a.get() == 1); // FAIL
}


If you allow this then it means that you can get a non-const pointer 
through a const object, which breaks the transitivity of const.

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[Don]

Nick Sabalausky wrote:
Yet again, a new DMD release has broken my code, and other people's code, 
too, just because of Phobos functions loosing their CTFE-ability. (strip(), 
toLower(), etc... And yes, I did bring up the strip() regression on the beta 
list, to no effect.)


The situation is, that prior to 2.054, use of Phobos in CTFE functions 
has not been supported. No official statements have ever been made that 
it was supported (and I've tried hard to publicize the fact that it was 
not supported). There were some fundamental wrong-code bugs and severe 
limitations in CTFE. And so although some Phobos functions seemed to 
work in CTFE, most of them were not correct.
So, any Phobos function which used to work in CTFE in some old release 
but doesn't any more is not a regression. It was just dumb luck, relying 
on undefined behaviour, if any happened to work in a particular release.


This has changed with 2.054. Although there are still some restrictions 
(no classes, many builtin functions aren't implemented), the fundamental 
wrong code bugs are fixed. So any Phobos function which works in CTFE in 
2.054, but fails in a future release, can be considered a regression.

We are now in a _completely_ different regime.

Re: Copying structs with pointers

[Jonathan M Davis]

On 2011-07-20 15:30, Peter Alexander wrote:
> On 20/07/11 11:06 PM, Jonathan M Davis wrote:
> > Postblit doesn't work with const or immutable right now:
> > http://d.puremagic.com/issues/show_bug.cgi?id=4867
> 
> Is that the issue though? I believe it's a deeper issue.

It means that regardless of whether there's a deeper issue, using const with 
postblit isn't going to work.

> An example:
> 
> struct Ptr
> {
> int* p;
> this(int x) { p = new int; *p = x; }
> this(this) { /+ do nothing +/ } // (!!!)
> const int get() { return *p; }
> void set(int x) { *p = x; }
> }
> 
> void main()
> {
> const Ptr a = Ptr(1);
> Ptr b = a; // shallow copy! const removed!
> b.set(2);
> assert(a.get() == 1); // FAIL
> }
> 
> 
> If you allow this then it means that you can get a non-const pointer
> through a const object, which breaks the transitivity of const.

Hmmm. This is definitely a problem. It should be possible to use postblits 
when the object being copied is const and has pointers and/or references. If 
not, that's fairly crippling. But without doing some sort of flow analysis, I 
don't see how the problem that you present can be fixed. If it were a copy 
constructor, it would be straightforward - everything gets default initialized 
and then you assign stuff from the const original, making copies where 
required. But a postblit does a shallow copy _first_, which means that either 
this is forced to point to const (thereby making it so that you can't do 
anything but a shallow copy and that the copy must be const), or the type 
system gets twisted a bit by allowing this to point to mutable even though 
it's const and the compiler then must ensure that copies are made (or at least 
that the original values are not kept) or const would be bypassed (and even 
that probably wouldn't work, since then you'd have to worry about the member 
variables being passed to functions as mutable inside of the constructor when 
they're really const underneath). And I don't think that either of those 
solutions really works.

Maybe we actually need a copy constructor of some kind for this sort of case. 
I don't see how to get around it with a postblit. This is definitely a big 
problem.

- Jonathan M Davis

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[Jonathan M Davis]

On 2011-07-20 15:37, Don wrote:
> Nick Sabalausky wrote:
> > Yet again, a new DMD release has broken my code, and other people's code,
> > too, just because of Phobos functions loosing their CTFE-ability.
> > (strip(), toLower(), etc... And yes, I did bring up the strip()
> > regression on the beta list, to no effect.)
> 
> The situation is, that prior to 2.054, use of Phobos in CTFE functions
> has not been supported. No official statements have ever been made that
> it was supported (and I've tried hard to publicize the fact that it was
> not supported). There were some fundamental wrong-code bugs and severe
> limitations in CTFE. And so although some Phobos functions seemed to
> work in CTFE, most of them were not correct.
> So, any Phobos function which used to work in CTFE in some old release
> but doesn't any more is not a regression. It was just dumb luck, relying
> on undefined behaviour, if any happened to work in a particular release.
> 
> This has changed with 2.054. Although there are still some restrictions
> (no classes, many builtin functions aren't implemented), the fundamental
> wrong code bugs are fixed. So any Phobos function which works in CTFE in
> 2.054, but fails in a future release, can be considered a regression.
> We are now in a _completely_ different regime.

If that's the case, then we should look at adding CTFEability tests to at 
least some portion of Phobos.

- Jonathan M Davis

Re: CTFE: What limitations remain?

[Walter Bright]

On 7/20/2011 1:59 PM, Don wrote:

I rewrote the documentation for CTFE, it's been in the docs on github for
several weeks but apparently didn't get into the download???
(I went on holidays before the beta was released, so I wasn't able to check it).


I don't see it here?

https://github.com/D-Programming-Language/d-programming-language.org/pulls

Re: Copying structs with pointers

[Peter Alexander]

On 20/07/11 11:50 PM, Jonathan M Davis wrote:

Maybe we actually need a copy constructor of some kind for this sort of case.
I don't see how to get around it with a postblit. This is definitely a big
problem.

- Jonathan M Davis


My thoughts exactly.

Re: D Programming Language Specification ebook

[Peter Alexander]

On 19/07/11 8:12 AM, Walter Bright wrote:

On 7/17/2011 6:14 AM, Mike James wrote:

Anyway, its handy to have when your stuck on a airport with nothing to
read
:-)


Reading specs for fun, I love it!



You know you're obsessed with D when...

:-)

Re: Copying structs with pointers

[Andrei Alexandrescu]

On 7/20/11 6:12 PM, Peter Alexander wrote:

On 20/07/11 11:50 PM, Jonathan M Davis wrote:

Maybe we actually need a copy constructor of some kind for this sort
of case.
I don't see how to get around it with a postblit. This is definitely a
big
problem.

- Jonathan M Davis


My thoughts exactly.


Walter and I are on it and know what's to be done there. But we couldn't 
find the time to do it yet.


Andrei

Binary Decision Diagrams

[d coder]

Greetings

Is there some BDD library port to D? Is anybody working on such stuff?

Please let me know. I need a good BDD library in D. If there is no such
existing work, I plan to port buddy
http://buddy.sourceforge.net/manual/main.html to D myself.

Regards
- Puneet

Windows GDC and libgcc_s_sjlj-1.dll

[Andre Tampubolon]

I just tried GDC on Windows, and I found out that the executables
created are linked into libgcc_s_sjlj-1.dll. Will it be possible to get
rid of the dependency on this DLL?

Building gtkD

[Steve Teale]

If there are still people out there who are struggling with this, I have just
gone through the process on Ubuntu, and made some notes as a result.

They can be found at http://britseyeview.com/software (most recent post).

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.1817.1311202371.14074.digitalmar...@puremagic.com...
> On 2011-07-20 15:37, Don wrote:
>> Nick Sabalausky wrote:
>> > Yet again, a new DMD release has broken my code, and other people's 
>> > code,
>> > too, just because of Phobos functions loosing their CTFE-ability.
>> > (strip(), toLower(), etc... And yes, I did bring up the strip()
>> > regression on the beta list, to no effect.)
>>
>> The situation is, that prior to 2.054, use of Phobos in CTFE functions
>> has not been supported. No official statements have ever been made that
>> it was supported (and I've tried hard to publicize the fact that it was
>> not supported). There were some fundamental wrong-code bugs and severe
>> limitations in CTFE. And so although some Phobos functions seemed to
>> work in CTFE, most of them were not correct.
>> So, any Phobos function which used to work in CTFE in some old release
>> but doesn't any more is not a regression. It was just dumb luck, relying
>> on undefined behaviour, if any happened to work in a particular release.
>>

Ok, I see. I guess I must have missed that.

>> This has changed with 2.054. Although there are still some restrictions
>> (no classes, many builtin functions aren't implemented), the fundamental
>> wrong code bugs are fixed. So any Phobos function which works in CTFE in
>> 2.054, but fails in a future release, can be considered a regression.
>> We are now in a _completely_ different regime.

Glad to hear it!

>
> If that's the case, then we should look at adding CTFEability tests to at
> least some portion of Phobos.
>

Totally agree. I think string-processing and anything else likely to be 
needed in string metaprogramming (such as to!string(int) and to!int(string)) 
would be the most important ones.

What is the stance on partial initializers when declaring multiple variables of the same type?

[Andrej Mitrovic]

I ran into this simple C declaration:

float float_x, float_y, float_xb, float_yb;

These need to be explicitly initialized in D, otherwise you either get
crashes or you won't get anything but a blank screen (with regards to
rendering with OpenGL).

Almost instinctively I went for:

float float_x, float_y, float_xb, float_yb = 0.0;

But that's incorrect, only float_yb is zero-initialized, the others
are initialized to NaN (well I predicted that but I was kinda hoping D
would be cool and use a common initializer).

What I'm asking is, are partial initializers useful for people? I'm
not suggesting any changes, but just starting a discussion. It does
look like this could maybe introduce bugs. I think someone might have
mentioned this topic before, but I don't recall.

Here's to a healthy discussion..

Re: What is the stance on partial initializers when declaring multiple variables of the same type?

[Jonathan M Davis]

On Thursday 21 July 2011 08:52:03 Andrej Mitrovic wrote:
> I ran into this simple C declaration:
> 
> float float_x, float_y, float_xb, float_yb;
> 
> These need to be explicitly initialized in D, otherwise you either get
> crashes or you won't get anything but a blank screen (with regards to
> rendering with OpenGL).
> 
> Almost instinctively I went for:
> 
> float float_x, float_y, float_xb, float_yb = 0.0;
> 
> But that's incorrect, only float_yb is zero-initialized, the others
> are initialized to NaN (well I predicted that but I was kinda hoping D
> would be cool and use a common initializer).
> 
> What I'm asking is, are partial initializers useful for people? I'm
> not suggesting any changes, but just starting a discussion. It does
> look like this could maybe introduce bugs. I think someone might have
> mentioned this topic before, but I don't recall.
> 
> Here's to a healthy discussion..

Honestly, I tend to think that it's bad practice to declare more than one 
variable on a line. Regardless, this is doing exactly what I'd expect it to. 
But I don't see much point in changing it. If you changed it so that all of 
those floats were initialized to 0.0, it would likely break existing code, and 
personally, I would think that it would be more surprising for them all to be 
initialized to 0.0 than for what happens to happen. In any case, I would 
generally encourage people to avoid declaring multiple variables on the same 
line. It generally makes for less readable code IMHO.

- Jonathan M Davis