Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 1:25 PM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei On reddit: http://www.reddit.com/r/programming/comments/11wkr7/the_d_conference_2013_is_raising_funds_via/ Andrei
Re: DConf 2013 on kickstarter.com: we're live!
There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. On Monday, 22 October 2012 at 18:30:09 UTC, Ali Çehreli wrote: On 10/22/2012 10:25 AM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Andrei, thanks for doing this! :) Is kickstarter the only way of pledging? I tried and had to create a kickstarter account, which I never needed. When the process then required *also* to create an Amazon account I stopped. :( Can I send a check or pay by PayPal? Thanks, Ali
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/2012 10:25 AM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Andrei, thanks for doing this! :) Is kickstarter the only way of pledging? I tried and had to create a kickstarter account, which I never needed. When the process then required *also* to create an Amazon account I stopped. :( Can I send a check or pay by PayPal? Thanks, Ali
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 18:49:22 UTC, Andrei Alexandrescu wrote: On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. I happened to have a facebook (alternate sign-in) amazon accounts so it was fairly quick and painless for me. I'll look forward to the results of the kickstarter.
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 1:25 PM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 We seem to be off to a good start. I've also just added a Facebook ad, see it demoed here: http://goo.gl/NrEis Thanks to all who've contributed, and all others please consider doing so. This is a great time to add material support to our passion for this project, and to make sure D grows and becomes increasingly significant. Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/2012 10:32 AM, Andrei Alexandrescu wrote: On reddit: http://www.reddit.com/r/programming/comments/11wkr7/the_d_conference_2013_is_raising_funds_via/ Looks like reddit's back up.
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 2:49 PM, Andrei Alexandrescu wrote: On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. Andrei So let's see to it that it does break through that limit!!!
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 23:37:25 UTC, Tyro[17] wrote: Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. So let's see to it that it does break through that limit!!! Already within a day and it's about 25% there. Looks promising.
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 17:25:28 UTC, Andrei Alexandrescu wrote: http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Typo on the front page: Some of use are lucky to already use ... ^
Re: [RFC] ColorD
Chad J wrote: On 10/21/2012 06:55 PM, Jens Mueller wrote: Chad J wrote: On 10/21/2012 06:11 PM, Jens Mueller wrote: Chad J wrote: On 10/21/2012 05:01 PM, Jens Mueller wrote: It seems to have a hard ncurses/termcap/etc dependency. Yes. I think you cannot make it portable without. Please proof me wrong and I'll fix this. Well, traditionally it's done with automake/autoconf. You'd end up with preprocessor defines that tell you whether the lib has been statically linked or not. This isn't available here because Phobos doesn't use these as a build system and I hope it never does. I mean to detect if your terminal is ANSI compatible without adding another dependency. It's easy to provide different version(...) to support different modes. One could do something like: 1. Check at run time if ncurses etc. are available. * If they are use them. * Otherwise fall back to ANSI codes or throw an Exception. What do you think? I completely agree. The difficulty I encountered is actually /doing/ the runtime detection. Does Phobos have a way to dynamically link .so files yet? It is possible since very long time to link dynamically using dmd. If yes, then we could search the obvious places (/lib/libncurses.so.5 matches on my machine right now) and link to any files found. For that purpose in particular I have written ddl. https://github.com/jkm/ddl http://jkm.github.com/ddl/ddl.html Just haven't found the time to integrate with the terminal stuff. Since color is probably never necessary for program correctness, I think it is acceptable to ignore color formatting and produce plain text when detection fails. It would make sense to make this configurable though: the Terminal object could have a .throwOnDetectionFailure flag that can be set if people want to be a bit more hardcore about it. Sounds useful. Ultimately I expect it to work with writeln or writefln to make it discoverable and easy to work with. One could try this. At least for Linux. You just have to add the appropriate escape sequences. But this won't work on Windows. I remember having a plan for this. See below. Back then I did design a format spec for introducing colors into format strings: www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html I doubt that the Phobos maintainers will accept this. This is very invasive. Hmmm, depends what is meant by invasive. I feel it's the only way to have discoverable and concise syntax. I'd be pretty disappointed if they didn't, regardless of who submits the pull request. I remember it being possible in Phobos to determine the destination of the format operation. If the destination is a string in memory, then no color formatting would be applied. If the destination is a Linux terminal of some kind, then some ncurses terminal info would be looked up (possible a cached lookup) and escape sequences generated based on that. If the destination is a Windows terminal, then these approaches can be considered: (1) Split the formatted text up on the color format boundaries. Send the slices into the stream one by one, calling the necessary WinAPI color formatting functions inbetween. I think this might not have been possible with Phobos' architecture. (2) Insert ANSI escape sequences into the text. The I/O code for Windows would then have to intercept these and convert them into the appropriate WinAPI calls. I think this was possible, and even distinguishable from the case of writing to a string in memory. If the invasiveness worry comes from the possibility of dumping escape sequences into non-terminal destinations, then I hope the above wall of text can alleviate that concern. Checking whether something is a terminal can be done using isatty on the file handle. I think this will work. But it is invasive because you want to add it to the formatting spec. Is this the usual way it is done? I don't know how it is done in Python or other languages. Is it relevant? I posit that having format syntax is simply better than not. This is on an objective basis. Maybe. Don't know. But in any case this is a add on. On top of the basic API. It is a Phobos integration thing. There is no weakness to this. The only shred of a counterargument I can think of is that it makes the format strings more difficult to learn. Other than that, it is possible to detect the destination of the formatter, so color codes will never end up in places where they shouldn't. A conservative approach to this should handle most desires and never interfere with all the people with no interest in color. On the upshot are the things I've mentioned: - A format specifier is potentially more discoverable. - A format specifier is more concise. This keeps your lines from wrapping. They are probably too long already. Do you consider this writecf(Color.red, something %s, here) concise as well? - To cement the previous
Re: [RFC] ColorD
This could be improved, the example you give writeln(Colors.Red, Foo Bar, Colors.Reset); imply that if you forget to put Colors.Reset at the end of writeln then all the following call will be made in Colors.Red which I don't like, IMHO writeln(Colors.Red, Foo Bar); is better and at the end of the writeln your settings are resetted. If you want to change the current settings, you have to use a different function call.. BR, renoX
Re: Const ref and rvalues again...
On 10/22/2012 12:18 AM, martin wrote: On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote: Const is different in D and in C++. Relating const and rvalues is arbitrary and does not make a lot of sense. It's actually pretty much the same concept in both languages except for the transitiveness in D. Case closed.
Re: Const ref and rvalues again...
On 10/22/2012 11:38 AM, Timon Gehr wrote: On 10/22/2012 12:18 AM, martin wrote: On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote: Const is different in D and in C++. Relating const and rvalues is arbitrary and does not make a lot of sense. It's actually pretty much the same concept in both languages except for the transitiveness in D. Case closed. (But it might be added that C++11 adds a new language feature just in order to be able to distinguish const and rvalue references in the callee, so even with C++'s semantics, this does not seem like a good idea.)
Re: [RFC] ColorD
On Sunday, 21 October 2012 at 22:32:35 UTC, Walter Bright wrote:
On 10/21/2012 12:28 PM, Robik wrote:
Simple example:
import std.stdio, colord;
void main()
{
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
resetConsoleColors(); // Bring back initial state
}
Need a method to get the current state, and reset the current
state. Otherwise, nested calls to the console functions will
screw up the state.
I.e.:
auto save = getConsoleState();
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
setConsoleState(save); // Bring back initial state
Or better:
auto save = getConsoleState();
scope (exit) setConsoleState(save);
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
On Windows, setting color to initial sets console colors to ones
that were set before launch of the program. On Posix it sets
default (ANSI remove formatting).
I will try to check if it is possible to get current colors on
Posix.
Re: Why does std.string.splitLines return an array?
On 10/22/12 1:05 AM, Chad J wrote:
On 10/21/2012 06:35 PM, Jonathan M Davis wrote:
On Sun, 2012-10-21 at 18:00 -0400, Chad J wrote:
std.string.splitLines returns an array, which is pretty grody. Why not
return a lazily-evaluated range struct so that we can avoid allocations
on this simple but common operation?
If you want a lazy range, then use std.algorithm.splitter. std.string
operates on and returns strings, not general ranges.
- Jonathan M Davis
std.algorithm.splitter is simply not acceptable for this. It doesn't
have this kind of logic:
bool matchLineEnd( string text, size_t pos )
{
if ( pos+1 text.length
text[pos] == '\r'
text[pos+1] == '\n' )
return true;
else if ( pos text.length
(text[pos] == '\r' || text[pos] == '\n') )
return true;
else
return false;
}
Agreed. We should add splitter() accepting only one argument of some
string type. It would use the line splitting logic above.
Could you please adapt your code to do this and package it in a pull
request? Thanks!
Andrei
Re: [RFC] ColorD
On 10/22/12 9:47 AM, Jens Mueller wrote: This is probably interesting for Phobos. But I'm not the one to make a decision. The core Phobos developers should decide. Hopefully somebody is reading this. Off the top of my head something that is specific for only certain systems (Unixen in this case) is decidedly of less Phobos interest. We could, nevertheless, put such functionality in system-specific modules. Andrei
Re: [RFC] ColorD
On Sunday, 21 October 2012 at 19:28:21 UTC, Robik wrote:
Hello,
I would like to introduce ColorD, small library that allows to
simply manipulate console output colors, both on Windows and
Posix operating systems. It also supports font styles such as
underline and strikethrough(Posix feature only).
Simple example:
import std.stdio, colord;
void main()
{
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
resetConsoleColors(); // Bring back initial state
}
Feedback welcome.
GitHub: https://github.com/robik/ColorD
Regards.
This is very much related to the ycurses and dcurses projects,
and I strongly suggest you work with people behind those projects
and come up with a nice/flexible/robust console API/package for
D.
Re: Regarding hex strings
If you want vastly human readable, you want heredoc hex syntax, something like this: ubyte[] = xEND 32 2b 32 3d 34 2e 20 32 2a 32 3d 34 2e 20 32 5e 32 3d 34 2e 20 54 68 65 72 65 66 6f 72 65 2c 20 2b 2c 20 2a 2c 20 61 6e 64 20 5e 20 61 72 65 20 74 68 65 20 73 61 6d 65 20 6f 70 65 72 61 74 69 6f 6e 2e 0a 22 36 34 30 4b 20 6f 75 67 68 74 20 74 6f 20 62 65 20 65 6e 6f 75 67 68 22 20 2d 2d 20 42 69 6c 6c 20 47 2e 2c 20 31 39 38 34 2e 20 22 54 68 65 20 49 6e 74 65 72 6e 65 74 20 69 73 20 6e 6f 74 20 61 20 70 72 69 6d 61 72 79 20 67 6f 61 6c 20 66 6f 72 20 50 43 20 75 73 61 67 65 END; Having a heredoc syntax for hex-strings that produce ubyte[] arrays is confusing for people who would (naturally) expect a string from a heredoc string. It is not named hereDOC for no reason. :)
Re: Regarding hex strings
On Thursday, 18 October 2012 at 00:45:12 UTC, bearophile wrote:
(Repost)
hex strings are useful, but I think they were invented in D1
when strings were convertible to char[]. But today they are an
array of immutable UFT-8, so I think this default type is not
so useful:
void main() {
string data1 = xA1 B2 C3 D4; // OK
immutable(ubyte)[] data2 = xA1 B2 C3 D4; // error
}
test.d(3): Error: cannot implicitly convert expression
(\xa1\xb2\xc3\xd4) of type string to ubyte[]
Generally I want to use hex strings to put binary data in a
program, so usually it's a ubyte[] or uint[].
So I have to use something like:
auto data3 = cast(ubyte[])(xA1 B2 C3 D4.dup);
So maybe the following literals are more useful in D2:
ubyte[] data4 = x[A1 B2 C3 D4];
uint[] data5 = x[A1 B2 C3 D4];
ulong[] data6 = x[A1 B2 C3 D4 A1 B2 C3 D4];
Bye,
bearophile
+1 on this one
I also like the x[ ... ] literal because it makes it obvious that
we are dealing with an array.
Re: Regarding hex strings
On 2012-45-18 02:10, bearophile bearophileh...@lycos.com wrote: So maybe the following literals are more useful in D2: ubyte[] data4 = x[A1 B2 C3 D4]; uint[] data5 = x[A1 B2 C3 D4]; ulong[] data6 = x[A1 B2 C3 D4 A1 B2 C3 D4]; That syntax is already taken, though. Still, I see no reason for x... not to return ubyte[]. -- Simen
Re: Const ref and rvalues again...
On Monday, 22 October 2012 at 09:41:38 UTC, Timon Gehr wrote:
(But it might be added that C++11 adds a new language feature
just in order to be able to distinguish const and rvalue
references in the callee, so even with C++'s semantics, this
does not seem like a good idea.)
Yeah, and that T syntax is mainly used for _mutable_ rvalue
references in move constructors and assignment operators to move
(hijack) mutable data from the rvalue to another T instance
instead of copying that data, knowing that the rvalue's data is
not going to be accessed anymore anyway. So this is a different
case and does currently not apply to D afaik since there is no
way to forward rvalues:
void foo(ref T lvalue) { }
void foo(T rvalue) { }
In the latter overload for rvalues, you aren't given the original
rvalue, but a copy of it!
Distinguishing between _const_ rvalue and lvalue references
though makes no sense imho, and that is my whole point.
Re: [RFC] ColorD
Andrei Alexandrescu wrote: On 10/22/12 9:47 AM, Jens Mueller wrote: This is probably interesting for Phobos. But I'm not the one to make a decision. The core Phobos developers should decide. Hopefully somebody is reading this. Off the top of my head something that is specific for only certain systems (Unixen in this case) is decidedly of less Phobos interest. We could, nevertheless, put such functionality in system-specific modules. It also works on Windows. Even already implemented. The situation is similar to the file abstraction which has a different API in the Unix world and the Windows world. Jens
Re: [RFC] ColorD
Robik wrote:
On Sunday, 21 October 2012 at 22:32:35 UTC, Walter Bright wrote:
On 10/21/2012 12:28 PM, Robik wrote:
Simple example:
import std.stdio, colord;
void main()
{
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
resetConsoleColors(); // Bring back initial state
}
Need a method to get the current state, and reset the current
state. Otherwise, nested calls to the console functions will screw
up the state.
I.e.:
auto save = getConsoleState();
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
setConsoleState(save); // Bring back initial state
Or better:
auto save = getConsoleState();
scope (exit) setConsoleState(save);
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
On Windows, setting color to initial sets console colors to ones
that were set before launch of the program. On Posix it sets default
(ANSI remove formatting).
I will try to check if it is possible to get current colors on
Posix.
Please look for this. But my research concluded that there is no such
way on Posix.
Jens
dmd -run and command line argument order
I just noticed this slightly odd behaviour from dmd -run and wondered if
it's a bug?
[vertest.d]
import std.stdio;
void main()
{
version(TEST) writefln(TEST);
}
If we compile without -run we get consistent/expected behaviour from
-version:
C:\TEMPdmd vertest.d -version=TEST
C:\TEMPvertest
TEST
C:\TEMPdmd -version=TEST vertest.d
C:\TEMPvertest
TEST
But, if we use -run...
C:\TEMPdmd -run vertest.d -version=TEST - weird, outputs nothing
C:\TEMPdmd -version=TEST -run vertest.d
TEST
Basically it looks like -run ignores any arguments that follow it..
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: New std.process?
On 22-10-2012 07:46, Graham St Jack wrote: On Sun, 21 Oct 2012 21:36:32 +0400, Denis Shelomovskij wrote: 21.10.2012 1:52, David Nadlinger пишет: On Saturday, 20 October 2012 at 18:56:01 UTC, Alex Rønne Petersen wrote: Oh, and could somebody please post a link to the latest version of the new std.process draft? I will probably add cross-platform support for constraining execution time and resource (RAM, mostly) usage, but there is no point in reimplementing it if it's already there. David Probably original discussion with links: http://www.digitalmars.com/d/archives/digitalmars/D/ The_new_std.process_163694.html Links from that thread: * std.process overhaul: https://github.com/kyllingstad/phobos/commits/new-std-process * druntime changes: https://github.com/schveiguy/druntime/commits/new-std-process I am also hanging out for the new std.process. Any idea when the required druntime changes will go in, or if they have already? I suspect they're probably some trivial POSIX/Windows API declarations, so reviewing and merging them shouldn't be a bottleneck, but somebody has to actually submit the changes as a pull request. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: [RFC] ColorD
On Monday, 22 October 2012 at 12:30:38 UTC, Jens Mueller wrote: But my research concluded that there is no such way on Posix. Yeah, if there was a way to get current colors, you wouldn't have to set environment variables for programs like vi to know if the background is light or dark. It's a pity the unix designers didn't change the definition slightly of the text palette way back when so you didn't have to know anyway...
Re: dmd -run and command line argument order
It does not ignore, it passes them as an arguments to resulting
program.
On Monday, 22 October 2012 at 12:36:44 UTC, Regan Heath wrote:
I just noticed this slightly odd behaviour from dmd -run and
wondered if it's a bug?
[vertest.d]
import std.stdio;
void main()
{
version(TEST) writefln(TEST);
}
If we compile without -run we get consistent/expected behaviour
from -version:
C:\TEMPdmd vertest.d -version=TEST
C:\TEMPvertest
TEST
C:\TEMPdmd -version=TEST vertest.d
C:\TEMPvertest
TEST
But, if we use -run...
C:\TEMPdmd -run vertest.d -version=TEST - weird, outputs
nothing
C:\TEMPdmd -version=TEST -run vertest.d
TEST
Basically it looks like -run ignores any arguments that follow
it..
R
Mixin replacement for switch...case?
Hi!
This is a question from a complete newbie.
Is there a way to replace switch...case statements by a mixin
template, maybe a variadic mixin template (does such a thing
exist?).
What I would want to achieve is to have this kind of syntax:
mixin Select!(value,
if0, { then0(); },
if1, { then1(); },
if2, { foo(); bar(); },
{ thenDefault(); }
);
to replace this:
switch(value) {
case if0 : { then0(); } break;
case if1 : { then1(); } break;
case if2 : { foo(); bar(); } break;
default : thenDefault();
}
The reason I ask this is because I almost never use fall through
and the verbosity of the switch statement has been driving me
crazy.
Re: [RFC] ColorD
On 10/22/12 8:24 AM, Jens Mueller wrote: Andrei Alexandrescu wrote: On 10/22/12 9:47 AM, Jens Mueller wrote: This is probably interesting for Phobos. But I'm not the one to make a decision. The core Phobos developers should decide. Hopefully somebody is reading this. Off the top of my head something that is specific for only certain systems (Unixen in this case) is decidedly of less Phobos interest. We could, nevertheless, put such functionality in system-specific modules. It also works on Windows. Even already implemented. The situation is similar to the file abstraction which has a different API in the Unix world and the Windows world. Jens Cool. Do all systems implement color as escape sequences? Andrei
Re: [RFC] ColorD
Andrei Alexandrescu wrote: On 10/22/12 8:24 AM, Jens Mueller wrote: Andrei Alexandrescu wrote: On 10/22/12 9:47 AM, Jens Mueller wrote: This is probably interesting for Phobos. But I'm not the one to make a decision. The core Phobos developers should decide. Hopefully somebody is reading this. Off the top of my head something that is specific for only certain systems (Unixen in this case) is decidedly of less Phobos interest. We could, nevertheless, put such functionality in system-specific modules. It also works on Windows. Even already implemented. The situation is similar to the file abstraction which has a different API in the Unix world and the Windows world. Jens Cool. Do all systems implement color as escape sequences? No. On Windows you have to explicitly call a function. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686047%28v=vs.85%29.aspx Jens
Re: Const ref and rvalues again...
On Monday, 22 October 2012 at 11:59:27 UTC, martin wrote: In the latter overload for rvalues, you aren't given the original rvalue, but a copy of it! I need to correct that after a quick test: the rvalue is passed directly (moved) instead of copying it (well, at least the copy constructor this(this) is not invoked, even in a debug build); that makes perfect sense, is efficient and eliminates the need for C++ rvalue references (T). It doesn't affect the need for an implicit rvalue = const ref propagation though. What I'd like to see is the following passing scheme for function arguments (read-only parameters are denoted by (*)): lvalue: rvalue: T: copy move (*) in T: copy move out T: pass pointer n/a ref T: pass pointer n/a (*) in ref T: pass pointer store on the caller's stack and pass its address So only the rvalue passing rule for the in ref T case would need to be implemented. This would allow to use foo(in ref T bar) for lvalues (eliding a copy expected to be costly) as well as rvalues instead of having to add an overload foo(in T bar) for rvalues. For rvalues, this would actually implicate a performance hit due to pointer indirection, so the compiler could attempt to add an automatic foo(in T bar) overload if not existent. For rvalues, the latter overload (i.e., in T parameters) should be preferred over in ref T parameters - exactly as the thread starter Malte proposes: - Make functions that take ref in arguments also accept rvalues. - The user can still provide an overload that accepts an rvalue, using the in keyword, and that one will be preferred over the ref in version.
Re: [RFC] ColorD
On Monday, 22 October 2012 at 12:26:29 UTC, Jens Mueller wrote: It also works on Windows. It's still more of a linux tradition. Implementing it as a separate package will be also a good exercise of writing a layer over Phobos I/O system.
Download link on digitalmars.com outdated
Just accidentially clicked the Download Now link for D and it still points to 2.058.
Normal/Gaussian random number generation for D
Hello all,
A request for feedback on the design of this code before I put it through some
serious testing and submit a formal pull request to Phobos' std.random.
The goal here is to provide an interface that is close to the Boost/C++11 design
while allowing for some extra interesting possibilities. In particular the goal
is to allow the possibility of different underlying generation algorithms or
engines that can serve different requirements regarding speed, precision,
memory consumption etc. See:
http://www.cse.cuhk.edu.hk/%7Ephwl/mt/public/archives/papers/grng_acmcs07.pdf
... for further details.
The present code contains both a function and struct interface for normal random
number generation; the latter stores the parameters of the distribution (mean
and standard deviation) and an instance of the underlying engine, but not the
random number generator.
(An alternative design choice for the struct would have been to design it as a
range with front/popFront, but for this to work I'd have had to also have it
store the RNG, and this would run into the same problems as RandomSample has due
to RNGs not being reference types. Boost/C++11 also do not store the RNG
internally but implement a variate_generator class which allows the coupling of
a random-number distribution and an underlying generator; this is the approach
I'd take for defining say a RandomVariate range.)
I've so far implemented one underlying engine, the Box-Muller method currently
used in Boost. This is not the best engine possible -- an implementation of the
Ziggurat algorithm is desirable -- but it represents what is typically used in
other libraries. The essence of Box-Muller is that it generates
(uniformly-distributed) numbers a pair at a time and then uses those to generate
a corresponding pair of normally-distributed numbers. The method is described here:
https://en.wikipedia.org/wiki/Box-Muller_transform
I've stuck very closely to the implementation in Boost, to the point of
reproducing a trick Boost uses to get round the fact that its uniform random
number generator only supports the interval [a, b) whereas the canonical
description of Box-Muller requires the random numbers to be distributed in the
interval (0, 1]. Obviously in D this is avoidable, but I felt there was some
advantage in reproducing identical results to Boost, at least within the limits
of floating-point numerical rounding (and maybe also because D's PI variable
goes to a greater number of decimal places).
From a licensing point of view this close reproduction isn't an issue, as Boost
and Phobos both use the same licence, but there'll be a credit to the original
Boost authors in any pull request. However, if there's a desire to
differentiate the code more strongly, that can be arranged :-) I've attached a
small C++ code example to demonstrate the common output for the D version and
that of Boost.
Anyway, what I'd really appreciate feedback on is the interface design for these
functions and structs. A few concrete questions:
(1) Does the order of template arguments seem optimal? My inclination is
perhaps to tweak it so that the Uniform RNG type goes first, the underlying
engine second, and the input/output type T goes last, as these are most likely
the order in which people will want to change things.
(2) Is there a desire to have a separate input and output type?
Alternatively, should I perhaps treat all input and internal processing as using
the real type and just use T for the output?
(3) Given the default template arguments provided, is there any way to
ensure that an instance of the Normal struct can be implemented like this:
auto normal01 = Normal(0, 1);
rather than having to do this:
auto normal01 = Normal!()(0, 1);
Yes, I could create a function that returns an instance, but I'm not sure what
to call it given that I want the normal() function to serve a similar purpose as
uniform() ... :-)
Thanks in advance for any and all feedback.
Best wishes,
-- Joe
import std.conv, std.exception, std.math, std.random, std.stdio, std.traits;
/**
Generates a random floating-point number drawn from a
normal (Gaussian) distribution with specified mean and
standard deviation (sigma).
*/
auto normal(T = real, alias NormalRandomNumberEngine = NormalBoxMullerEngine, UniformRandomNumberGenerator = Random)
(T mean, T sigma, ref UniformRandomNumberGenerator urng = rndGen)
if (isFloatingPoint!T isUniformRNG!UniformRandomNumberGenerator)
{
static NormalRandomNumberEngine!(T, UniformRandomNumberGenerator) engine;
return normal(mean, sigma, engine, urng);
}
/**
ditto
*/
auto normal(T = real, alias NormalRandomNumberEngine = NormalBoxMullerEngine, UniformRandomNumberGenerator = Random)
(T mean, T sigma, ref NormalRandomNumberEngine!(T, UniformRandomNumberGenerator) normalEngine, ref UniformRandomNumberGenerator urng = rndGen)
if (isFloatingPoint!T
Re: Mac OS installer
On 2012-10-22 15:45, Adam D. Ruppe wrote: I was recently involved in a stack overflow question about mac os: http://stackoverflow.com/questions/12832241/cant-install-dmd-2-060-on-os-x-10-6-8/12897850 I gave my usual answer of just use the zip which solved the problem there, but perhaps there's something we can do to improve the installer so people who do use it can have an easier time. I don't know anything about the Mac though, so there's nothing more I can do except punt it to someone else... so here I am. http://d.puremagic.com/issues/show_bug.cgi?id=8682 -- /Jacob Carlborg
Re: Is there any way to create something like this?
That static version you made Adam was just perfect for what I need! Thanks for the help! Renato On Sunday, 21 October 2012 at 15:19:24 UTC, Adam D. Ruppe wrote: On Sunday, 21 October 2012 at 13:10:16 UTC, RenatoUtsch wrote: Is there any way to make the GeneralLibrary class and the createLibrary() (or even better, make the GeneralLibrary constructor do that) to work with this kind of construction? Yes, there's ways to do that, but they might not be what you had in mind, because you'll either have to use different static types for each version or make GeneralLibrary a dynamic type, which means it will error at runtime rather than compile time. Either way, createLibrary will probably have to be a template. Here's an example of a static wrapper: I just accidentally saved over the static example with the dynamic example. Ugh. I guess what I'll do is link it in: http://arsdnet.net/dcode/example_dynamic.d Look at the function createLibrary and pretend the dynamicFunctionCall method wasn't there. That's what the static example looked like - just opDispatch. In main, to use the static checks, you must say auto library11 instead of GeneralLibrary. The interface is only useful for dynamic calls. auto gives you the wrapper class with static checks. This isn't very interesting because the wrapper adds nothing; you might as well just construct the original object. But you could change the function in the wrapper to do something else. But anyway, each wrapper class created inherits from a GeneralLibrary interface, so you could pass them around.. but since the interface does nothing, you really have to use auto on the return type to actually use the class. If you aren't doing anything with the wrapper, you could also just alias GeneralLibrary to be the newest version of the actual class too. Not much fun so let's look at a dynamic option. This will suck too, but in different ways. This one won't work with overloaded functions, default parameters on functions (sad, fixable in some cases, but not all), has a speed hit (you could help this a bit by optimizing dynamicFunctionCall, but it will always have some slowdown), and returns Variants instead of the original type, which is kinda annoying. And, of course, it is a dynamic call, so any failures will only happen at runtime. Here's some code: http://arsdnet.net/dcode/example_dynamic.d I haven't tested it fully, but it seems to throw exceptions at the right times for the simple functions in here. This code is messier and includes a compiler bug hack (I think)... but it worked. There's some comments in there to talk about what it does. End result: given GeneralLibrary library11 = createLibrary!(1.1); library11.func1(); // Should work library11.func11(); // Should work library11.func12(); // Should fail // line 103 Will throw at runtime: test4.NoSuchMethodException@test4.d(103): No such method: func12 And it *should* work with types too, still doing strong type checks, but doing them at runtime for the arguments. All return values for these functions are wrapped in Variants, so you'll have to pull them out dynamically too.. You could probably combine these two examples and have static types if you use auto and dynamic if you use the GeneralLibrary interface. Another option might be to have the createLibrary function be aware of all the versions - you'd have to hard code a list that it can read at compile time - and then do the kind of thing in the static example, but trying to cast to the newer versions of the class and throwing if it fails. Then you'd keep the static types, but get dynamic checks on if the method is available. This would be just a loop, cast to a newer class, if not null and the call compiles, call the function. I'm out of screwing around time this morning so I won't write this one up, but it should be doable.
Re: [RFC] ColorD
On Mon, 22 Oct 2012 06:04:51 -0500, Dejan Lekic dejan.le...@gmail.com
wrote:
On Sunday, 21 October 2012 at 19:28:21 UTC, Robik wrote:
Hello,
I would like to introduce ColorD, small library that allows to simply
manipulate console output colors, both on Windows and Posix operating
systems. It also supports font styles such as underline and
strikethrough(Posix feature only).
Simple example:
import std.stdio, colord;
void main()
{
setConsoleColors(Fg.red, Bg.blue);
writeln(Red text on blue background.);
resetConsoleColors(); // Bring back initial state
}
Feedback welcome.
GitHub: https://github.com/robik/ColorD
Regards.
This is very much related to the ycurses and dcurses projects, and I
strongly suggest you work with people behind those projects and come up
with a nice/flexible/robust console API/package for D.
I had some trouble getting in touch with ylixir last time, and pardon me
if I'm wrong,
but *you* are the 'people behind' dcurses. =P
I would be willing to chip in for something like this though.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: How mutable is immutable?
On 18/10/12 19:43, Timon Gehr wrote:
On 10/18/2012 10:08 AM, Don Clugston wrote:
On 17/10/12 18:02, Timon Gehr wrote:
On 10/17/2012 01:49 PM, Don Clugston wrote:
...
That's the point -- *which* checks are missing from @safe?
Escaping stack data and arbitrarily freeing memory are not operations
found in memory safe languages.
HOW do you propose to check for escaping stack data?
Static escape analysis. Use the 'scope' qualifier to designate
data that is not allowed to be escaped in order to make it modular.
...
The implementation of the 'scope' storage class should be fixed. We
could then require an unsafe cast(scope) to disable prevention of stack
address escaping.
No we can't. f cannot know that the string it has been given is on the
stack. So main() must prevent it from being given to f() in the first
place. How can it do that?
f can know that it mustn't escape it, which is enough.
void foo(bool b, string y)
{
immutable (char)[4] x = abba;
string s = b ? x : y;
f(s);
}
Make it safe.
It is safe if the parameter to f is marked with 'scope'. (and this in
turn obliges f not to escape it.)
Well, OK, but that involves changing the semantics of immutable. You
could not pass this kind of local immutable to _any_ existing code.
It would render almost all existing code that uses immutable obsolete.
And what do you get in exchange? Practically nothing!
Analyze scope on the expression level.
The analysis would determine that x[] is 'scope'. It would
conservatively propagate this fact to (b ? x[] : y). Then the local
variable 's' will get the 'scope' storage class.
In general, use a fixed-point iteration to determine all local
variables that might refer to scope'd data and prevent that they get
escaped.
Rust's borrowed pointers may give some hints on how
to extend 'scope' to fields of structs.
I think it is more fundamental than that.
As to delete, delete is as unsafe when the involved data is immutable
as when it is mutable. Why require an additional cast in one case?
This is not about safety.
Modifying immutable data breaks the type system. Deleting mutable data
does not.
AFAIK it is safe to implement delete as a call to the
finalizer, followed by setting the memory to T.init.
...
Now I see where you are coming from. This is indeed a safe approach for
references to/arrays of fully mutable value types, but not for delete
in general.
Make sure to treat void* specially though.
struct S{ immutable int x; this(int x){this.x=x;}}
void main()@safe{
void* s = new S(2);
delete s;
}
Class instance memory does not have a T.init, because it is not
assigned a T. And even if it was, how would you know at compile time if
the bound instance has any immutable fields?
Should that be a runtime exception?
Probably. Yeah, it's a bit hard if you have a base class, you can't
statically check if it has immutable members in a derived class.
Or you could be conservative and disallow delete of anything where you
don't know the exact type at compile time.
Re: D seems interesting, but...
On 15/10/12 13:39, Jacob Carlborg wrote: On 2012-10-15 11:58, Don Clugston wrote: I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation. I know it's not a perfect tool and it contains bugs but most things do work. I don't know which issues have been reported by you, but it seems there's a problem with the -l flag. Running dvm install 2.060 usually works. Could you please point out which issues have been reported by you. I don't remember, it's a long time ago. But this was one of them: https://github.com/jacob-carlborg/dvm/issues/11 Basically it was case of: download, find a bug, find another bug, think this has already cost me more time than it could ever save me, quit now. I have very limited time to work with D, as I understand most people here has, and I'm currently working on other projects than DVM since basically does what I intended it to do when I started the project. It seems most D installers are broken in one way or another. But the success rate with DVM seems to be quite high anyway.
Re: dmd -run and command line argument order
On Mon, 22 Oct 2012 14:08:22 +0100, mist n...@none.none wrote: It does not ignore, it passes them as an arguments to resulting program. Ahh, of course. :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Regarding hex strings
On Mon, Oct 22, 2012 at 01:14:21PM +0200, Dejan Lekic wrote: If you want vastly human readable, you want heredoc hex syntax, something like this: ubyte[] = xEND 32 2b 32 3d 34 2e 20 32 2a 32 3d 34 2e 20 32 5e 32 3d 34 2e 20 54 68 65 72 65 66 6f 72 65 2c 20 2b 2c 20 2a 2c 20 61 6e 64 20 5e 20 61 72 65 20 74 68 65 20 73 61 6d 65 20 6f 70 65 72 61 74 69 6f 6e 2e 0a 22 36 34 30 4b 20 6f 75 67 68 74 20 74 6f 20 62 65 20 65 6e 6f 75 67 68 22 20 2d 2d 20 42 69 6c 6c 20 47 2e 2c 20 31 39 38 34 2e 20 22 54 68 65 20 49 6e 74 65 72 6e 65 74 20 69 73 20 6e 6f 74 20 61 20 70 72 69 6d 61 72 79 20 67 6f 61 6c 20 66 6f 72 20 50 43 20 75 73 61 67 65 END; Having a heredoc syntax for hex-strings that produce ubyte[] arrays is confusing for people who would (naturally) expect a string from a heredoc string. It is not named hereDOC for no reason. :) What I meant was, a syntax similar to heredoc, not an actual heredoc, which would be a string. T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: D seems interesting, but...
On 2012-10-22 17:33, Don Clugston wrote: I don't remember, it's a long time ago. But this was one of them: https://github.com/jacob-carlborg/dvm/issues/11 Basically it was case of: download, find a bug, find another bug, think this has already cost me more time than it could ever save me, quit now. I'll see if I can create a bug fix release. -- /Jacob Carlborg
splitter semantics
I was trying to improve algorithm's splitter functions.
This was mostly relaxing/documenting the restrictions, and adding
a new implementation for simple forward ranges and/or infinite
ranges support (the current implementation was limited to RA +
hasLength + hasSlicing).
Anyways, I noticed there was an (undocumented) splitter(pred)
inside algorithm. Problem: It is currently using completely
unique semantics.
Contrary to the other std.algorithm.splitter, it joins runs of
terminators together (avoiding empty empty tokens). Also,
contrary to the other std.algorithm.splitter, if the last element
satisfies isTerminator, it does not create an empty token. It
*does*, however, create a leading empty token.
It turns out that one of the only use there is of this functions
is to implement std.array.splitter(someString), by simply calling
std.algorithm.splitter!isWhite.
But what makes also that strange though is that the lazy
std.array.splitter(someString) *ALSO* deviates from the
aggressive std.array.split(someString) (that it is supposed to
emulate), in that split will simply NOT create any empty tokens,
even in front.
TLDR:
1. hello .split() = [hello]; //std.string
2. hello .splitter() = [, hello]; //std.string
3. hello .splitter!isWhite() = [, hello]; //std.algo
4. hello .splitter(' ') = [, hello, , ]; //std.algo
As you can see 2-3 are using some absolutely unique semantics.
This semantic (IMO), makes no sense.
I'd like to propose a clear split between std.algorithm's
splitter, and std.array's:
*std.algo.splitter!pred should have the same behavior as the
other splitters in the module.
*std.array.splitter(string) will have the same behavior as
std.array.split(string)
The way I see it: algorithm.splitter!predicate is not documented,
so we can do anything we want with it.
As for std.array.splitter(string): It's behavior just doesn't
make any sense. So we might as well fix it to parallel
std.array.split's.
Thoughts? Feedback?
Related note: Why are:
auto splitter(C)(C[] s) if(isSomeString!(C[]))
S[] split(S)(S s) if (isSomeString!S)
inside std.array anyways? Their behavior is string specific, with
strictly no raw array equivalent, places them square in the
middle of std.string, no? Along with splitLines et al, for
example.
DConf 2013 on kickstarter.com: we're live!
We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 1:25 PM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei On reddit: http://www.reddit.com/r/programming/comments/11wkr7/the_d_conference_2013_is_raising_funds_via/ Andrei
Re: Shared keyword and the GC?
On Oct 18, 2012, at 6:06 PM, Michel Fortin michel.for...@michelf.ca wrote: All this is nice, but what is the owner thread for immutable data? Because immutable is always implicitly shared, all your strings and everything else that is immutable is thus shared and must be tracked by the global heap's collector and can never be handled by a thread-local collector. Even if most immutable data never leaves the thread it was allocated in, there's no way you can know. Yes. I don't think per-thread GCs will work very well without support for immutable data, an for that you need to have a distinction between immutable and shared immutable (just like you have with mutable data). I complained about this almost three years ago when the semantics of shared were being defined, but it got nowhere. Yeah, that's unfortunate. shared today really has two meanings: instance visibility and what happens when the instance is accessed. By comparison, immutable just describes what happens when the instance is accessed. The really weird part of all this being that immutable data is exempt from the transitivity requirement of shared. Though that makes me realize that casting a UDT to shared could mean traversing all data reachable by that instance and marking it as shared as well, which sounds absolutely terrible. Perhaps something could be done in instances where the only place data is passed between threads in an app is via std.concurrency? Allowing strings to be referenced by global shared references would still be problematic though. I'll have to give this some thought.
Re: Shared keyword and the GC?
On Oct 18, 2012, at 11:56 PM, Alex Rønne Petersen a...@lycus.org wrote: I'm not really sure how this solves the problem of having pointers from a thread-local heap into the global heap and vice versa. Can you elaborate on that? The problem is that even if you know whether a piece of memory is flagged shared, you cannot know if some arbitrary number of threads happen to have pointers to it and can thus mutate anything inside it while a thread-local collection is in progress. Blocks flagged as shared would be completely ignored by the thread-local GC collection. Since shared data may never reference unshared data, that should avoid anything being collected that's still referenced. I hadn't thought about immutable though, which may turn out to be a problem.
SCons and gdc
This message is specifically addressed to Russel Winder, but I'm posting it here as it may concern other D SCons users too. I've been using Russel's new D tooling to great effect -- it has been working quite well with dmd. However, I'm wondering if there's a way to make it work correctly for gdc (which uses gcc-style command-line syntax)? Currently, it tries to run gdc with dmd-style syntax, which causes object files to be wrongly named (-offilename.o gets interpreted as -o ffilename.o by gdc). A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds. Thanks! T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White
Re: SCons and gdc
Hi, On Mon, 2012-10-22 at 10:55 -0700, H. S. Teoh wrote: […] I've been using Russel's new D tooling to great effect -- it has been working quite well with dmd. However, I'm wondering if there's a way to make it work correctly for gdc (which uses gcc-style command-line syntax)? Currently, it tries to run gdc with dmd-style syntax, which causes object files to be wrongly named (-offilename.o gets interpreted as -o ffilename.o by gdc). Uuurrr... the gdc tool should use GCC standard options, and indeed fail in DMD/GDMD/LDC style options. If this is not the case we should raise a bug report, create a unit test fail and add it into the code base. A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds. […] I have to admit to not having tested GDC so much as it isn't 2.060 compatible as yet, and LDC is, so I am using the ldc tool for the moment. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SCons and gdc
On Mon, Oct 22, 2012 at 07:03:03PM +0100, Russel Winder wrote: Hi, On Mon, 2012-10-22 at 10:55 -0700, H. S. Teoh wrote: […] I've been using Russel's new D tooling to great effect -- it has been working quite well with dmd. However, I'm wondering if there's a way to make it work correctly for gdc (which uses gcc-style command-line syntax)? Currently, it tries to run gdc with dmd-style syntax, which causes object files to be wrongly named (-offilename.o gets interpreted as -o ffilename.o by gdc). Uuurrr... the gdc tool should use GCC standard options, and indeed fail in DMD/GDMD/LDC style options. If this is not the case we should raise a bug report, create a unit test fail and add it into the code base. Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like: env = Environment( DC = '/usr/src/d/gdcroot/bin/gdc', DFLAGS = ['-O', '-g', '-funittest'] ) But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool? A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds. […] I have to admit to not having tested GDC so much as it isn't 2.060 compatible as yet, and LDC is, so I am using the ldc tool for the moment. [...] I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060. T -- I'm still trying to find a pun for punishment...
Re: DConf 2013 on kickstarter.com: we're live!
There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. On Monday, 22 October 2012 at 18:30:09 UTC, Ali Çehreli wrote: On 10/22/2012 10:25 AM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Andrei, thanks for doing this! :) Is kickstarter the only way of pledging? I tried and had to create a kickstarter account, which I never needed. When the process then required *also* to create an Amazon account I stopped. :( Can I send a check or pay by PayPal? Thanks, Ali
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/2012 10:25 AM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Andrei, thanks for doing this! :) Is kickstarter the only way of pledging? I tried and had to create a kickstarter account, which I never needed. When the process then required *also* to create an Amazon account I stopped. :( Can I send a check or pay by PayPal? Thanks, Ali
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. Andrei
Re: SCons and gdc
On Mon, 2012-10-22 at 20:14 +0200, Alex Rønne Petersen wrote: […] It is, and has been for months. I am guessing you are saying that upstream GDC is now 2.060 compliant? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SCons and gdc
On 22-10-2012 21:11, Russel Winder wrote: On Mon, 2012-10-22 at 20:14 +0200, Alex Rønne Petersen wrote: […] It is, and has been for months. I am guessing you are saying that upstream GDC is now 2.060 compliant? Yes, as in: http://www.github.com/D-Programming-GDC/GDC -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: SCons and gdc
On Mon, 2012-10-22 at 11:23 -0700, H. S. Teoh wrote: […] Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like: env = Environment( DC = '/usr/src/d/gdcroot/bin/gdc', DFLAGS = ['-O', '-g', '-funittest'] ) But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool? There are now three tools: dmd, gdc, and ldc. Currently with the above it looks like you are using the dmd tool and replacing the dmd with gdc. There is not yet a d tool which tries a specific sequence according to some priority. I couldn't decide on a Windows/OS X/Linux best priority order for DMD, GDC and LDC so I ran away form trying to implement it. This needs doing. […] I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060. I build LDC from it's repository, but I have not tried this approach with GCC and hence GDC. I guess I am waiting for GDC to be in GCC 4.8 and for that to be in Debian and/or Fedora. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SCons and gdc
On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote: It is, and has been for months. The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion). Not demanding a solution, just saying. :-)
Re: SCons and gdc
On 2012-10-22 19:55, H. S. Teoh wrote: A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds. Perhaps gdmd has a flag which lets you pass gdc/gcc specific flags. -- /Jacob Carlborg
Re: Shared keyword and the GC?
On 2012-10-22 19:44, Sean Kelly wrote: Blocks flagged as shared would be completely ignored by the thread-local GC collection. Since shared data may never reference unshared data, that should avoid anything being collected that's still referenced. I hadn't thought about immutable though, which may turn out to be a problem. Funny thing, immutable was supposed to make it easier to do concurrency programming. -- /Jacob Carlborg
Re: SCons and gdc
On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote: On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote: It is, and has been for months. The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion). Not demanding a solution, just saying. :-) I've managed to build git GDC on Debian unstable (64-bit), and have just added the instructions to: http://gdcproject.org/wiki/Installation I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork: https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix I've submitted a pull request for the fork, but that was only today, so it probably won't get committed until a bit later. If you want, I can send you the build script I have, that contains all the commands (well, hopefully all) to unpack, patch, and build the Debian GCC sources (patched with GDC, of course). If all goes well, it should provide you with a working GDC. :) This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. (P.S. GCC's build system seriously needs a major overhaul. It's extremely fragile and completely unfriendly when it comes to telling you what the problem is when it fails. The error message is often fr away from the real source of the problem, and often has no indication whatsoever as to what the nature of the real problem is. I spent at least 2 whole days fighting with it before I figured out how to pacify it enough for the build to succeed. I wouldn't wish this experience on anyone.) T -- It's bad luck to be superstitious. -- YHL
Re: SCons and gdc
On Mon, Oct 22, 2012 at 08:15:13PM +0100, Russel Winder wrote: On Mon, 2012-10-22 at 11:23 -0700, H. S. Teoh wrote: […] Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like: env = Environment( DC = '/usr/src/d/gdcroot/bin/gdc', DFLAGS = ['-O', '-g', '-funittest'] ) But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool? There are now three tools: dmd, gdc, and ldc. Currently with the above it looks like you are using the dmd tool and replacing the dmd with gdc. Does it use the dmd tool by default? How do I select the gdc tool instead? I tried env.Append(tools = 'gdc') but it didn't make any difference. There is not yet a d tool which tries a specific sequence according to some priority. I couldn't decide on a Windows/OS X/Linux best priority order for DMD, GDC and LDC so I ran away form trying to implement it. This needs doing. If there's an easy way to select which tool to use, then it's good enough for me. Having a tool that tries to guess what you want usually ends up doing the wrong thing, especially since I have both compilers installed and often switch between them in different projects for testing, comparison, profiling, etc., purposes. […] I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060. I build LDC from it's repository, but I have not tried this approach with GCC and hence GDC. I guess I am waiting for GDC to be in GCC 4.8 and for that to be in Debian and/or Fedora. [...] I'm going to take a shot at building a .deb for the latest git gdc-4.7 branch, which AFAIK should support at least 2.059 (and maybe 2.060?). It's probably non-trivial, as the debian gcc build scripts are a tangled labyrinth I've yet to unravel. :) T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Re: SCons and gdc
On 10/22/2012 09:41 PM, H. S. Teoh wrote: I've managed to build git GDC on Debian unstable (64-bit), and have just added the instructions to: http://gdcproject.org/wiki/Installation I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork: https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix Oh, cool. Thanks for that. I will have a go some time in the next days and report back how it goes. If you want, I can send you the build script I have, that contains all the commands (well, hopefully all) to unpack, patch, and build the Debian GCC sources (patched with GDC, of course). If all goes well, it should provide you with a working GDC. :) I'll give it a go with your branch first (or hopefully, with an update that has it merged in) and get back to you if I run into trouble. Just a query -- the Raspberry Pi instructions have some notes on tweaking the Debian patch script -- did you have to do this, or did you just leave it as-is? This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. I take it Walter is resistant to a rename for the frontend source files? :-\ Thanks again and best wishes, -- Joe
Re: SCons and gdc
On 22-10-2012 21:41, H. S. Teoh wrote: On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote: On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote: It is, and has been for months. The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion). Not demanding a solution, just saying. :-) I've managed to build git GDC on Debian unstable (64-bit), and have just added the instructions to: http://gdcproject.org/wiki/Installation I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork: https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix I've submitted a pull request for the fork, but that was only today, so it probably won't get committed until a bit later. If you want, I can send you the build script I have, that contains all the commands (well, hopefully all) to unpack, patch, and build the Debian GCC sources (patched with GDC, of course). If all goes well, it should provide you with a working GDC. :) This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. Might want to poke Iain about this. Sounds like a missing -x c++. (P.S. GCC's build system seriously needs a major overhaul. It's extremely fragile and completely unfriendly when it comes to telling you what the problem is when it fails. The error message is often fr away from the real source of the problem, and often has no indication whatsoever as to what the nature of the real problem is. I spent at least 2 whole days fighting with it before I figured out how to pacify it enough for the build to succeed. I wouldn't wish this experience on anyone.) Unfortunately, one does not simply overhaul the GCC build system. It consists of thousands upon thousands of lines of logic to configure, build, and test GCC for all sorts of obscure scenarios (have you ever done a Canadian cross build of GCC?), most of which other build systems couldn't possibly get right. T -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: SCons and gdc
On 22 October 2012 20:41, H. S. Teoh hst...@quickfur.ath.cx wrote: On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote: On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote: It is, and has been for months. The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion). Not demanding a solution, just saying. :-) I've managed to build git GDC on Debian unstable (64-bit), and have just added the instructions to: http://gdcproject.org/wiki/Installation I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork: https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix I've submitted a pull request for the fork, but that was only today, so it probably won't get committed until a bit later. If you want, I can send you the build script I have, that contains all the commands (well, hopefully all) to unpack, patch, and build the Debian GCC sources (patched with GDC, of course). If all goes well, it should provide you with a working GDC. :) This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. It shoudln't be doing that - I would instead question what revision of GCC you are currently using. As it's switch to C++ as the default compiler around 2 months ago. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: SCons and gdc
On Mon, Oct 22, 2012 at 09:53:40PM +0200, Alex Rønne Petersen wrote: On 22-10-2012 21:41, H. S. Teoh wrote: [...] This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. Might want to poke Iain about this. Sounds like a missing -x c++. Where may he be poked at? :) (P.S. GCC's build system seriously needs a major overhaul. It's extremely fragile and completely unfriendly when it comes to telling you what the problem is when it fails. The error message is often fr away from the real source of the problem, and often has no indication whatsoever as to what the nature of the real problem is. I spent at least 2 whole days fighting with it before I figured out how to pacify it enough for the build to succeed. I wouldn't wish this experience on anyone.) Unfortunately, one does not simply overhaul the GCC build system. It consists of thousands upon thousands of lines of logic to configure, build, and test GCC for all sorts of obscure scenarios Yes, written in m4, bash, and that hilariously huge Makefile (or its automake progenitors thereof). It's completely opaque to me. (have you ever done a Canadian cross build of GCC?), most of which other build systems couldn't possibly get right. [...] rant Well, this is just my biased arrogant opinion, but the root of the problem is that make is an antiquated overly-simplistic script that has long outlived its time, but due to historical reasons still survive festering under the layers of patches that it has acquired over the course of its sad life. Automake and its ilk are just yet another (system of) layer of patches upon the same broken system that doesn't address the fundamental design flaws in make. It's an edifice of cards that nobody dares touch because, well, it would take too much effort to reproduce all the tiny obscure cases it has been tweaked for over the years. But it's nonetheless a nigh unmaintainable fortress of cards that will collapse at the slightest provocation in the most unhelpful of ways. It's like implementing the whole of Windows 8 in KR C. In this day and age, one would *think* we could do better, but no, this fossil from the 70's still shambles on, to the unnecessary suffering of countless generations of new programmers. /rant T -- They say that guns don't kill people, people kill people. Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 18:49:22 UTC, Andrei Alexandrescu wrote: On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. I happened to have a facebook (alternate sign-in) amazon accounts so it was fairly quick and painless for me. I'll look forward to the results of the kickstarter.
Re: SCons and gdc
On Mon, Oct 22, 2012 at 09:54:32PM +0200, Joseph Rushton Wakeling wrote: On 10/22/2012 09:41 PM, H. S. Teoh wrote: [...] Just a query -- the Raspberry Pi instructions have some notes on tweaking the Debian patch script -- did you have to do this, or did you just leave it as-is? Hmm, I *thought* I left it as-is, but apparently I did have the tweak in the patch script (and it doesn't work if you leave it out). I'll update the wiki. This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. I take it Walter is resistant to a rename for the frontend source files? :-\ [...] From what I gather, yes. T -- Famous last words: I *think* this will work...
Re: SCons and gdc
On Mon, Oct 22, 2012 at 09:15:41PM +0100, Iain Buclaw wrote: On 22 October 2012 20:41, H. S. Teoh hst...@quickfur.ath.cx wrote: [...] This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. It shoudln't be doing that - I would instead question what revision of GCC you are currently using. As it's switch to C++ as the default compiler around 2 months ago. [...] Does gdc git master require gcc-4.8 to build (I mean, 4.8 installed as default compiler on the system, not just 4.8 sources)? % gcc --version gcc (Debian 4.7.2-4) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/mnt/1/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-4) T -- Let's call it an accidental feature. -- Larry Wall
Re: splitter semantics
monarch_dodra:
1. hello .split() = [hello]; //std.string
2. hello .splitter() = [, hello]; //std.string
3. hello .splitter!isWhite() = [, hello]; //std.algo
4. hello .splitter(' ') = [, hello, , ]; //std.algo
There is a bug report on this stuff (8013). Please model them on
the ouput of std.string where possible.
Bye,
bearophile
Re: Shared keyword and the GC?
On 10/22/12 3:16 PM, Jacob Carlborg wrote: On 2012-10-22 19:44, Sean Kelly wrote: Blocks flagged as shared would be completely ignored by the thread-local GC collection. Since shared data may never reference unshared data, that should avoid anything being collected that's still referenced. I hadn't thought about immutable though, which may turn out to be a problem. Funny thing, immutable was supposed to make it easier to do concurrency programming. But not garbage collection. Andrei
Re: Shared keyword and the GC?
On Oct 22, 2012, at 12:16 PM, Jacob Carlborg d...@me.com wrote: On 2012-10-22 19:44, Sean Kelly wrote: Blocks flagged as shared would be completely ignored by the thread-local GC collection. Since shared data may never reference unshared data, that should avoid anything being collected that's still referenced. I hadn't thought about immutable though, which may turn out to be a problem. Funny thing, immutable was supposed to make it easier to do concurrency programming. In the realm of shared data concurrency, immutable is definitely useful. But where data is all thread-local I'm not entirely sure. Either way though, immutable within the context of this discussion is a library optimization issue rather than anything to do with the type itself.
Re: Shared keyword and the GC?
Le 19/10/2012 08:49, Alex Rønne Petersen a écrit : On 17-10-2012 16:26, deadalnix wrote: Why not definitively adopt the following (and already proposed) memory scheme (some practice are now considered valid when this scheme is not respected) : Thread local head (one by thread) - shared heap - immutable heap This model have multiple benefices : - TL heap only can be processed by only interacting with one thread. - immutable head can be collected 100% concurently if we allow some floating garbage. - shared heap is the only problem, but as its size stay small, the problem stay small. Can you elaborate? I'm not sure I understand. OK let me detail a little more. First, I'll explain TL GC. You have to understand shared heap here as both shared and immutable heap. TL collection can be done disturbing only one thread. When the TL collection is done, a set of pointer to shared heap is known. Now, all new pointer in the TL heap to shared heap is either : - a new allocation. - a pointer read from the shared heap. So, basically, at the end, we have a set of root to collect the shared heap. The thread can continue to run when the shared heap is collected. Now let's consider the immutable heap. Given a set of root from TL and shared, the immutable heap can be collected concurrently. I think it is straightforward and will not elaborate. So the problem is now the shared heap. Here is how I see its collection. When the GC want to collect shared it first signal itself to each thread that will GC TL data and give back a set of root. As of this point, the GC mark all new allocation as live and set a write barrier on shared : when a shared object is written, it is marked ive (obviously), its old value is scanned, and its new value is scanned too. The reason is pretty simple : the old value may have been read by a thread and stored locally. When the collection is done, the write barrier can be removed. Obviously, the write barrier is not needed for immutable object or any shared write that isn't a pointer write, which lead to a very nice way to collect things. The obvious drawback is that pointer for TL to another TL or from shared to TL will confuse the GC. But it is already not @safe anyway.
Re: Shared keyword and the GC?
Le 18/10/2012 20:26, Sean Kelly a écrit : On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersena...@lycus.org wrote: So, let's look at D: 1. We have global variables. 1. Only std.concurrency enforces isolation at a type system level; it's not built into the language, so the GC cannot make assumptions. 1. The shared qualifier effectively allows pointers from one thread's heap into another's. Well, the problem is more that a variable can be cast to shared after instantiation, so to allow thread-local collections we'd have to make cast(shared) set a flag on the memory block to indicate that it's shared, and vice-versa for unshared. Then when a thread terminates, all blocks not flagged as shared would be finalized, leaving the shared blocks alone. Then any pool from the terminated thread containing a shared block would have to be merged into the global heap instead of released to the OS. This is already unsafe anyway. The clean solution is either to allocate the object as shared, then cast it to TL and back to shared of it make sense. The second option is to clone the object. Having a flag by object isn't a good idea IMO. I think we need to head in this direction anyway, because we need to make sure that thread-local data is finalized by its owner thread. A blocks owner would be whoever allocated the block or if cast to shared and back to unshared, whichever thread most recently cast the block back to unshared. Tracking the owner of a block gives us the shared state implicitly, making thread-local collections possible. Who wants to work on this? :-)
Re: Shared keyword and the GC?
Le 22/10/2012 22:44, Andrei Alexandrescu a écrit : On 10/22/12 3:16 PM, Jacob Carlborg wrote: On 2012-10-22 19:44, Sean Kelly wrote: Blocks flagged as shared would be completely ignored by the thread-local GC collection. Since shared data may never reference unshared data, that should avoid anything being collected that's still referenced. I hadn't thought about immutable though, which may turn out to be a problem. Funny thing, immutable was supposed to make it easier to do concurrency programming. But not garbage collection. OCmal's GC is one of the fastest GC ever made. And it is the case because it uses immutability to great benefice. As immutable data can only refers to immutable data, I don't see a single problem here. When collection shared and TL, you get a set of root pointer to immutable. All immutable can be collected from such set. All object allocated during the collection is supposed to be live.
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 1:25 PM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 We seem to be off to a good start. I've also just added a Facebook ad, see it demoed here: http://goo.gl/NrEis Thanks to all who've contributed, and all others please consider doing so. This is a great time to add material support to our passion for this project, and to make sure D grows and becomes increasingly significant. Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/2012 10:32 AM, Andrei Alexandrescu wrote: On reddit: http://www.reddit.com/r/programming/comments/11wkr7/the_d_conference_2013_is_raising_funds_via/ Looks like reddit's back up.
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/12 2:49 PM, Andrei Alexandrescu wrote: On 10/22/12 2:32 PM, mist wrote: There is a serious reason of getting through some registration issues and pledging via kickstarter - project either gets all money if it is funded or no at all if it is not (and all pledges are returned automatically). And, of course, any other means of supporting won't be counted by kickstarter towards target sum. Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. Andrei So let's see to it that it does break through that limit!!!
Re: SCons and gdc
On Monday, 22 October 2012 at 19:17:51 UTC, Jacob Carlborg wrote: On 2012-10-22 19:55, H. S. Teoh wrote: A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds. Perhaps gdmd has a flag which lets you pass gdc/gcc specific flags. It does, it's the -q flag.
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 23:37:25 UTC, Tyro[17] wrote: Yes, this. If we don't break through the limit, nobody is charged a dime. It would be more complicated to refund checks etc. So let's see to it that it does break through that limit!!! Already within a day and it's about 25% there. Looks promising.
Re: [RFC] ColorD
On 10/22/2012 03:47 AM, Jens Mueller wrote: Chad J wrote: There is no weakness to this. The only shred of a counterargument I can think of is that it makes the format strings more difficult to learn. Other than that, it is possible to detect the destination of the formatter, so color codes will never end up in places where they shouldn't. A conservative approach to this should handle most desires and never interfere with all the people with no interest in color. On the upshot are the things I've mentioned: - A format specifier is potentially more discoverable. - A format specifier is more concise. This keeps your lines from wrapping. They are probably too long already. Do you consider this writecf(Color.red, something %s, here) concise as well? The case is too easy. You're formatting an entire line. - To cement the previous point: nesting requires a few extra characters with a format specifier, rather than a couple extra /lines/ for extra function calls. Don't understand this point. Can you give an example? Option A: auto save = getConsoleState(); scope (exit) setConsoleState(save); setConsoleColors(Fg.red, Bg.blue); writeln(Red text on blue background.); Option B: writefln(%CFredBblu(Red text on blue background.%)); - Calls to stateful console functions allow people to write bugs like saving console state and then forgetting to restore it (or throwing an exception and neglecting to restore from within a scope guard). Format specifiers do not have this problem. The same holds for writecf(Color.red, something %s, here) See my above example. In that case the formatter no longer requires even using the scope feature because there are no resources to clean up. The library handles that mess. Also statefulness is a pain to deal with. Stack-like operation with push/pop or bracketing constructs is usually much less troublesome for this sort of thing. - etc (I'm sure I'm forgetting one or two.) These are the reasons why my ideal language has color formatting built into its I/O routines. Just wanted to point out that instead of that you can add writec* functions. I think the only thing is that these are less discoverable but they also work without formatting, e.g. writec(Color.red, my text); The thing I found very difficult with other color formatting APIs was formatting individual words or characters. Entire lines are easy-peasy stuff in any API. Solving the entire-lines case won't impress me. ;) Here's my more typical use case: writefln(The %CFred(widgetometer%) is a device for measuring); writefln(widget effectiveness. It is possible to ); writefln(reconcile transcendental properties by hitting); writefln(%CFblu(B%) for blue coefficients, %CFgrn(G%) for green); writefln(coefficients, or %CFyel(Y%) for yellow coefficients.); writefln(Here is a correspondence table:); writefln( %CFnue( %) | %CFblu( B %) %CFgrn( G %) %CFyel( Y %) ); writefln( %CFnue(-%)-+-%CFnue(---%)-%CFnue(---%)-%CFnue(---%)-); writefln( %CFblu(B%) | %CFblu(200%) %CFwht(330%) %CFwht(303%) ); writefln( %CFgrn(G%) | %CFwht(110%) %CFgrn(020%) %CFwht(033%) ); writefln( %CFyel(Y%) | %CFwht(101%) %CFwht(011%) %CFyel(002%) ); I realized that I wanted a nue color that has no effect but allows me to align things effectively ;) Anyhow, please try to write the above example using any other style. Interleaved function calls are particularly fun g
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 17:25:28 UTC, Andrei Alexandrescu wrote: http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Typo on the front page: Some of use are lucky to already use ... ^
[proposal] version statements with multiple arguments.
Looking at std.io (hopefully the right version maybe?) I see this:
version(OSX)
{ do something; }
version(Windows)
{ do the same thing as above; }
version(FreeBSD)
{ ditto; }
version(Linux)
{ finally do something different; }
and:
version(Windows) version(DigitalMars)
{ something; }
I was rather surprised that this wasn't accepted:
//Error: found '||' when expecting ')'
version(OSX || Windows || FreeBSD)
{ do something; }
version(Linux)
{ do something different; }
The last one could be intuitively described as:
version(Windows DigitalMars)
{ blah; }
So I guess in the end I am proposing a change.
A change that I cannot see breaking backwards compatibility while also
shortening code duplication.
It also seems much more 'intuitive' to me.
version(Windows) version(DigitalMars) {}
made me think twice to make sure I knew what it was doing.
What do you guys think? If this was implemented, how could it break
backwards compatibility?
Is something like this worth a change?
Are there any drawbacks to this idea?
--
Shut up, Opera.
Re: [proposal] version statements with multiple arguments.
On Tuesday, 23 October 2012 at 03:22:08 UTC, 1100110 wrote:
So I guess in the end I am proposing a change.
A change that I cannot see breaking backwards compatibility
while also shortening code duplication.
It also seems much more 'intuitive' to me.
version(Windows) version(DigitalMars) {}
made me think twice to make sure I knew what it was doing.
What do you guys think? If this was implemented, how could it
break backwards compatibility?
Is something like this worth a change?
Are there any drawbacks to this idea?
This issue comes once in a while. The suggested solution:
version(OSX)
version = Somethingable
version(Windows)
version = Somethingable
version(FreeBSD)
version = Somethingable
version(Somethingable)
dosomething();
version(Linux)
otherthing;
Not necessarily more concise but it can add description to what
the actual version being created.
Re: [proposal] version statements with multiple arguments.
Indeed, having version logic has been requested many times before.
For example:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Can_I_do_an_or_in_a_version_block_33426.html
http://www.digitalmars.com/d/archives/digitalmars/D/11946.html
quote from those:
Walter would reject it. He has stated clearly in the past that
he intended version to be simple and minimal, and that adding
anything onto it will only result in abuses.
I tend to think that not having version logic (,||,!) results
in greater abuse, ie people WILL come up with their own
incompatible, verbose solutions (string mixins and whatnot) to
achieve the same results;
Another point is that we are sometimes too lazy to write
statements as follows:
version (linux){ version = linuxOrBSD;}
version (BSD){ version = linuxOrBSD;}
version(linuxOrBSD){do_something;}
(that's ugly but it's the official recommended way; much more
verbose than:
version(linux || BSD){do_something;}
)
and instead we lazily duplicate code, because do_something is
small enough:
version (linux){ do_something;}
version (BSD){ do_something;}
Later on we (or the maintainer) update the first do_something
and forget to update the second. Bug follows.
Seriously who hasn't encountered that?
Might as well provide a clean standard solution so everybody uses
it. It should be easy to implement and wont' break any code.
Re: [proposal] version statements with multiple arguments.
On Mon, 22 Oct 2012 22:31:43 -0500, Jesse Phillips
jessekphillip...@gmail.com wrote:
On Tuesday, 23 October 2012 at 03:22:08 UTC, 1100110 wrote:
So I guess in the end I am proposing a change.
A change that I cannot see breaking backwards compatibility while also
shortening code duplication.
It also seems much more 'intuitive' to me.
version(Windows) version(DigitalMars) {}
made me think twice to make sure I knew what it was doing.
What do you guys think? If this was implemented, how could it break
backwards compatibility?
Is something like this worth a change?
Are there any drawbacks to this idea?
This issue comes once in a while. The suggested solution:
[snip]
Not necessarily more concise but it can add description to what the
actual version being created.
That is true, and I do recall that version = something; now that I think
about it.
It just seems to me that version statements are essentially booleans, and
could be easily rewritten as:
static if(true || false || false) { } by the compiler, similar to how (I
*think*) certain binary operators are rewritten.
(I'm just going by what I hear, I'm not really a compiler kinda guy...)
It would make sense to me to be able to use boolean operators on what is
essentially
a true/false statement.
I'd be willing to see if I can hack together support for it, as a proof of
concept,
but I wanted to see if it would be blatantly shot down first.
So... What I'd really like to know is: Would *you* welcome such a change?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Array of structs construction
Can't we simply use map, so as not to introduce new syntax?
import std.algorithm:map;
import std.array:array;
// some imports here
void main() {
//BigInt[] data1 = [5, 6, 9];
auto data1 = [5, 6, 9].map!(a=BigInt(a)).array;
Ranged!(int,5,10)[] data2 = [5, 6, 9];
auto data2 = [5, 6, 9].map!(a=Ranged!(int,5,10)).array;
}
I think this is less verbose than something like:
AStruct[] arr = mixin(structArray!AStruct(1,1, 1,2, 2,2,
2,3));
Also, we can make it even more concise by:
auto data1 = [5, 6, 9].map!(make!BigInt).array; //make has been
proposed as a proxy to construct a struct/class
or even the very concise:
auto data1 = [5, 6, 9].mapMake!BigInt;
where mapMake would be similar to std.algorithm.map except it
would take a struct (or class) type instead of a delegate. It's
code should be fairly obvious. We could choose whether to return
a lazy range or not in that case so the .array is not required.
Re: SCons and gdc
On 22 October 2012 21:46, H. S. Teoh hst...@quickfur.ath.cx wrote: On Mon, Oct 22, 2012 at 09:15:41PM +0100, Iain Buclaw wrote: On 22 October 2012 20:41, H. S. Teoh hst...@quickfur.ath.cx wrote: [...] This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this. It shoudln't be doing that - I would instead question what revision of GCC you are currently using. As it's switch to C++ as the default compiler around 2 months ago. [...] Does gdc git master require gcc-4.8 to build (I mean, 4.8 installed as default compiler on the system, not just 4.8 sources)? % gcc --version gcc (Debian 4.7.2-4) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. No -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Slices and array appending
On Monday, 22 October 2012 at 04:59:41 UTC, Jonathan M Davis wrote: Blocks of memory are allocated and freed as a whole. When an array is forced to be reallocated, then a new block of memory is allocated for it, and any existing slices continue to refer to the original block of memory. The original block will not be freed until there are no more slices which refer to it. You really should read this article if you want to know how arrays work in D: http://dlang.org/d-array-article.html - Jonathan M Davis Ah thanks, I didn't realize the _entire_ original array would hang around. That makes my current approach really dumb. Cheers
Re: More automated interfacing of D with C codebases
On 2012-10-21 21:45, timotheecour wrote: Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc). SWIG requires some kind of interface files, which I assume one must have to manually write. Then what's the difference? I've had good experience using SWIG to automate the job for me, and used it successfully to port the following libraries to D: * ncurses * opencv * sfml to name a few. I believe this is the way forward, as opposed to maintaining (necessary stale) ports such as Deimos. Swig isn't perfect however, and sometimes will bail out on constructs such as: C++ classes with multiple inheritance, or a few obscure C or C++ constructs. Even in that case, I find it much easier to tweak the swig interface file to get desired output rather than undertake the huge manual conversion task. For sfml, the interface file is just about 40 lines for example. Improving such kind of automated tools is where we should be concentrating efforts, not on maintaining deimos. One such improvement I made was to allow conversion of C++ templates to D templates (works in large majority of cases), which makes the library much easier to use than using name mangling schemes. More improvements would be welcome (eg support for static library generation as opposed to dynamic load libraries), reducing the need for tweaking swig interface files etc. I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code * No support for Objective-C BTW, how does SWIG handle macros and documentation? -- /Jacob Carlborg
Re: Reordered class fields?
On 2012-36-22 01:10, bearophile bearophileh...@lycos.com wrote: This benchmark shows that if you allocate the class instances on the heap one at a time the total amount of memory used is the same for the various Bar (maybe because of the GC), so that optimization is useful for emplace() only and similar in-place allocations The current GC always allocates a power of two, with a minimum of 16 bytes. You should see an effect if you make a class that will be above such a threshold without reordering, and below with. So is such class field reordering worth an enhancement request in Bugzilla? Nothing bad can come of it. -- Simen
Re: Reordered class fields?
On 2012-10-22 01:36, bearophile wrote: D classes are free to reorder their fields, so maybe Bar1 should reorder its fields as Bar3, to save 4 bytes for each instance on 32 bit systems: Are D allowed to reorder the class fields? What happens then to binary compatibility? -- /Jacob Carlborg
Re: Reordered class fields?
Simen Kjaeraas: The current GC always allocates a power of two, with a minimum of 16 bytes. You should see an effect if you make a class that will be above such a threshold without reordering, and below with. Right. Nothing bad can come of it. OK :-) -- Jacob Carlborg: Are D allowed to reorder the class fields? This page says: http://dlang.org/class.html The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. Consider the fields much like the local variables in a function - the compiler assigns some to registers and shuffles others around all to get the optimal stack frame layout. This frees the code designer to organize the fields in a manner that makes the code more readable rather than being forced to organize it according to machine optimization rules. Explicit control of field layout is provided by struct/union types, not classes. Bye, bearophile
Re: Reordered class fields?
On 2012-10-22 10:48, bearophile wrote: This page says: http://dlang.org/class.html The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. Consider the fields much like the local variables in a function - the compiler assigns some to registers and shuffles others around all to get the optimal stack frame layout. This frees the code designer to organize the fields in a manner that makes the code more readable rather than being forced to organize it according to machine optimization rules. Explicit control of field layout is provided by struct/union types, not classes. Ok, I didn't know that. -- /Jacob Carlborg
Re: Correct way to map C #define to version
Sumit Raja: Am I using version correctly? How is this done usually? I think version is usually meant to be given as compiler switch. Maybe a simple enum + static if is enough in your case. And keep in mind that C int and D int are different on 64 bit systems, the D int is always 32 bit. In Phobos there are ints of the size of C. Bye, bearophile
Re: Overload resolution (value vs reference)
Thanks for explanation!
Re: Correct way to map C #define to version
On Mon, 22 Oct 2012 12:39:48 +0100, bearophile bearophileh...@lycos.com
wrote:
Sumit Raja:
Am I using version correctly? How is this done usually?
I think version is usually meant to be given as compiler switch. Maybe
a simple enum + static if is enough in your case.
Good suggestion. I was curious so I had a tinker and produced this
example which might be useful to you.
import core.stdc.stdint;
import std.stdio;
enum LIBAVFILTER_VERSION_MAJOR = 2; \\ change this to 3 to see a
difference in size below
enum LIBAVFILTER_VERSION_MINOR = 77;
enum LIBAVFILTER_VERSION_MICRO = 100;
enum FF_API_PACKING = (LIBAVFILTER_VERSION_MAJOR 3);
struct AVFilterBufferRefAudioProps {
uint64_t channel_layout;/// channel layout of audio buffer
int nb_samples; /// number of audio samples per channel
int sample_rate;/// audio buffer sample rate
static if(FF_API_PACKING) {
int planar; /// audio buffer - planar or packed
}
}
void main()
{
writefln(size of AVFilterBufferRefAudioProps = %s,
AVFilterBufferRefAudioProps.sizeof);
}
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: More automated interfacing of D with C codebases
SWIG requires some kind of interface files, which I assume one
must have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include SFML/Audio.hpp
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additional tweaks may be needed to support
certain constructs like multiple inheritance, etc, but nothing
daunting (~ 50 lines of code for my sfml interface file)
I don't think SWIG is the right approach because:
* You have to create these interface files
=
see above. Interface files can be very small.
* It seem to not handle all code
I was still able to port large libraries like sfml and opencv,
using tweaks to the interface files and enhancing swig to support
C++template to D template conversion. There's a small number of
cases where swig currently chokes, some of which could be easily
fixed if there's enough demand.
* No support for Objective-C
=
http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
One of SWIG's most recent additions is support for Objective-C
parsing. This is currently an experimental feature that may be
improved in future releases.
BTW, how does SWIG handle macros and documentation?
You'd have to write a C/C++ function that does what the macro
does in the interface file, which would in turn be converted to a
D function.
For exporting C documentation to D, I've asked on stackoverflow:
http://stackoverflow.com/questions/12413957/export-comments-in-swig-wrapper
I'm not sure it's supported ATM, but that's definitely something
possible since swig has a full blown C++ parser.
Re: More automated interfacing of D with C codebases
correction regarding macros:
myheader.h:
#define MEX_INFORMATION_VERSION 1
interface file myheader.i:
%{
%include myheader.h
%}
%include myheader.h
generated d file will contain:
int MEX_INFORMATION_VERSION() @property {
auto ret = swig.mex_im.swig_mex_MEX_INFORMATION_VERSION_get();
return ret;
}
which allows one to use the macro from D. Certainly not the best
way (an enum would be preferable) but it works. Again, swig could
be improved. Also if static libraries could be generated, the
overhead above wouldn't be such a big deal with link time
optimization.
For functional macros, I'm not sure, but once can write a C
function that calls the macro, and then swig will convert to D
function. Ideally, swig would directly convert it to a templated
function.
I think maintaining a repository of interface files would be a
better idea than maintaining manually converted C files. The
former would be much smaller easier to maintain, and for 99%
cases stay in sync with library updates. The latter would end up
as a graveyard of never up to date partially-portable C ports
that no-one will want to maintain.
Re: More automated interfacing of D with C codebases
On Monday, 22 October 2012 at 06:28:12 UTC, Jacob Carlborg wrote: On 2012-10-21 21:45, timotheecour wrote: Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc). SWIG requires some kind of interface files, which I assume one must have to manually write. Then what's the difference? Huge difference. It's not necessary to figure out corresponding type sizes on every system. I only need to figure out what needs to be in there. And once all the work of creating the interface file is done, the work of porting to another architecture or operating system or compiler is much reduced. It's not necessary to figure out which api calls are macros on arch XYZ or are simply not there: cdcl Tcl_IncrRefCount clib Tcl_IncrRefCount # if Tcl_IncrRefCount is not defined as a library call, search for the macro. if lib_Tcl_IncrRefCount ! _clib_Tcl_IncrRefCount cmacro Tcl_IncrRefCount tcl.h void 'Tcl_Obj *' endif My example Tck/Tk conversion doesn't handle 8.6, but the effort to add it will be very minimal. All of the hard work of discovering the needed typedefs has been done. [...] I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code I don't know SWIG, but the idea is the same for my tool. If you try to automate processing of the pre-processed headers, all of the included system headers will be processed and too much that isn't needed will be output. The included system definitions will conflict with D definitions. I'm not sure that handling *all* code is necessary. How often do you see this sort of thing in C code? _XPrivate .private9, .private10; Rather than spend effort on handling *every* possible obscure C/C++/ObjC construct, it's easier to simply handle those in the interface file. Other constructs that are more common can be added to SWIG or to my tool. They're both open source. -- Brad
