Re: D Conference 2012 - Sep 26-29 at the Banker's Suite and Ballroom in Astoria, Oregon
On Wednesday, 22 February 2012 at 22:07:26 UTC, Walter Bright wrote: Pricing isn't set yet, nor has a web site been set up yet, this is just a heads up to reserve the dates on your calendar, and start thinking about that presentation you want to do! The general idea is: Wed evening - meet greet at the Banker's Suite Thu-Fri - presentations at the Banker's Ballroom Sat - discussion groups If your company wants to set up a booth or a table, or be a sponsor, please contact me. Is there any more information available? If so, where can I find it. I live nearby (Seattle) so I will be attending, but need to make plans. Paul
Re: Can't run 'masm386'
Adam Wilson flybo...@gmail.com wrote in message news:op.wefr0erm707...@invictus.skynet.com... It looks like 2 days ago someone DID in fact change the minit.asm file. They changed the references to LICENSE and README. Your best bet is probably to redownload minit.obj from the druntime repo to update it's modified date. In that case, the copy of minit.obj in git really should have its timestamp updated too, otherwise people are just going to keep running into this. (Or, as someone suggested, just remove the minit.obj depends on minit.asm from the makefile.)
Re: Can't run 'masm386'
On Wed, 16 May 2012 22:53:59 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Adam Wilson flybo...@gmail.com wrote in message news:op.wefr0erm707...@invictus.skynet.com... It looks like 2 days ago someone DID in fact change the minit.asm file. They changed the references to LICENSE and README. Your best bet is probably to redownload minit.obj from the druntime repo to update it's modified date. In that case, the copy of minit.obj in git really should have its timestamp updated too, otherwise people are just going to keep running into this. (Or, as someone suggested, just remove the minit.obj depends on minit.asm from the makefile.) I'm editing the makefiles anyways, it could be done, but I want to make sure there are no other weird dependencies on it first. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
isInputRange instead of isForwardRange for std.algorithm.fill
It looks to me that isForwardRange is too much of a restriction for the fill algorithm, isInputRange could do, we don't need any save() here or am I missing something ?
Re: Standard struct constructors for the heap?
Andrej Mitrovic: Mixin workaround: Yeah, in some cases I have used a similar workaround. Now I'd like to avoid the workaround. Bye, bearophile
Re: O.T. Re: D dropped in favour of C# for PSP emulator
On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote: Al 17/05/12 03:32, En/na Walter Bright ha escrit: On 5/16/2012 12:29 AM, bearophile wrote: Then why is Andrei using the name std.algorithm.schwartzSort? May the schwartz be with you. Very appropriate :-) On 27 May is the 35 anniversary of the first released film from the Star Wars series. Walter's quote was from Spaceballs. :-) -Lars
News server load becoming more and more an issue
Hi, Not sure who looks after the news server that hosts the relevant D newsgroups, but over the last few weeks, the amount of high load messages has been increasing at a steady rate, to an extend that it is becoming a real nuisance to read the newsgroups via a classic newsreader like thunderbird (hence using the web forum interface for this message). Can someone please change the settings on the news server to solve this (or move to another server) ? Many thanks, fil
Re: D dropped in favour of C# for PSP emulator
On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote: How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users. If you don't know about binary search, you won't write assumeSorted(r).contains(x) you'll just write r.contains(x) because you have no idea that binary search exists. Why would you bother typing extra characters for a benefit that you are unaware of? If you do know that binary search exists then the obvious algorithm name is binarySearch. If I use .contains to coax a binarySearch then I'm relying on a little bit of faith. In what situations does it give a binary search? [1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is sorted? iota(10).contains(5); // is iota implicitly a sorted range? assumeSorted([1, 2, 3]).map!(x = x + 1).contains(3); // does Phobos know that the map is order preserving? assumeSorted([1, 2, 3]).filter!(a 1).contains(2); // does Phobos know that filters always preserve order? I'd have to read the documentation to find out which of these uses binary search. In fact, I'd probably have to read the Phobos source. If I just used binarySearch then I would be 100% guaranteed that it will use a binary search. I don't have to second guess the compiler -- I just *know*.
Re: News server load becoming more and more an issue
On Thursday, 17 May 2012 at 08:54:16 UTC, filgood wrote: Hi, Not sure who looks after the news server that hosts the relevant D newsgroups, but over the last few weeks, the amount of high load messages has been increasing at a steady rate, to an extend that it is becoming a real nuisance to read the newsgroups via a classic newsreader like thunderbird (hence using the web forum interface for this message). Can someone please change the settings on the news server to solve this (or move to another server) ? Many thanks, fil There was a post from Andrei saying that they were looking into it, but I feel your pain. Somehow the web interface appears to be more resilient to the post failures, but my Thunderbird and Windows Live Email keep complaining all the time. :( Which is somehow ironic, since I prefer native applications to web based ones.
Re: News server load becoming more and more an issue
What about a new group on: https://groups.google.com/ On Thursday, 17 May 2012 at 09:01:12 UTC, Paulo Pinto wrote: On Thursday, 17 May 2012 at 08:54:16 UTC, filgood wrote: Hi, Not sure who looks after the news server that hosts the relevant D newsgroups, but over the last few weeks, the amount of high load messages has been increasing at a steady rate, to an extend that it is becoming a real nuisance to read the newsgroups via a classic newsreader like thunderbird (hence using the web forum interface for this message). Can someone please change the settings on the news server to solve this (or move to another server) ? Many thanks, fil There was a post from Andrei saying that they were looking into it, but I feel your pain. Somehow the web interface appears to be more resilient to the post failures, but my Thunderbird and Windows Live Email keep complaining all the time. :( Which is somehow ironic, since I prefer native applications to web based ones.
Re: Why typedef's shouldn't have been removed :(
Ugh, ran into a problem again... I was hoping I could do a type deduction for a write() function I had, based on whether the input is 'size_t' (in which case it'd be hexadecimal) or 'uint' (in which case it'd be decimal), but nope! that doesn't work. :( Any chance we'll be able to distinguish aliases like these sometime?
Re: Why typedef's shouldn't have been removed :(
On Thursday, May 17, 2012 11:16:08 Mehrdad wrote: Ugh, ran into a problem again... I was hoping I could do a type deduction for a write() function I had, based on whether the input is 'size_t' (in which case it'd be hexadecimal) or 'uint' (in which case it'd be decimal), but nope! that doesn't work. :( Any chance we'll be able to distinguish aliases like these sometime? The compiler _might_ be made to output aliases in error messages along with what they're aliased to, but it's kind of the whole point of aliases that they _not_ be their own type. So, it wouldn't make any sense to distinguish them with type deduction and the like. As it stands, as far as the compiler is concerned, there is _zero_ difference between size_t and ulong on 64-bit and size_t and uint on 32-bit. It's effectively the same as a search and replace. You obviously want something _other_ than an alias, but since size_t uses an alias, that's the way it is, and that's the way that it's bound to stay. - Jonathan M Davis
Re: Can't run 'masm386'
minit.obj is still there. I commented this part: src\rt\minit.obj : src\rt\minit.asm $(CC) -c $(CFLAGS) src\rt\minit.asm That works. On 5/17/2012 11:35 AM, Nick Sabalausky wrote: Andre Tampubolon an...@lc.vlsm.org wrote in message news:jp1kld$15mj$1...@digitalmars.com... I was trying to build druntime. I got this error: dmd -c -d -o- -Isrc -Iimport -Hfimport\core\sys\windows\windows.di src\core\sys\windows\windows.d dmc -c src\core\stdc\errno.c -oerrno_c.obj dmc -c src\rt\complex.c dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found Strange. This thing never happened before. I've hit that before. Druntime comes with minit.obj already compiled. Apperently, minit.asm isn't expected to change, so it's not expected that minit.obj will need to be rebuilt. At least that's what I was told. So what must have happened is the same as what happened to me: The timestamp on minit.asm was updated (or the file was inadvertantly changed). Or maybe minit.obj accidentally got deleted. Either way, make thinks minit needs to be rebuilt (which is not normally expected of minit), so it tries to, and it can't find masm386 (which doesn't come with DMD or DMC), so the error. So just: 1. Check that minit.obj still exists, and if not, grab it again. 2. Make sure the timestamp on minit.asm isn't newer than minit.obj 3. Make sure minit.asm didn't get changed.
Re: Should range foreach be iterating over an implicit copy?
Nick Sabalausky: One side of the argument is that this behavior is correct and expected since structs are value types, and iterating shouldn't consume the range. In that D.learn thread I've shown that iterating on a fixed-size array, that is a value, doesn't perform a copy of the array. Imagine, for example, an input range that read from stdin. Leaving that range unconsumed would make no sense at all. Actually, any input range can be expected to *not* leave an uniterated copy behind: if it *could* have an uniterated copy left behind, it would be a forward range, not an input range. Seems right. Bye, bearophile
Re: Why typedef's shouldn't have been removed :(
On Thursday, May 17, 2012 02:38:13 Jonathan M Davis wrote: On Thursday, May 17, 2012 11:16:08 Mehrdad wrote: Ugh, ran into a problem again... I was hoping I could do a type deduction for a write() function I had, based on whether the input is 'size_t' (in which case it'd be hexadecimal) or 'uint' (in which case it'd be decimal), but nope! that doesn't work. :( Any chance we'll be able to distinguish aliases like these sometime? The compiler _might_ be made to output aliases in error messages along with what they're aliased to, but it's kind of the whole point of aliases that they _not_ be their own type. So, it wouldn't make any sense to distinguish them with type deduction and the like. As it stands, as far as the compiler is concerned, there is _zero_ difference between size_t and ulong on 64-bit and size_t and uint on 32-bit. It's effectively the same as a search and replace. You obviously want something _other_ than an alias, but since size_t uses an alias, that's the way it is, and that's the way that it's bound to stay. I'd point out though that if your problem is type deduction and compile time reflection, the code that you're generating will be generated on the architecture that it's being run on (unless you're generating .d files that you keep around for future builds), so the fact that size_t is a different size on a different machine is more or less irrelevant. You'll end up using whatever the size is for _that_ machine, which is all that it needs. The fact that it's not the same size as it might be on another machine should be irrelevant. Maybe you've found a use case where it matters, but certainly in general, I don't see why it would. It's actually _less_ of a problem with code generation, because it can generate whatever is correct for that architecture, whereas if the programmer is doing it themselves, they can easily forget to use size_t and end up with their code not compiling properly on another architecture due to narrowing conversions and the like. Code generation just doesn't need size_t normally (if ever). It's the programmers writing code which do. - Jonathan M Davis
Do not write object file?
Every time I compile a D code, an .obj file is generated. Is there any to prevent that? I tried dmd -o- hello.d. Indeed there's no obj file. And no executable, too. Maybe this is a bug?
Re: Do not write object file?
The linker makes exe from obj.
Re: New Traits
On 2012-05-16 23:20, John Maschmeyer wrote: On Wednesday, 16 May 2012 at 17:08:43 UTC, Philippe Sigaud wrote: If you give it a module name (qualified with package name), does it output the entire module code? Yes Awesome, now where is that CTFE D compiler :) -- /Jacob Carlborg
Re: New Traits
On 2012-05-16 23:19, John Maschmeyer wrote:
It works for a function literal that has been assigned to a variable.
Function Literal:
int function(int) func = x = x+1;
writeln(__traits(codeof, func));
Outputs:
int function(int) func = delegate pure nothrow @safe int(int x)
{
return x + 1;
}
;
Does it work if the lambda is passed to a function:
void foo (int delegate (int x) dg)
{
wirteln(__traits(codeof, dg);
}
foo(x = x + 1);
--
/Jacob Carlborg
Re: News server load becoming more and more an issue
I prefer to use native apps like Paulo. Andrei, any news regarding the news server? Thx, fil On 17/05/2012 10:17, Andrea Fontana wrote: What about a new group on: https://groups.google.com/ On Thursday, 17 May 2012 at 09:01:12 UTC, Paulo Pinto wrote: On Thursday, 17 May 2012 at 08:54:16 UTC, filgood wrote: Hi, Not sure who looks after the news server that hosts the relevant D newsgroups, but over the last few weeks, the amount of high load messages has been increasing at a steady rate, to an extend that it is becoming a real nuisance to read the newsgroups via a classic newsreader like thunderbird (hence using the web forum interface for this message). Can someone please change the settings on the news server to solve this (or move to another server) ? Many thanks, fil There was a post from Andrei saying that they were looking into it, but I feel your pain. Somehow the web interface appears to be more resilient to the post failures, but my Thunderbird and Windows Live Email keep complaining all the time. :( Which is somehow ironic, since I prefer native applications to web based ones.
Re: Do not write object file?
On Thursday, 17 May 2012 at 10:16:38 UTC, Andre Tampubolon wrote: Every time I compile a D code, an .obj file is generated. Is there any to prevent that? I tried dmd -o- hello.d. Indeed there's no obj file. And no executable, too. Maybe this is a bug? If you don't want object files to be generated (actually they must be generated in order for linker to build exe) compile with rdmd (it will put object files in a temp directory so your project folder is kept clean): rdmd --build-only (dmd parameter here) main.d also rdmd will take care of your dependencies so you just have to pass it your main file.
Re: arrays: if(null == [ ])
Le 16/05/2012 23:15, Steven Schveighoffer a écrit : On Wed, 16 May 2012 17:11:58 -0400, deadalnix deadal...@gmail.com wrote: Le 16/05/2012 15:12, Steven Schveighoffer a écrit : On Tue, 15 May 2012 04:42:10 -0400, deadalnix deadal...@gmail.com wrote: Le 14/05/2012 21:53, Steven Schveighoffer a écrit : On Mon, 14 May 2012 15:30:25 -0400, deadalnix deadal...@gmail.com wrote: Le 14/05/2012 16:37, Steven Schveighoffer a écrit : Note that [] is a request to the runtime to build an empty array. The runtime detects this, and rather than consuming a heap allocation to build nothing, it simply returns a null-pointed array. This is 100% the right decision, and I don't think anyone would ever convince me (or Andrei or Walter) otherwise. Obviously this is the right thing to do ! The question is why an array of length 0 isn't nulled ? It lead to confusing semantic here, and can keep alive memory that can't be accessed. int[] arr; arr.reserve(1); assert(arr.length == 0); -Steve The length isn't set to 0 here. You obviously don't want that to be nulled. The assert disagrees with you :) -Steve The length IS 0. It IS 0 before the call to reserve. It is never SET to 0. OK, so it's allowed to be 0 and not-null. doesn't this lead to the confusing semantics you were talking about? What about this? int[] arr; arr.reserve(1); int[] arr2 = [1,2,3]; arr2 = arr; // now length has been *set* to 0, should it also be nulled? But I want arr2 and arr to point at the same thing, maybe I'm not using arr anymore. Maybe I returned it from a function, and I no longer have access to arr. -Steve That make sense :D
Re: Do not write object file?
Actually what I mean is once the compilation is done, the object file will be automatically removed. So I guess this is my misunderstanding of dmd -o-. No problem, then. On 5/17/2012 6:09 PM, Aleksandar Ružičić aleksan...@ruzicic.info wrote: On Thursday, 17 May 2012 at 10:16:38 UTC, Andre Tampubolon wrote: Every time I compile a D code, an .obj file is generated. Is there any to prevent that? I tried dmd -o- hello.d. Indeed there's no obj file. And no executable, too. Maybe this is a bug? If you don't want object files to be generated (actually they must be generated in order for linker to build exe) compile with rdmd (it will put object files in a temp directory so your project folder is kept clean): rdmd --build-only (dmd parameter here) main.d also rdmd will take care of your dependencies so you just have to pass it your main file.
Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto));`
Is there anything preventing us from adding constraints on the
auto function return value? I mean, such language extension seems
to be quite useful.
For example, it would be no longer necessary to provide method
bodies for functions with auto return values.
In many cases this would eliminate the need for introducing an
interface.
interface returnsDuckTyped
{
auto foo() if(isInputRange(auto));
}
Re: Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto));`
On Thursday, 17 May 2012 at 11:49:18 UTC, Roman D. Boiko wrote:
Is there anything preventing us from adding constraints on the
auto function return value? I mean, such language extension
seems to be quite useful.
For example, it would be no longer necessary to provide method
bodies for functions with auto return values.
In many cases this would eliminate the need for introducing an
interface.
interface returnsDuckTyped
{
auto foo() if(isInputRange!auto);
}
(fixed typo)
Re: Is dsource .org completely deserted?
On 17/05/12 01:45, Nick Sabalausky wrote: My main point is that those features (fork/pull request/issue tracking, etc) should be decoupled from hosting so that, for example, self-hosted repos would *not* provide inferior service, in fact they woudn't have to provide some stupid bundled interface at all: As a *user* (NOT as a project maintainer), you would just use *your own* choice of github, bitbucket, Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the fuck repo you wanted to access, wherever the hell said repo happens to live. The whole point is that interface and hosting have no business being coupled as they are now. Tying repo and interface together makes absolutely no sense whatsoever. I do agree with you. However ... to really get that working our only choice is to take time and effort to contribute to one of the open source code hosting solutions. I'm familiar with only two decent ones -- Launchpad (which is tied to bzr) and Gitorious (which seems to be not very well maintained these days, though I haven't looked too recently, and which IIRC doesn't include issue tracking etc.). It would be great if we could have code-hosting equivalents of WordPress, Drupal, Joomla! etc., but for now there's nothing that really cuts the mustard compared to the dedicated services out there. Bear in mind, though, that even if you _did_ have the stuff available for self-hosting, in many cases it would still make sense to host with a dedicated service.
Re: O.T. Re: D dropped in favour of C# for PSP emulator
On Thu, 17 May 2012 09:50:44 +0100, Lars T. Kyllingstad pub...@kyllingen.net wrote: On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote: Al 17/05/12 03:32, En/na Walter Bright ha escrit: On 5/16/2012 12:29 AM, bearophile wrote: Then why is Andrei using the name std.algorithm.schwartzSort? May the schwartz be with you. Very appropriate :-) On 27 May is the 35 anniversary of the first released film from the Star Wars series. Walter's quote was from Spaceballs. :-) Ahh.. I see your schwartz is as big as mine :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: input completion system
On 05/16/2012 04:37 AM, Katayama Hirofumi MZ wrote:
Hi, everyone!
Could you make input completion system for D?
There is also DDT for eclipse. It works really well except for all the
is(typeof({})) code which is starting to become present everywhere in
libraries. Hence we are going to loose a feature.
Re: arrays: if(null == [ ])
On Thu, 17 May 2012 00:08:49 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday, May 16, 2012 09:18:38 Steven Schveighoffer wrote: but I still think we should discourage using null as a sentinel, it leads to confusing code. If null were actually properly differentiated from empty, then this wouldn't be a problem, but it's not. It _should_ be possible to treat null as a sentinel. The fact that it causes issues is a major flaw in the language IMHO. But given that flaw, it does very quickly become error-prone to use null as a sentinel. In general, I'd say that the only reasonable place to do so is when returning an array (and especially a string) from a function. The return value can then be immeditely checked with is null before it has the chance to have something happen to it which could cause it to be empty but non-null. I want to re-re-re-register my dismay in the situation also. For me it always comes back to.. I can do it with a pointer.. a pointer! Why not an array?!? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why typedef's shouldn't have been removed :(
On 5/17/12, Jonathan M Davis jmdavisp...@gmx.com wrote: The compiler _might_ Clang already does this with C++ for error messages, I see no reason why DMD shouldn't do the same.
Re: 2D (or higher) equivalent of ranges?
On Wed, May 16, 2012 at 11:20 PM, Tobias Pankrath tob...@pankrath.net wrote: More exotic: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/recursive.html That looks like a compile time composite pattern and I'd say it's a natural way to iterate over every form of graph. To be a equivalent to ranges in the std.algorithm sense, they must also be a good vehicle to implement graph algorithms effectively. I'd question this for the recursive ranges. How would you implement Dijkstra with r-ranges? I don't remember how I did Dijkstra in D. That was 2 years ago (see https://github.com/PhilippeSigaud/dranges/blob/master/graphalgorithm.d ). IIRC That was an algorithm directly acting on the graph, not on a r-range. I have a module to present a graph as a (linear, standard) range, either exploring the graph in a deph-first or breadth-first manner, see: https://github.com/PhilippeSigaud/dranges/blob/master/graphrange.d As for recursive ranges, even two years afterwards I still don't know if exposing a r-range is a good idea or not. The thing is, a r-range preserves the global topology (shape) and as such is awfully near a container. And, as you said, some algorithm do not translate easily into a range function. I haven't think much about it though. I'm still waiting for a definitive word on allocators and seeing the AA implementation to go back to graphs.
Return type inference
This does not work and I can see why.
---
auto foo(int x)
{
if(x 0)
return foo(-x);
return x;
}
DMD 2.059 says:
oopsc/compiler/test.d(7): Error: forward reference to foo
oopsc/compiler/test.d(14): Error: forward reference to foo
For the human reader it is easy to see that the return type of
foo should be int. Could the following rule be added to make dmd
see this, too?
If there are multiple ReturnStatements, the types of them must
match exactly. If there are no ReturnStatements, the return
type is inferred to be void.
new
If the function is called recursively the type of the result of
this call is inferred in the same way. If the recursive call is
part of a return statement then this statement is not
considered for type inference. If all return statements are
discarded in this way, it is an error.
Re: Standard struct constructors for the heap?
On Wed, 16 May 2012 19:50:25 -0400, bearophile bearophileh...@lycos.com
wrote:
Regarding the efforts of removing limitations from D, do you know if
there are problems in implementing this oldish enhancement request?
http://d.puremagic.com/issues/show_bug.cgi?id=4086
Should be absolutely feasible.
I'd also like to see this work:
struct X
{
int x;
this(int x) {this.x = x;}
}
void main(){
X x; // no ctor needed
X *xp = new X; // but this is an error!
}
-Steve
Re: Can't run 'masm386'
On Thu, 17 May 2012 01:53:59 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: (Or, as someone suggested, just remove the minit.obj depends on minit.asm from the makefile.) I don't think this is a good idea, minit.asm could have code changes, in which case you are building with a stale object. I'd rather have the error than accidentally use a stale object. Any chance this asm file can be written in D with asm block? -Steve
Re: Return type inference
On 5/17/12, Tobias Pankrath tob...@pankrath.net wrote: snip http://d.puremagic.com/issues/show_bug.cgi?id=7483
Re: Return type inference
On 17.05.2012 17:10, Tobias Pankrath wrote:
This does not work and I can see why.
---
auto foo(int x)
{
if(x 0)
return foo(-x);
Pluck in other condition then x 0 and you may see it's not so easy.
Basically compiler has to deduce that recursion stops and trace down to
the bottom of it.
return x;
}
DMD 2.059 says:
oopsc/compiler/test.d(7): Error: forward reference to foo
oopsc/compiler/test.d(14): Error: forward reference to foo
For the human reader it is easy to see that the return type of
foo should be int. Could the following rule be added to make dmd
see this, too?
If there are multiple ReturnStatements, the types of them must match
exactly. If there are no ReturnStatements, the return type is inferred
to be void.
new
If the function is called recursively the type of the result of this
call is inferred in the same way. If the recursive call is part of a
return statement then this statement is not considered for type
inference. If all return statements are discarded in this way, it is
an error.
--
Dmitry Olshansky
stream interfaces - with ranges
OK, so I had a couple partially written replies on the 'deprecating
std.stream etc' thread, then I had to go home.
But I thought about this a lot last night, and some of the things Andrei
and others are saying is starting to make sense (I know!). Now I've
scrapped those replies and am thinking about redesigning my i/o package
(most of the code can stay intact).
I'm a little undecided on some of the details, but here is what I think
makes sense:
1. We need a buffering input stream type. This must have additional
methods besides the range primitives, because doing one-at-a-time byte
reads is not going to cut it.
2. I realized, buffering input stream of type T is actually an input range
of type T[]. Observe:
struct /*or class*/ buffer(T)
{
T[] buf;
InputStream input;
...
@property T[] front() { return buf; }
void popFront() {input.read(buf);} // flush existing buffer, read
next.
@property bool empty() { return buf.length == 0;}
}
Roughly speaking, not all the details are handled, but this makes a
feasible input range that will perform quite nicely for things like
std.algorithm.copy. I haven't checked, but copy should be able to handle
transferring a range of type T[] to an output range with element type T,
if it's not able to, it should be made to work. I know at least, an
output stream with element type T supports putting T or T[]. What I think
really makes sense is to support:
buffer!ubyte b;
outputStream o;
o.put(b); // uses range primitives to put all the data to o, one element
(i.e. ubyte[]) of b at a time
3. An ultimate goal of the i/o streaming package should be to be able to
do this:
auto x = new XmlParser(rootElement/rootElement);
or at least
auto x = new XmlParser(buffered(rootElement/rootElement));
So I think arrays need to be able to be treated as a buffering streams. I
tried really hard to think of some way to make this work with my existing
system, but I don't think it will without unnecessary baggage, and losing
interoperability with existing range functions.
Where does this leave us?
1. I think we need, as Andrei says, an unbuffered streaming abstraction.
I think I have this down pretty solidly in my current std.io.
2. A definition of a buffering range, in terms of what additional
primitives the range should have. The primitives should support buffered
input and buffered output (these are two separate algorithms), but
independently (possibly allowing switching for rw files).
3. An implementation of the above definition hooked to the unbuffered
stream abstraction, to be utilized in more specific ranges. But by
itself, can be used as an input range or directly by code.
4. Specialization ranges for each type of input you want (i.e. byLine,
byChunk, textStream).
5. Full replacement option of File backend. File will start out with
C-supported calls, but any promotion to using a more D-like range type
will result in switching to a D-based stream using the above mechanisms.
Of course, all existing code should compile that does not try to assume
the File always has a valid FILE *.
What do you all think? I'm going to work out what the definition of 2
should be, based on what I've written and what makes sense.
Have I started to design something feasible or unworkable? :)
-Steve
stream interfaces - with ranges
OK, so I had a couple partially written replies on the 'deprecating
std.stream etc' thread, then I had to go home.
But I thought about this a lot last night, and some of the things Andrei
and others are saying is starting to make sense (I know!). Now I've
scrapped those replies and am thinking about redesigning my i/o package
(most of the code can stay intact).
I'm a little undecided on some of the details, but here is what I think
makes sense:
1. We need a buffering input stream type. This must have additional
methods besides the range primitives, because doing one-at-a-time byte
reads is not going to cut it.
2. I realized, buffering input stream of type T is actually an input range
of type T[]. Observe:
struct /*or class*/ buffer(T)
{
T[] buf;
InputStream input;
...
@property T[] front() { return buf; }
void popFront() {input.read(buf);} // flush existing buffer, read
next.
@property bool empty() { return buf.length == 0;}
}
Roughly speaking, not all the details are handled, but this makes a
feasible input range that will perform quite nicely for things like
std.algorithm.copy. I haven't checked, but copy should be able to handle
transferring a range of type T[] to an output range with element type T,
if it's not able to, it should be made to work. I know at least, an
output stream with element type T supports putting T or T[]. What I think
really makes sense is to support:
buffer!ubyte b;
outputStream o;
o.put(b); // uses range primitives to put all the data to o, one element
(i.e. ubyte[]) of b at a time
3. An ultimate goal of the i/o streaming package should be to be able to
do this:
auto x = new XmlParser(rootElement/rootElement);
or at least
auto x = new XmlParser(buffered(rootElement/rootElement));
So I think arrays need to be able to be treated as a buffering streams. I
tried really hard to think of some way to make this work with my existing
system, but I don't think it will without unnecessary baggage, and losing
interoperability with existing range functions.
Where does this leave us?
1. I think we need, as Andrei says, an unbuffered streaming abstraction.
I think I have this down pretty solidly in my current std.io.
2. A definition of a buffering range, in terms of what additional
primitives the range should have. The primitives should support buffered
input and buffered output (these are two separate algorithms), but
independently (possibly allowing switching for rw files).
3. An implementation of the above definition hooked to the unbuffered
stream abstraction, to be utilized in more specific ranges. But by
itself, can be used as an input range or directly by code.
4. Specialization ranges for each type of input you want (i.e. byLine,
byChunk, textStream).
5. Full replacement option of File backend. File will start out with
C-supported calls, but any promotion to using a more D-like range type
will result in switching to a D-based stream using the above mechanisms.
Of course, all existing code should compile that does not try to assume
the File always has a valid FILE *.
What do you all think? I'm going to work out what the definition of 2
should be, based on what I've written and what makes sense.
Have I started to design something feasible or unworkable? :)
-Steve
Re: Return type inference
On Thursday, 17 May 2012 at 13:10:20 UTC, Tobias Pankrath wrote:
For the human reader it is easy to see that the return type of
foo should be int. Could the following rule be added to make dmd
see this, too?
If the function is called recursively the type of the result of
this call is inferred in the same way. If the recursive call is
part of a return statement then this statement is not
considered for type inference. If all return statements are
discarded in this way, it is an error.
It's not that simple:
int bar(int x);
real bar(real x);
auto foo(int x)
{
if (x 0)
return bar(foo(x-1));
return 0;
}
In order to determine the first return type, it needs to find out
what overloaded 'bar' to call, which requires determining the
first return type.
If you ignore the first return statement and only consider the
int then there could be problems. e.g. if above we had:
real bar(int x);
And we ignored the first return statement then the determined
return type would be wrong (would infer int, but bar(foo(x-1))
would return real).
Re: Should range foreach be iterating over an implicit copy?
On Thu, 17 May 2012 01:48:06 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: I'm a little discouraged that my concern about input ranges can't save their state, and yet that's exactly what happens implicitly hasn't been addressed. I was hoping to at least get a That's not really a problem and here's why... input ranges can save their state if they are also forward ranges. However, that said... Andrei Alexandrescu wrote... It is deliberate and the intent is that millions of programmers used to foreach from other languages don't scream where is my range??? Era Scarecrow wrote... Range can refer to many things, and I'm assuming array is one of them. So... If the array is consumed when using foreach, that seems dumb right? (An array in the end is just a small struct afterall...) I admit, those are fair points. With those in mind, I've given it some more thought, and here are my current...umm...thoughts: [snip] This is not a problem with ranges, this is an issue with value types versus reference types. I believe someone has created a byRef struct that wraps a range and iterates it byRef (maybe dsimcha?) Almost all ranges except true input-only ranges (i.e. input ranges that are only input ranges) should be value types. If we *didn't* do this, you would need heap data for each range. -Steve
Re: Why typedef's shouldn't have been removed :(
On Thu, May 17, 2012 at 03:04:00PM +0200, Andrej Mitrovic wrote:
On 5/17/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
The compiler _might_
Clang already does this with C++ for error messages, I see no reason
why DMD shouldn't do the same.
I have brought this up before. Maybe I should open an enhancement
request? GCC (g++) already does this, for example:
/tmp/test.c:3:12: error: cannot convert ‘const char*’ to ‘CSPTR {aka
int*}’ in initialization
where int* has been typedef'd to CSPTR. Note that both are shown, which
is important because sometimes you need one, and sometimes the other.
T
--
Жил-был король когда-то, при нём блоха жила.
AliasTuples, rather than Records, to return multiple values
Hi everybody! I've been lurking this forum for quite some time, attracted by the power and elegance of D. Although I'm not a programmer by profession, I often happen to develop programs for scientific data evaluation at work and I've always being intrigued with programming languages since I was a teenager. A lot of time has passed since the last time I looked at D, and now I'm really impressed with the amount of progress that has been done. However, I don't understand why some feature that would be so desirable are still not implemented and, although there are already a lot of posts about them, little to no progress is done at implementing them. One of these is using tuples to return multiple values from functions. I'd like to share with you my thoughts and opinions about how tuples might work and be useful in D. I hope you find this contribution useful, and you will let me understand where the problems are otherwise. I also apologize for the length of my post if it doesn't really contain anything new. At the time being we have two kinds of tuples in D and a lot of confusion about them. The first one is the Tuple object in Phobos (std.typecons.Tuple), which I'm going to call Record for the rest of the post to avoid confusion. They are pretty similar to Python's tuples, except that they are not immutable and have named items (admittedly a useful addition). By introducing Records, you were probably trying to achieve the following two points: 1) Provide a way to group values together, as if they were anonymous struct's. Unfortunately, Records are not compatible with ordinary struct's despite all their similarities. And I'm also not totally convinced they are that useful, except when dealing with point 2. They just confuse novices about whether they should be using Records or struct's, just like they can't choose between tuples and lists in Python. 2) Provide a mechanism for functions to return multiple values. It may be noted that functions in D can already return multiple values through out/ref arguments, but most people agree that returning multiple values would be a neater solution (I also do). This mechanism doesn't work yet because of the lack of compiler support. I don't understand, however, why Records should be a better candidate to implement this feature than TypeTuples (more about that later). Before going on, let me open a parenthesis about how returning multiple values works in Python. Suppose that the function func returns two values. The following saves the two values in the variables a and b. (a, b) = func() The parentheses around the tuple are not necessary, but I include them anyway for clarity. I'd like you to notice that this syntax is treated specially in Python. Python's tuples are immutable so you can't assign values to them. c = (0, 1) c[0] = 2 # error: tuple object does not support item assignment c = (2, 3) # this changes the reference c so that it points to a different tuple d = (a, b) d = func() # this doesn't assign the return values to a and b! (a, b) = func() # this does, but it's obviously a special case Ok, enough for Python, let's go on with D. The second kind of tuple is the in-built construct used in templates to group template arguments (std.typetuple.TypeTuple). Let's call it AliasTuple for the rest of the post, since TypeTuple is really a misnomer (as others before me have already pointed out: they can contain more than just types). It must be noted that AliasTuples are not containers. They may be considered a kind of compile-time container, but definitely not a run-time container. With this, I mean that they don't copy their content in a structured form in a determined region of memory at runtime, like arrays, linked-lists and Records do. This implies, for example, that we can't take their address or make an array of them. AliasTuples are just collections of aliases, they don't contain actual data. So they are not just another struct-like container in the language, like Records are. We may debate about how many defects AliasTuples have but, I guess, we all agree that they are an extremely useful construct for D's templates. Without them, templates in D would certainly be much more difficult to use and they would lose much of their power. Therefore, I hope nobody really intends to scrap them. If they have deficiencies (for instance, they can't actually be used to return multiple values from functions), I think we should improve them so that they cover all the useful use cases. It is my opinion that AliasTuples are much more appropriate to manage multiple return values than Records. However, for that to be possible, we must solve some of their weaknesses. One of them is that there isn't a concise literal expression yet. Let's suppose that we can create a tuple like this: @(1, 2, float) // equivalent to TypeTuple!(1, 2, float) Of course it would be preferable to have just
Re: Return type inference
On Thu, 17 May 2012 09:10:18 -0400, Tobias Pankrath tob...@pankrath.net
wrote:
This does not work and I can see why.
---
auto foo(int x)
{
if(x 0)
return foo(-x);
return x;
}
DMD 2.059 says:
oopsc/compiler/test.d(7): Error: forward reference to foo
oopsc/compiler/test.d(14): Error: forward reference to foo
For the human reader it is easy to see that the return type of
foo should be int.
At this point, I think the human should intervene:
int foo(int x)
...
I would *hate* to have to read code like yours to try and understand it.
-Steve
Re: Should range foreach be iterating over an implicit copy?
On 17.05.2012 18:18, Steven Schveighoffer wrote: On Thu, 17 May 2012 01:48:06 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: I'm a little discouraged that my concern about input ranges can't save their state, and yet that's exactly what happens implicitly hasn't been addressed. I was hoping to at least get a That's not really a problem and here's why... input ranges can save their state if they are also forward ranges. s/ save state / copy themselves Fixed :) That's why I tried to come up with BacktrackRange or some such. An input range that you can shake to reset to some saved point, but can't have two separate states at _the same time_ (nor full copy, it's like ... file) -- Dmitry Olshansky
Re: Why typedef's shouldn't have been removed :(
H. S. Teoh: I have brought this up before. Maybe I should open an enhancement request? Something like this? http://d.puremagic.com/issues/show_bug.cgi?id=5004 Bye, bearophile
Re: Should range foreach be iterating over an implicit copy?
On Wed, 16 May 2012 17:37:14 -0400, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
A small debate has broken out over on D.learn (
http://forum.dlang.org/thread/jovicg$jta$1...@digitalmars.com#post-jovicg:24jta:241:40digitalmars.com
)
that I thought I should move here.
Basically, the issue is this: Currently, when you have a struct-based
range,
foreach will iterate over a *copy* of it:
Range r;
auto save = r;
foreach(e; r)
assert(r == save);
assert(r == save);
One side of the argument is that this behavior is correct and expected
since
structs are value types, and iterating shouldn't consume the range.
My argument is this:
First of all, foreach is conceptually a flow-control statement, not a
function. So I'd intuitively expect:
Range r;
foreach(e; r) {...}
To work like this:
Range r;
for(; !r.empty; r.popFront)
{
auto e = r.front;
...
}
Hm... proposal:
foreach(e; ref r)
{
}
equates to your desired code. Would this help?
-Steve
Re: Return type inference
Andrej Mitrovic: http://d.puremagic.com/issues/show_bug.cgi?id=7483 Probably related: http://d.puremagic.com/issues/show_bug.cgi?id=8111 Bye, bearophile
Re: isInputRange instead of isForwardRange for std.algorithm.fill
On 5/17/12 2:14 AM, Guillaume Chatelet wrote: It looks to me that isForwardRange is too much of a restriction for the fill algorithm, isInputRange could do, we don't need any save() here or am I missing something ? That's correct, please file as a bug so we remember. (The second range must be forward in the overload fill(InputRange, ForwardRange) because it's iterated multiple times.) Andrei
Re: D dropped in favour of C# for PSP emulator
On 5/17/12 4:00 AM, Peter Alexander wrote: On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote: How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users. If you don't know about binary search, you won't write assumeSorted(r).contains(x) you'll just write r.contains(x) because you have no idea that binary search exists. Why would you bother typing extra characters for a benefit that you are unaware of? If you do know that binary search exists then the obvious algorithm name is binarySearch. If I use .contains to coax a binarySearch then I'm relying on a little bit of faith. In what situations does it give a binary search? [1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is sorted? Doesn't compile. iota(10).contains(5); // is iota implicitly a sorted range? Doesn't compile. assumeSorted([1, 2, 3]).map!(x = x + 1).contains(3); // does Phobos know that the map is order preserving? Doesn't compile, this would: assumeSorted([1, 2, 3].map!(x = x + 1)).contains(3) (which is quite a trick; map figures the input is a random-access range and exposes a random-access interface as well. Good luck doing that in other languages.) assumeSorted([1, 2, 3]).filter!(a 1).contains(2); // does Phobos know that filters always preserve order? Doesn't compile, and couldn't because filter() cannot preserve random access. I'd have to read the documentation to find out which of these uses binary search. In fact, I'd probably have to read the Phobos source. If I just used binarySearch then I would be 100% guaranteed that it will use a binary search. I don't have to second guess the compiler -- I just *know*. I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain. Andrei
Re: Return type inference
In order to determine the first return type, it needs to find out what overloaded 'bar' to call, which requires determining the first return type. I didn't think of overloaded functions. If we consider only direct recursion, it should still work?
Re: News server load becoming more and more an issue
On 5/17/12 5:58 AM, filgood wrote: Andrei, any news regarding the news server? Things are moving, but to be honest they're moving a lot slower than I'd like. Andrei
Re: Return type inference
On 17-05-2012 16:22, Steven Schveighoffer wrote:
On Thu, 17 May 2012 09:10:18 -0400, Tobias Pankrath
tob...@pankrath.net wrote:
This does not work and I can see why.
---
auto foo(int x)
{
if(x 0)
return foo(-x);
return x;
}
DMD 2.059 says:
oopsc/compiler/test.d(7): Error: forward reference to foo
oopsc/compiler/test.d(14): Error: forward reference to foo
For the human reader it is easy to see that the return type of
foo should be int.
At this point, I think the human should intervene:
int foo(int x)
...
I would *hate* to have to read code like yours to try and understand it.
-Steve
I have to agree. Sometimes auto can be over-used. Even in functional
languages with H-M type inference, I tend to always make my functions
have explicit signatures (unless they're supposed to be generic). It's
just clearer to the person reading the code later on.
--
- Alex
Re: Should range foreach be iterating over an implicit copy?
On Thursday, May 17, 2012 11:05:46 Steven Schveighoffer wrote:
Hm... proposal:
foreach(e; ref r)
{
}
equates to your desired code. Would this help?
Or you could just do
for(; !r.empty; r.popFront())
{
auto e = r.front;
}
I really don't think that that's a big deal. I don't think that the language
change would be worth having yet another thing in the language to remember,
particularly when it's so easy to just use for to do the job.
- Jonathan M Davis
Re: stream interfaces - with ranges
On 5/17/12 9:02 AM, Steven Schveighoffer wrote:
1. We need a buffering input stream type. This must have additional
methods besides the range primitives, because doing one-at-a-time byte
reads is not going to cut it.
I was thinking a range of T[] could be enough for a buffered input range.
2. I realized, buffering input stream of type T is actually an input range
of type T[]. Observe:
Ah, there we go :o).
struct /*or class*/ buffer(T)
{
T[] buf;
InputStream input;
...
@property T[] front() { return buf; }
void popFront() {input.read(buf);} // flush existing buffer, read next.
@property bool empty() { return buf.length == 0;}
}
Roughly speaking, not all the details are handled, but this makes a
feasible input range that will perform quite nicely for things like
std.algorithm.copy. I haven't checked, but copy should be able to handle
transferring a range of type T[] to an output range with element type T,
if it's not able to, it should be made to work.
We can do this for copy, but if we need to specialize a lot of other
algorithms, maybe we didn't strike the best design.
I know at least, an
output stream with element type T supports putting T or T[].
Right.
What I think
really makes sense is to support:
buffer!ubyte b;
outputStream o;
o.put(b); // uses range primitives to put all the data to o, one element
(i.e. ubyte[]) of b at a time
I think that makes sense.
3. An ultimate goal of the i/o streaming package should be to be able to
do this:
auto x = new XmlParser(rootElement/rootElement);
or at least
auto x = new XmlParser(buffered(rootElement/rootElement));
So I think arrays need to be able to be treated as a buffering streams. I
tried really hard to think of some way to make this work with my existing
system, but I don't think it will without unnecessary baggage, and losing
interoperability with existing range functions.
I think we can create a generic abstraction buffered() that layers
buffering on top of an input range. If the input range has unbuffered
read capability, buffered() would use those. Otherwise, it would use
loops using empty, front, and popFront.
Where does this leave us?
1. I think we need, as Andrei says, an unbuffered streaming abstraction.
I think I have this down pretty solidly in my current std.io.
Great. What are the primitives?
2. A definition of a buffering range, in terms of what additional
primitives the range should have. The primitives should support buffered
input and buffered output (these are two separate algorithms), but
independently (possibly allowing switching for rw files).
Sounds good.
3. An implementation of the above definition hooked to the unbuffered
stream abstraction, to be utilized in more specific ranges. But by
itself, can be used as an input range or directly by code.
Hah, I can't believe I wrote about the same thing above (and I swear I
didn't read yours).
4. Specialization ranges for each type of input you want (i.e. byLine,
byChunk, textStream).
What is the purpose? To avoid unnecessary double buffering?
5. Full replacement option of File backend. File will start out with
C-supported calls, but any promotion to using a more D-like range type
will result in switching to a D-based stream using the above mechanisms.
Of course, all existing code should compile that does not try to assume
the File always has a valid FILE *.
This will be tricky but probably doable.
Andrei
Re: Can't run 'masm386'
On 5/17/2012 6:38 AM, Steven Schveighoffer wrote: Any chance this asm file can be written in D with asm block? No.
Re: D dropped in favour of C# for PSP emulator
Andrei Alexandrescu: I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain. Names are very important, they are the fist and most important part of an API, they are the first handle for human programmers and their minds. The amount of care Python development group gives to the choice of names is visible and it makes a difference in Python usability. Important names can't be chosen by a single person, because single persons have quirks (they overstate how much common a word or concept is, etc etc). So important names are better chosen by groups, that allow to average out those quirks. I suggest to stick somewhere inside Phobos a name like binarySearch. Bye, bearophile
Re: Can't run 'masm386'
On Thu, 17 May 2012 06:38:15 -0700, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 17 May 2012 01:53:59 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: (Or, as someone suggested, just remove the minit.obj depends on minit.asm from the makefile.) I don't think this is a good idea, minit.asm could have code changes, in which case you are building with a stale object. I'd rather have the error than accidentally use a stale object. Any chance this asm file can be written in D with asm block? -Steve Ok, I never wrote the change into the makefiles anyways, I just updated from the repo to change the modified date. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Why typedef's shouldn't have been removed :(
On Thu, May 17, 2012 at 04:29:57PM +0200, bearophile wrote: H. S. Teoh: I have brought this up before. Maybe I should open an enhancement request? Something like this? http://d.puremagic.com/issues/show_bug.cgi?id=5004 [...] Heh, I've actually voted for that bug before, and forgot about it afterwards. :-) T -- It said to install Windows 2000 or better, so I installed Linux instead.
Re: D dropped in favour of C# for PSP emulator
On Thu, May 17, 2012 at 10:26:18AM -0500, Andrei Alexandrescu wrote:
On 5/17/12 4:00 AM, Peter Alexander wrote:
[...]
I'd have to read the documentation to find out which of these uses
binary search. In fact, I'd probably have to read the Phobos source.
If I just used binarySearch then I would be 100% guaranteed that it
will use a binary search. I don't have to second guess the compiler
-- I just *know*.
I agree binarySearch is more precise, but I also think it's a minor
issue not worth the cost of changing at this point. Improving names
of things in the standard library is a quest that could go forever,
make everybody happy we're making progress, and achieve no
substantial gain.
[...]
Why not just add something like this then:
E binarySearch(R,K)(R range, K key)
{
return assumeSorted(range).contains(key);
}
Nobody says we have to change the names of existing code. Adding a
wrapper with a nice name works just fine, and doesn't break any existing
code, etc..
T
--
Who told you to swim in Crocodile Lake without life insurance??
Re: D dropped in favour of C# for PSP emulator
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu
wrote:
I agree binarySearch is more precise, but I also think it's a
minor issue not worth the cost of changing at this point.
Improving names of things in the standard library is a quest
that could go forever, make everybody happy we're making
progress, and achieve no substantial gain.
No need to change anything, just add something:
bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}
(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).
Re: D dropped in favour of C# for PSP emulator
On Thu, May 17, 2012 at 06:52:26PM +0200, Peter Alexander wrote:
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:
I agree binarySearch is more precise, but I also think it's a
minor issue not worth the cost of changing at this point.
Improving names of things in the standard library is a quest that
could go forever, make everybody happy we're making progress, and
achieve no substantial gain.
No need to change anything, just add something:
bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}
(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).
Great minds think alike. ;-)
T
--
It said to install Windows 2000 or better, so I installed Linux instead.
Re: D dropped in favour of C# for PSP emulator
Am Fri, 11 May 2012 21:02:40 +0200 schrieb Philippe Sigaud philippe.sig...@gmail.com: On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh hst...@quickfur.ath.cx wrote: If newbies had the proper introduction to the concept of templates (instead of being dunked in the deep end of the pool with signature constraints that use templates, nested templates, etc., with no prior warning), they wouldn't have such a hard time with them. I wrote a tutorial on templates, any comment is welcome: https://github.com/PhilippeSigaud/D-templates-tutorial Direct link to the pdf: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true I need to get back to it, I was side-tracked by other projects and still have things to add to the doc. Philippe Your PDF is my reference manual on templates for quite a while. Thanks for putting it up! -- Marco
Re: AliasTuples, rather than Records, to return multiple values
Le 17/05/2012 16:20, Dario Schiavon a écrit : Hi everybody! I've been lurking this forum for quite some time, attracted by the power and elegance of D. Although I'm not a programmer by profession, I often happen to develop programs for scientific data evaluation at work and I've always being intrigued with programming languages since I was a teenager. A lot of time has passed since the last time I looked at D, and now I'm really impressed with the amount of progress that has been done. However, I don't understand why some feature that would be so desirable are still not implemented and, although there are already a lot of posts about them, little to no progress is done at implementing them. One of these is using tuples to return multiple values from functions. I'd like to share with you my thoughts and opinions about how tuples might work and be useful in D. I hope you find this contribution useful, and you will let me understand where the problems are otherwise. I also apologize for the length of my post if it doesn't really contain anything new. At the time being we have two kinds of tuples in D and a lot of confusion about them. The first one is the Tuple object in Phobos (std.typecons.Tuple), which I'm going to call Record for the rest of the post to avoid confusion. They are pretty similar to Python's tuples, except that they are not immutable and have named items (admittedly a useful addition). By introducing Records, you were probably trying to achieve the following two points: 1) Provide a way to group values together, as if they were anonymous struct's. Unfortunately, Records are not compatible with ordinary struct's despite all their similarities. And I'm also not totally convinced they are that useful, except when dealing with point 2. They just confuse novices about whether they should be using Records or struct's, just like they can't choose between tuples and lists in Python. 2) Provide a mechanism for functions to return multiple values. It may be noted that functions in D can already return multiple values through out/ref arguments, but most people agree that returning multiple values would be a neater solution (I also do). This mechanism doesn't work yet because of the lack of compiler support. I don't understand, however, why Records should be a better candidate to implement this feature than TypeTuples (more about that later). Before going on, let me open a parenthesis about how returning multiple values works in Python. Suppose that the function func returns two values. The following saves the two values in the variables a and b. (a, b) = func() The parentheses around the tuple are not necessary, but I include them anyway for clarity. I'd like you to notice that this syntax is treated specially in Python. Python's tuples are immutable so you can't assign values to them. c = (0, 1) c[0] = 2 # error: tuple object does not support item assignment c = (2, 3) # this changes the reference c so that it points to a different tuple d = (a, b) d = func() # this doesn't assign the return values to a and b! (a, b) = func() # this does, but it's obviously a special case Ok, enough for Python, let's go on with D. The second kind of tuple is the in-built construct used in templates to group template arguments (std.typetuple.TypeTuple). Let's call it AliasTuple for the rest of the post, since TypeTuple is really a misnomer (as others before me have already pointed out: they can contain more than just types). It must be noted that AliasTuples are not containers. They may be considered a kind of compile-time container, but definitely not a run-time container. With this, I mean that they don't copy their content in a structured form in a determined region of memory at runtime, like arrays, linked-lists and Records do. This implies, for example, that we can't take their address or make an array of them. AliasTuples are just collections of aliases, they don't contain actual data. So they are not just another struct-like container in the language, like Records are. We may debate about how many defects AliasTuples have but, I guess, we all agree that they are an extremely useful construct for D's templates. Without them, templates in D would certainly be much more difficult to use and they would lose much of their power. Therefore, I hope nobody really intends to scrap them. If they have deficiencies (for instance, they can't actually be used to return multiple values from functions), I think we should improve them so that they cover all the useful use cases. It is my opinion that AliasTuples are much more appropriate to manage multiple return values than Records. However, for that to be possible, we must solve some of their weaknesses. One of them is that there isn't a concise literal expression yet. Let's suppose that we can create a tuple like this: @(1, 2, float) // equivalent to TypeTuple!(1, 2, float) Of course it would be preferable to have just the parentheses without the @.
Re: Should range foreach be iterating over an implicit copy?
On Thu, 17 May 2012 11:42:04 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, May 17, 2012 11:05:46 Steven Schveighoffer wrote:
Hm... proposal:
foreach(e; ref r)
{
}
equates to your desired code. Would this help?
Or you could just do
for(; !r.empty; r.popFront())
{
auto e = r.front;
}
I really don't think that that's a big deal. I don't think that the
language
change would be worth having yet another thing in the language to
remember,
particularly when it's so easy to just use for to do the job.
Probably true. The only one I'd see as being impossible to duplicate is:
foreach(ref e; ref r)
-Steve
Re: AliasTuples, rather than Records, to return multiple values
On Thu, May 17, 2012 at 07:20:38PM +0200, deadalnix wrote: [...] I think you show a real need here, but I don't really like your proposal. I'd advocate for recycling the comma operator for tuple building. +1. I know the topic of comma operator has been beaten to death several times over, but I'm curious, how much is it _actually_ being used outside of for loops? Would introducing (x,y,z) tuple syntax _really_ break a lot of code? Would it even break _any_ code? -- since tuple syntax would tend to be used where you normally don't use the comma operator. T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Re: stream interfaces - with ranges
On Thu, 17 May 2012 11:46:18 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 5/17/12 9:02 AM, Steven Schveighoffer wrote: Roughly speaking, not all the details are handled, but this makes a feasible input range that will perform quite nicely for things like std.algorithm.copy. I haven't checked, but copy should be able to handle transferring a range of type T[] to an output range with element type T, if it's not able to, it should be made to work. We can do this for copy, but if we need to specialize a lot of other algorithms, maybe we didn't strike the best design. Right. The thing is, buffered streams are good as plain ranges for one thing -- forwarding data. There probably aren't many algorithms in std.algorithm that are applicable. And there is always the put idiom, Appender.put(buf) should work to accumulate all data into an array, which can then be used as a normal range. One thing that worries me, if you did something like array(bufferedStream), it would accumulate N copies of the buffer reference, which wouldn't be what you want at all. Of course, you could apply map to buffer to dup it. 3. An ultimate goal of the i/o streaming package should be to be able to do this: auto x = new XmlParser(rootElement/rootElement); or at least auto x = new XmlParser(buffered(rootElement/rootElement)); So I think arrays need to be able to be treated as a buffering streams. I tried really hard to think of some way to make this work with my existing system, but I don't think it will without unnecessary baggage, and losing interoperability with existing range functions. I think we can create a generic abstraction buffered() that layers buffering on top of an input range. If the input range has unbuffered read capability, buffered() would use those. Otherwise, it would use loops using empty, front, and popFront. Right, this is different from my proposed buffer implementation, which puts a buffer on top of an unbuffered input *stream*. But of course, we can define it for both, since it will be a compile-time interface. Where does this leave us? 1. I think we need, as Andrei says, an unbuffered streaming abstraction. I think I have this down pretty solidly in my current std.io. Great. What are the primitives? See here: https://github.com/schveiguy/phobos/blob/new-io2/std/io.d#L170 Through IODevice. The BufferedStream type is going to be redone as a range. 3. An implementation of the above definition hooked to the unbuffered stream abstraction, to be utilized in more specific ranges. But by itself, can be used as an input range or directly by code. Hah, I can't believe I wrote about the same thing above (and I swear I didn't read yours). Well, not quite :) You wrote about it being supported by an underlying range, I need to have it supported by an underlying stream. We probably need both. But yeah, I think we are mostly on the same page here. 4. Specialization ranges for each type of input you want (i.e. byLine, byChunk, textStream). What is the purpose? To avoid unnecessary double buffering? No, a specialization range *uses* a buffer range as its backing. A buffer range I think is necessarily going to be a reference type (probably a class). The specialized range won't replace the buffer range, in other words. Something like byLine is going to do the work of extracting lines from the buffer, it will reference the buffer data directly. But it won't reimplement buffering. 5. Full replacement option of File backend. File will start out with C-supported calls, but any promotion to using a more D-like range type will result in switching to a D-based stream using the above mechanisms. Of course, all existing code should compile that does not try to assume the File always has a valid FILE *. This will be tricky but probably doable. Doing this will unify all the i/o packages together into one interface -- File. I think it's a bad story for D if you have 2 ways of doing i/o (or at least 2 ways of doing the *same thing* with i/o). -Steve
Re: isInputRange instead of isForwardRange for std.algorithm.fill
On 05/17/12 17:19, Andrei Alexandrescu wrote: On 5/17/12 2:14 AM, Guillaume Chatelet wrote: It looks to me that isForwardRange is too much of a restriction for the fill algorithm, isInputRange could do, we don't need any save() here or am I missing something ? That's correct, please file as a bug so we remember. (The second range must be forward in the overload fill(InputRange, ForwardRange) because it's iterated multiple times.) Andrei Issue : http://d.puremagic.com/issues/show_bug.cgi?id=8112 Associated pull request : https://github.com/D-Programming-Language/phobos/pull/588 Guillaume
alias 'this' with opCall?
Why doesn't opCall() get forwarded by alias this? Is that a bug or a feature?
Re: enums extension
On Wednesday, 16 May 2012 at 05:54:45 UTC, Simen Kjaeraas wrote:
On Wed, 16 May 2012 06:22:15 +0200, Comrad
comrad.karlov...@googlemail.com wrote:
Dear developers and community,
I want to draw you attention to the topic which was already
discussed here:
http://forum.dlang.org/thread/9to6n8$12d6$1...@digitaldaemon.com
and here:
http://forum.dlang.org/thread/bl1n0e$1km5$1...@digitaldaemon.com
My question is: was something similar already done? are there
some plans to do that?
I have implemented this functionality in user code, with some
caveats:
module enumMagic;
string EnumDefAsString(T)()
if (is(T == enum))
{
string result = ;
foreach (e; __traits(allMembers, T)) {
result ~= e ~ = T. ~ e ~ ,;
}
return result;
}
template ExtendEnum(T, string s)
if (is(T == enum)
is(typeof({mixin(enum a{~s~});})))
{
mixin(
enum ExtendEnum {
~ EnumDefAsString!T()
~ s
~ });
}
unittest {
enum Foo {
a,
b,
c
}
alias ExtendEnum!( Foo, q{
d,
e
}) Bar;
Bar b;
b = Bar.a; // Look ma, I stole this from Foo!
b = Bar.d;
assert( Bar.a == Foo.a ); // Can compare the two.
//b = Foo.a; // But cannot assign from one to the other.
}
void main( ) {
}
A library implementation with the missing features is possible,
but would use a
struct instead of an enum, an be a rather larger piece of code
than this.
This is not really useful, because one can't pass Foo into a
function if it's declared to take Bar...
Re: alias 'this' with opCall?
On Thu, May 17, 2012 at 08:06:58PM +0200, Mehrdad wrote: Why doesn't opCall() get forwarded by alias this? Is that a bug or a feature? Sounds like a bug. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
Re: alias 'this' with opCall?
okie. http://d.puremagic.com/issues/show_bug.cgi?id=8113
Re: enums extension
On Thursday, 17 May 2012 at 18:27:07 UTC, Mehrdad wrote: On Wednesday, 16 May 2012 at 06:24:54 UTC, Robert DaSilva wrote: The inheritances notation implies that it's a subset and can be assigned to an instances of the base. This would not be true with enums. FileAccessMask foo = FileAccessMask.FILE_READ_DATA; AccessMask bar = foo; // Error Actually, that^ *should* work in my case; that was my point... Wait, no, scratch that, I misread it; you're right. It shouldn't work without a cast, but it should work with a cast.
Re: enums extension
On Wednesday, 16 May 2012 at 06:24:54 UTC, Robert DaSilva wrote: The inheritances notation implies that it's a subset and can be assigned to an instances of the base. This would not be true with enums. FileAccessMask foo = FileAccessMask.FILE_READ_DATA; AccessMask bar = foo; // Error Actually, that^ *should* work in my case; that was my point...
Re: Should range foreach be iterating over an implicit copy?
On Thursday, May 17, 2012 13:23:22 Steven Schveighoffer wrote:
On Thu, 17 May 2012 11:42:04 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, May 17, 2012 11:05:46 Steven Schveighoffer wrote:
Hm... proposal:
foreach(e; ref r)
{
}
equates to your desired code. Would this help?
Or you could just do
for(; !r.empty; r.popFront())
{
auto e = r.front;
}
I really don't think that that's a big deal. I don't think that the
language
change would be worth having yet another thing in the language to
remember,
particularly when it's so easy to just use for to do the job.
Probably true. The only one I'd see as being impossible to duplicate is:
foreach(ref e; ref r)
But that only works if front returns a ref. If it doesn't, the ref would be to
a local variable (so I don't know if that even compiles). And if front returns
a ref, all you have to do is use front instead of e. So, no it wouldn't be
_identical_, but close enough.
- Jonathan M Davis
Re: D dropped in favour of C# for PSP emulator
On Thursday, May 17, 2012 18:00:40 bearophile wrote: Andrei Alexandrescu: I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain. Names are very important, they are the fist and most important part of an API, they are the first handle for human programmers and their minds. The amount of care Python development group gives to the choice of names is visible and it makes a difference in Python usability. Important names can't be chosen by a single person, because single persons have quirks (they overstate how much common a word or concept is, etc etc). So important names are better chosen by groups, that allow to average out those quirks. I suggest to stick somewhere inside Phobos a name like binarySearch. Yes, names are important, but you'll also never get people to agree on them. They're a classic bikeshedding issue. Unless a name is patently bad, if changing it is going to break code, then you usually shouldn't change it - not when we're talking about a public API (_especially_ when it's the standard library of a language). All of the changes that we made to make Phobos' function names actually follow Phobos' official naming conventions were disruptive enough as it is. We're really trying to read language and library stability, so breaking changes need greater and greater justification for them to be worth it, and simply renaming a function generally isn't going to cut it anymore - not without a _very_ good reason. - Jonathan M Davis
Re: D dropped in favour of C# for PSP emulator
On Thursday, May 17, 2012 18:52:26 Peter Alexander wrote:
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu
wrote:
I agree binarySearch is more precise, but I also think it's a
minor issue not worth the cost of changing at this point.
Improving names of things in the standard library is a quest
that could go forever, make everybody happy we're making
progress, and achieve no substantial gain.
No need to change anything, just add something:
bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}
(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).
Yeah, but then we've added a function which adds no real functionality, and we
generally try to avoid that. So, it _might_ be reasonable to add it, but it
tends to go against how we're trying to function.
- Jonathan M Davis
Re: D dropped in favour of C# for PSP emulator
On 5/17/12 11:52 AM, Peter Alexander wrote:
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:
I agree binarySearch is more precise, but I also think it's a minor
issue not worth the cost of changing at this point. Improving names of
things in the standard library is a quest that could go forever, make
everybody happy we're making progress, and achieve no substantial gain.
No need to change anything, just add something:
bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}
(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).
I don't see much benefit in this - just lateral walking. As long as the
keyphrase binary search is present in the documentation, that's all
that's needed as far as newcomers discoverability is concerned.
Andrei
Re: D dropped in favour of C# for PSP emulator
Am Mon, 14 May 2012 10:19:40 +0200 schrieb Jakob Bornecrantz wallbra...@gmail.com: On Saturday, 12 May 2012 at 23:27:15 UTC, Alex Rønne Petersen wrote: You know, my project consisting of 130-ish source files and 24.000-ish lines of code compiles from scratch in ~20 seconds on my machine, building one file at a time... I honestly have not managed to come up with a build system for D that is actually slow, if compared to C/C++. Try using GDC the compiler that can actually produce good code, or using -inline -release flags. Debug build (GDC, multi invocation, 3 threads) real 0m42.452s Release build (GDC, multi invocation, 3 threads) real 1m0.140s Debug build (GDC, single invocation) real 0m22.151s Release build (GDC, single invocation) real 0m54.960s $ find src/ -name *.d | xargs wc -l | tail --lines 1 46057 total Cheers, Jakob. This is true. Once you decide to use GDC for whatever reason (chances of inclusion into GCC, better optimization, ...) you are also about 1 revision behind the DMD release. I usually assume that GDC 2.057 code will compile on DMD 2.059, but not the reverse. So I never actually use DMD any more to remember how fast it compiles. He could have made a similar experience. Also I see a lot of you compare D with C/C++ compilation times, whereas the author was finally deciding for C#. I believe he used that language before and it probably has a compiler with comparable speed to DMD (e.g. much faster than GDC). After all a C# compiler can compile to simplistic byte code for a VM with much less real world constraints. Often compilers for VM languages come with the compiler integrated into the standard library, allowing for easy integration into IDEs and further optimizations of the compile time. I remember Delphi (not as a VM language) had the compiler and linker integrated into the IDE which made single file rebuilds practically instantaneous. -- Marco
Posix vs. Windows
From looking at Phobos, I'm understanding that the main difference between the implementation of various features for Posix systems as compared to Windows systems (aside from the API, etc.) is that Windows tends to do a lot of stuff *before* the program is loaded (and hence requires special cases in a lot of places), whereas Posix systems tend to require you to call initializers manually (and hence they're called just like any other function). Just wanted to check, is this understanding correct? (The reasoning being, if I'm writing my own little kernel, I want to figure out whether I should be compiling Phobos with Posix or with Windows, to minimize my headaches... although I should mention that, either way, I'm going to be developing on Windows, in PE format.)
Re: Can't run 'masm386'
On 2012-05-17 17:53, Walter Bright wrote: On 5/17/2012 6:38 AM, Steven Schveighoffer wrote: Any chance this asm file can be written in D with asm block? No. Wasn't the whole point of supporting inline assembly directly in D to avoid these situations. -- /Jacob Carlborg
Re: Can't run 'masm386'
On Thursday, 17 May 2012 at 20:07:23 UTC, Jacob Carlborg wrote: On 2012-05-17 17:53, Walter Bright wrote: On 5/17/2012 6:38 AM, Steven Schveighoffer wrote: Any chance this asm file can be written in D with asm block? No. Wasn't the whole point of supporting inline assembly directly in D to avoid these situations. It has been some time since I last looked at it, but IIRC there is no way to write minit.asm in D inline asm because it requires control over the name of its data sections in order to be able to »bracket« all the ModuleInfo references (so an array of all ModuleInfos can be reconstructed later). David
Re: Is dsource .org completely deserted?
Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote in message news:mailman.886.1337255711.24740.digitalmar...@puremagic.com... On 17/05/12 01:45, Nick Sabalausky wrote: My main point is that those features (fork/pull request/issue tracking, etc) should be decoupled from hosting so that, for example, self-hosted repos would *not* provide inferior service, in fact they woudn't have to provide some stupid bundled interface at all: As a *user* (NOT as a project maintainer), you would just use *your own* choice of github, bitbucket, Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the fuck repo you wanted to access, wherever the hell said repo happens to live. The whole point is that interface and hosting have no business being coupled as they are now. Tying repo and interface together makes absolutely no sense whatsoever. I do agree with you. However ... to really get that working our only choice is to take time and effort to contribute to one of the open source code hosting solutions. I'm familiar with only two decent ones -- Launchpad (which is tied to bzr) and Gitorious (which seems to be not very well maintained these days, though I haven't looked too recently, and which IIRC doesn't include issue tracking etc.). It would be great if we could have code-hosting equivalents of WordPress, Drupal, Joomla! etc., but for now there's nothing that really cuts the mustard compared to the dedicated services out there. That's not quite what I mean (actually, AIUI, bitbucket's software can already be installed on your own server and used like WordPress. It just won't know anything about any projects hosted on http://bitbucket.org; or anywhere else). What I'm suggesting is no different from, say, image files: 1. A repo should just be a repo. It's just data. No special interface attached other than just git or hg or whatever. It's *just* a repo. This is like a png file. 2. The protocols (ie. either git/hg/etc or better yet a standard extension that handles both git and hg) would then incorporate the things that github/bitbucket have proven to be commonly useful and franky *expected*, like fork-tracking, pull requests, issue tracking, etc. I'd imagine this would likely involve special extentions to the git/hg/etc repo format. But no matter how this is actually implemented, this would be like libpng (although it would likely have a standard cmd line and web-based interfaces, too - which wouldn't make sence for libpng, but it would be essential here). 3. Then, there would be optional *frontends* to #2, in either real-program form (like Tortoise*), or in shitty-web-app form (GitHub mark 2, BitBucket mark 2, etc). These would *not* be like WordPress/etc, because WordPress/etc are packaged together with data. Instead, these would be like Photoshop, GIMP, or whatever crappy web-app equivalent people might like. Have you ever heard of, or even read, Hugi Magazine? ( http://www.hugi.scene.org/main.php?page=hugi ). It has interesting content, but the format is absolutely moronic: Instead of coming in PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's right. So you can't use your choice of viewer, and you can't even read it on another device without them actually *porting* the fucking issue. GitHub/BitBucket/etc (along with 90% of Web 2.0 and cloud), are very, very much like Hugi. And yet somehow, people seem to think it's a fantastic *advancement*. Bleh. Bear in mind, though, that even if you _did_ have the stuff available for self-hosting, in many cases it would still make sense to host with a dedicated service. Totally agree. The point here isn't to stop or obsolete hosting services, it's just to properly decouple data from software. Some of the consequences of that: A. Coder Joe finds project FooBar. He browses the source, browses through the *forks* (*even* forks hosted *elsewhere*), makes his own fork (no matter where or how he chooses to host it), and creates/browses pull-requests and issue-tickets through the interface of *his own* choosing, not some interface chosen by FooBar's maintainer. B. FooBar's maintainer doesn't even have to provide *any* special WordPress equivalent interface or anything, no matter *how* or where he chooses to host FooBar's official repo. He just exposes the repo (with the standard extensions to allow all this stuff) either on his own server, or on any hosting site, and that's it: He's done, and his project automatically has all the GitHub/BitBucket-like benefits everyone has come to expect, and all regardless of how or where he chooses to host FooBar. And his users can use whatever interface *they* prefer. *Everyone* wins. *Everyone* gets their *own* way. C. Self-hosting becomes a perfectly reasonable option, unlike now. D. External hosting, like with GitHub/BitBucket, *continues* to be a perfectly reasonable option.
Re: Is dsource .org completely deserted?
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message news:jp3ocp$2e1c$1...@digitalmars.com... 2. The protocols (ie. either git/hg/etc or better yet a standard extension that handles both git and hg) would then incorporate the things that github/bitbucket have proven to be commonly useful and franky *expected*, like fork-tracking, pull requests, issue tracking, etc. I'd imagine this would likely involve special extentions to the git/hg/etc repo format. But no matter how this is actually implemented, this would be like libpng (although it would likely have a standard cmd line and web-based interfaces, too - which wouldn't make sence for libpng, but it would be essential here). Sorry, what I meant there was it would likely have standard cmd line and web ***API*** interfaces. Ie, not actual web pages, but a web service protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever the hell the popular equivalent is these days. ;)
Re: Is dsource .org completely deserted?
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message news:jp3oq2$2esa$1...@digitalmars.com... Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message news:jp3ocp$2e1c$1...@digitalmars.com... 2. The protocols (ie. either git/hg/etc or better yet a standard extension that handles both git and hg) would then incorporate the things that github/bitbucket have proven to be commonly useful and franky *expected*, like fork-tracking, pull requests, issue tracking, etc. I'd imagine this would likely involve special extentions to the git/hg/etc repo format. But no matter how this is actually implemented, this would be like libpng (although it would likely have a standard cmd line and web-based interfaces, too - which wouldn't make sence for libpng, but it would be essential here). Sorry, what I meant there was it would likely have standard cmd line and web ***API*** interfaces. Ie, not actual web pages, but a web service protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever the hell the popular equivalent is these days. ;) Or hell, doesn't even have to be web, could be SCGI or a new thing or whatever, just some standardized network protocol.
Re: Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto));
`
To: digitalmars.D digitalmars-d@puremagic.com
User-Agent: KMail/4.8.2 (Linux/3.3.1-1-ARCH; KDE/4.8.2; x86_64; ; )
X-Authenticated: #68274723
X-Flags: 0001
X-KMail-CryptoMessageFormat: 15
X-KMail-EncryptActionEnabled: false
X-KMail-Fcc: 15
X-KMail-SignatureActionEnabled: false
X-KMail-Transport: 1406625660
X-Mailer: GMX.com Web Mailer
x-registered: 0
X-GMX-UID: pi3HbzE+3zOlOEKpenAhypZ+IGRvb0CJ
On Thursday, May 17, 2012 13:49:16 Roman D. Boiko wrote:
Is there anything preventing us from adding constraints on the
auto function return value? I mean, such language extension seems
to be quite useful.
For example, it would be no longer necessary to provide method
bodies for functions with auto return values.
In many cases this would eliminate the need for introducing an
interface.
interface returnsDuckTyped
{
auto foo() if(isInputRange(auto));
}
It would still be necessary, because the compiler needs to know what the
actual return type is. Knowing that the type implements popFront, front, and
empty isn't enough. It needs to know the actual, physical layout of the type
to generate the proper code. And when dealing with an interface, the return
type must be covariant, and unless the types are both classes and one is
derived from the other (directly or indirectly), they won't be covariant even
if they have all of the same functions.
- Jonathan M Davis
Re: New Traits
On Thursday, 17 May 2012 at 10:30:26 UTC, Jacob Carlborg wrote:
Does it work if the lambda is passed to a function:
void foo (int delegate (int x) dg)
{
wirteln(__traits(codeof, dg);
}
foo(x = x + 1);
Unforutnately, no. As written the lambda is a runtime parameter,
so there is no way the trait can get the actual function code.
Instead, all that will print is the signature of the delegate.
If that were a template parameter, it would theoretically be
possible to print the lambda expression, but as currently
implemented it doesn't.
Re: Getting the const-correctness of Object sorted once and for all
Am Mon, 14 May 2012 16:54:34 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 5/14/2012 10:08 AM, Tove wrote:
but c++ has the 'mutable' keyword as an easy escape route...
The existence of that capability means that 'const' in C++ cannot be
meaningfully reasoned about.
class Foo
{
uint a, b;
// can only call const pure nothrow members here:
lazy uint somethingLazyInitialized = { return 2 * bar(); }
uint bar() const pure nothrow @safe
{
// complex calculation
return a + b;
}
override uint toHash() const pure nothrow @safe
{
// sets the field on the first use
return somethingLazyInitialized;
}
}
Internally the lazy uint consists of a function pointer and the uint. A lazy
field acts like a read-only property. Whenever the field is read, code is
generated that first checks, if the function pointer is not null. It then
updates the uint with the return value of the function call and sets the
function pointer to null, to indicate that the value is now initialized.
An instance of Foo cannot be immutable (it makes no sense to ask for that with
lazy initialization), but it can be const. This is a form of logical const that
still allows reasoning about the code + compiler enforcement in contrast to the
more flexible (in a positive and negative sense) C++ mutable.
--
Marco
D versus C#/.NET module systems
This question on programmers.stackexchange.com questions the complexity of the C#/.NET namespace/module/dll system in relation to more elegant approaches taken by other languages. http://programmers.stackexchange.com/questions/149056/why-do-net-modules-separate-module-file-names-from-namespaces I'm not an expert in the D programming language, but i's module system seems to be nowhere near as baroque as the C#/.NET way. If anyone would care to chime in regarding D on that stack exchange question, it would be appreciated.
Re: Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto));
On Thursday, 17 May 2012 at 21:09:10 UTC, Jonathan M Davis wrote: It would still be necessary, because the compiler needs to know what the actual return type is. Knowing that the type implements popFront, front, and empty isn't enough. It needs to know the actual, physical layout of the type to generate the proper code. And when dealing with an interface, the return type must be covariant, and unless the types are both classes and one is derived from the other (directly or indirectly), they won't be covariant even if they have all of the same functions. - Jonathan M Davis I felt there is some fundamental problem, otherwise it would have been implemented already. But couldn't find any myself. Thanks!
Re: New Traits
On Thu, 17 May 2012 23:20:01 +0200, John Maschmeyer wrote:
On Thursday, 17 May 2012 at 10:30:26 UTC, Jacob Carlborg wrote:
Does it work if the lambda is passed to a function:
void foo (int delegate (int x) dg)
{
wirteln(__traits(codeof, dg);
}
foo(x = x + 1);
Unforutnately, no. As written the lambda is a runtime parameter,
so there is no way the trait can get the actual function code. Instead,
all that will print is the signature of the delegate.
If that were a template parameter, it would theoretically be possible to
print the lambda expression, but as currently implemented it doesn't.
An alias parameter to a template would actually be the ideal use-case for
what I have in mind. Essentially, it would work just like map/reduce/
filter (function passed by alias), but translate the lambda to SQL/XPath/
etc.
Re: News server load becoming more and more an issue
Andrea Fontana nos...@example.com wrote in message news:fauqirfsbdadgijxg...@forum.dlang.org... What about a new group on: https://groups.google.com/ God no. Google groups is a putrid turd.
Re: DFL?
On Wednesday, 16 May 2012 at 15:52:37 UTC, Richard Webb wrote: Try using the version from https://github.com/Rayerd/dfl instead of the one from the official site. Thank you, but that didn't work. I now get the following error: C:\D\dmd2\import\dflC:\D\dmd2\windows\bin\dmd -c -debug -g -wi -I.. all.d bas e.d application.d internal/dlib.d internal/clib.d internal/utf.d internal/com.d control.d clippingform.d form.d registry.d drawing.d menu.d notifyicon.d commond ialog.d filedialog.d folderdialog.d panel.d textbox.d richtextbox.d picturebox.d listbox.d groupbox.d splitter.d usercontrol.d button.d label.d collections.d in ternal/winapi.d internal/wincom.d event.d socket.d timer.d environment.d message box.d tooltip.d combobox.d treeview.d tabcontrol.d colordialog.d listview.d data .d clipboard.d fontdialog.d progressbar.d resources.d statusbar.d imagelist.d to olbar.d Notice: As of Phobos 2.058, std.ctype has been deprecated. It will be removed in August 2012. Please use std.ascii instead. internal\utf.d(91): Error: identifier 'useWfuncs' of 'std.file.useWfuncs' is not defined Failed. Done. Could Not Find C:\D\dmd2\import\dfl\*.obj DFL lib files not found. Error: dfl_debug.lib not found
Re: DFL?
On 05/17/12 23:47, Ronny wrote: On Wednesday, 16 May 2012 at 15:52:37 UTC, Richard Webb wrote: Try using the version from https://github.com/Rayerd/dfl instead of the one from the official site. Thank you, but that didn't work. I now get the following error: C:\D\dmd2\import\dflC:\D\dmd2\windows\bin\dmd -c -debug -g -wi -I.. all.d bas e.d application.d internal/dlib.d internal/clib.d internal/utf.d internal/com.d control.d clippingform.d form.d registry.d drawing.d menu.d notifyicon.d commond ialog.d filedialog.d folderdialog.d panel.d textbox.d richtextbox.d picturebox.d listbox.d groupbox.d splitter.d usercontrol.d button.d label.d collections.d in ternal/winapi.d internal/wincom.d event.d socket.d timer.d environment.d message box.d tooltip.d combobox.d treeview.d tabcontrol.d colordialog.d listview.d data ..d clipboard.d fontdialog.d progressbar.d resources.d statusbar.d imagelist.d to olbar.d Notice: As of Phobos 2.058, std.ctype has been deprecated. It will be removed in August 2012. Please use std.ascii instead. internal\utf.d(91): Error: identifier 'useWfuncs' of 'std.file.useWfuncs' is not defined Failed. Done. Could Not Find C:\D\dmd2\import\dfl\*.obj DFL lib files not found. Error: dfl_debug.lib not found Looks like a -d is missing on the command line to allow deprecated functions.
Re: News server load becoming more and more an issue
On 17-05-2012 23:41, Nick Sabalausky wrote: Andrea Fontananos...@example.com wrote in message news:fauqirfsbdadgijxg...@forum.dlang.org... What about a new group on: https://groups.google.com/ God no. Google groups is a putrid turd. Just use emails, rather than the web interface. ;) But really, we just need the NG server to be fixed. Nothin' wrong with good ol' NNTP. -- - Alex
Re: Is dsource .org completely deserted?
On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote: [...] Have you ever heard of, or even read, Hugi Magazine? ( http://www.hugi.scene.org/main.php?page=hugi ). It has interesting content, but the format is absolutely moronic: Instead of coming in PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's right. So you can't use your choice of viewer, and you can't even read it on another device without them actually *porting* the fucking issue. GitHub/BitBucket/etc (along with 90% of Web 2.0 and cloud), are very, very much like Hugi. And yet somehow, people seem to think it's a fantastic *advancement*. Bleh. [...] Is it really _that_ bad? GitHub does support directly running git pull/push, clone, etc. just by specifying the URL. If you want to send somebody a pull request, you could just put your repo on any git hosting service (or run your own), and email the relevant people the URL to your repo. Then they can just run git pull $url and that's that. Though you do have a point that a standard protocol for pull requests, issue tracking, etc., would be nice. If git was extended to have, say, discussion tracking for pull requests, then people can actually discuss your requests in a hosting-independent way, and you can, e.g., run 'git pull discuss --client=mutt' to read discussions via Mutt or whatever your favorite non-dumb mail/news reader is. But this is more a limitation of the current git protocol than the fault of any of the present hosting systems. You could, y'know, send pull requests to the upstream git source to rectify this situation... ;-) T -- Creativity is not an excuse for sloppiness.
Re: Is dsource .org completely deserted?
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.902.1337292243.24740.digitalmar...@puremagic.com... On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote: [...] Have you ever heard of, or even read, Hugi Magazine? ( http://www.hugi.scene.org/main.php?page=hugi ). It has interesting content, but the format is absolutely moronic: Instead of coming in PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's right. So you can't use your choice of viewer, and you can't even read it on another device without them actually *porting* the fucking issue. GitHub/BitBucket/etc (along with 90% of Web 2.0 and cloud), are very, very much like Hugi. And yet somehow, people seem to think it's a fantastic *advancement*. Bleh. [...] Is it really _that_ bad? GitHub does support directly running git pull/push, clone, etc. just by specifying the URL. If you want to send somebody a pull request, you could just put your repo on any git hosting service (or run your own), and email the relevant people the URL to your repo. Then they can just run git pull $url and that's that. Well no, it's not *that* bad (that's why I said very much like rather then the same as), but it's along the same general lines - just not quite as far. Though you do have a point that a standard protocol for pull requests, issue tracking, etc., would be nice. If git was extended to have, say, discussion tracking for pull requests, then people can actually discuss your requests in a hosting-independent way, and you can, e.g., run 'git pull discuss --client=mutt' to read discussions via Mutt or whatever your favorite non-dumb mail/news reader is. But this is more a limitation of the current git protocol than the fault of any of the present hosting systems. Right, exactly. You could, y'know, send pull requests to the upstream git source to rectify this situation... ;-) That means I'd have to actually find the time to write them ;) (and deal with C/Pyton/etc... Yuck!) Thing is though, these features have *already* been created, *multiple* times, by multiple groups of people. And yet, every single time, it was done basically the wrong way. That bugs me. ;) But you're right, the solution is for someone to actually *make* the right solution. My main point for now though, was just to at least get across the idea of what the right way even *is* and why it's better. It's only a small first step, but a necessary first step. -- Creativity is not an excuse for sloppiness. Heh :)
Re: D dropped in favour of C# for PSP emulator
On Thu, May 17, 2012 at 7:00 PM, Marco Leise marco.le...@gmx.de wrote: Your PDF is my reference manual on templates for quite a while. Thanks for putting it up! Glad to hear it :-) *Sigh* It's only 2-3 months old and is already lagging behind the current D spec. Things like is(T t = U!(Args), Args...) are now possible (I say otherwise in the appendix). The 'Args...' part is new. Also, UFCS. I should read it anew, really, and complete the missing parts. Do not hesitate to write an issue on GitHub if you see any mistakes.
Re: Should range foreach be iterating over an implicit copy?
On Thursday, 17 May 2012 at 05:48:44 UTC, Nick Sabalausky wrote: - A range is not a collection, it's a *view* of a collection (or of something else). This is a necessary distinction because ranges and collections work in fundamentally different ways: A range is, *by necessity* consumed as it's iterated - that's what popFront *does*, that's fundamentally how ranges work. For many collections, OTOH, it makes *no* sense to consume the collection while iterating it. Thus, range != collection, it's a view of a collection. - Ranges are D's answer to iterators. I don't think people used to iterators from other languages would expect their iterator to magically reset itself after being used. So I see no reason why they would expect a range (ie, an iterator-pair-with-benefits) to behave differently than that. - D's arrays conflate the ideas of collection and range, hence the odd edge case Era pointed out, and hence the need for foreach to automatically make a copy. But in my (not super-extensive) experience creating ranges, I've found that to be a problematic pattern (due to the fundamental distinction between a range and a collection), and learned to prefer making my iterable things *return* a range, rather than actually *be* ranges. - Admittedly, it would be annoying if foreach had to be used like this on all collections: foreach(e; myArray.rangeOf), so I guess it would make sense for a range to automatically be obtained when foreach-ing over a collection. However, I'm still not 100% sold on the current method of doing that (making foreach automatically copy struct-based ranges), partly because of the questionable implications it has for input ranges, and partly because (for struct-ranges) it leaves no way to access the range that's actually being iterated. - At the very least, perhaps input ranges just shouldn't be allowed to be structs? After all, structs are intended to be copied around, but input ranges, by definition, can't have their current state copied. I would be very much in support of having ranges and containers be distinct, with a standard way to get a range from a container. Something very similar is done in C#, where containers have a getEnumerator() method. The enumerator itself has a Current property and moveNext method (similar to front and popFront of a range), and thus is consumed as you use it. In my experience, this system works very well. Another advantage of giving arrays a method to obtain a range instead of them being a range themselves is that using foreach on a const/immutable array would work as expected without having to perform a slice to make it work. I would even go so far as to say that having an array BE a range really doesn't make any sense, conceptually.
Re: AliasTuples, rather than Records, to return multiple values
Le 17/05/2012 19:27, H. S. Teoh a écrit : On Thu, May 17, 2012 at 07:20:38PM +0200, deadalnix wrote: [...] I think you show a real need here, but I don't really like your proposal. I'd advocate for recycling the comma operator for tuple building. +1. I know the topic of comma operator has been beaten to death several times over, but I'm curious, how much is it _actually_ being used outside of for loops? Would introducing (x,y,z) tuple syntax _really_ break a lot of code? Would it even break _any_ code? -- since tuple syntax would tend to be used where you normally don't use the comma operator. T I'd advocate for the following behavior : 1/ void member of tuple are computed, but not stored in the tuple. 2/ A tuple with one member can unpack automagically. With both, I'm pretty the code broken is close to none. To go further, I advocate for declaration to be expression. It would allow (int a, int b) = foo(); Which rox, as Andrei said :D
Re: D dropped in favour of C# for PSP emulator
On 5/17/12 5:44 PM, Philippe Sigaud wrote: On Thu, May 17, 2012 at 7:00 PM, Marco Leisemarco.le...@gmx.de wrote: Your PDF is my reference manual on templates for quite a while. Thanks for putting it up! Glad to hear it :-) *Sigh* It's only 2-3 months old and is already lagging behind the current D spec. Things like is(T t = U!(Args), Args...) are now possible (I say otherwise in the appendix). The 'Args...' part is new. Also, UFCS. I should read it anew, really, and complete the missing parts. Do not hesitate to write an issue on GitHub if you see any mistakes. You may want to set up scripts that extract and compile code samples. Andrei
