DVM - D Version Manager 0.3.1
I just released a new version of DVM, 0.3.1. This is purely a bug fix release for Windows. I didn't bother compiling for Linux or Mac OS X. Changelog: Version 0.3.1 Bugs Fixed * dvm use changes the default compiler on Windows * Can't install on Windows without administrator rights For instructions how to install and downloads see: https://bitbucket.org/doob/dvm -- /Jacob Carlborg
Re: DB ORM
On 10/08/11 06.47, Kagamin wrote: Jonas Drewsen Wrote: Just stumbled upon this db orm for c++ that uses the gcc frontend to rewrite c++ code to make classes suitable for database access. http://www.codesynthesis.com/products/odb/ They are using pragmas to accomplish this. I guess an equally good implementation in D would use custom attributes for this once (if) they are supported. /Jonas If there's no mapping, that's bad. A database is a product on its own. It doesn't have to be what you'd like it to be. Objects can correspond to tables quite vaguely. The database may have tricky legacy conventions you don't want to have in your code directly. What about deletion and creation if you have hierarchy of types and objects? What if and object is split between joined tables? Inner joined or left joined. I'm not sure I understand. Are you against using DB ORMs in general? ORM is certainly not a perfect mapping of a database and have plenty of shortcomings. Deletion and creation of hierarchies is actually handled by some ORMs and there are ways to handle joins as well. I've not actively used the C++ ORM myself but have been using python storm, ruby active record etc. Most of them really makes your code more lean and readable. In the special cases where a simple mapping is not enough (performance or feature wise) you can always fall back to standard SQL queries. /Jonas
Re: Fixing valid options for std.getopt
On 2011-08-09 23:32, Jens Mueller wrote: Hi, I've added some changes to getopt to change when an options is accepted/rejected. I'm going to describe its old behavior in contrast with its old behavior. Consider parsing an option of Type T: T timeout; getopt(args, t|timeout,timeout); Short options (single dash): -t v accept (was rejected) -t=v accept -tv only accept for numeric v (was accepted for all types except associative arrays) Strange short options: -timeout v reject -timeout=v reject (was accepted) -timeoutv reject Long options (double dash): --timeout v accept --timeout=v accept --timeoutv reject Strange long options: --t v reject (was accepted) --t=v reject (was accepted) --tv reject I would like to know whether you find the new behavior better or if you prefer the old. Or even a mix of both. Or none of the above. The current behavior is quite simple if you remember some simple rules: 1. Short options consist of a single dash and a single character. 2. Long options consist of two dashes and more than one character. 3. Passing short and long options is supported by short/long optionspace+value andshort/long option=value 4. The formshort optionvalue is only supported for numeric values. 5. Anything else is not supported and an exception is thrown. To look at the changes see here: https://github.com/jkm/phobos/commit/b208eeb142ff5a3f189c2595b9800425646b4794 (fixes old behavior) https://github.com/jkm/phobos/commit/a25cd2459418d462c85ab14c2d970dd413b4fb05 (introduces new behavior) Please comment. Jens I like it, but I see no reason to accept short optionvalue. I've never understood why anyone would want to accept that. For example, looking at DMD's help message is often hard to tell where an option end and the value beings, i.e. -offilename. -- /Jacob Carlborg
Re: path tracing benchmark
On 2011-08-09 22:04, bearophile wrote: Christian Kamm: bearophile, just out of interest, what's the performance like if you ran ldmd -O3 -release -inline smallpt2_d.d ? I don't remember what ldmd is. Without LTO the performance of the LDC compile was a bit lower than the G++ compile. ldmd is a wrapper that converts dmd arguments to ldc arguments. So you can call ldc with the same arguments you would call dmd. -- /Jacob Carlborg
Re: PSP emulator written in D
On Aug 10, 11 05:15, bearophile wrote:
This again shows that some common basic exceptions are needed in Phobos:
http://code.google.com/p/pspemu/source/browse/trunk/src/pspemu/Exceptions.d
These exceptions are not common or basic. I think it's better to make
constructors inheritable when there are no new members, or add something
like this to std.exception:
---
mixin template ExceptionConstructors() {
this(string msg, string file = __FILE__, size_t line = __LINE__,
Throwable next = null) {
super(msg, file, line, next);
}
this(string msg, Throwable next, string file = __FILE__, size_t
line = __LINE__) {
super(msg, next, file, line);
}
}
---
So those custom exceptions can be created as
class TimeoutException : Exception {
mixin ExceptionConstructors;
}
Re: Fixing valid options for std.getopt
Dmitry Olshansky wrote: On 10.08.2011 1:32, Jens Mueller wrote: Hi, I've added some changes to getopt to change when an options is accepted/rejected. I'm going to describe its old behavior in contrast with its old behavior. Consider parsing an option of Type T: T timeout; getopt(args, t|timeout,timeout); Short options (single dash): -t v accept (was rejected) +1 on this, I recall spending about an hour trying to get why -t v is not working. Though I dunno why change -tv, I think it's widely used form and not only for numerics. I believe it's only safe for numerics. Consider the following example. -tsomestring was passed because -t is supported short option but your program also accepts the boolean long option --tsomestring. Now forgetting a single dash will change the behavior silently. One can argue it's the programmer's job to not define options in this combination. Basically whenever you define a non-boolean short option don't specify a long option starting with the same letter. Allowing it only for numeric values avoids having this rule. Thus, it's less error-prone I think. Jens
Re: Why do shift operators undergo integral promotion?
On Aug 10, 11 01:06, Walter Bright wrote:
On 8/9/2011 2:46 AM, Don wrote:
From a discussion on D.learn.
If x and y are different integral types, then in an expression like
x y
the integral promotion rules are applied to x and y.
This behaviour is obviously inherited from C, but why did C use such a
counter-intuitive and bug-prone rule?
Why isn't typeof(x y) simply typeof(x) ?
What would break if it did?
You might think the the rule is that typeof( x y) is typeof( x + y),
but it isn't: the arithmetic conversions are NOT applied:
typeof(int long) is int, not long, BUT
typeof(short int) is int.
And we have this death trap (bug 2809):
void main()
{
short s = -1;
ushort u = s;
assert( u == s );
assert ( (s 1) == (u 1) ); // FAILS
}
That last is why we can't just change the behavior from C.
Does C or C++ even have a '' operator? If we need to have a
type-promotion rule like C, it could be made as
x y == cast(promoted type) cast(typeof(x)) (unsigned(x) y)
e.g.
cast(short)(-1) 1 == 0x7f.
Curl wrapper
Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? Regards, Jonas
Re: Fixing valid options for std.getopt
Jacob Carlborg wrote: On 2011-08-09 23:32, Jens Mueller wrote: Hi, I've added some changes to getopt to change when an options is accepted/rejected. I'm going to describe its old behavior in contrast with its old behavior. Consider parsing an option of Type T: T timeout; getopt(args, t|timeout,timeout); Short options (single dash): -t v accept (was rejected) -t=v accept -tv only accept for numeric v (was accepted for all types except associative arrays) Strange short options: -timeout v reject -timeout=v reject (was accepted) -timeoutv reject Long options (double dash): --timeout v accept --timeout=v accept --timeoutv reject Strange long options: --t v reject (was accepted) --t=v reject (was accepted) --tv reject I would like to know whether you find the new behavior better or if you prefer the old. Or even a mix of both. Or none of the above. The current behavior is quite simple if you remember some simple rules: 1. Short options consist of a single dash and a single character. 2. Long options consist of two dashes and more than one character. 3. Passing short and long options is supported by short/long optionspace+value andshort/long option=value 4. The formshort optionvalue is only supported for numeric values. 5. Anything else is not supported and an exception is thrown. To look at the changes see here: https://github.com/jkm/phobos/commit/b208eeb142ff5a3f189c2595b9800425646b4794 (fixes old behavior) https://github.com/jkm/phobos/commit/a25cd2459418d462c85ab14c2d970dd413b4fb05 (introduces new behavior) Please comment. Jens I like it, but I see no reason to accept short optionvalue. I've never understood why anyone would want to accept that. For example, looking at DMD's help message is often hard to tell where an option end and the value beings, i.e. -offilename. I think short options with no space are supported because a number of people (don't know how many) type no spaces. For example $ ping -c1 some host vs $ ping -c 1 some host Both work. ping's documentation explains the -c option using a space. I.e. the documentation is easy to read. Supporting it does not break anything for you. And this way it does no harm to anybody. The only reason for dropping it may be inconsistency, i.e. why does it only work for numeric values. Jens
Re: Fixing valid options for std.getopt
David Nadlinger wrote: On 8/10/11 2:57 AM, Jonathan M Davis wrote: It's _very_ odd for dmd to have flags which are multi-character but only take a single -, and I'd argue that that's not behavior which should be emulated. I don't know what your definition of odd is, but some counterexamples that immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, … I've also come across this. I first thought it's a GNU vs. something other issue. But gcc proves me wrong. The basic difference is whether a long option has to have two dashes. If it doesn't, then bundling of short options cannot be supported as Mike Wey pointed out some time ago. I often use this bundling when using tar, e.g. tar -xf file. Maybe the above tools need no bundling. Jens
Re: Curl wrapper
On Wednesday, August 10, 2011 09:16:35 Jonas Drewsen wrote: Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? LOL. No, I'm not the one who schedules reviews. We don't really have anyone who does that. We don't even have altogether formal queue. People post when they have something for review, and we roughly keep track of what's supposed to be next in the queue based on what gets posted when and what's actually ready for review after whatever is currently up for review is done being reviewed. Someone then volunteers to be the review manager for whatever is being reviewed, and they handle posting about the review and counting the votes and whatnot. I _did_ volunteer to be the review manager for the curl wrapper when you last brought it up for review, though you never responded about that and std.path ended up getting reviewed first, since Lars was back from vacation. Now, there are a few items which are in the review queue at the moment. We should probably have a page somewhere which keeps track of the review queue more formally, but we don't at the moment. The whole thing is fairly informal. However, if I recall correctly, the items which are supposedly ready for review are the new std.log and the curl wrapper. Also, Jesse Phillips has a module for parsing CSV files which may or may not be ready for review (his post on it made it clear that he was looking to have it reviewed soon, but it wasn't entirely clear whether it was actually ready for a formal review). There are some other items which I believe are at least close to being ready for review (e.g. Robert Jacques has done some work on revising std.json), but I'm not aware of anything else which is actually ready for review. So, that leaves std.log and the curl wrapper. I believe that std.log has been the queue longer, so if Jose is actually ready for it to be reviewed now (he was on vacation, which is why it hasn't been reviewed yet), then that should be reviewed before the curl wrapper, but if he's not ready, and you're ready for the curl wrapper to be reviewed, then the curl wrapper should be reviewed next. - Jonathan M Davis
Re: Fixing valid options for std.getopt
Jonathan M Davis wrote: On 10.08.2011 2:35, Bernard Helyer wrote: On Tue, 09 Aug 2011 22:34:29 +, Bernard Helyer wrote: For SDC I've had to resort to filtering through args before getopt and replacing -m32 with --m32. The output flag needs to have that treatment too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these changes and give them two thumbs up. d-n_n-b That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it? Same here, though not a big deal. Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled? I'm not sure that it's a bad idea to give some options on how getopt works (e.g. a way to disallow the bundling of arguments), but in general it should probably work like the C getopt as far as what it accepts goes, and I believe that these changes bring it more in line with the C getopt. I will check man 3 getopt. Typically, the only way to use multi-character flags is --, and when you use -, every all of the characters immediately following it are individual flags. It's _very_ odd for dmd to have flags which are multi-character but only take a single -, and I'd argue that that's not behavior which should be emulated. So, in general, I think that these changes are very much the right approach. However, it may be reasonable to have a way to alter some of getopt's behavior for those who want it. Supporting a short option like -ofoo.bin may be error prone. Let's say I also have the long boolean option --obar. Now somebody passes -obar but intended --obar. Is this problematic? Jens
Is std.log ready for review?
Jose, are you ready for std.log to be reviewed? I believe that it's the item which has been in the review queue the longest at this point. So, if you're ready, then it should be reviewed. If you're not ready, then it sounds like the curl wrapper _is_ ready, and we'll probably move on with reviewing that. So, the question is: are you ready for std.log to be reviewed? - Jonathan M Davis
Re: PSP emulator written in D
On 9/08/11 10:15 PM, bearophile wrote: So to blow on this tiny fire, do you know ways to improve the D2 language and D2 Phobos to help game development? There's different levels of game developer. Indies will mostly want convenience, but AAA developers need control. For example, a good vector + matrix + quaternion math library would be great for indies, but AAA developers would likely write their own, even if the library was highly optimised with SIMD, floatInVec etc. SIMD intrinsics are obviously essential for AAA development. The garbage collector is something that still needs work. My current project has several second stalls every once in a while due to the GC (indies might be happy to miss a frame or two (30-60ms) but AAA developers won't, so you either don't use the GC, or it has to collect in under a couple of ms). I managed to remove all my per-frame allocations, but this was not easy. I had to modify my druntime to print out when allocations where happening to find them (most were those static array initialisations that I often talk about). Of course, having libraries available for audio/image loading/manipulation is helpful, and bindings for OpenGL etc. but those are already available through Derelict. I don't think they need to be in Phobos. The most important thing at the moment is just to get the language into a usable state and to get all the advertised features working. We also need more tutorials and resources to explain the subtler parts of D2 (e.g. when, why and how template alias parameters work).
Re: Fixing valid options for std.getopt
On Wednesday, August 10, 2011 09:51:32 Jens Mueller wrote: Jonathan M Davis wrote: On 10.08.2011 2:35, Bernard Helyer wrote: On Tue, 09 Aug 2011 22:34:29 +, Bernard Helyer wrote: For SDC I've had to resort to filtering through args before getopt and replacing -m32 with --m32. The output flag needs to have that treatment too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these changes and give them two thumbs up. d-n_n-b That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it? Same here, though not a big deal. Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled? I'm not sure that it's a bad idea to give some options on how getopt works (e.g. a way to disallow the bundling of arguments), but in general it should probably work like the C getopt as far as what it accepts goes, and I believe that these changes bring it more in line with the C getopt. I will check man 3 getopt. Typically, the only way to use multi-character flags is --, and when you use -, every all of the characters immediately following it are individual flags. It's _very_ odd for dmd to have flags which are multi-character but only take a single -, and I'd argue that that's not behavior which should be emulated. So, in general, I think that these changes are very much the right approach. However, it may be reasonable to have a way to alter some of getopt's behavior for those who want it. Supporting a short option like -ofoo.bin may be error prone. Let's say I also have the long boolean option --obar. Now somebody passes -obar but intended --obar. Is this problematic? Personally, I'll all for requiring that multi-character flags use -- and not -, and I _do_ think that it's problematic to allow multi-character flags to use -. However, I'm not entirely against having a way to tell getopt to accept multi- character flags with a single - if people want that and it can work reasonably without causing problems as long as people are careful about the flags that their program accepts. It definitely shouldn't be the default behavior though. However, given that getopt is a single function call with a variadic argument, the only way that I can think of that you'd be able to tell it whether to accept multi-character flags with a single - would be a template argument, and I'd be very concerned that accepting multi-character flags with a single - would make getopt overly complicated. I'd have to examine the implementation though to see how much worse it would make it. It would probably have to change so that there is no difference between - and -- (both are treated like --), except that --ofbar.bin isn't accepted with your changes (you need either --of bar.bin or --of=bar.bin). So, treating - like -- isn't really going to do what the people who want multi-character flags with - would want anyway (and I do think that disallowing --ofbar.bin is the correct decision, so I'm not advising changing that). So, I don't know. I'm generally against programs having multi-character flags which work with -, and I'm definitely afraid that allowing such things with a separate setting for getopt is going to overcomplicate getopt. Regardless, I would be _completely_ against the default allowing it. So, I'd prefer that getopt just have the one set of behaviors and disallow multi-character flags with -, but I don't want to just reject it out of hand if others want it and it's reasonably feasible without overcomplicating things. The real question is how the C getopt works, since that's what our getopt is at least supposed to be modeled after (and given that it has the same name, it's not unreasonable to expect essentially the same behavior). However, a quick glance at getopt's man page makes it seem far more complicated than our getopt, which I would consider to be undesirable. So, we may not want to quite follow the C getopt. However, we should definitely look at how it handles the flags and what it allows and try for something similar. - Jonathan M Davis
Re: Any D developer at GDC europe next week ?
On 09.08.2011 18:52, Trass3r wrote: Hi perhaps there is a chance to talk about D in the game industry ?! I will be there. Convince Crytek to switch to D ;) I will do my best :) -Stephan
Re: Curl wrapper
Jonas Drewsen wrote: Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? Regards, Jonas Sorry, I wanted to post this earlier but then I totally forgot about it, so here's a last minute request: Could you add proxy support to the wrapper? All of CURLOPT_PROXY CURLOPT_PROXYPORT and CURLOPT_PROXYTYPE should be available. (The 'combined' CURLOPT_PROXY since 7.21.7 is too new, that's not even in the current ubuntu) Also, although it'd break encapsulation, I think the curl handle should be accessible from the Http and Curl structs. But that's debatable, so I'll brink it up in the review thread where it should be discussed first. -- Johannes Pfau
[GSOC] regular expressions beta is here
In case I failed to mention it before, I m working on the project codenamed FReD that is aimed at ~100%* source level compatible overhaul of std.regex, that uses better implementation techniques, provides modern Unicode support and common syntax riches. I think it's time for a public beta release, since it _should_ be ready for mainstream usage. There are some rough edges, and a couple issues that I'm aware of but they are nowhere in realistic use cases. In order to avoid unexpected regressions I'd be glad if current std.regex users do try it for their projects/tests. To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. I'll upload newer packages as bugs get exposed and fixed. Alternatively, if you a comfortable with git you may just git clone entire repo. Some helpful notes (same as README) can be found here : https://github.com/blackwhale/FReD/wiki/Beta-release Caveats: In order for it compile a tiny change to 2.054 source is needed (no need to recompile Phobos! it's only in templates): patch std.algorithm.cmp according to this diff https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4631 https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4633 and to get CTFE features working add if(!__ctfe) listed in the next diff on the same webpage. (this is already upstream, so if you're using a fork of phobos just pull this in) * some API problems might lead to a breaking change, though it didn't happen in this release -- Dmitry Olshansky
Re: Fixing valid options for std.getopt
On 2011-08-10 09:26, Jens Mueller wrote: I think short options with no space are supported because a number of people (don't know how many) type no spaces. For example $ ping -c1some host vs $ ping -c 1some host Both work. ping's documentation explains the -c option using a space. I.e. the documentation is easy to read. Supporting it does not break anything for you. And this way it does no harm to anybody. The only reason for dropping it may be inconsistency, i.e. why does it only work for numeric values. Jens Just saying I don't like that. I won't break anything for me but it will let people continue to implement tools which uses this syntax. -- /Jacob Carlborg
Re: Std.path: Final Vote
On Fri, 05 Aug 2011 09:26:39 -0400, dsimcha wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. I would just like to remind everyone that there are now only two days left until voting ends. While I am certainly pleased that everyone has so far voted yes, I am a bit worried that so few people have voted in the first place. This module may become a permanent part of D's standard library. If you care about this, either way, please cast your vote now. -Lars
Re: [GSOC] regular expressions beta is here
On Wed, 10 Aug 2011 13:42:25 +0300, Dmitry Olshansky dmitry.o...@gmail.com wrote: and to get CTFE features working add if(!__ctfe) listed in the next diff Hi, does this rewrite cover compile-time regex compilation? E.g. regex!`^a` compiling to s.lengths[0]=='a' or something like that. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: PSP emulator written in D
Peter Alexander: There's different levels of game developer. Indies will mostly want convenience, but AAA developers need control. Right. Both groups are important. For example, a good vector + matrix + quaternion math library would be great for indies, but AAA developers would likely write their own, even if the library was highly optimised with SIMD, floatInVec etc. A 2D/3D/4D vector is good to have in Phobos. (Quaternion are optional). SIMD intrinsics are obviously essential for AAA development. The problem is they change as time goes. So instead of adding a ton of those (ugly) intrinsics, I suggest to add a meta-feature to D: a syntax to write inlin-able asm expressions (as present in LDC). With this syntax, SIMD intrinsics become library (even Phobos) code to standardize. I had to modify my druntime to print out when allocations where happening to find them (most were those static array initialisations that I often talk about). This is useful. Why don't you create a patch that (when a specific compiler switch is on) lists at compile-time all heap allocations and closure allocations of a compilation unit? The most important thing at the moment is just to get the language into a usable state This will take time, and you can't rush it. Thank you for the answers, bye, bearophile
Re: [GSOC] regular expressions beta is here
On 2011-08-10 12:42, Dmitry Olshansky wrote: In case I failed to mention it before, I m working on the project codenamed FReD that is aimed at ~100%* source level compatible overhaul of std.regex, that uses better implementation techniques, provides modern Unicode support and common syntax riches. I think it's time for a public beta release, since it _should_ be ready for mainstream usage. There are some rough edges, and a couple issues that I'm aware of but they are nowhere in realistic use cases. In order to avoid unexpected regressions I'd be glad if current std.regex users do try it for their projects/tests. To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. I'll upload newer packages as bugs get exposed and fixed. Alternatively, if you a comfortable with git you may just git clone entire repo. Some helpful notes (same as README) can be found here : https://github.com/blackwhale/FReD/wiki/Beta-release Caveats: In order for it compile a tiny change to 2.054 source is needed (no need to recompile Phobos! it's only in templates): patch std.algorithm.cmp according to this diff https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4631 https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4633 and to get CTFE features working add if(!__ctfe) listed in the next diff on the same webpage. (this is already upstream, so if you're using a fork of phobos just pull this in) * some API problems might lead to a breaking change, though it didn't happen in this release I have a suggestion, make RegexMatch implicitly convertible to bool, indicating if there was a match or not. Aren't there a lot of things that should be declared as private in the fred.d module? -- /Jacob Carlborg
Re: [GSOC] regular expressions beta is here
On 10.08.2011 15:16, Vladimir Panteleev wrote: On Wed, 10 Aug 2011 13:42:25 +0300, Dmitry Olshansky dmitry.o...@gmail.com wrote: and to get CTFE features working add if(!__ctfe) listed in the next diff Hi, does this rewrite cover compile-time regex compilation? E.g. regex!`^a` compiling to s.lengths[0]=='a' or something like that. Yes, I've dubbed it static regex. In fact it will be something similar to this, though it will do a heap allocation for backtracking points, on first call to match. Heap allocations are definetly going away in final release. You can pass -version=fred_ct -debug to dmd to see generated programs. At the moment it's more prof of concept then speed devil, something I might see about to change once CTFE bugs worked out. Anyway when it doesn't crush the compiler, it's pretty fast :) -- Dmitry Olshansky
Re: [GSOC] regular expressions beta is here
On 10.08.2011 15:34, Jacob Carlborg wrote: On 2011-08-10 12:42, Dmitry Olshansky wrote: In case I failed to mention it before, I m working on the project codenamed FReD that is aimed at ~100%* source level compatible overhaul of std.regex, that uses better implementation techniques, provides modern Unicode support and common syntax riches. I think it's time for a public beta release, since it _should_ be ready for mainstream usage. There are some rough edges, and a couple issues that I'm aware of but they are nowhere in realistic use cases. In order to avoid unexpected regressions I'd be glad if current std.regex users do try it for their projects/tests. To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. I'll upload newer packages as bugs get exposed and fixed. Alternatively, if you a comfortable with git you may just git clone entire repo. Some helpful notes (same as README) can be found here : https://github.com/blackwhale/FReD/wiki/Beta-release Caveats: In order for it compile a tiny change to 2.054 source is needed (no need to recompile Phobos! it's only in templates): patch std.algorithm.cmp according to this diff https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4631 https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4633 and to get CTFE features working add if(!__ctfe) listed in the next diff on the same webpage. (this is already upstream, so if you're using a fork of phobos just pull this in) * some API problems might lead to a breaking change, though it didn't happen in this release I have a suggestion, make RegexMatch implicitly convertible to bool, indicating if there was a match or not. Interesting idea, one problem with it is that I want this: auto m = match(bleh, bleh); writeln(m); to actually print bleh, not true Right now due to a carry over bug from std.regex (interface thing) writln(m) will just do a stackoverflow, m.hit however works. Aren't there a lot of things that should be declared as private in the fred.d module? Yes, it's a side effect of me having a lot of debugging tool that do need these internals. If only package protection attribute of something was working Not to mention that the whole module should work in SafeD with a couple of @trusted here and there. -- Dmitry Olshansky
Re: PSP emulator written in D
The garbage collector is something that still needs work. My current project has several second stalls every once in a while due to the GC (indies might be happy to miss a frame or two (30-60ms) but AAA developers won't, so you either don't use the GC, or it has to collect in under a couple of ms). There already is a concurrent GC which might be of interest for you.
Re: path tracing benchmark
If I compile it with with LDC1 with Link Time Optimization + Interning: ldc -O3 -release -inline -output-bc smallpt2_d.d opt -std-compile-opts smallpt2_d.bc smallpt2_do.bc llvm-ld -native -ltango-base-ldc -ltango-user-ldc -ldl -lm -lpthread -internalize-public-api-list=_Dmain -o=smallpt2_do smallpt2_do.bc Is there a more convenient way to get LTO with LDC?
Re: Why do shift operators undergo integral promotion?
Walter Bright wrote:
On 8/9/2011 2:46 AM, Don wrote:
From a discussion on D.learn.
If x and y are different integral types, then in an expression like
x y
the integral promotion rules are applied to x and y.
This behaviour is obviously inherited from C, but why did C use such a
counter-intuitive and bug-prone rule?
Why isn't typeof(x y) simply typeof(x) ?
What would break if it did?
You might think the the rule is that typeof( x y) is typeof( x + y),
but it isn't: the arithmetic conversions are NOT applied:
typeof(int long) is int, not long, BUT
typeof(short int) is int.
And we have this death trap (bug 2809):
void main()
{
short s = -1;
ushort u = s;
assert( u == s );
assert ( (s 1) == (u 1) ); // FAILS
}
That last is why we can't just change the behavior from C.
C doesn't even have the operator.
There is no valid backwards compatibility with C argument here.
I cannot see ANY justification whatsoever for the behaviour of .
Applying integral promotion to is completely wrong. It is a bug in
100% of cases.
Possibilities are:
(1) use typeof( x y) is typeof(x)
(2) as (1), but break with C, and apply the same rule for typeof(xy)
(The C rule isn't too unreasonable for x y).
(3) generate a compile error for x y when x is short or byte.
Actually, I found that I misread the spec. It actually says:
The operands must be integral types, and undergo the usual integral
promotions. The result type is the type of the left operand after the
promotions. The result value is the result of shifting the bits by the
right operand's value.
So with x y, the type of y actually has no effect; if x is smaller
than int, the result is int; otherwise, the type is x.
So in fact, if x is short or byte, then x y is NEVER an unsigned
shift, regardless of what y is: it's always the same as x y.
But the spec says performs an unsigned shift.
This disagrees with the = operator as well: = always performs an
unsigned shift, even though the spec says that
x = y is the same as x = x y.
Given that is the same as for any unsigned type
Re: DB ORM
About ORM, the Python has SQLObject (http://sqlobject.org/), the Java has Hibernate (http://www.hibernate.org/), and the C# has NHibernate and Entity Framework (http://msdn.microsoft.com/en-us/data/aa937723). The D maybe also need one. Glad to see someone being interesting in this. -- Zhang bitwo...@qq.com
Re: [GSOC] regular expressions beta is here
On Wed, 10 Aug 2011 07:51:32 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 10.08.2011 15:34, Jacob Carlborg wrote:
On 2011-08-10 12:42, Dmitry Olshansky wrote:
In case I failed to mention it before, I m working on the project
codenamed FReD that is aimed at ~100%* source level compatible overhaul
of std.regex, that uses better implementation techniques, provides
modern Unicode support and common syntax riches.
I think it's time for a public beta release, since it _should_ be ready
for mainstream usage. There are some rough edges, and a couple issues
that I'm aware of but they are nowhere in realistic use cases.
In order to avoid unexpected regressions I'd be glad if current
std.regex users do try it for their projects/tests.
To get a small no-crap-included beta package see download section of
https://github.com/blackwhale/FReD for .7zs.
I'll upload newer packages as bugs get exposed and fixed.
Alternatively,
if you a comfortable with git you may just git clone entire repo. Some
helpful notes (same as README) can be found here :
https://github.com/blackwhale/FReD/wiki/Beta-release
Caveats:
In order for it compile a tiny change to 2.054 source is needed (no
need
to recompile Phobos! it's only in templates):
patch std.algorithm.cmp according to this diff
https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4631
https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4633
and to get CTFE features working add if(!__ctfe) listed in the next
diff
on the same webpage.
(this is already upstream, so if you're using a fork of phobos just
pull
this in)
* some API problems might lead to a breaking change, though it didn't
happen in this release
I have a suggestion, make RegexMatch implicitly convertible to bool,
indicating if there was a match or not.
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Without actually looking at the code, why wouldn't something like this
work?
struct RegexMatch
{
...
string toString() {...}
opCast(T : bool)() {...}
}
This isn't an implicit cast, but it will work for conditional statements.
-Steve
Re: path tracing benchmark
Trass3r: Is there a more convenient way to get LTO with LDC? This is the best/only one I have found for LDC1. Feel free to search for something better/shorter (and tell me if you find it, please). Bye, bearophile
Re: Curl wrapper
On 10/08/11 09.49, Jonathan M Davis wrote: On Wednesday, August 10, 2011 09:16:35 Jonas Drewsen wrote: Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? LOL. No, I'm not the one who schedules reviews. We don't really have anyone who does that. We don't even have altogether formal queue. People post when they have something for review, and we roughly keep track of what's supposed to be next in the queue based on what gets posted when and what's actually ready for review after whatever is currently up for review is done being reviewed. Someone then volunteers to be the review manager for whatever is being reviewed, and they handle posting about the review and counting the votes and whatnot. I _did_ volunteer to be the review manager for the curl wrapper when you last brought it up for review, though you never responded about that and std.path ended up getting reviewed first, since Lars was back from vacation. Yeah sorry about not getting back earlier. Been on vacation and other stuff - no excuse though. I'll wait for Jose to reply whether he is ready with the std.log and if he is not I guess I can post the curl wrapper review info. Btw. didn't Andrei implement a std.log module as well recently? Now, there are a few items which are in the review queue at the moment. We should probably have a page somewhere which keeps track of the review queue more formally, but we don't at the moment. The whole thing is fairly informal. However, if I recall correctly, the items which are supposedly ready for review are the new std.log and the curl wrapper. Also, Jesse Phillips has a module for parsing CSV files which may or may not be ready for review (his post on it made it clear that he was looking to have it reviewed soon, but it wasn't entirely clear whether it was actually ready for a formal review). There are some other items which I believe are at least close to being ready for review (e.g. Robert Jacques has done some work on revising std.json), but I'm not aware of anything else which is actually ready for review. So, that leaves std.log and the curl wrapper. I believe that std.log has been the queue longer, so if Jose is actually ready for it to be reviewed now (he was on vacation, which is why it hasn't been reviewed yet), then that should be reviewed before the curl wrapper, but if he's not ready, and you're ready for the curl wrapper to be reviewed, then the curl wrapper should be reviewed next. - Jonathan M Davis
Re: path tracing benchmark
Am 10.08.2011, 14:54 Uhr, schrieb bearophile bearophileh...@lycos.com: Trass3r: Is there a more convenient way to get LTO with LDC? This is the best/only one I have found for LDC1. Feel free to search for something better/shorter (and tell me if you find it, please). Well, obviously you need to install the gold linker and that llvm plugin. But I don't know how to go on after that. LDC does have -O4 and -O5 switches but they probably don't work?!
Re: Curl wrapper
On 10/08/11 11.14, Johannes Pfau wrote: Jonas Drewsen wrote: Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? Regards, Jonas Sorry, I wanted to post this earlier but then I totally forgot about it, so here's a last minute request: Could you add proxy support to the wrapper? All of CURLOPT_PROXY CURLOPT_PROXYPORT and CURLOPT_PROXYTYPE should be available. (The 'combined' CURLOPT_PROXY since 7.21.7 is too new, that's not even in the current ubuntu) Also, although it'd break encapsulation, I think the curl handle should be accessible from the Http and Curl structs. But that's debatable, so I'll brink it up in the review thread where it should be discussed first. I'll put it on the list of review comments if that is ok. I would very much like to gather as much review input as possible before running over the code once more. /Jonas
Review Queue Update?
The review of the new std.path is drawing to a close and it looks like another success! (Congratulations, Lars.) Lately, though, the queue of stuff to review has been getting rather long, admittedly a problem we'd like to have. I want to get a list of stuff that's ready or will be ready in short order, so we can prioritize. I know at least the following are ready or fairly close. Please list anything else: std.regionallocator (A segmented stack memory allocator, by me. I'd like to fast-track this because it's being used in the GSoC project I'm mentoring and getting it into Phobos would simplify things for us.) std.parallelalgorithm (A small module of parallel implementations of various algorithms, by me. This one can wait because it's pretty niche and nothing I know of depends on it.) std.process (New and much improved, by Steve Schveighoffer and IIRC Lars Kylingstad also contributed. Personally I'd like this to be given a high priority b/c the old std.process sucks so much and it's been waiting so long for compiler bugs to get fixed, etc.) std.log (Logging module by Jose Armando Garcia.) curl wrapper (By Jonas Drewsen.) std.variant (Major improvements, by Robert Jacques.)
Re: Std.path: Final Vote
Am 10.08.2011, 13:19 Uhr, schrieb Lars T. Kyllingstad public@kyllingen.nospamnet: On Fri, 05 Aug 2011 09:26:39 -0400, dsimcha wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. I would just like to remind everyone that there are now only two days left until voting ends. While I am certainly pleased that everyone has so far voted yes, I am a bit worried that so few people have voted in the first place. This module may become a permanent part of D's standard library. If you care about this, either way, please cast your vote now. -Lars Yes, if you correct Some characters of pattern have special a meaning ;)
Re: path tracing benchmark
LDC does have -O4 and -O5 switches but they probably don't work?! Had a quick look at the source, no indications that -O4 and O5 do anything more than -O3.
Re: Review Queue Update?
On Wed, 10 Aug 2011 09:22:46 -0400, dsimcha dsim...@yahoo.com wrote: std.process (New and much improved, by Steve Schveighoffer and IIRC Lars Kylingstad also contributed. Personally I'd like this to be given a high priority b/c the old std.process sucks so much and it's been waiting so long for compiler bugs to get fixed, etc.) I just want to get this one straight, *Lars* is the main author, I just contributed a Windows implementation for his interface :) BTW, this one has to be delayed until Walter fixes the DMC runtime... -Steve
Re: DB ORM
zhang wrote: About ORM, the Python has SQLObject (http://sqlobject.org/), the Java has Hibernate (http://www.hibernate.org/), and the C# has NHibernate and Entity Framework (http://msdn.microsoft.com/en-us/data/aa937723). The D maybe also need one. Glad to see someone being interesting in this. I think D needs user defined attributes first.
Re: Review Queue Update?
On Wed, 10 Aug 2011 09:22:46 -0400, dsimcha wrote: The review of the new std.path is drawing to a close and it looks like another success! (Congratulations, Lars.) Lately, though, the queue of stuff to review has been getting rather long, admittedly a problem we'd like to have. I want to get a list of stuff that's ready or will be ready in short order, so we can prioritize. I've got a CSV parser which is close. I just want to get an unofficial review of the documentation, but I've thought of one thing that I should document better.
Re: [GSOC] regular expressions beta is here
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Right now due to a carry over bug from std.regex (interface thing)
writln(m) will just do a stackoverflow, m.hit however works.
No, that won't be any problem:
struct Foo
{
bool b;
alias b this;
}
auto f = Foo();
static assert(is(typeof(f) == Foo));
The above assert passes as expected.
Aren't there a lot of things that should be declared as private in the
fred.d module?
Yes, it's a side effect of me having a lot of debugging tool that do
need these internals. If only package protection attribute of something
was working
Not to mention that the whole module should work in SafeD with a couple
of @trusted here and there.
Ok, I see.
--
/Jacob Carlborg
Re: [GSOC] regular expressions beta is here
On Wed, 10 Aug 2011 14:44:44 +0300, Dmitry Olshansky dmitry.o...@gmail.com wrote: Yes, I've dubbed it static regex. In fact it will be something similar to this, though it will do a heap allocation for backtracking points, on first call to match. Heap allocations are definetly going away in final release. Awesome stuff. D's codegen abilities have the potential to put regex matching way ahead of any C/C++ libraries that don't JIT or stuff like that. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Review Queue Update?
Where is this new std.process btw.? Is it on github or somewhere?
Re: [GSOC] regular expressions beta is here
On 10.08.2011 16:54, Steven Schveighoffer wrote:
On Wed, 10 Aug 2011 07:51:32 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 10.08.2011 15:34, Jacob Carlborg wrote:
On 2011-08-10 12:42, Dmitry Olshansky wrote:
In case I failed to mention it before, I m working on the project
codenamed FReD that is aimed at ~100%* source level compatible
overhaul
of std.regex, that uses better implementation techniques, provides
modern Unicode support and common syntax riches.
I think it's time for a public beta release, since it _should_ be
ready
for mainstream usage. There are some rough edges, and a couple issues
that I'm aware of but they are nowhere in realistic use cases.
In order to avoid unexpected regressions I'd be glad if current
std.regex users do try it for their projects/tests.
To get a small no-crap-included beta package see download section of
https://github.com/blackwhale/FReD for .7zs.
I'll upload newer packages as bugs get exposed and fixed.
Alternatively,
if you a comfortable with git you may just git clone entire repo. Some
helpful notes (same as README) can be found here :
https://github.com/blackwhale/FReD/wiki/Beta-release
Caveats:
In order for it compile a tiny change to 2.054 source is needed (no
need
to recompile Phobos! it's only in templates):
patch std.algorithm.cmp according to this diff
https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4631
https://github.com/D-Programming-Language/phobos/pull/176/files#L0L4633
and to get CTFE features working add if(!__ctfe) listed in the next
diff
on the same webpage.
(this is already upstream, so if you're using a fork of phobos just
pull
this in)
* some API problems might lead to a breaking change, though it didn't
happen in this release
I have a suggestion, make RegexMatch implicitly convertible to bool,
indicating if there was a match or not.
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Without actually looking at the code, why wouldn't something like this
work?
struct RegexMatch
{
...
string toString() {...}
opCast(T : bool)() {...}
}
This isn't an implicit cast, but it will work for conditional statements.
Thanks, I'll give it a try.
--
Dmitry Olshansky
Re: Review Queue Update?
On Wed, 10 Aug 2011 18:07:53 +0300, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Where is this new std.process btw.? Is it on github or somewhere? I believe this is it: https://github.com/kyllingstad/phobos/blob/new-std-process/std/process.d -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Any D developer at GDC europe next week ?
Am 10.08.2011, 10:20 Uhr, schrieb Stephan s...@extrawurst.org: On 09.08.2011 18:52, Trass3r wrote: Hi perhaps there is a chance to talk about D in the game industry ?! I will be there. Convince Crytek to switch to D ;) I will do my best :) -Stephan Start by asking what programming language they use. C++? Oh rly? Then ask them what they like and don't like about it. And when they feel really pity about their current situation with C++ you drop an innocent side-note about how you use D and how arrays, templates and other stuff works there. Also if you meet the founders there talking about what a wonderful city Istanbul is may get you a foot in the door.
Re: Review Queue Update?
On Wed, 10 Aug 2011 11:12:49 -0400, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Wed, 10 Aug 2011 18:07:53 +0300, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Where is this new std.process btw.? Is it on github or somewhere? I believe this is it: https://github.com/kyllingstad/phobos/blob/new-std-process/std/process.d Just to warn you, the windows port *does not work* because of a flaw in how DMC handles pipes. Other OSes should work. -Steve
Re: Review Queue Update?
dsimcha dsim...@yahoo.com wrote in message news:j1u0o8$2gdg$1...@digitalmars.com... The review of the new std.path is drawing to a close and it looks like another success! (Congratulations, Lars.) Lately, though, the queue of stuff to review has been getting rather long, admittedly a problem we'd like to have. I want to get a list of stuff that's ready or will be ready in short order, so we can prioritize. I know at least the following are ready or fairly close. Please list anything else: std.regionallocator (A segmented stack memory allocator, by me. I'd like to fast-track this because it's being used in the GSoC project I'm mentoring and getting it into Phobos would simplify things for us.) std.parallelalgorithm (A small module of parallel implementations of various algorithms, by me. This one can wait because it's pretty niche and nothing I know of depends on it.) std.process (New and much improved, by Steve Schveighoffer and IIRC Lars Kylingstad also contributed. Personally I'd like this to be given a high priority b/c the old std.process sucks so much and it's been waiting so long for compiler bugs to get fixed, etc.) std.log (Logging module by Jose Armando Garcia.) curl wrapper (By Jonas Drewsen.) std.variant (Major improvements, by Robert Jacques.) I hope I'm not venturing too much into bikeshed territiory here, but FWIW, I've been really, really looking forward to std.process and the curl wrapper.
Re: Review Queue Update?
Am 10.08.2011, 15:51 Uhr, schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 10 Aug 2011 09:22:46 -0400, dsimcha dsim...@yahoo.com wrote: std.process (New and much improved, by Steve Schveighoffer and IIRC Lars Kylingstad also contributed. Personally I'd like this to be given a high priority b/c the old std.process sucks so much and it's been waiting so long for compiler bugs to get fixed, etc.) I just want to get this one straight, *Lars* is the main author, I just contributed a Windows implementation for his interface :) BTW, this one has to be delayed until Walter fixes the DMC runtime... -Steve Please shed some light on the new std.process! Is this what I expect it is? Does it allow IPC through a pipe between parent and child process and reading/writing by line as well as single characters? Does it allow polling for new data?
Re: Std.path: Final Vote
On Wed, 2011-08-10 at 11:19 +, Lars T. Kyllingstad wrote: [ . . . ] I would just like to remind everyone that there are now only two days left until voting ends. While I am certainly pleased that everyone has so far voted yes, I am a bit worried that so few people have voted in the first place. This module may become a permanent part of D's standard library. If you care about this, either way, please cast your vote now. I suspect there are many people who have not followed the debate nor reviewed the code who are therefore taking the view that to cast a vote would be somewhat out of order. I think that as long as those people who have been active in the evaluation have cast a vote, and Walter et al. are happy that due process has been followed, then even with what appears to be a low turn out, given that it is yes, nem con, becoming part of the standard library is a sensible natural consequence. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: PSP emulator written in D
KennyTM~: These exceptions are not common or basic. You are right, sorry. I meant common ones like this: http://d.puremagic.com/issues/show_bug.cgi?id=6410 Bye, bearophile
Re: Std.path: Final Vote
== Quote from Russel Winder (rus...@russel.org.uk)'s article --=-/EZ9N8/9sZ9dsJoreonX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 2011-08-10 at 11:19 +, Lars T. Kyllingstad wrote: [ . . . ] I would just like to remind everyone that there are now only two days=20 left until voting ends. While I am certainly pleased that everyone has= =20 so far voted yes, I am a bit worried that so few people have voted in= =20 the first place. =20 This module may become a permanent part of D's standard library. If you= =20 care about this, either way, please cast your vote now. I suspect there are many people who have not followed the debate nor reviewed the code who are therefore taking the view that to cast a vote would be somewhat out of order. I think that as long as those people who have been active in the evaluation have cast a vote, and Walter et al. are happy that due process has been followed, then even with what appears to be a low turn out, given that it is yes, nem con, becoming part of the standard library is a sensible natural consequence. Yeah. IMHO, the voting process is mostly a formality, though a necessary one. If a module makes it to a vote, it's probably going to be overwhelmingly accepted, but that's because the process serves as an effective deterrent to crappy code making it to a vote, not because the vote isn't serving any useful purpose. It's kind of like Ph.D. thesis defenses in the U.S. Almost noone ever fails, but that's because noone ever defends their thesis until they're almost sure it would pass, not because the defense process is a useless rubber stamp.
Re: DB ORM
Am 10.08.2011, 16:01 Uhr, schrieb Piotr Szturmaj bncr...@jadamspam.pl: zhang wrote: About ORM, the Python has SQLObject (http://sqlobject.org/), the Java has Hibernate (http://www.hibernate.org/), and the C# has NHibernate and Entity Framework (http://msdn.microsoft.com/en-us/data/aa937723). The D maybe also need one. Glad to see someone being interesting in this. I think D needs user defined attributes first. When I think about all the attributes I set on fields in Java code for Hibernate you may actually be right. Even without inheritance and more arcane stuff I would expect to be able to define some relations between objects/tables, so associated data can be fetched either eagerly or lazily. Where lazily is the minimum, because eager may just as well load the whole database into memory. Then you get into the trouble of having n-to-m associations and the need for a cache. I believe it is a lot of work for a single person to create something of the quality of Hibernate. An intermediate step may be appropriate, where all the automatic glue is still done by the programmer. Caching, associations, inheritance and the like. The Persister looks to me like just that and with the CTFE abilities it could not have less overhead which is a selling point.
Re: [GSOC] regular expressions beta is here
On 10.08.2011 18:54, Jacob Carlborg wrote:
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Right now due to a carry over bug from std.regex (interface thing)
writln(m) will just do a stackoverflow, m.hit however works.
No, that won't be any problem:
struct Foo
{
bool b;
alias b this;
}
auto f = Foo();
static assert(is(typeof(f) == Foo));
The above assert passes as expected.
That may be all well, but try writeln on it, what will it print?
After some experience with alias this I had to conclude that it's rather
blunt tool, and I'd rather stay away of it.
Actually I like Steven's opCast suggestion, so that it works in
conditionals.
Aren't there a lot of things that should be declared as private in the
fred.d module?
Yes, it's a side effect of me having a lot of debugging tool that do
need these internals. If only package protection attribute of something
was working
Not to mention that the whole module should work in SafeD with a couple
of @trusted here and there.
Ok, I see.
--
Dmitry Olshansky
Re: [GSOC] regular expressions beta is here
Dmitry Olshansky: To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. When you write some English text you don't write a single block of text, you organize it into paragraphs, and paragraphs into chapters, chapters into sections, sections into books, etc. Time ago I have understood that paragraphs are very good in source code too. So I suggest you to add a blank line here and there inside your functions to separate them into paragraphs. I can't give you a style rule, you will need to create your own style, but often a function that's more than 10 lines line long needs one or more blank lines inside (some people say that every time you see one of such paragraphs in a function, especially if it has a comment before it, then you need to perform an extract method to improve the code. I believe this is a bad advice). I see no contracts in the code (I mean the ones with assert inside, instead of enforce). I suggest Walter to fix this situation. One idea is to include two versions of Phobos lib in the zip of the dmd distribution, one with asserts compiled in and one without, and let DMD import from the correct library according to the compilation flags. Some solution to this problem is getting urgent, because Phobos is growing without the use of one of the nicest features of D (contract programming). Solving this problem is more urgent than having an excellent regex library in Phobos. If people don't use contract programming much, is because you can't use it in Phobos. Bye, bearophile
Re: DB ORM
Piotr Szturmaj: I think D needs user defined attributes first. In past discussions I have seen three or more different ideas of what 'user defined attributes' need to be in D: - A person has suggested for them to be like Python decorators, this means function templates that take a function and wrap it in some way; - For me they are better thought as small extensions to the type system, to implement new simple things, mostly using static introspection. - You are probably thinking more about Java or C# style attributes. So I suggest you to write down what kind of user defined attributes you want in D, their semantics, usage and syntax. Bye, bearophile
Re: path tracing benchmark
On 10/08/2011 14:49, Trass3r wrote: LDC does have -O4 and -O5 switches but they probably don't work?! Had a quick look at the source, no indications that -O4 and O5 do anything more than -O3. They don't, there's no way to do LTO built into LDC. I seem to recall some conversation about adding it, I may just be remembering this thread though *g* -- Robert http://octarineparrot.com/
Re: DB ORM
zhang wrote: The D maybe also need one. Glad to see someone being interesting in this. You might want to look at class DataObject in database.d here: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff It's pretty minimal but it covers the cases that irk me most and should work with columns built from joins (at least on mysql).
Re: Std.path: Final Vote
On Fri, 05 Aug 2011 22:26:39 +0900, dsimcha dsim...@yahoo.com wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. Yes!!
Re: [GSOC] regular expressions beta is here
On 10.08.2011 20:02, bearophile wrote: Dmitry Olshansky: To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. When you write some English text you don't write a single block of text, you organize it into paragraphs, and paragraphs into chapters, chapters into sections, sections into books, etc. Time ago I have understood that paragraphs are very good in source code too. So I suggest you to add a blank line here and there inside your functions to separate them into paragraphs. I can't give you a style rule, you will need to create your own style, but often a function that's more than 10 lines line long needs one or more blank lines inside (some people say that every time you see one of such paragraphs in a function, especially if it has a comment before it, then you need to perform an extract method to improve the code. I believe this is a bad advice). While I haven't asked for review, I do appreciate comments. I have to say I did no cleanup or otherwise shape up the code, I'm still working on semantic side part of problems:) Honestly I can't get why you are so nervous about code style anyway, you seem to bring this up way to often. About spaces personally I dislike eating extra vertical space for clarity, curly braces on it's own line is already way too much. I see no contracts in the code (I mean the ones with assert inside, instead of enforce). I suggest Walter to fix this situation. One idea is to include two versions of Phobos lib in the zip of the dmd distribution, one with asserts compiled in and one without, and let DMD import from the correct library according to the compilation flags. Some solution to this problem is getting urgent, because Phobos is growing without the use of one of the nicest features of D (contract programming). Solving this problem is more urgent than having an excellent regex library in Phobos. If people don't use contract programming much, is because you can't use it in Phobos. Have to respectfully disagree on this, don't try to nail everything on contracts. They are nice but have little value over plain assert _unless_ we are talking about classes and _inheritance_, which isn't the case here. And there are lots of asserts here, but much more of input is enforced since it's totally expected to supply wrong pattern (or have an outside user to type in the pattern). Bye, bearophile -- Dmitry Olshansky
Re: [GSOC] regular expressions beta is here
On 2011-08-10 17:55, Dmitry Olshansky wrote:
On 10.08.2011 18:54, Jacob Carlborg wrote:
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Right now due to a carry over bug from std.regex (interface thing)
writln(m) will just do a stackoverflow, m.hit however works.
No, that won't be any problem:
struct Foo
{
bool b;
alias b this;
}
auto f = Foo();
static assert(is(typeof(f) == Foo));
The above assert passes as expected.
That may be all well, but try writeln on it, what will it print?
Hmm, it doesn't print anything, I think it looks like a bug in writeln.
After some experience with alias this I had to conclude that it's rather
blunt tool, and I'd rather stay away of it.
Actually I like Steven's opCast suggestion, so that it works in
conditionals.
Oh, I didn't know that it would work implicitly in conditionals. Then
I'm happy with opCast :)
--
/Jacob Carlborg
Re: [GSOC] regular expressions beta is here
On 2011-08-10 18:02, bearophile wrote: Dmitry Olshansky: To get a small no-crap-included beta package see download section of https://github.com/blackwhale/FReD for .7zs. When you write some English text you don't write a single block of text, you organize it into paragraphs, and paragraphs into chapters, chapters into sections, sections into books, etc. Time ago I have understood that paragraphs are very good in source code too. So I suggest you to add a blank line here and there inside your functions to separate them into paragraphs. I can't give you a style rule, you will need to create your own style, but often a function that's more than 10 lines line long needs one or more blank lines inside (some people say that every time you see one of such paragraphs in a function, especially if it has a comment before it, then you need to perform an extract method to improve the code. I believe this is a bad advice). I always add a blank line before and after statements. -- /Jacob Carlborg
Re: DB ORM
On 2011-08-10 16:01, Piotr Szturmaj wrote: zhang wrote: About ORM, the Python has SQLObject (http://sqlobject.org/), the Java has Hibernate (http://www.hibernate.org/), and the C# has NHibernate and Entity Framework (http://msdn.microsoft.com/en-us/data/aa937723). The D maybe also need one. Glad to see someone being interesting in this. I think D needs user defined attributes first. User defined attributes would be really nice but I'm quite certain that it would work without user defined attributes. Worst case scenario template mixins could be used to simulate attributes. -- /Jacob Carlborg
Re: path tracing benchmark
On 10/08/2011 17:43, Trass3r wrote: Am 10.08.2011, 18:16 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: On 10/08/2011 14:49, Trass3r wrote: Had a quick look at the source, no indications that -O4 and O5 do anything more than -O3. They don't, there's no way to do LTO built into LDC. I seem to recall some conversation about adding it, I may just be remembering this thread though *g* Why is there no way? Patches welcome ;) Can't LDC be modified to support gold+plugin just like clang? Of course it can - I said built into, not in. The only reason it's not there is because no one has written support for it. -- Robert http://octarineparrot.com/
Re: What library functionality would you most like to see in D?
On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games). -- Simen
Re: What library functionality would you most like to see in D?
On Sun, 31 Jul 2011 15:49:42 +0200, bearophile bearophileh...@lycos.com wrote: - std.operator: standard operators as functions, to be used with higher order functions; Nice idea. So simple yet so useful. -- Simen
Re: What library functionality would you most like to see in D?
On Tue, 02 Aug 2011 20:04:40 +0200, Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net wrote: I'm nearing completion on an arbitrary-precision floating point library, along with implementations of decimal32, decimal64 and decimal128 structs. Awesome. -- Simen
CTFE - compiling other languages inside D
With the recent ORM and RegEx projects dissecting SQL statements and
regular expressions turning them into D code, I am impressed by the
possibilities of CTFE. Where are the limitations to this system? An
unlikely example would be a C compiler within CTFE that takes a string of
C source code and turns it into a D mixin. Is that possible?
I have written a visualizer that is supposed to work on the web and as a
stand-alone application. So I chose JavaScript to implement it, since it
is the only programming language available to web developers across
platforms. Then I used Rhino JavaScript for Java, implemented a few web
APIs in Java (HTML canvas, AJAX) and had an applet for IE8 and older and a
standalone-application in one go. Rhino compiles JavaScript into Java
code, but from the untyped nature of JavaScript it is not possible to
optimize much there and it came down to writing a JavaScript to Java byte
code compiler for the authors of Rhino. So they cannot use the possibly
advanced optimization features of the actual Java compiler.
Now there is V8, the JavaScript engine in Chrome which is written in C++,
uses JIT compilation and profiling and is *very* fast. But if I wanted to
use D and speed was my only concern I would sacrifice some of the
ECMAScript standard:
- everything is typed
- code cannot be altered or generated on runtime (i.e. eval)
Some things may be difficult to do. In the following case the obj adds a
new field later on, so the for loop has to iterate over the first two
fields of that data type, excluding 'newField'.
var obj = { a : 1, b : text };
for (var key in obj) {
...
}
obj.newField = 0.5;
Another tricky case where there have to be two versions of foo for a and
b or a common type for a and b that includes a numeric field n and
a text field c. That means a and b would become objects of the same
type where the compiler would have to check if this is at all possible.
function foo(x) {
...
}
a = { n : 1 };
b = { c : 'w' };
foo(a);
foo(b);
At the end of the day it wouldn't be 100% ECMAScript any more, but it
would allow that code to compile in an optimized way and at the same time
run within a browser. Any standard ECMA feature that doesn't work would
result in an error message. This would probably also allow browsers to
apply more optimizations on the resulting code in terms of JIT
compilation. Here is a small snippet in JavaScript and in D:
function log(x) {
...
}
var x = 3;
x *= 1.2345;
arr = new Array(10);
for (var i = 0; i 10; ++i) arr[i] = i;
log(arr[5]);
---
function log(long x) { // we need an 'long' version of the log function
...
}
double x = 3; // x is later assigned a floating point number
x *= 1.2345;
long[10] arr; // the slots in this array are all assigned integral numbers
before any of them are read
for (int i = 0; i 10; ++i) arr[i] = i;
log(arr[5]);
Re: [GSOC] regular expressions beta is here
Dmitry Olshansky: Honestly I can't get why you are so nervous about code style anyway, you seem to bring this up way to often. I bring it often because many D programmers seem half blind to this problem. I am not willing to go to the extremes Go language goes to solve this problem, but I'd like more recognition of this problem in D programmers. A bit more common style is quite helpful to create an ecology of D programmers that share single modules. I guess D programmers are used to C/C++ languages, where there are not modules and where programs are usually made of many files. So they don't see why sharing single modules in the pool is so useful. About spaces personally I dislike eating extra vertical space for clarity, curly braces on it's own line is already way too much. Think about reading a book without the half lines between paragraphs. In code it's the same. Some empty lines are good to improve readability of the code. Curly braces are not always present, sometimes a paragraphs ends before or after or right on a curly brace. Have to respectfully disagree on this, don't try to nail everything on contracts. Contracts don't replace unittests, they complement each other. They are nice but have little value over plain assert _unless_ we are talking about classes and _inheritance_, which isn't the case here. It's easy to forget to test the output of a function, the out contracts help here. In structs the invariant helps you avoid forgetting to call manually a sanity test function every time you come in and out of a method. And there are lots of asserts here, but much more of input is enforced since it's totally expected to supply wrong pattern (or have an outside user to type in the pattern). The idea is to replace those enforces with asserts, and allow user programs to import Phobos stuff that still contain asserts (from a secondary Phobos lib). Enforces are for certain kinds of user code, I don't think they are fit in Phobos. Bye, bearophile
Re: What library functionality would you most like to see in D?
Simen Kjaeraas: Nice idea. So simple yet so useful. It's not an original idea, it's essentially a Phobos version of this Python standard library :-) http://docs.python.org/library/operator.html Bye, bearophile
Re: [GSOC] regular expressions beta is here
On Wed, 10 Aug 2011 12:46:25 -0400, Jacob Carlborg d...@me.com wrote: On 2011-08-10 17:55, Dmitry Olshansky wrote: After some experience with alias this I had to conclude that it's rather blunt tool, and I'd rather stay away of it. Actually I like Steven's opCast suggestion, so that it works in conditionals. alias this has lots of problems, but it doesn't mean it's *design* is blunt, just that the implementation of it is not too good. Oh, I didn't know that it would work implicitly in conditionals. Then I'm happy with opCast :) http://www.d-programming-language.org/operatoroverloading.html#Cast Note that it only works for structs (not sure if that return type is a struct or not...) -Steve
Re: [GSOC] regular expressions beta is here
bearophile: The thing is just because you call it a problem a lot doesn't mean everyone else sees it that way. A lot of us have many years of experience and just don't see it the same way you do.
Re: CTFE - compiling other languages inside D
Marco Leise wrote: An unlikely example would be a C compiler within CTFE that takes a string of C source code and turns it into a D mixin. Is that possible? It'd be a fair amount of work, but it should be possible. It's tempting to try to implement that as an alternative to D bindings modules. mixin include_C ( import(stdio.h) ); Turning Javascript into D is probably harder yet... but I still think it could be done. tbh though, I think you'd be better off using a javascript interpreter and duplicating a little bit of effort to optimize stuff. So you write it in javascript, then use a javascript engine in your distributable app. Functions that are cpu intensive are then rewritten in D so the script can call them and get better speed out of it.
Re: [GSOC] regular expressions beta is here
Adam D. Ruppe: A lot of us have many years of experience and just don't see it the same way you do. This you is a group that includes people like Guido V. Rossum, Rob Pike, Ken Thompson and R. Hettinger (they have feelings even stronger than mine on this topic). Bye, bearophile
Re: Std.path: Final Vote
On 8/10/11 9:46 AM, dsimcha wrote: == Quote from Russel Winder (rus...@russel.org.uk)'s article --=-/EZ9N8/9sZ9dsJoreonX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 2011-08-10 at 11:19 +, Lars T. Kyllingstad wrote: [ . . . ] I would just like to remind everyone that there are now only two days=20 left until voting ends. While I am certainly pleased that everyone has= =20 so far voted yes, I am a bit worried that so few people have voted in= =20 the first place. =20 This module may become a permanent part of D's standard library. If you= =20 care about this, either way, please cast your vote now. I suspect there are many people who have not followed the debate nor reviewed the code who are therefore taking the view that to cast a vote would be somewhat out of order. I think that as long as those people who have been active in the evaluation have cast a vote, and Walter et al. are happy that due process has been followed, then even with what appears to be a low turn out, given that it is yes, nem con, becoming part of the standard library is a sensible natural consequence. Yeah. IMHO, the voting process is mostly a formality, though a necessary one. If a module makes it to a vote, it's probably going to be overwhelmingly accepted, but that's because the process serves as an effective deterrent to crappy code making it to a vote, not because the vote isn't serving any useful purpose. It's kind of like Ph.D. thesis defenses in the U.S. Almost noone ever fails, but that's because noone ever defends their thesis until they're almost sure it would pass, not because the defense process is a useless rubber stamp. That makes horror stories of failed defenses all the more horrifying :o). Apologies for not voting. I'm not able to put time into a review now, but I'm confident that the process has shaken any major issues I might have had with the module. We've come a long way in terms of community and process. Andrei
Re: [GSOC] regular expressions beta is here
On 8/10/11 9:55 AM, Dmitry Olshansky wrote:
On 10.08.2011 18:54, Jacob Carlborg wrote:
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Right now due to a carry over bug from std.regex (interface thing)
writln(m) will just do a stackoverflow, m.hit however works.
No, that won't be any problem:
struct Foo
{
bool b;
alias b this;
}
auto f = Foo();
static assert(is(typeof(f) == Foo));
The above assert passes as expected.
That may be all well, but try writeln on it, what will it print?
After some experience with alias this I had to conclude that it's rather
blunt tool, and I'd rather stay away of it.
If alias this is any more blunt than regular subtyping (inheritance),
that would be a bug. Feel free to submit if you find such issues.
Andrei
Re: PSP emulator written in D
On 10/08/11 12:21 PM, bearophile wrote:
A 2D/3D/4D vector is good to have in Phobos. (Quaternion are optional).
Quaternions are important for fast 3D rotations, but yes, vectors are
most important.
SIMD intrinsics are obviously essential for AAA development.
The problem is they change as time goes. So instead of adding a ton of those
(ugly) intrinsics, I suggest to add a meta-feature to D: a syntax to write
inlin-able asm expressions (as present in LDC). With this syntax, SIMD
intrinsics become library (even Phobos) code to standardize.
The problem with that approach is that the compiler doesn't know about
them and will likely have trouble optimising. GCC will optimise SIMD
intrinsic math in the same way that it optimises scalar math.
Also, unless I'm mistaken, you can't use inline assembly to define a
vector type whose storage is an xmm register. In GCC, you'd do
typedef __m128 Vec4;
or at least
struct Vec4 { __m128 m_xyzw; };
This ensures that when you return them or pass them into a function then
they are passed in registers and don't have to go through memory. Can
you do that in LDC? (I'm not familiar with it).
I had to modify my druntime to print out when allocations where happening to find
them (most were those static array initialisations that I often talk about).
This is useful. Why don't you create a patch that (when a specific compiler
switch is on) lists at compile-time all heap allocations and closure
allocations of a compilation unit?
I will do if/when I find time.
Re: Std.path: Final Vote
On Fri, 05 Aug 2011 16:26:39 +0300, dsimcha dsim...@yahoo.com wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. Yes! -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [GSOC] regular expressions beta is here
On 8/10/11 10:46 AM, Jacob Carlborg wrote:
On 2011-08-10 17:55, Dmitry Olshansky wrote:
On 10.08.2011 18:54, Jacob Carlborg wrote:
Interesting idea, one problem with it is that I want this:
auto m = match(bleh, bleh);
writeln(m);
to actually print bleh, not true
Right now due to a carry over bug from std.regex (interface thing)
writln(m) will just do a stackoverflow, m.hit however works.
No, that won't be any problem:
struct Foo
{
bool b;
alias b this;
}
auto f = Foo();
static assert(is(typeof(f) == Foo));
The above assert passes as expected.
That may be all well, but try writeln on it, what will it print?
Hmm, it doesn't print anything, I think it looks like a bug in writeln.
After some experience with alias this I had to conclude that it's rather
blunt tool, and I'd rather stay away of it.
Actually I like Steven's opCast suggestion, so that it works in
conditionals.
Oh, I didn't know that it would work implicitly in conditionals. Then
I'm happy with opCast :)
That's pretty cool actually because it naturally extends the built-in
approach. When you do e.g. if (pointer) that's really equivalent to if
(cast(bool) pointer) and so on.
Andrei
Re: Curl wrapper
On 10/08/11 09.49, Jonathan M Davis wrote: On Wednesday, August 10, 2011 09:16:35 Jonas Drewsen wrote: Hi, I believe the curl wrapper is ready for a first round of reviews. If I remember correctly it is Jonathan who schedules the reviews. So Jonathan: Do you know when this could fit in? LOL. No, I'm not the one who schedules reviews. We don't really have anyone who does that. We don't even have altogether formal queue. People post when they have something for review, and we roughly keep track of what's supposed to be next in the queue based on what gets posted when and what's actually ready for review after whatever is currently up for review is done being reviewed. Someone then volunteers to be the review manager for whatever is being reviewed, and they handle posting about the review and counting the votes and whatnot. I _did_ volunteer to be the review manager for the curl wrapper when you last brought it up for review, though you never responded about that and std.path ended up getting reviewed first, since Lars was back from vacation. Yeah sorry about not getting back earlier. Been on vacation and other stuff - no excuse though. I'll wait for Jose to reply whether he is ready with the std.log and if he is not I guess I can post the curl wrapper review info. Btw. didn't Andrei implement a std.log module as well recently? He was, and then other people started doing it at the same time, and ultimately, Jose ended up doing one which is supposed to be at least somewhat based on what Andrei was doing IIRC, but I haven't really paid much attention to the details, so I don't know quite what the API or implementation looks like at this point. - Jonathan M Davis
Re: [GSOC] regular expressions beta is here
On 10.08.2011 21:11, bearophile wrote: Dmitry Olshansky: Honestly I can't get why you are so nervous about code style anyway, you seem to bring this up way to often. I bring it often because many D programmers seem half blind to this problem. I am not willing to go to the extremes Go language goes to solve this problem, but I'd like more recognition of this problem in D programmers. A bit more common style is quite helpful to create an ecology of D programmers that share single modules. I guess D programmers are used to C/C++ languages, where there are not modules and where programs are usually made of many files. So they don't see why sharing single modules in the pool is so useful. About spaces personally I dislike eating extra vertical space for clarity, curly braces on it's own line is already way too much. Think about reading a book without the half lines between paragraphs. In code it's the same. Some empty lines are good to improve readability of the code. Curly braces are not always present, sometimes a paragraphs ends before or after or right on a curly brace. Braces *are* paragraphs of code, with proper indention it's more then enough to fell the structure. If I really need to stop in the middle function, it's to explain something, then a single line of comment instead of meaningless empty line (which leaves reader clueless as to why) is good enough. Except that I'm not opposed to spaces at global scope. Have to respectfully disagree on this, don't try to nail everything on contracts. Contracts don't replace unittests, they complement each other. unittest != assert, though the former do contain asserts. They are nice but have little value over plain assert _unless_ we are talking about classes and _inheritance_, which isn't the case here. It's easy to forget to test the output of a function, the out contracts help here. In structs the invariant helps you avoid forgetting to call manually a sanity test function every time you come in and out of a method. And there are lots of asserts here, but much more of input is enforced since it's totally expected to supply wrong pattern (or have an outside user to type in the pattern). The idea is to replace those enforces with asserts, and allow user programs to import Phobos stuff that still contain asserts (from a secondary Phobos lib). Enforces are for certain kinds of user code, I don't think they are fit in Phobos. No gonna work, file I/O is certainly in Phobos, as are network sockets, etc. You can't assert that something external won't fail. While you'd normally assert on your local logical invariants. As for other things I thought e.g. ranges are already hooked on asserts, as much as other templates. If you have a list of modules where you find the lack of compiled in contracts/asserts unbearable, do tell. I hate being drugged in these discussions, but just can't resist. -- Dmitry Olshansky
Re: PSP emulator written in D
Peter Alexander: Can you do that in LDC? (I'm not familiar with it). They can't do that, I think: http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions I will do if/when I find time. Good. This enhancement request asks for just closures, but listing general heap allocations too is possible: http://d.puremagic.com/issues/show_bug.cgi?id=5070 Regarding your problem of the static array initialisations, it will be eventually fixed, I presume. Don has said it's not too much hard to fix, and I think it's worth fixing. Bye, bearophile
Re: CTFE - compiling other languages inside D
On 8/10/11 11:09 AM, Marco Leise wrote: With the recent ORM and RegEx projects dissecting SQL statements and regular expressions turning them into D code, I am impressed by the possibilities of CTFE. Where are the limitations to this system? An unlikely example would be a C compiler within CTFE that takes a string of C source code and turns it into a D mixin. Is that possible? Yah, that would be possible (albeit difficult). I think, however, that better applications of CTFE are not for translating full-blown languages into D. Instead, the best added value would be to translate small DSLs into D code. Examples include: * regex (I'm very glad Dmitry found the time to implement that - static regexen will long serve as a poster child of CTFE's power); * SQL - embedded SQL integrated perfectly with D data would be awesome and relatively easy to define; * Tokenizers (think lex); * Parsers (think yacc, antlr etc); * String interpolation (think Python's format, printf-style format parsed statically etc); * Make :o); * Protocol description; * Automata, transducers of various kinds; * and more. I hope Dmitry's work will mark a growing trend of defining DSLs in D. Andrei
Re: What library functionality would you most like to see in D?
On 10.08.2011 19:02, Simen Kjaeraas wrote: On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games). Second the full OS bindings. etc\c\win32 would be really nice. You'll not get cross platform support, but at least you have it handy.
Re: [GSOC] regular expressions beta is here
On Wed, 10 Aug 2011 20:59:27 +0300, Dmitry Olshansky dmitry.o...@gmail.com wrote: About spaces personally I dislike eating extra vertical space for clarity, curly braces on it's own line is already way too much. Think about reading a book without the half lines between paragraphs. In code it's the same. Some empty lines are good to improve readability of the code. Curly braces are not always present, sometimes a paragraphs ends before or after or right on a curly brace. Braces *are* paragraphs of code, with proper indention it's more then enough to fell the structure. If I really need to stop in the middle function, it's to explain something, then a single line of comment instead of meaningless empty line (which leaves reader clueless as to why) is good enough. Except that I'm not opposed to spaces at global scope. I agree with bearophile; I find code that leaves a blank line between closely-related lines make the code much more readable. I don't understand what's with the craving for maximum vertical terseness either, but that may be because the resolution of my primary monitor is currently 1200x1920 :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: CTFE - compiling other languages inside D
On 8/10/11 2:09 PM, Marco Leise wrote: With the recent ORM and RegEx projects dissecting SQL statements and regular expressions turning them into D code, I am impressed by the possibilities of CTFE. Where are the limitations to this system? An unlikely example would be a C compiler within CTFE that takes a string of C source code and turns it into a D mixin. Is that possible? I think it's possible, though CTFE can't access outside resources. In my ideal language with CTFE capabilites, you say how to connect to the database and at compile-time the classes are generated from that.
Re: [GSOC] regular expressions beta is here
On 10.08.2011 22:11, Vladimir Panteleev wrote: On Wed, 10 Aug 2011 20:59:27 +0300, Dmitry Olshansky dmitry.o...@gmail.com wrote: About spaces personally I dislike eating extra vertical space for clarity, curly braces on it's own line is already way too much. Think about reading a book without the half lines between paragraphs. In code it's the same. Some empty lines are good to improve readability of the code. Curly braces are not always present, sometimes a paragraphs ends before or after or right on a curly brace. Braces *are* paragraphs of code, with proper indention it's more then enough to fell the structure. If I really need to stop in the middle function, it's to explain something, then a single line of comment instead of meaningless empty line (which leaves reader clueless as to why) is good enough. Except that I'm not opposed to spaces at global scope. I agree with bearophile; I find code that leaves a blank line between closely-related lines make the code much more readable. I don't understand what's with the craving for maximum vertical terseness either, but that may be because the resolution of my primary monitor is currently 1200x1920 :) Lucky you, hm... probably turning my monitor on 90 degrees can get me in this league of abundant vertical space :) -- Dmitry Olshansky
Re: CTFE - compiling other languages inside D
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:j1ufc0$avd$1...@digitalmars.com...
Marco Leise wrote:
An unlikely example would be a C compiler within CTFE that takes a
string of C source code and turns it into a D mixin. Is that
possible?
It'd be a fair amount of work, but it should be possible.
It's tempting to try to implement that as an alternative to D
bindings modules.
mixin include_C ( import(stdio.h) );
It's a neat possibility, but the downside of that approach, I suspect, is
that it may slow down compilation.
With that approach, stdio.h has to be processed *every* time your program
is compiled, not just whenever stdio.h is changed (which is what you would
get if the conversion were done with a separate tool and a proper
buildsystem). Also, I'm sure that CTFE is probably slower than running an
already compiled tool. It would have to be slower, since it *is*
interpreted, after all.
This is another reason why CTFE really needs to support IO access (I really
believe the strict adherance to CTFE must be *guaranteed* stateless is a
mistake. It's right to strongly discourage it, but making the ban this
strict is taking things too far - similar to Java's ban on pointers). Then,
include_C could be implemented roughly like this:
string include_C(string filename)
{
auto cache = filename~.cache;
if(exists(cache) timestamp(cache) = timestamp(filename))
return loadFile(cache);
else
{
auto result = convert_C(loadFile(filename));
saveFile(cache, result);
return result;
}
}
string convert_C(string src)
{
// Do the conversion, possibly even by invoking a pre-compiled tool.
}
// Only gets processed if stdio.h has changed
mixin( include_C_file(stdio.h) );
The other big benefit, of course, if that we'd finally get compile-time
write*() for free.
This would also open the door for a CTFE/library-based buildsystem that
doesn't require a dedicated makefile or equivalent, which is an
interesting prospect.
Re: Std.path: Final Vote
On 8/5/11 7:26 AM, dsimcha wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. My vote is yes, with a few advisory comments. Comments on the documentation: * This module is used to parse path strings. - This module is used to manipulate path strings. * perform any I/O - perform any actual file system actions * use std.file.isDir and std.file.exists - use the XREF macro to generate cross-reference links. * backslashes on this platform - backslashes on that platform * The result of calling a function on an ill-formed path is undefined. This simplifies documentation but is a bit extreme. We could and should specify the behavior for strings that don't look quite like paths. * BTW we should have a validPath() function that tells whether a string looks like a valid path or not. * Add example: assert (baseName(dir/file.ext, .xyz) == file.ext); * defaultExtension - setDefaultExtension? * absolutePath calls getcwd(), negating the assertion in the beginning that there's no real directory access going on. * absolutePath and others use string, others use generic characters. Why? (This is my strongest comment.) * filenameCharCmp and filenameCmp - why long and not int? * Example in expandTilde uses odd ALL_UPERCASE variable names. Comments on the implementation: * We're increasingly moving towards consolidating imports into one. * . is hardcoded as a symbol for the current dir. * Would be interesting to figure what it would take to make pathSplitter reuse splitter. * Misalignment in lines 2195--2238. I think you don't need the extra scope there anyway, but if you do, don't make a special rule for that case - obey normal brace indentation. Andrei
Re: [GSOC] regular expressions beta is here
Dmitry Olshansky:
Braces *are* paragraphs of code,
They sometimes are, but inside functions there are other kinds of paragraphs.
As an example, this is first-quality C code (partially written by R. Hettinger):
http://hg.python.org/cpython/file/d5b274a0b0a5/Modules/_collectionsmodule.c
If you take a random function from that page, like:
653 static int
654 deque_del_item(dequeobject *deque, Py_ssize_t i)
655 {
656 PyObject *item;
657
658 assert (i = 0 i deque-len);
659 if (_deque_rotate(deque, -i) == -1)
660 return -1;
661
662 item = deque_popleft(deque, NULL);
663 assert (item != NULL);
664 Py_DECREF(item);
665
666 return _deque_rotate(deque, i);
667 }
You see a blank line after Py_DECREF(item); despite there is no closing
brace. The purpose of those blank lines is to help the person that reads the
code to tell apart the various things done by that function. This is C code is
well written.
No gonna work, file I/O is certainly in Phobos, as are network sockets,
etc. You can't assert that something external won't fail.
OK.
I hate being drugged in these discussions, but just can't resist.
I am sorry, but thank you for answering :-)
Bye,
bearophile
Re: Any D developer at GDC europe next week ?
Marco Leise marco.le...@gmx.de wrote in message news:op.vzz7f9b29y6...@dslb-088-070-152-209.pools.arcor-ip.net... Am 10.08.2011, 10:20 Uhr, schrieb Stephan s...@extrawurst.org: On 09.08.2011 18:52, Trass3r wrote: Hi perhaps there is a chance to talk about D in the game industry ?! I will be there. Convince Crytek to switch to D ;) I will do my best :) -Stephan Start by asking what programming language they use. C++? Oh rly? Then ask them what they like and don't like about it. And when they feel really pity about their current situation with C++ you drop an innocent side-note about how you use D and how arrays, templates and other stuff works there. Also if you meet the founders there talking about what a wonderful city Istanbul is may get you a foot in the door. That's actually very similar to an approach I've heard about (LEAP - Listen Empathize Agree Partner) for dealing with patients of psychological disorders that involve denial (addiction, schizophrenia, etc...). I suppose you could consider liking C++ a psychological disorder ;)
Re: [GSOC] regular expressions beta is here
Am 10.08.2011, 19:24 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: bearophile: The thing is just because you call it a problem a lot doesn't mean everyone else sees it that way. A lot of us have many years of experience and just don't see it the same way you do. I think a blank line makes code easier on the eyes. When you scroll over it you recognize easily where you are from the size and shape of the paragraphs. So I totally understand that. On the other hand my laptop screen is 1280x800 and I also feel that sometimes I think I scroll over the end of a function body when there is just a blank line in a block of code. So usually I go with the approach of inserting a comment line instead of a blank line, which is usually italic and in a brighter color. If I was working on a Phobos module I would try to mime existing code style (and probably find out that there is no common style :p ). Anyway such things can be up to a vote just like the idea to not use single capital letters only for template type placeholders (i.e. T, S). Google's code style wiki is nice. It lists all the rules and also offers an explanation. We can have that for Phobos, too. So topics like these don't come up over and over again. The D style guide is a good start: http://www.digitalmars.com/d/2.0/dstyle.html
DIP11
What is the status of DIP11 http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11 Has anyone started implementing it? Has it been rejected? /Jonas
Re: [GSOC] regular expressions beta is here
On Wednesday, August 10, 2011 21:42:01 Marco Leise wrote: Am 10.08.2011, 19:24 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: bearophile: The thing is just because you call it a problem a lot doesn't mean everyone else sees it that way. A lot of us have many years of experience and just don't see it the same way you do. I think a blank line makes code easier on the eyes. When you scroll over it you recognize easily where you are from the size and shape of the paragraphs. So I totally understand that. On the other hand my laptop screen is 1280x800 and I also feel that sometimes I think I scroll over the end of a function body when there is just a blank line in a block of code. So usually I go with the approach of inserting a comment line instead of a blank line, which is usually italic and in a brighter color. If I was working on a Phobos module I would try to mime existing code style (and probably find out that there is no common style :p ). Anyway such things can be up to a vote just like the idea to not use single capital letters only for template type placeholders (i.e. T, S). Google's code style wiki is nice. It lists all the rules and also offers an explanation. We can have that for Phobos, too. So topics like these don't come up over and over again. The D style guide is a good start: http://www.digitalmars.com/d/2.0/dstyle.html This sort of thing has been discussed by the Phobos dev team previously, and the general consensus was not to enforce much in the way of formatting in a style guide. There a few things that were agreed upon (such as always putting braces on their own line), but on the whole, the style guide is supposed to focus on the API (so, things like function and variable names) rather than how code is formatted. I have an update to the style guide as a pull request which is currently being reviewed to make sure that the style guide on the site is in line with what we do: https://github.com/D-Programming-Language/d-programming-language.org/pull/16 But I'm certain that you're not going to get the Phobos devs to agree on a style guide like Bearophile wants. And honestly, I'm a bit tired of the topic coming up. The does need some updates, but it's mostly correct. It's essentially what we've decided on, and I don't see any reason to keep discussing it over and over. Personally, I'd prefer that Dmitry had more blank lines in his code, but it's up to him how he does that as long as his code falls within the rules set down by the D style guide. And for any of his code which isn't going into Phobos, it's completely up to him how to format it. - Jonathan M Davis
Re: [GSOC] regular expressions beta is here
On 10.08.2011 22:12, Jonathan M Davis wrote: There a few things that were agreed upon (such as always putting braces on their own line), There is? Parallelism and json uses braces on the same line.
Re: CTFE - compiling other languages inside D
Am 10.08.2011, 20:34 Uhr, schrieb Nick Sabalausky a@a.a:
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:j1ufc0$avd$1...@digitalmars.com...
Marco Leise wrote:
An unlikely example would be a C compiler within CTFE that takes a
string of C source code and turns it into a D mixin. Is that
possible?
It'd be a fair amount of work, but it should be possible.
It's tempting to try to implement that as an alternative to D
bindings modules.
mixin include_C ( import(stdio.h) );
It's a neat possibility, but the downside of that approach, I suspect, is
that it may slow down compilation.
With that approach, stdio.h has to be processed *every* time your
program
is compiled, not just whenever stdio.h is changed (which is what you
would
get if the conversion were done with a separate tool and a proper
buildsystem). Also, I'm sure that CTFE is probably slower than running an
already compiled tool. It would have to be slower, since it *is*
interpreted, after all.
This is another reason why CTFE really needs to support IO access (I
really
believe the strict adherance to CTFE must be *guaranteed* stateless is
a
mistake. It's right to strongly discourage it, but making the ban this
strict is taking things too far - similar to Java's ban on pointers).
Then,
include_C could be implemented roughly like this:
string include_C(string filename)
{
auto cache = filename~.cache;
if(exists(cache) timestamp(cache) = timestamp(filename))
return loadFile(cache);
else
{
auto result = convert_C(loadFile(filename));
saveFile(cache, result);
return result;
}
}
string convert_C(string src)
{
// Do the conversion, possibly even by invoking a pre-compiled tool.
}
// Only gets processed if stdio.h has changed
mixin( include_C_file(stdio.h) );
The other big benefit, of course, if that we'd finally get compile-time
write*() for free.
This would also open the door for a CTFE/library-based buildsystem that
doesn't require a dedicated makefile or equivalent, which is an
interesting prospect.
Although there are other languages allowing you to call external programs
during compilation it feels like opening Pandora's box and people will
start sending code around that does rm -rf ~/*. Then again, the same
effect can be accomplished later at runtime so I don't know if there is
really any objective difference.
I wouldn't mind if there was a compiler switch to enable compile-time I/O
for exactly the things you mentioned.
For starters, how about this?:
static string someExternalText = __ctfeReadFile(external.txt);
static byte[] chipInitialState = __ctfeReadFile(initial_state.bin);
Every external file used in compiling a source file would be added to the
list of files to check for their modification date in relation to the
resulting object file. This ensures that the object is recreated when
either of the sources change. The list can be in a separate file per each
D source using this feature.
This offers:
- no execution of arbitrary commands
- usual compile-if-newer logic doesn't reinvent the wheel
- compile-time conversion of C headers
- add snippets in domain specific languages by their own respective source
files
- include microcode blobs and other binary data in your modules if desired
Personally I think this idea rocks, but YMMV :p .
Re: CTFE - compiling other languages inside D
On 10/08/2011 21:32, Marco Leise wrote: For starters, how about this?: static string someExternalText = __ctfeReadFile(external.txt); static byte[] chipInitialState = __ctfeReadFile(initial_state.bin); Every external file used in compiling a source file would be added to the list of files to check for their modification date in relation to the resulting object file. This ensures that the object is recreated when either of the sources change. The list can be in a separate file per each D source using this feature. This offers: - no execution of arbitrary commands - usual compile-if-newer logic doesn't reinvent the wheel - compile-time conversion of C headers - add snippets in domain specific languages by their own respective source files - include microcode blobs and other binary data in your modules if desired Personally I think this idea rocks, but YMMV :p . You can already do that! enum _ = import(someFile); Then when compiling, use the -J switch (required) to specify the include directory. -- Robert http://octarineparrot.com/
Re: CTFE - compiling other languages inside D
Marco Leise wrote: For starters, how about this?: static string someExternalText = __ctfeReadFile(external.txt); static byte[] chipInitialState = __ctfeReadFile(initial_state.bin); static string someExternalText = import(external.txt); static byte[] chipInitialState = import(initial_state.bin); (You need to pass the -Jpath switch)
Re: [GSOC] regular expressions beta is here
Am 10.08.2011, 22:12 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com: [...] I don't see any reason to keep discussing it over and over. You see, and that is why we should make that explicit rather than implicit in the style guide. An additional point personal preference could list blank lines to group logical blocks of code.
Re: [GSOC] regular expressions beta is here
On 10.08.2011 22:12, Jonathan M Davis wrote: There a few things that were agreed upon (such as always putting braces on their own line), There is? Parallelism and json uses braces on the same line. It was agreed upon, and where it has been noticed, it has been fixed. But as I said, the style guide needs updating on a few points. Braces on their own line is one of them. - Jonathan M Davis
