Re: [OT] Threading (Was: bug covering other bug)
On Sat, 27 Aug 2011 09:01:21 +0300, Brad Roberts wrote: On 8/26/2011 10:29 PM, Vladimir Panteleev wrote: On Sat, 27 Aug 2011 07:44:16 +0300, Brad Roberts wrote: I don't think the mailing list software is what's at fault. There's _tons_ of people who use it, myself included obviously. If it was a general problem with the list software (mailman, probably the most popular list management software out there), it'd be a lot more prevelant. Try again. Did you even read my explanation? There is no room for doubt that the mailing list is replacing message IDs. The message ID has "mailman" and "puremagic.com" in it, for crying out loud. If you're so damn confident that Mailman is absolutely perfect and cannot be flawed, have you considered that it might be a problem with how you've set it up? Way to get unnecessarily emotional.. relax a little. I did read your mail. I was reacting to your over generalization that the list software is "just a shoddy frontend to the nntp server" and that people should stop using it. I never claimed it couldn't be buggy. I advised Andrej to stop using it if the issue was bothering him. I did not imply that everyone should stop using it. Such conversion issues are nearly unavoidable with gateways between different message formats/protocols, so I wasn't criticizing Mailman or this particular set-up, but the idea in general. "Try again." came off as arrogant dismissal to me. I may have over-reacted. The bug report that Jerome dug up is interesting, and also helps further my point, it's not a general problem with all messages between the nntp and smtp gateways. It seems to require cross-posting. That would match better with the frequency of occurrence of the problem, both are fairly rare. Was your message cross-posted? Because its Message-ID is . List subscribers probably got a message with a different Message-ID (the real one). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] Threading (Was: bug covering other bug)
On 8/26/2011 10:29 PM, Vladimir Panteleev wrote: > On Sat, 27 Aug 2011 07:44:16 +0300, Brad Roberts wrote: > >> I don't think the mailing list software is what's at fault. There's >> _tons_ of people who use it, myself included obviously. If it was a >> general problem with the list software (mailman, probably the most >> popular list management software out there), it'd be a lot more >> prevelant. Try again. > > Did you even read my explanation? > > There is no room for doubt that the mailing list is replacing message IDs. > The message ID has "mailman" and > "puremagic.com" in it, for crying out loud. > > If you're so damn confident that Mailman is absolutely perfect and cannot be > flawed, have you considered that it might > be a problem with how you've set it up? Way to get unnecessarily emotional.. relax a little. I did read your mail. I was reacting to your over generalization that the list software is "just a shoddy frontend to the nntp server" and that people should stop using it. I never claimed it couldn't be buggy. The bug report that Jerome dug up is interesting, and also helps further my point, it's not a general problem with all messages between the nntp and smtp gateways. It seems to require cross-posting. That would match better with the frequency of occurrence of the problem, both are fairly rare. Looks like they've been discussing options for a fix, though not terribly actively. Once it's fixed, and released in an update shipped with ubuntu, I'll get it installed. There's another workaround, if the report is accurate, don't cross-post to multiple newsgroups. Not a lot of reason to do so with the D groups.
Re: bug covering other bug
bearophile wrote: > Mariusz G.: > >> So, on my Linux x64 dmd 2.53 & 2.54, while hunting another bug (i already >> highly doubt it's my) - i've found this one: > > I can't reproduce the problem on 2.055head on 32 bit Windows. > DMD 64 bit is relatively recent, it contains several bugs still. More - http://d.puremagic.com/issues/show_bug.cgi?id=6562 >> Another problem i'm searching for, is something with interfacing to C, >> pointer to floats and properties and/or aliasing. NVM > > I don't understand. I'm passing address of float variables to external C function. dmd is passing 80bit (real) though. 0x00d4f139 <+441>: movss -0xec(%rbp),%xmm7 0x00d4f141 <+449>: movss -0xe8(%rbp),%xmm6 0x00d4f149 <+457>: movss -0xe4(%rbp),%xmm5 0x00d4f151 <+465>: movss -0xe0(%rbp),%xmm4 0x00d4f159 <+473>: movss -0xdc(%rbp),%xmm3 0x00d4f161 <+481>: movss -0xd8(%rbp),%xmm2 0x00d4f169 <+489>: movss -0xd4(%rbp),%xmm1 0x00d4f171 <+497>: movss -0xd0(%rbp),%xmm0 => 0x00d4f179 <+505>: callq 0x10b4b04 Well, actually my swig binding is casting from float* to void*, neverthless float is C float and real is 80bit, so it shouldn't be a problem? So, it's a next bug i should report, yes? > Creating the project of your life with 64 bit DMD is a not so good idea. > Currently DMD 32 bit is more reliable if you want to create a large > project. You're right, I've pushed to D too much, because it's one of projects 'features', and overall code design is driven by that. I'll just make my current D code working properly, and write C++ modules (so i could fallback to D soon). Now question, is it generally worth to refactor quite big amounts of code Thanks, Mariusz
Re: [OT] Threading (Was: bug covering other bug)
Vladimir Panteleev wrote: > On Sat, 27 Aug 2011 07:44:16 +0300, Brad Roberts > wrote: > >> I don't think the mailing list software is what's at fault. There's >> _tons_ of people who use it, myself included obviously. If it was a >> general problem with the list software (mailman, probably the most >> popular list management software out there), it'd be a lot more >> prevelant. Try again. > > Did you even read my explanation? > > There is no room for doubt that the mailing list is replacing message > IDs. The message ID has "mailman" and "puremagic.com" in it, for crying > out loud. > > If you're so damn confident that Mailman is absolutely perfect and > cannot be flawed, have you considered that it might be a problem with > how you've set it up? > It is so obvious that this cannot be a mailman bug that there even is an open ticket for it in the mailman tracker! https://bugs.launchpad.net/mailman/+bug/266263 Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] Threading (Was: bug covering other bug)
On Sat, 27 Aug 2011 07:44:16 +0300, Brad Roberts wrote: I don't think the mailing list software is what's at fault. There's _tons_ of people who use it, myself included obviously. If it was a general problem with the list software (mailman, probably the most popular list management software out there), it'd be a lot more prevelant. Try again. Did you even read my explanation? There is no room for doubt that the mailing list is replacing message IDs. The message ID has "mailman" and "puremagic.com" in it, for crying out loud. If you're so damn confident that Mailman is absolutely perfect and cannot be flawed, have you considered that it might be a problem with how you've set it up? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] Threading (Was: bug covering other bug)
On Friday, August 26, 2011 9:29:47 PM, Vladimir Panteleev wrote: > On Sat, 27 Aug 2011 07:08:45 +0300, Andrej Mitrovic > wrote: > >> Mariusz Gliwiński: http://codepad.org/9uZf3E1N >> bearophile: http://codepad.org/j84TLFC8 >> >> It happens 90% of the time when bear replies. > > That doesn't mean it's his fault. > > I think I see the problem: > > 1. Mariusz posts via the mailing-list interface. The original Message ID is > <7480573.bRnhgVsvUV@magdalene>. > 2. The mailing-list interface replaces the Message ID with its own. > 3. Bearophile replies via the newsgroup. His client puts the mailing list's > Message ID in the References header. > > Thus, when you receive Bearophile's post, the message IDs don't match, > because you've received Mariusz' original Message > ID via the list interface. > > It's definitely not Bearophile's fault, his client's fault, and there is > nothing Bearophile can do to prevent it. To fix > it, ask Brad to do something about this (disable Message ID replacement? make the interface do a bidirectional Message > ID mapping in both Message-ID and References headers?), or stop using the > mailing list interface, which is obviously > just a shoddy frontend to the NNTP server. I don't think the mailing list software is what's at fault. There's _tons_ of people who use it, myself included obviously. If it was a general problem with the list software (mailman, probably the most popular list management software out there), it'd be a lot more prevelant. Try again.
Re: [OT] Threading (Was: bug covering other bug)
On Sat, 27 Aug 2011 07:08:45 +0300, Andrej Mitrovic wrote: Mariusz Gliwiński: http://codepad.org/9uZf3E1N bearophile: http://codepad.org/j84TLFC8 It happens 90% of the time when bear replies. That doesn't mean it's his fault. I think I see the problem: 1. Mariusz posts via the mailing-list interface. The original Message ID is <7480573.bRnhgVsvUV@magdalene>. 2. The mailing-list interface replaces the Message ID with its own. 3. Bearophile replies via the newsgroup. His client puts the mailing list's Message ID in the References header. Thus, when you receive Bearophile's post, the message IDs don't match, because you've received Mariusz' original Message ID via the list interface. It's definitely not Bearophile's fault, his client's fault, and there is nothing Bearophile can do to prevent it. To fix it, ask Brad to do something about this (disable Message ID replacement? make the interface do a bidirectional Message ID mapping in both Message-ID and References headers?), or stop using the mailing list interface, which is obviously just a shoddy frontend to the NNTP server. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] Threading (Was: bug covering other bug)
Mariusz Gliwiński: http://codepad.org/9uZf3E1N bearophile: http://codepad.org/j84TLFC8 It happens 90% of the time when bear replies.
Re: [OT] Threading (Was: bug covering other bug)
On Sat, 27 Aug 2011 06:51:03 +0300, Andrej Mitrovic wrote: I'm using gmail. That's not very helpful. If you post the e-mail headers for Mariusz' and bearophile's posts, as you received them, it'd probably be possible to point out whether the problem is with Gmail or the mailing list gateway. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] Threading (Was: bug covering other bug)
I'm using gmail.
[OT] Threading (Was: bug covering other bug)
On Sat, 27 Aug 2011 05:44:24 +0300, Andrej Mitrovic wrote: Bear, you keep creating new threads when you reply to other peoples posts.. My newsreader (Opera) threads Bearophile's posts fine. Let's have a look: Marius' post has: Message-ID: Bearophile's post has: Message-ID: References: I don't see the problem. I see you're using the mailing list interface. Perhaps the gateway is mangling headers, or your mail client has some arbitrary Message ID length limit? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: bug covering other bug
Bear, you keep creating new threads when you reply to other peoples posts..
Re: bug covering other bug
Mariusz G.: > So, on my Linux x64 dmd 2.53 & 2.54, while hunting another bug (i already > highly doubt it's my) - i've found this one: I can't reproduce the problem on 2.055head on 32 bit Windows. DMD 64 bit is relatively recent, it contains several bugs still. > Another problem i'm searching for, is something with interfacing to C, > pointer > to floats and properties and/or aliasing. NVM I don't understand. > Could someone point me that i'm doing something wrong, so it would give me > motivation to fight with all this bugs more? Maybe you are doing nothing wrong. > Because i'm already lacking of mental power when struggling with this massive > bug'osis while writing (hopefully) project of my live. Creating the project of your life with 64 bit DMD is a not so good idea. Currently DMD 32 bit is more reliable if you want to create a large project. > What's your opinion? I suggest to use D for less critical projects, and to help its debugging and improvement (in Bugzilla or even in GitHub). And to use C++/Java/C#/Python/etc for your life projects. Bye, bearophile
bug covering other bug
Hey,
firstly - i'm sorry that i'm not posting it directly to bugtracker but i highly
care about this issue.
So, on my Linux x64 dmd 2.53 & 2.54, while hunting another bug (i already
highly doubt it's my) - i've found this one:
private import std.stdio;
class T {
@property {
float[3] scale() {
return [1, 2, 3];
}
void scale(float[3] value) {
float tx = 1;
writeln(tx, " ", tx, " ", tx,
tx, " ", tx, " ", tx,
tx, " ", tx, " ", tx);
}
}
}
void main() {
auto t = new T;
t.scale = [1, 2, 3];
}
Compilation results in segmentation fault.
Another problem i'm searching for, is something with interfacing to C, pointer
to floats and properties and/or aliasing. NVM
Could someone point me that i'm doing something wrong, so it would give me
motivation to fight with all this bugs more?
Because i'm already lacking of mental power when struggling with this massive
bug'osis while writing (hopefully) project of my live.
Awareness that i would make what i already did in C++ much faster (because of
bugs and libs, not a language) slowly stops being recompensated by elegance of
code i can write with D and highly skilled community as you are.
What's your opinion?
Sincerely,
Mariusz Gliwiński
Re: SQLite Wrapper?
dsimcha Wrote: > I was looking through the Phobos source code and was reminded that > there's an SQLite binding in there now. Is there a wrapper for this in > the works/in the review queue? Andrej found the wrapper. This was the place the bindings came from. As for a wrapper in Phobos, I figure there would end up being discussion of an JDBC like database wrapper which would be used for any database connection.
Re: SQLite Wrapper?
FYI I just bumped into this 10 minutes ago: https://github.com/bayun/SQLite3-D/ I don't know the quality of code or how well it works though.
Re: Optional braces
kennytm: > I've created a patch* for dangling else checking. I have not yet compiled and tried your code, but from what I see all the design decisions you have taken are good, including the error message (I think it doesn't need to contain "dangling else" because that's a different thing), the cases you accept and you refuse, the use of the -d switch, etc). > You can disable the check with the -d flag. If this is true, then I suggest to give a hint about this in the error message too. So I suggest to add to the error message the word "deprecated". Thank you, bearophile ~~ D: Getting better one micro step each week - Continental drift for the win ~~
Re: Optional braces
"Steven Schveighoffer" wrote: > Hm... the only problem I see with simply disallowing if(a) if(b) is this: > > if(a) > while(condition) > if(b) > statement; > else // oops! this goes with if(b) > statement; > > Or would this be disallowed as well? This could not be combined into a > single if statement obviously, so the only the option to fix this is adding > braces. > > I'd hate to see this disallowed, which seems perfectly legitimate: > > if(a) >while(condition) > if(b) > statement; > > -Steve I've created a patch* for dangling else checking. Your first example will be banned and the second is allowed. Check the test cases there for more examples. *: https://github.com/D-Programming-Language/dmd/pull/336
Re: Algorithms and slices
On Friday, August 26, 2011 11:49 Timon Gehr wrote:
> On 08/26/2011 08:24 PM, Mafi wrote:
> > The algorithms in std.algorithm are great. They operate the same on
> > arrays/slices and generic ranges. But they return their own range-types.
> > Often this ok but sometimes you need a T[]. You may say to just use
> > array() but this allocates a new array! I think you sometimes want to
> > get a slice to the original array. I wrote this function. It checks if
> > it is ok what it is doing at runtime.
> >
> >
> > import std.stdio, std.algorithm, std.range, std.conv, std.exception;
> >
> > void main() {
> > auto x = [0, 1, 2, 3, 4, 5];
> > auto t = x.take(3);
> > foreach(i, ref elem; t) {
> > writefln("%s : %s (%s)", i, elem, &elem);
> > }
> > foreach(i, ref elem; array(t)) {
> > writefln("%s : %s (%s)", i, elem, &elem);
> > }
> > foreach(i, ref elem; slice(t)) {
> > writefln("%s : %s (%s)", i, elem, &elem);
> > }
> > }
> >
> > /**
> > Retuns a slices of the data the given range represents.
> >
> > throws: ConvException if the data is not continous.
> > *
> > ElementType!(R)[] slice(R)(R range) if(isInputRange!R) {
> > alias ElementType!(R) E;
> > E* addr = null;
> > size_t length = 0;
> > foreach(i, ref e; range) {
> > static assert(is(typeof(e) == E));
> >
> > if(addr is null) {
> > addr = &e;
> > } else {
> > enforce(&e is (addr + i), new ConvException("Could not create a
> > continous slice."));
> > }
> >
> > length++;
> > assert(i == length-1);
> > }
> > if (addr is null) return null;
> > else return addr[0.. length];
> > }
> > //
> >
> > Is there functinality like this in phobos? Does such a function fit into
> > the range world.
>
> That exposes the implementation details of all range-based functions.
> Are there even any range types in Phobos that do save their elements in
> a continuous array?
No. I believe that the only ranges which have an array underneath are arrays
and std.container.Array's range type. Phobos' range-based functions either
return the range type that it was given or a wrapper around that type (and the
range which was passed to it could already have been a wrapper around another
range). If a range-based function can return the original range type, then it
does (generally - if not always - because the range was sliceable). Otherwise,
you get a wrapper. Almost by definition, the fact that the range returned from
a range-based function is not the same type as the range passed in means that
the result is not a contiguous sub-range of the range which was passed in.
There are a few cases where you end up with a contiguous range which can't be
a slice, but they're all lazy ranges (e.g. until). And if you really want to
have a slice in that sort of situation, then you can just take the length of
the resultant lazy range and then take a slice of that length from the
beginning of the original range. e.g.
static assert(isSliceable!(typeof(range)));
auto slice = range[0 .. walkLength(until(range, delimiter))];
That won't work with strings, but neither will the proposed function. For
strings, you'd have to do something like
static assert(isSomeString!(typeof(range)));
auto slice = range[0 .. toUCSindex(walkLength(until(range, delimiter)))];
So, even if it works, I don't think that the proposed function buys us
anything.
- Jonathan M Davis
Re: Web browser
"jdrewsen" wrote in message news:j38su2$evo$1...@digitalmars.com... > Hi, > > I seem to remember that someone not too long ago mentioned he was > working on a web browser written in D as a pet project. I cannot locate > that post. Does anyone remember this and maybe have a link to the project > by chance? > Might be thinking of me. I've talked about wanting to do that and maybe porting Arora to D or something like that, but I've never actually stated on anything and probably won't have a chance to in the near future :( But I don't know, maybe someone else has actually started something?
Re: Algorithms and slices
On Fri, 26 Aug 2011 20:24:43 +0200, Mafi wrote: > The algorithms in std.algorithm are great. They operate the same on > arrays/slices and generic ranges. But they return their own range-types. > Often this ok but sometimes you need a T[]. I have a feeling that std.range.inputRangeObject() will be helpful here. It provides a polymorphic interface to different types of ranges. It returns an InputRangeObject(R), but don't let its name give the wrong impression: it can be used as any non-OutputRange :), as long as the range R supports that interface. Say, the element type is int and the range is a ForwardRange. Then you can have ForwardRange!int r = inputRangeObject(my_range_returning_algo()); Or, when you don't need the ForwardRange functionality, you can specify another type on the left hand side: InputRange!int r = inputRangeObject(my_range_returning_algo()); (You must specify the type explicitly.) Then you can have arrays of interfaces to these actually unrelated ranges: InputRange!int[] my_input_ranges; my_input_ranges ~= inputRangeObject(foo_algo()); my_input_ranges ~= inputRangeObject(bar_algo()); (Not tested. Type casting may be needed on the right hand sides as well.) Ali
Re: Web browser
jdrewsen wrote: > I seem to remember that someone not too long ago mentioned he was > working on a web browser written in D as a pet project. I started one, but haven't had a chance to come back to it since that first weekend. It does not currently compile since I've changed the libraries without updating the main code (I'll come back to that once the next dmd is out probably). Nevertheless, it's in here: http://arsdnet.net/dcode/ browser.d. Also requires simpledisplay.d, curl.d, dom.d, imagedraft.d, and default.css. I haven't spent a lot of time on it like I said, but it's almost usable already: http://arsdnet.net/crappybrowser5.png http://arsdnet.net/crappybrowser6.png (my posts discussing the process and other screenshots are on a server which is currently down, so these two are the best I have for now). As you can see there, it's got some image support, almost reasonable CSS support, and in the code, you'll see event handling and basic form support. But, you can also see - in the first screenshot especially - that the table algorithm is a piece of garbage and there's some bugs in handling css floats - they work, until you get a clear: both; in a nested container. Then it just goes all to hell.
Web browser
Hi, I seem to remember that someone not too long ago mentioned he was working on a web browser written in D as a pet project. I cannot locate that post. Does anyone remember this and maybe have a link to the project by chance? Thanks Jonas
Re: Algorithms and slices
On 26.08.2011 22:24, Mafi wrote: The algorithms in std.algorithm are great. They operate the same on arrays/slices and generic ranges. But they return their own range-types. Often this ok but sometimes you need a T[]. You may say to just use array() but this allocates a new array! I think you sometimes want to get a slice to the original array. I wrote this function. It checks if it is ok what it is doing at runtime. I'd argue that functions in question should return slice if the input range is sliceable. IIRC they do this when possible e.g. as in find but not filter, am I missing something? --- Dmitry Olshansky
Re: moving wxd to github
Andrej Mitrovic wrote: When I try to build via DMC's make I get: D:\dev\projects\wxd>make cd wxc make Error on line 181: can't read makefile '/build/msw/config.dmc' I don't see a build folder anywhere. Are these build instructions outdated on http://wxd.sourceforge.net/#installation ? If you build with DM make, you need to set $WXDIR env variable. It should say so, on that page. "set WXDIR=C:\wxWidgets-2.8.10" Normally tested with GNU make though, and should be 2.8.12 now. --anders
Re: Algorithms and slices
On 08/26/2011 08:24 PM, Mafi wrote:
The algorithms in std.algorithm are great. They operate the same on
arrays/slices and generic ranges. But they return their own range-types.
Often this ok but sometimes you need a T[]. You may say to just use
array() but this allocates a new array! I think you sometimes want to
get a slice to the original array. I wrote this function. It checks if
it is ok what it is doing at runtime.
import std.stdio, std.algorithm, std.range, std.conv, std.exception;
void main() {
auto x = [0, 1, 2, 3, 4, 5];
auto t = x.take(3);
foreach(i, ref elem; t) {
writefln("%s : %s (%s)", i, elem, &elem);
}
foreach(i, ref elem; array(t)) {
writefln("%s : %s (%s)", i, elem, &elem);
}
foreach(i, ref elem; slice(t)) {
writefln("%s : %s (%s)", i, elem, &elem);
}
}
/**
Retuns a slices of the data the given range represents.
throws: ConvException if the data is not continous.
*
ElementType!(R)[] slice(R)(R range) if(isInputRange!R) {
alias ElementType!(R) E;
E* addr = null;
size_t length = 0;
foreach(i, ref e; range) {
static assert(is(typeof(e) == E));
if(addr is null) {
addr = &e;
} else {
enforce(&e is (addr + i), new ConvException("Could not create a
continous slice."));
}
length++;
assert(i == length-1);
}
if (addr is null) return null;
else return addr[0.. length];
}
//
Is there functinality like this in phobos? Does such a function fit into
the range world.
That exposes the implementation details of all range-based functions.
Are there even any range types in Phobos that do save their elements in
a continuous array?
Algorithms and slices
The algorithms in std.algorithm are great. They operate the same on
arrays/slices and generic ranges. But they return their own range-types.
Often this ok but sometimes you need a T[]. You may say to just use
array() but this allocates a new array! I think you sometimes want to
get a slice to the original array. I wrote this function. It checks if
it is ok what it is doing at runtime.
import std.stdio, std.algorithm, std.range, std.conv, std.exception;
void main() {
auto x = [0, 1, 2, 3, 4, 5];
auto t = x.take(3);
foreach(i, ref elem; t) {
writefln("%s : %s (%s)", i, elem, &elem);
}
foreach(i, ref elem; array(t)) {
writefln("%s : %s (%s)", i, elem, &elem);
}
foreach(i, ref elem; slice(t)) {
writefln("%s : %s (%s)", i, elem, &elem);
}
}
/**
Retuns a slices of the data the given range represents.
throws: ConvException if the data is not continous.
*
ElementType!(R)[] slice(R)(R range) if(isInputRange!R) {
alias ElementType!(R) E;
E* addr = null;
size_t length = 0;
foreach(i, ref e; range) {
static assert(is(typeof(e) == E));
if(addr is null) {
addr = &e;
} else {
enforce(&e is (addr + i), new ConvException("Could not
create a continous slice."));
}
length++;
assert(i == length-1);
}
if (addr is null) return null;
else return addr[0.. length];
}
//
Is there functinality like this in phobos? Does such a function fit into
the range world.
Re: Optional braces
Cool stuff! DMD is almost there but it reports the line number of
whatever comes next, even if there was only whitespace, e.g.:
void main()
{
int foo = 2
} <- error line here instead of above
Re: moving wxd to github
When I try to build via DMC's make I get: D:\dev\projects\wxd>make cd wxc make Error on line 181: can't read makefile '/build/msw/config.dmc' I don't see a build folder anywhere. Are these build instructions outdated on http://wxd.sourceforge.net/#installation ?
Re: moving wxd to github
s/tarball/zip file The zipped source has the duplicate newlines, but that probably doesn't show up based on what editor you use. But anyway, the git version works fine.
Re: moving wxd to github
On 8/26/11, Anders F Björklund wrote: > The code uses CRLF, must be some kind of bug with your > git setup - looks "OK" from here (with the ^M that is). Sorry I've downloaded the tarball, not the git repo. The git repo doesn't have these problems, thanks.
Re: moving wxd to github
I can see the problem now. The code uses CR followed by CRLF on every line. This was probably some kind of unix -> windows EOL conversion bug. Either CRLF or CR's should be killed (personally I'm ok with unix endlines). The code uses CRLF, must be some kind of bug with your git setup - looks "OK" from here (with the ^M that is). Apparently you set core.autocrlf=false in your git config, (instead of "auto") to avoid it trying to convert things ? --anders
Re: Optional braces
On 2011/08/27 1:52, Andrej Mitrovic wrote: Of course they're still needed in other places, but to be honest I'm tired of "found foo, expected bla" errors due to missing semicolons. You can have both semi-colons and nice error messages if you put some effort into the parser. Clang manages this even for C++. Some sample SDC output: test.d(5:16): error: missing ';' after initialisation. int foo = 2 ^ ; test.d(5:18): error: missing ';' after expression. assert(false) ^ ; test.d(5:27): error: missing ';' after declaration. void function(int) foo ^ ;
Re: moving wxd to github
Andrej Mitrovic wrote: Do you mean you're stepping down as the maintainer of wxd, or just the GDC/CodeBlocks stuff? All three. Mostly wxD, but also the others - not using. I'll leave it up as-is, but won't be adding D2 features. --anders
Re: moving wxd to github
Andrej Mitrovic wrote: I can see the problem now. The code uses CR followed by CRLF on every line. This was probably some kind of unix -> windows EOL conversion bug. Either CRLF or CR's should be killed (personally I'm ok with unix endlines). The code uses CRLF, must be some kind of bug with your git setup - looks "OK" from here (with the ^M that is). --anders
Re: Tokenizing D at compile time?
== Quote from Rainer Schuetze (r.sagita...@gmx.de)'s article > The lexer used by Visual D is also CTFE capable: > http://www.dsource.org/projects/visuald/browser/trunk/vdc/lexer.d > As Timon pointed out, it will separate into D tokens, not the more > combined elements in your array. > Here's my small CTFE test: Thanks, but I've come to the conclusion that this lexer is way too big a dependency for something as small as parallel array ops, unless it were to be integrated into Phobos by itself. I'll just stick with the ugly syntax. Unfortunately, according to my benchmarks array ops may be so memory bandwidth-bound that parallelization doesn't yield very good speedups anyhow.
Re: Optional braces
On 26.08.2011 17:03, Andrei Alexandrescu wrote: On 8/25/11 9:13 PM, Walter Bright wrote: But I worry that we might wind up tarting up the language with too many a boatload of them, to the point where it becomes a confusing mass. At what point should Meg Ryan stop with the plastic surgery? :-) It's a legitimate concern, and there's no right response to it. My point is that the argument is weak and caving to it would be a mistake. In essence Nick claims he can't be bothered to change: if (long_expression_one) if (long_expression_two) if (long_expression_three) statement with if ((long_expression_one) && (long_expression_two) && (long_expression_three)) statement which adds a grand total of two parens. I often write code like this: if(auto p = getSome()) if(auto parent = p.getParent()) if(auto uncle = parent.getBrother()) uncle.doSome(); This cannot be translated into a conjunction of conditions without having to specify declarators before. I would not like to lose that possiblity. I'm not so sure about the dangling else issue. I don't want to be pampered all the time, but I have to admit to have run into that issue, too.
Re: Optional braces
On 8/26/11, Adam Ruppe wrote: >> we might as well get rid of the semicolon as well. > > You can have my semicolons when you pry them from my cold, dead hands. > I'd kill them (the semicolons, not your hands :p) in places they're not needed anymore. And we already have that in struct, class, enum definitions. Of course they're still needed in other places, but to be honest I'm tired of "found foo, expected bla" errors due to missing semicolons.
Re: Optional braces
Andrej Mitrovic: > Ok, I thought this was included. It wasn't included in my original enhancement request. But now I don't exactly know what situations Andrei wants to disallow. Bye, bearophile
Re: moving wxd to github
I can see the problem now. The code uses CR followed by CRLF on every line. This was probably some kind of unix -> windows EOL conversion bug. Either CRLF or CR's should be killed (personally I'm ok with unix endlines).
Re: moving wxd to github
*correction: It's not just the samples, it's the library code too. I don't understand, why the blank lines?
Re: Optional braces
> we might as well get rid of the semicolon as well. You can have my semicolons when you pry them from my cold, dead hands.
Re: Optional braces
Marco Leise: > Does your enhancement include other operators like '&&' or is it > practically just for the 'check if flag is disabled' case? My enhancement request regards just a narrow case. (But the actual implementation of it may add some other related cases, I don't know). Bye, bearophile
Re: Optional braces
On 8/26/11, bearophile wrote: > Andrej Mitrovic: > >> I don't see what banning this buys us. > > That's not banned. > > Bye, > bearophile > Ok, I thought this was included.
Re: Optional braces
Andrej Mitrovic: > I don't see what banning this buys us. That's not banned. Bye, bearophile
Re: Optional braces
I've used this a few times:
foreach (dir; dirs)
foreach (string file; dirEntries(dir, SpanMode.shallow))
{
if (file.isFile)
// do something..
}
And I only use this in short loops like this. It's more compact, I
dislike having to create too much indentation.
I don't see what banning this buys us. If we're going to force some
kind of predefined coding style on everyone then we might as well get
rid of the semicolon as well.
Re: Optional braces
On 8/26/11 8:48 AM, Steven Schveighoffer wrote: On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu wrote: It's a legitimate concern, and there's no right response to it. My point is that the argument is weak and caving to it would be a mistake. In essence Nick claims he can't be bothered to change: if (long_expression_one) if (long_expression_two) if (long_expression_three) statement with if ((long_expression_one) && (long_expression_two) && (long_expression_three)) statement which adds a grand total of two parens. The claim "blah blah long thing with the simple unrelated condition requiring ugly line breaks and screwy formattng/alignment in a big pita to read uber-expression. fuck this shit. It looks ok in english, but in code the damn thing reads like a fucking regex" does not stand scrutiny, and mixing in the matter of indentation is a red herring as indentation is unaffected by the introduction of the rule. I'll also note that the argument smacks of the misleading vividness fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). We shouldn't shelve an idea because a poor argument against it was eloquently phrased. Finally, we've derived significant benefits from ideas in the same spirit. I don't see signs that we've started overdoing it, or that the returns are diminishing. To me all signs point to a fertile approach to explore. Hm... the only problem I see with simply disallowing if(a) if(b) is this: if(a) while(condition) if(b) statement; else // oops! this goes with if(b) statement; Or would this be disallowed as well? This could not be combined into a single if statement obviously, so the only the option to fix this is adding braces. I don't think that bug is bound to occur with any significant frequency. Over the years I've seen ample evidence that the mismatched else in conjunction with repeated ifs causes bugs, both in other people's code and (alas) my own. But I have never seen or heard of a case in which an inserted additional control flow statement still caused problems. I'd hate to see this disallowed, which seems perfectly legitimate: if(a) while(condition) if(b) statement; Me too. Andrei
Re: moving wxd to github
Do you mean you're stepping down as the maintainer of wxd, or just the GDC/CodeBlocks stuff? wxWidgets look very interesting to me, lots of documentation available from what I can tell. Plus it seems it's easy to grab a device context out of a wxWidget frame, so I could use Cairo with that (e.g. http://code.google.com/p/wxcairo/wiki/IntegratingWithCairo). I think I'll give wxd a try these days. Btw, what is up with the excessive blank lines in the example source files? After every statement there is a blank line, it almost seems like a result of some indenter script that screwed things up. This is easily fixable for my own needs, of course. :)
Re: Optional braces
On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu wrote: It's a legitimate concern, and there's no right response to it. My point is that the argument is weak and caving to it would be a mistake. In essence Nick claims he can't be bothered to change: if (long_expression_one) if (long_expression_two) if (long_expression_three) statement with if ((long_expression_one) && (long_expression_two) && (long_expression_three)) statement which adds a grand total of two parens. The claim "blah blah long thing with the simple unrelated condition requiring ugly line breaks and screwy formattng/alignment in a big pita to read uber-expression. fuck this shit. It looks ok in english, but in code the damn thing reads like a fucking regex" does not stand scrutiny, and mixing in the matter of indentation is a red herring as indentation is unaffected by the introduction of the rule. I'll also note that the argument smacks of the misleading vividness fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). We shouldn't shelve an idea because a poor argument against it was eloquently phrased. Finally, we've derived significant benefits from ideas in the same spirit. I don't see signs that we've started overdoing it, or that the returns are diminishing. To me all signs point to a fertile approach to explore. Hm... the only problem I see with simply disallowing if(a) if(b) is this: if(a) while(condition) if(b) statement; else // oops! this goes with if(b) statement; Or would this be disallowed as well? This could not be combined into a single if statement obviously, so the only the option to fix this is adding braces. I'd hate to see this disallowed, which seems perfectly legitimate: if(a) while(condition) if(b) statement; -Steve
Re: Optional braces
On 8/25/11 9:13 PM, Walter Bright wrote: On 8/25/2011 6:30 PM, Andrei Alexandrescu wrote: On 8/25/11 6:10 PM, Walter Bright wrote: On 8/25/2011 6:04 PM, Nick Sabalausky wrote: Oh god no, don't ban that. I *like* to do that sort of thing: Unusual, but legitimate. I think I'll shelve the idea. It would be great to reconsider. The counter-argument is very weak. We've already put a number of special cases in the grammar to ward off "bugs". But I worry that we might wind up tarting up the language with too many a boatload of them, to the point where it becomes a confusing mass. At what point should Meg Ryan stop with the plastic surgery? :-) It's a legitimate concern, and there's no right response to it. My point is that the argument is weak and caving to it would be a mistake. In essence Nick claims he can't be bothered to change: if (long_expression_one) if (long_expression_two) if (long_expression_three) statement with if ((long_expression_one) && (long_expression_two) && (long_expression_three)) statement which adds a grand total of two parens. The claim "blah blah long thing with the simple unrelated condition requiring ugly line breaks and screwy formattng/alignment in a big pita to read uber-expression. fuck this shit. It looks ok in english, but in code the damn thing reads like a fucking regex" does not stand scrutiny, and mixing in the matter of indentation is a red herring as indentation is unaffected by the introduction of the rule. I'll also note that the argument smacks of the misleading vividness fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). We shouldn't shelve an idea because a poor argument against it was eloquently phrased. Finally, we've derived significant benefits from ideas in the same spirit. I don't see signs that we've started overdoing it, or that the returns are diminishing. To me all signs point to a fertile approach to explore. Andrei
Re: User defined safety?
On 08/26/2011 02:38 PM, Adam Ruppe wrote:
My pet feature request could do this too. User defined attributes
combined with a list of functions called by a function.
===
@custom("mysafe") void foo() {}
void bar() {}
@custom("mysafe") void main() {
foo();
bar();
}
CheckCustomSafety!("mysafe", main);
template CheckCustomSafety(string attribute, alias func) {
static if(!__traits(hasCustomAttribute(func, attribute))
pragma(error, func.stringof ~ " is not " ~ attribute);
foreach(f; __traits(getCalledFunctions, func))
CheckCustomSafety!(attribute, f);
}
And throw in an or for trusted.
The reason I want this is to check for things more like custom
purity, but I think it'd work for your custom safety too.
(and user defined attributes are just useful for other things too!)
The biggest problem I see with using my idea is the error
message will probably suck.
I think it could be possible to provide decent error messages, by
providing some means (via traits) to get line and file numbers of the
calls. The biggest problem I see with this design is, that only
functions reachable from main will be checked. I'd rather see something
in the lines of
mysafe.d
__traits(declareCustomAttribute, "mysafe"); // can detect name clash
__traits(declareCustomAttribute, "mytrusted");
__traits(declareCustomAttribute, "mysystem");
__traits(attribSetMutuallyExclusiveWithDefault, ["mysafe",
"mytrusted","mysystem"],"mysystem");
__traits(registerStaticChecker, "mysafe", CheckMysafe);
(the traits could be replaced by better syntax, of course)
and then we could use int main() @mysafe {} which would automatically be
checked.
There should also be some way to parameterize custom attributes, and to
perform code transformations (probably that would require AST-macros and
AST-pattern matching to be nice)
__traits(declareCustomAttribute, "memoized(int=int.max)"); // maximum
size of hash table.
int foo(int x)@memoized(100){ ... } // memoize at most 100 values
Re: moving wxd to github
Marco Leise wrote: Would have ? Well, you can still use the existing stuff* for D(1). It was mostly that focus has shifted to D2, since four years ago... I updated most of it for better 64-bit support last year, and there was a new Code::Blocks 10.05 but that was about it for development. When I started D2 was already advertised as the way to go so I restricted myself to projects that work with D2. It does work with D2 (well, except for DMD 64-bit that is). I think the restriction was "the GUI must be written in", and it isn't - but in C++ and in D. And of course the IDE doesn't have real D support, only when it looks like C++ ? Anyway, the whole idea of moving it to github.com was so that development could continue. We'll see how that goes. The upstream project, wx.NET, has also been going through some changes. And wxWidgets 3.0 hasn't been released yet. --anders
Re: User defined safety?
My pet feature request could do this too. User defined attributes
combined with a list of functions called by a function.
===
@custom("mysafe") void foo() {}
void bar() {}
@custom("mysafe") void main() {
foo();
bar();
}
CheckCustomSafety!("mysafe", main);
template CheckCustomSafety(string attribute, alias func) {
static if(!__traits(hasCustomAttribute(func, attribute))
pragma(error, func.stringof ~ " is not " ~ attribute);
foreach(f; __traits(getCalledFunctions, func))
CheckCustomSafety!(attribute, f);
}
And throw in an or for trusted.
The reason I want this is to check for things more like custom
purity, but I think it'd work for your custom safety too.
(and user defined attributes are just useful for other things too!)
The biggest problem I see with using my idea is the error
message will probably suck.
Re: moving wxd to github
Am 26.08.2011, 13:47 Uhr, schrieb Anders F Björklund : Marco Leise wrote: That are some good projects you were working on. We've got the precompiled DMD, Eclipse DDT and GtkD, but I would have tried wxWidgets in Code::Blocks with D. And while building GDC from source is possible, the Windows folks probably preferred a binary (and some Mac and Linux users, too). I hope someone steps in and this is not another wave of dying projects. Would have ? Well, you can still use the existing stuff* for D(1). It was mostly that focus has shifted to D2, since four years ago... I updated most of it for better 64-bit support last year, and there was a new Code::Blocks 10.05 but that was about it for development. * http://www.codeblocks.org/downloads/26 http://sourceforge.net/projects/gdcwin/files/gdc/r229/ http://sourceforge.net/projects/gdcgnu/files/gdc/r229/ http://sourceforge.net/projects/gdcmac/files/gdc/r229/ I guess you can also use QtD and Qt Creator, if you want something D2 ? --anders When I started D2 was already advertised as the way to go so I restricted myself to projects that work with D2. (Btw. I do have that Code::Blocks version and wrote a little c++ editor plug-in for private use.)
Re: Optional braces
Am 26.08.2011, 13:10 Uhr, schrieb bearophile : Marco Leise: Is (!x & y) an issue or is it rather people omitting spaces in their code !x&y ? This topic was already discussed in past, in two threads, this one of them: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=135741 The Coccinelle tool has found a large number of !x & y bug patterns in already debugged high-quality C/C++ code. Search for "Correct occurrences of !x&y" in this page: http://coccinelle.lip6.fr/impact_linux.php See also, a good lint catches this bug: http://d.puremagic.com/issues/show_bug.cgi?id=5814 And once these lints complain about 1 + 2 * 3 being ambiguous I lose all hope in mankind. But point taken, there is a provably large number of such bugs. In fact they can be narrowed down to 'check if a flag is disabled' as in this example: "if (!(flags & SOME_FLAG))". It's a common mistake, it causes significant troubles, it's easy to catch, avoiding it is cheap syntax-wise, and there is a precedent similar case already implemented in D. Ok, I get it. If in the above case we are forced to write ((!x) & y) that's ... LISP. Nope, it asks for just one pair of parentheses, like: !(x & y) Or: (!x) & y I guess "(!x) & y" is a rare case anyway. I though of "if ((!x) && y)". Does your enhancement include other operators like '&&' or is it practically just for the 'check if flag is disabled' case? At least I'm not convinced by what is in the bug report. You will have to bring on the table stronger evidence that this an useless change, if you want to refuse the enhancement request 5409. Walter and Don have accepted it, I think. I don't know what Andrei thinks of it. Bye, bearophile
Re: Shared lib support for Linux
wow, been looking for this since a long time, only found for gdc. 2011/8/26 bioinfornatics > I have explain here: https://github.com/ldc-developers/ldc/issues/4 how to > get shared lib for ldc2 compiler >
User defined safety?
I wonder if anybody has brought up the idea of using or expanding the SafeD features to cover a user-defined kind of safety? Right now, @safe means memory safe and it is defined by the language. However, there are many kinds of safety that benefit from being layered in a manner similar to how safe/trusted/system works. A web application for example might want to restrict raw sql access in one layer, where care is taken to avoid injection attacks. The rest of the application trusts only this layer and is forbidden from accessing the sql drivers directly. A security audit script can grep for such forbidden use of sql, thus enforcing a 'provable' safe use of sql (with the liberal use of the word provable). In D it could be possible to enforce this layered design by the compiler. It is possible right now by an application programmer through the (ab)use of safe/trusted/system, by lumping memory and sql-injection safety together, though this has some serious drawbacks. What do you think of this, is it a good or bad use of these features? Going further, SafeD could be expanded by allowing user defined security labels as parameters of safe/trusted/system. For example, the user could define @system(SQL) and @trusted(SQL) as well as @system(SMTP) and @trusted(SMTP). @safe code can use the @trusted sql and smtp components, but not @system. In this model, @trusted(SMTP) is only allowed to call @system(SMTP) and not @system(SQL).
Re: moving wxd to github
Marco Leise wrote: I am also stepping down as a maintainer, including the pre-built GDC distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D. Hopefully the new wxD project will have better luck of accomplishing a open-source cross-platform GUI and IDE for the D programming language ? That are some good projects you were working on. We've got the precompiled DMD, Eclipse DDT and GtkD, but I would have tried wxWidgets in Code::Blocks with D. And while building GDC from source is possible, the Windows folks probably preferred a binary (and some Mac and Linux users, too). I hope someone steps in and this is not another wave of dying projects. Would have ? Well, you can still use the existing stuff* for D(1). It was mostly that focus has shifted to D2, since four years ago... I updated most of it for better 64-bit support last year, and there was a new Code::Blocks 10.05 but that was about it for development. * http://www.codeblocks.org/downloads/26 http://sourceforge.net/projects/gdcwin/files/gdc/r229/ http://sourceforge.net/projects/gdcgnu/files/gdc/r229/ http://sourceforge.net/projects/gdcmac/files/gdc/r229/ I guess you can also use QtD and Qt Creator, if you want something D2 ? --anders
Re: Optional braces
Marco Leise: > Is (!x & y) an issue or is it rather people omitting spaces in their code > !x&y ? This topic was already discussed in past, in two threads, this one of them: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=135741 The Coccinelle tool has found a large number of !x & y bug patterns in already debugged high-quality C/C++ code. Search for "Correct occurrences of !x&y" in this page: http://coccinelle.lip6.fr/impact_linux.php See also, a good lint catches this bug: http://d.puremagic.com/issues/show_bug.cgi?id=5814 It's a common mistake, it causes significant troubles, it's easy to catch, avoiding it is cheap syntax-wise, and there is a precedent similar case already implemented in D. > If in the above case we are forced to write ((!x) & y) that's ... LISP. Nope, it asks for just one pair of parentheses, like: !(x & y) Or: (!x) & y > least I'm not convinced by what is in the bug report. You will have to bring on the table stronger evidence that this an useless change, if you want to refuse the enhancement request 5409. Walter and Don have accepted it, I think. I don't know what Andrei thinks of it. Bye, bearophile
Re: Optional braces
Am 26.08.2011, 11:32 Uhr, schrieb bearophile : There is one more special case that we plan to disallow, that's not in DMD yet: 5409 Disallow (!x & y) http://d.puremagic.com/issues/show_bug.cgi?id=5409 Is (!x & y) an issue or is it rather people omitting spaces in their code !x&y ? I can't imagine anyone will assume that !x & y negates the whole expression. At least a kernel developer should know the operator precedence. Are there actually lots of kernel bugs related to the version with spaces? I think the warning you get in many languages/IDEs when you write "if (x = y)" is ok. It tells you to wrap that expression in parenthesis if you really meant to do an assignment. It is a very special case that is not common among all imperative languages and is easily overlooked, especially if you worked with a language that uses = for comparisons. If in the above case we are forced to write ((!x) & y) that's ... LISP. At least I'm not convinced by what is in the bug report.
Re: Optional braces
> And there are few more special cases where I'd like to see > changes/improvements on (there are other improvements that I'd like to see, > but they aren't special cases): > > 3878 Arguments and attributes with the same name > 4407 Catch wrong argument<->attribute assignments in methods > 5187 Attribute hiding error or warning > 5788 Return [] array > 5807 Disallow mixed C/D style array declarations > 6005 Type alias - variable name don't clash > 6277 Disallow short floating point literals Please remove 6277 from this short list, because it doesn't introduce one more special case, it removes two of them. Bye, bearophile
Re: Optional braces
Walter: Here you are essentially asking for a more global view of the D design, to see if we are using too much "plastic surgery". To have such global view we need to look at many unrelated things. So sorry if this looks like a lot of meat on the fire, there is no other way. > We've already put a number of special cases in the grammar to ward off "bugs". There is one more special case that we plan to disallow, that's not in DMD yet: 5409 Disallow (!x & y) http://d.puremagic.com/issues/show_bug.cgi?id=5409 And there are few more special cases where I'd like to see changes/improvements on (there are other improvements that I'd like to see, but they aren't special cases): 3878 Arguments and attributes with the same name 4407 Catch wrong argument<->attribute assignments in methods 5187 Attribute hiding error or warning 5788 Return [] array 5807 Disallow mixed C/D style array declarations 6005 Type alias - variable name don't clash 6277 Disallow short floating point literals (The enhancement request 6277 was discussed a lot, and generally accepted by people here.) >But I worry that we might wind up tarting up the language with too many a >boatload of them, to the point where it becomes a confusing mass. At what >point should Meg Ryan stop with the plastic surgery? :-)< This a valid concern. The purpose of the discussions here is right to weight advantages against disadvantages, and to see what one weights more. But to perform this weighting you have to consider all factors at the same time. A well chosen "plastic surgery" in a language is often one that doesn't change the look of real world programs much. This is possible because a good rule is something that often wise programmers already follow when they write good code, or is something that is usually a bug anyway, like (!x & y). Where possible it's good to base similar decisions on data and real usage. So: - How many changes requires Phobos if the "else mismatch" syntax gets disallowed in D? - Is this syntax change able to catch bugs in the already existing Phobos code? (and other good D2 code)? - How much bad does it look D2 code if you introduce this grammar change? Is the result of this plastic surgery actually bad looking? Such data helps answer the final question: are those disadvantages less important than the estimated amount of bugs caused by mismatch else? My suggestion is to implement this small grammar change, compile Phobos with it, and then to take a look how much changes it requires, how much worse looking (if any) Phobos code becomes, and if this change finds any bugs in the code. This will help take the decision. In my experience in my D code there are causes of bugs more important than "else mismatch", like: 3878 Arguments and attributes with the same name 4407 Catch wrong argument<->attribute assignments in methods 3999 Enum equality to an int 5212 Safer typesafe variadics So I care more for those enhancement requests than for "else mismatch". Bye, bearophile
Re: moving wxd to github
Am 26.08.2011, 10:10 Uhr, schrieb Anders F Björklund : I am also stepping down as a maintainer, including the pre-built GDC distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D. Hopefully the new wxD project will have better luck of accomplishing a open-source cross-platform GUI and IDE for the D programming language ? --anders That are some good projects you were working on. We've got the precompiled DMD, Eclipse DDT and GtkD, but I would have tried wxWidgets in Code::Blocks with D. And while building GDC from source is possible, the Windows folks probably preferred a binary (and some Mac and Linux users, too). I hope someone steps in and this is not another wave of dying projects. - Marco
Re: Shared lib support for Linux
I have explain here: https://github.com/ldc-developers/ldc/issues/4 how to get shared lib for ldc2 compiler
Re: Shared lib support for Linux
It's been five months since I last ask for dynamic lib support of linux , I want to know when this can be achieved . A rough schedule time will be very help, thank in advance . On 22 March 2011 11:31, Long Chang wrote: > > Hello , > > The DMD will support shared lib for linux in future, But I wan't to > know when this can be completed . > > I am try use GDC build libgdruntime.a with -fPIC, and catch some > error I can't fix it . > > for example: > ../../../../libphobos/rt/arraybyte.d > ../../../../libphobos/rt/arraybyte.d: In function > ‘_arraySliceExpAddSliceAssign_g’: > ../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx’ > clobbered in ‘asm’ > > If Druntime team can help GDC team fix this issue will be great . > > > Kind Regards / Long Chang
moving wxd to github
As part of a necessary rewrite to better support wxWidgets 3.0 and D2, the wxD development is moving from SourceForge (cvs) to GitHub (git). As an interim step the existing source repository has been converted, the details at: http://sourceforge.net/scm/?type=git&group_id=133831 Besides updating the API, that currently follows wxWidgets 2.6 (ouch) even if you can link it with 2.8 and 2.9 as well if needed by system, if will change the current "struct" method of passing arrays to C++ into some kind of dual "size_t" and "void*" method as required by DMD. I am also stepping down as a maintainer, including the pre-built GDC distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D. Hopefully the new wxD project will have better luck of accomplishing a open-source cross-platform GUI and IDE for the D programming language ? --anders http://wxd.sourceforge.net/ http://www.codeblocks.org/ http://www.digitalmars.com/d/archives/digitalmars/D/wxD_GUI_and_Code_Blocks_IDE_46121.html
Re: Tokenizing D at compile time?
On 26.08.2011 03:08, dsimcha wrote:
I'm working on a parallel array ops implementation for
std.parallel_algorithm. (For the latest work in progress see
https://github.com/dsimcha/parallel_algorithm/blob/master/parallel_algorithm.d
).
To make it (somewhat) pretty, I need to be able to tokenize a single
statement worth of D source code at compile time. Right now, the syntax
requires manual tokenization:
mixin(parallelArrayOp(
"lhs[]", "=", "op1[]", "*", "op2[]", "/", "op3[]"
));
where lhs, op1, op2, op3 are arrays.
I'd like it to be something like:
mixin(parallelArrayOp(
"lhs[] = op1[] * op2[] / op3[]"
));
Does anyone have/is there any easy way to write a compile-time D tokenizer?
The lexer used by Visual D is also CTFE capable:
http://www.dsource.org/projects/visuald/browser/trunk/vdc/lexer.d
As Timon pointed out, it will separate into D tokens, not the more
combined elements in your array.
Here's my small CTFE test:
///
int[] ctfeLexer(string s)
{
Lexer lex;
int state;
uint pos;
int[] ids;
while(pos < s.length)
{
uint prevpos = pos;
int id;
int type = lex.scan(state, s, pos, id);
assert(prevpos < pos);
if(!Lexer.isCommentOrSpace(type, s[prevpos .. pos]))
ids ~= id;
}
return ids;
}
unittest
{
static assert(ctfeLexer(q{int /* comment to skip */ a;}) ==
[ TOK_int, TOK_Identifier, TOK_semicolon ]);
}
If you want the tokens as strings rather than just the token ID, you can
collect "s[prevpos .. pos]" instead of "id" into an array.
