Re: New Traits
On 2012-05-18 04:21, John Maschmeyer wrote:
Also, passing lambdas via template alias parameters works. So something
like this should work as well.
void foo(alias dg)() {
writeln(__traits(codeof, dg));
}
void main() {
foo!(x=>x+1)();
}
Very nice.
--
/Jacob Carlborg
Re: Should range foreach be iterating over an implicit copy?
On Thursday, 17 May 2012 at 14:18:55 UTC, Steven Schveighoffer wrote: [...] I believe someone has created a byRef struct that wraps a range and iterates it byRef (maybe dsimcha?) Nope, me. :) https://github.com/kyllingstad/ltk/blob/master/ltk/range.d#L12 It only supports the input range primitives, because that was all I needed when I wrote it. I offered to contribute it to Phobos (with support for the remaining range types, of course), but the interest for it seemed rather low. -Lars
Re: stream interfaces - with ranges
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
---
If you use range I/F to read bytes from device, we will always do
blocking IO - even if the device is socket. It is not efficient.
auto sock = new TcpSocketDevice();
if (sock.empty) { auto e = sock.front; }
// In empty primitive, we *must* wait the socket gets one or more
bytes or really disconnected.
// If not, what exactly returns sock.front?
// Then using range interface for socket reading enforces blocking
IO. It is *really* inefficient.
---
I think IO primitives must be distinct from range ones for the reasons
mentioned above...
I'm designing experimental IO primitives:
https://github.com/9rnsr/dio
I call the input stream "source", and call output stream "sink".
"source" has a 'pull' primitive, and sink has 'push' primitive, and
they can avoid blocking.
If you want to construct input range interface from "source", you
should use 'ranged' helper function in io.core module. 'ranged'
returns a wrapper object, and in its front method, It reads bytes from
"source", and if the read bytes not sufficient, blocks the input.
In other words, range is not almighty. We should think distinct
primitives for the IO.
Kenji Hara
2012/5/17 Steven Schveighoffer :
> 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("");
>
> or at least
>
> auto x = new XmlParser(buffered(""));
>
> 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: New Traits
On Thursday, 17 May 2012 at 21:39:03 UTC, Justin Whear wrote:
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.
I just pushed an update that should support this.
It can now resolve aliases and lambdas properly. This means
things like this will work correctly.
module pack.test;
int foo() { return 0;}
int foo(int i) { return i+1; }
void foo(double d) { }
foreach(overload; __traits(getOverloads, pack.test, "foo"))
writeln(__traits(codeof, overload);
Also, passing lambdas via template alias parameters works. So
something like this should work as well.
void foo(alias dg)() {
writeln(__traits(codeof, dg));
}
void main() {
foo!(x=>x+1)();
}
Re: Is dsource .org completely deserted?
"Andrej Mitrovic" wrote in message news:mailman.904.1337305802.24740.digitalmar...@puremagic.com... > On 5/18/12, H. S. Teoh wrote: >> Is it really that bad? > > Speaking of Github, it's really annoying how many projects get listed > here even though they have nothing to do with D: > https://github.com/languages/D/created > > I don't understand how Github manages to pick up so many java/cpp > codebases and mark them as D codebases. I wonder if it's trying to detect D files with '*d' instead of '*.d' Or, maybe an accidental regex for '.d$' instead of '\.d$' The [few] projects in there that I looked at all had either a "README.md" or at least some filename that ended with a "d".
Re: Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto)); `
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: Should range foreach be iterating over an implicit copy?
On Friday, May 18, 2012 01:04:35 Erik Jensen wrote: > 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. opSlice is the standard way to return a range from a container. - Jonathan M Davis
Re: News server load becoming more and more an issue
Andrei Alexandrescu wrote: > Things are moving Is the server using the last version of INN at all? -manfred
Re: Is dsource .org completely deserted?
On 5/18/12, H. S. Teoh wrote: > Is it really that bad? Speaking of Github, it's really annoying how many projects get listed here even though they have nothing to do with D: https://github.com/languages/D/created I don't understand how Github manages to pick up so many java/cpp codebases and mark them as D codebases.
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 Leise 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
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: 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: D dropped in favour of C# for PSP emulator
On Thu, May 17, 2012 at 7:00 PM, Marco Leise 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: Is dsource .org completely deserted?
"H. S. Teoh" 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: 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: News server load becoming more and more an issue
On 17-05-2012 23:41, Nick Sabalausky wrote: "Andrea Fontana" 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: 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\dfl>C:\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: 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\dfl>C:\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: 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" 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: 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!
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: Getting the const-correctness of Object sorted once and for all
Am Mon, 14 May 2012 16:54:34 -0700
schrieb Walter Bright :
> 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
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: Would it be possible (and useful) to introduce declarations like `auto foo() if(isInputRange(auto));
`
To: "digitalmars.D"
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: Is dsource .org completely deserted?
"Nick Sabalausky" wrote in message news:jp3oq2$2esa$1...@digitalmars.com... > "Nick Sabalausky" 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: Is dsource .org completely deserted?
"Nick Sabalausky" 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?
"Joseph Rushton Wakeling" 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 opti
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: 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
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: D dropped in favour of C# for PSP emulator
Am Mon, 14 May 2012 10:19:40 +0200 schrieb "Jakob Bornecrantz" : > 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
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
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 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: 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
>
> 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: 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: alias 'this' with opCall?
okie. http://d.puremagic.com/issues/show_bug.cgi?id=8113
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: 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: 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
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...
alias 'this' with opCall?
Why doesn't opCall() get forwarded by alias this? Is that a bug or a feature?
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
Re: stream interfaces - with ranges
On Thu, 17 May 2012 11:46:18 -0400, Andrei Alexandrescu
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("");
or at least
auto x = new XmlParser(buffered(""));
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: 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: Should range foreach be iterating over an implicit copy?
On Thu, 17 May 2012 11:42:04 -0400, Jonathan M Davis
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
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: D dropped in favour of C# for PSP emulator
Am Fri, 11 May 2012 21:02:40 +0200 schrieb Philippe Sigaud : > On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh 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: 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
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 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: 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: Can't run 'masm386'
On Thu, 17 May 2012 06:38:15 -0700, Steven Schveighoffer wrote: On Thu, 17 May 2012 01:53:59 -0400, Nick Sabalausky 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: 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 5/17/2012 6:38 AM, Steven Schveighoffer wrote: Any chance this asm file can be written in D with asm block? No.
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("");
or at least
auto x = new XmlParser(buffered(""));
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: 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: Return type inference
On 17-05-2012 16:22, Steven Schveighoffer wrote:
On Thu, 17 May 2012 09:10:18 -0400, Tobias Pankrath
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: 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
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: 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: 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: 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: Should range foreach be iterating over an implicit copy?
On Wed, 16 May 2012 17:37:14 -0400, Nick Sabalausky
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: 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 17.05.2012 18:18, Steven Schveighoffer wrote: On Thu, 17 May 2012 01:48:06 -0400, Nick Sabalausky 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: Return type inference
On Thu, 17 May 2012 09:10:18 -0400, Tobias Pankrath
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
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 j
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 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
--
Жил-был король когда-то, при нём блоха жила.
Re: Should range foreach be iterating over an implicit copy?
On Thu, 17 May 2012 01:48:06 -0400, Nick Sabalausky 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: 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).
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("");
or at least
auto x = new XmlParser(buffered(""));
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("");
or at least
auto x = new XmlParser(buffered(""));
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 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.
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
Re: Return type inference
On 5/17/12, Tobias Pankrath wrote: > snip http://d.puremagic.com/issues/show_bug.cgi?id=7483
Re: Can't run 'masm386'
On Thu, 17 May 2012 01:53:59 -0400, Nick Sabalausky 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: Standard struct constructors for the heap?
On Wed, 16 May 2012 19:50:25 -0400, bearophile
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
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.
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: 2D (or higher) equivalent of ranges?
On Wed, May 16, 2012 at 11:20 PM, Tobias Pankrath 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.
Re: Why typedef's shouldn't have been removed :(
On 5/17/12, Jonathan M Davis 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: arrays: if(null == [ ])
On Thu, 17 May 2012 00:08:49 +0100, Jonathan M Davis 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: 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: O.T. Re: D dropped in favour of C# for PSP emulator
On Thu, 17 May 2012 09:50:44 +0100, Lars T. Kyllingstad 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: 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: 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)
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: 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ć" " 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.
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 wrote: Le 16/05/2012 15:12, Steven Schveighoffer a écrit : On Tue, 15 May 2012 04:42:10 -0400, deadalnix wrote: Le 14/05/2012 21:53, Steven Schveighoffer a écrit : On Mon, 14 May 2012 15:30:25 -0400, deadalnix 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: 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: 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: Do not write object file?
The linker makes exe from obj.
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: 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
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: 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" 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: 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: 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: 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.
