Re: Can't run 'masm386'

On Wed, 16 May 2012 22:53:59 -0700, Nick Sabalausky wrote: "Adam Wilson" wrote in message news:op.wefr0erm707...@invictus.skynet.com... It looks like 2 days ago someone DID in fact change the minit.asm file. They changed the references to LICENSE and README. Your best bet is probably to re

Re: Can't run 'masm386'

"Adam Wilson" wrote in message news:op.wefr0erm707...@invictus.skynet.com... > > It looks like 2 days ago someone DID in fact change the minit.asm file. > They changed the references to LICENSE and README. Your best bet is > probably to redownload minit.obj from the druntime repo to update it's

Re: Should range foreach be iterating over an implicit copy?

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..." However, that said... "Andrei Alexandrescu" wrote... > It i

Re: Request for Review: DI Generation Improvements

On Wed, 16 May 2012 05:46:44 -0700, Steven Schveighoffer wrote: On Tue, 15 May 2012 05:51:44 -0400, kenji hara wrote: Old days import/core/thread.di was generated from src/core/thread.d . Current import/core/thread.di is generated from src/core/thread.*di* . Huh? Why the copy? Just m

Re: Can't run 'masm386'

On Wed, 16 May 2012 18:35:33 -0700, Andre Tampubolon wrote: 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\r

Re: Should range foreach be iterating over an implicit copy?

On Wednesday, 16 May 2012 at 21:40:39 UTC, Andrei Alexandrescu wrote: On 5/16/12 4:37 PM, Nick Sabalausky wrote: One counter-argument that was raised is that TDPL has an example on page 381 that indicates foreach iterates over an implicit copy. I don't have a copy handy ATM, so I can't look at

Re: Can't run 'masm386'

On Wed, 16 May 2012 18:35:33 -0700, Andre Tampubolon wrote: 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\

Re: Can't run 'masm386'

"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\

O.T. Re: D dropped in favour of C# for PSP emulator

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 se

Re: DFL?

On Wednesday, 16 May 2012 at 23:32:07 UTC, 1100110 wrote: On Wed, 16 May 2012 10:52:35 -0500, Richard Webb wrote: Try using the version from https://github.com/Rayerd/dfl instead of the one from the official site. If that doesn't help, dmd has an option to enable deprecated features. th

Can't run 'masm386'

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

Re: D dropped in favour of C# for PSP emulator

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.

Re: Standard struct constructors for the heap?

On 5/17/12, bearophile wrote: > snip Mixin workaround: import std.conv; @property string makeCtors(T)() { T t; string res; foreach (i; 0 .. typeof(t.tupleof).length) { res ~= "this(typeof(this.tupleof[0.." ~ to!string(i+1) ~ "]) tup) { thi

Re: The more interesting question

On 16-05-2012 00:20, deadalnix wrote: Le 15/05/2012 21:57, Andrew Wiley a écrit : On Tue, May 15, 2012 at 11:46 AM, deadalnix mailto:deadal...@gmail.com>> wrote: Le 15/05/2012 18:19, Gor Gyolchanyan a écrit : On Tue, May 15, 2012 at 7:51 PM, Christophe mailto:trav...@phare.normalesup.org>

Re: Standard struct constructors for the heap?

struct Node { int data; Node* next; } void main() { Node n1 = new Node(10); // OK Node n2 = new Node(10, null); // OK } I am sleepy. Third try: struct Node { int data; Node* next; } void main() { Node* n1 = new Node(10); // OK Node* n2 = new Node(10, null); // OK

Re: Standard struct constructors for the heap?

struct Node { int data; Node* next; } void main() { Node n1 = Node(10); // OK Node n2 = Node(10, null); // OK } Sorry, I meant: struct Node { int data; Node* next; } void main() { Node n1 = new Node(10); // OK Node n2 = new Node(10, null); // OK } Bye, bearophil

Standard struct constructors for the heap?

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 The idea is to just allow the heap creation of simple structs with no need to define a constructor: st

Re: Is dsource .org completely deserted?

"Joseph Rushton Wakeling" wrote in message news:mailman.840.1337179907.24740.digitalmar...@puremagic.com... > On 15/05/12 04:16, Nick Sabalausky wrote: >> I firmly believe that GitHub/BitBucket/etc-style features need to be >> standard *protocols*, not features bundled inseparably to project >>

Re: DFL?

On Wed, 16 May 2012 10:52:35 -0500, Richard Webb wrote: Try using the version from https://github.com/Rayerd/dfl instead of the one from the official site. If that doesn't help, dmd has an option to enable deprecated features. that might fix all of your issues, if using the github repo

Re: deprecating std.stream, std.cstream, std.socketstream

On 16/05/2012 17:48, H. S. Teoh wrote: On Wed, May 16, 2012 at 05:41:49PM +0100, Stewart Gordon wrote: Why would anybody want to read a large binary file _one byte at a time_? [...] import std.range; byte[] readNBytes(R)(R range, size_t n) if (isInputRange!R&& hasSlicing!R) {

Re: deprecating std.stream, std.cstream, std.socketstream

On 16/05/2012 18:21, Walter Bright wrote: You can have that range read from byChunk(). It's really the same thing that C's stdio does. And what if I want it to work on ranges that don't have a byChunk method? Stewart.

Re: Request for Review: DI Generation Improvements

On Wed, 16 May 2012 14:37:46 -0700, Jonathan M Davis wrote: On Wednesday, May 16, 2012 10:00:24 Adam Wilson wrote: The biggest problem right now is that, while we all agree that these changes need to happen, getting them merged appears to be nigh impossible. There appears to be a bottlene

Re: arrays: if(null == [ ])

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 trea

Re: The more interesting question

On Wednesday, May 16, 2012 19:52:07 Alex Rønne Petersen wrote: > I guess we can conclude that one should not use 'null' or 'is' for > arrays unless absolutely necessary. '[]' and '==' should probably do for > the majority of code. The only reason to use is is if you're checking for identity rather

Re: scope(exit) without exception handling?

On 05/16/12 23:46, H. S. Teoh wrote: > On Wed, May 16, 2012 at 11:34:18PM +0200, Timon Gehr wrote: >> On 05/16/2012 11:09 PM, H. S. Teoh wrote: >>> >>> OK, this isn't the same as your nothrow wrapper, but the principle is >>> the same. The funcWrap template can basically call _any_ function >>> tha

Re: Should range foreach be iterating over an implicit copy?

On Wednesday, 16 May 2012 at 21:37:54 UTC, 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,

Re: scope(exit) without exception handling?

On Wed, May 16, 2012 at 11:34:18PM +0200, Timon Gehr wrote: > On 05/16/2012 11:09 PM, H. S. Teoh wrote: > > > >OK, this isn't the same as your nothrow wrapper, but the principle is > >the same. The funcWrap template can basically call _any_ function > >that returns _anything_. > > > >D just acquire

Re: deprecating std.stream, std.cstream, std.socketstream

On 5/16/12 4:40 PM, Timon Gehr wrote: On 05/16/2012 11:08 PM, Andrei Alexandrescu wrote: On 5/16/12 1:00 PM, Steven Schveighoffer wrote: What I think we would end up with is a streaming API with range primitives tacked on. - empty is clunky, but possible to implement. However, it may become in

Re: Should range foreach be iterating over an implicit copy?

On 5/16/12 4:37 PM, Nick Sabalausky wrote: One counter-argument that was raised is that TDPL has an example on page 381 that indicates foreach iterates over an implicit copy. I don't have a copy handy ATM, so I can't look at it myself, but I'd love to see Andrei weigh in on this: I'm curious if t

Re: deprecating std.stream, std.cstream, std.socketstream

On 05/16/2012 11:08 PM, Andrei Alexandrescu wrote: On 5/16/12 1:00 PM, Steven Schveighoffer wrote: What I think we would end up with is a streaming API with range primitives tacked on. - empty is clunky, but possible to implement. However, it may become invalid (think of reading a file that is

Should range foreach be iterating over an implicit copy?

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 *c

Re: scope(exit) without exception handling?

On 05/16/2012 11:17 PM, Jonathan M Davis wrote: On Wednesday, May 16, 2012 23:05:07 Timon Gehr wrote: On 05/16/2012 08:59 AM, Walter Bright wrote: On 5/15/2012 8:54 PM, Mehrdad wrote: Is there any way for me to use scope(exit) (or perhaps a destructor, like RAII) to mean, "Execute this block o

Re: scope(exit) without exception handling?

On 05/16/2012 11:09 PM, H. S. Teoh wrote: OK, this isn't the same as your nothrow wrapper, but the principle is the same. The funcWrap template can basically call _any_ function that returns _anything_. D just acquired whole new levels of cool for me. :-) There are still some restrictions to

Re: Request for Review: DI Generation Improvements

On Wednesday, May 16, 2012 10:00:24 Adam Wilson wrote: > The biggest problem right now is that, while we all agree that these > changes need to happen, getting them merged appears to be nigh impossible. > There appears to be a bottleneck in the process caused by the lack of > capable persons to ver

Re: deprecating std.stream, std.cstream, std.socketstream

On 05/16/12 22:58, Steven Schveighoffer wrote: > On Wed, 16 May 2012 16:38:54 -0400, Artur Skawina wrote: > >> On 05/16/12 22:15, Steven Schveighoffer wrote: >>> I still don't get the need to "add" this to ranges. The streaming API >>> works fine on its own. >> >> This is not an argument agains

Re: The more interesting question

On Wed, May 16, 2012 at 11:22:48PM +0200, Alex Rønne Petersen wrote: > On 16-05-2012 23:09, Steven Schveighoffer wrote: > >On Wed, 16 May 2012 17:06:41 -0400, Alex Rønne Petersen > >wrote: [...] > >>void myLog(string msg) > >>{ > >>printf(msg.ptr); > >>} > >> > >>(Which works as expected because s

Re: The more interesting question

On 05/16/2012 11:08 PM, deadalnix wrote: Le 16/05/2012 22:19, Alex Rønne Petersen a écrit : ... Theoretically, yes, practically, not really. void myLog(string msg) { printf(msg); } This is exactly why array shouldn't fallback into pointer silently. Your code here is flawed and unsafe.

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, May 16, 2012 at 04:52:09PM -0400, Steven Schveighoffer wrote: > On Wed, 16 May 2012 16:30:43 -0400, H. S. Teoh > wrote: > > >On Wed, May 16, 2012 at 04:15:22PM -0400, Steven Schveighoffer wrote: > >>On Wed, 16 May 2012 15:38:02 -0400, H. S. Teoh > >> wrote: > >[...] > >>>One direction tha

Re: The more interesting question

On 16-05-2012 23:09, Steven Schveighoffer wrote: On Wed, 16 May 2012 17:06:41 -0400, Alex Rønne Petersen wrote: On 16-05-2012 22:42, Steven Schveighoffer wrote: On Wed, 16 May 2012 16:19:36 -0400, Alex Rønne Petersen wrote: Theoretically, yes, practically, not really. void myLog(string ms

Re: 2D (or higher) equivalent of ranges?

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 vehicl

Re: New Traits

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 what does this output? int foo() { return 0;} int foo(int i) { return i+1; } void foo(double d) { } foreach(i,overload; _

Re: @noreturn?

On 05/16/2012 05:29 PM, Steven Schveighoffer wrote: On Wed, 16 May 2012 10:47:33 -0400, Timon Gehr wrote: On 05/16/2012 02:27 PM, Steven Schveighoffer wrote: Is the out contract required in a method signature? That is, is it valid to omit the out contract in the .di file? Contracts are s

Re: New Traits

On Wednesday, 16 May 2012 at 17:04:32 UTC, Justin Whear wrote: Does codeof work with lambda literals? If so, I'm envisioning a LINQ-to- SQL-esque library. It works for a function literal that has been assigned to a variable. Function Literal: int function(int) func = x => x+1; writeln(_

Re: arrays: if(null == [ ])

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, S

Re: scope(exit) without exception handling?

On Wednesday, May 16, 2012 23:05:07 Timon Gehr wrote: > On 05/16/2012 08:59 AM, Walter Bright wrote: > > On 5/15/2012 8:54 PM, Mehrdad wrote: > >> Is there any way for me to use scope(exit) (or perhaps a destructor, > >> like RAII) > >> to mean, "Execute this block of code for me when the block is

Re: The more interesting question

On Wed, 16 May 2012 17:06:41 -0400, Alex Rønne Petersen wrote: On 16-05-2012 22:42, Steven Schveighoffer wrote: On Wed, 16 May 2012 16:19:36 -0400, Alex Rønne Petersen wrote: Theoretically, yes, practically, not really. void myLog(string msg) { printf(msg); } Wait, this should be an er

Re: deprecating std.stream, std.cstream, std.socketstream

On 5/16/12 1:00 PM, Steven Schveighoffer wrote: What I think we would end up with is a streaming API with range primitives tacked on. - empty is clunky, but possible to implement. However, it may become invalid (think of reading a file that is being appended to by another process). - popFront an

Re: scope(exit) without exception handling?

Le 16/05/2012 08:59, Walter Bright a écrit : On 5/15/2012 8:54 PM, Mehrdad wrote: Is there any way for me to use scope(exit) (or perhaps a destructor, like RAII) to mean, "Execute this block of code for me when the block is exited, will ya?", *without* introducing dependencies on exception handl

Re: The more interesting question

On 16-05-2012 22:42, Steven Schveighoffer wrote: On Wed, 16 May 2012 16:19:36 -0400, Alex Rønne Petersen wrote: Theoretically, yes, practically, not really. void myLog(string msg) { printf(msg); } Wait, this should be an error. You need toStringz there. -Steve Sorry, I meant: void myLog

Re: Memory reordering explained by example

Le 16/05/2012 12:59, Gor Gyolchanyan a écrit : The problem is, that ancient processor architectures are used for modern processors and software. The correct solution to the concurrency problems would be a new architecture, designed to naturally deal with concurrency. On Wed, May 16, 2012 at 12:4

Re: scope(exit) without exception handling?

On 05/16/2012 08:59 AM, Walter Bright wrote: On 5/15/2012 8:54 PM, Mehrdad wrote: Is there any way for me to use scope(exit) (or perhaps a destructor, like RAII) to mean, "Execute this block of code for me when the block is exited, will ya?", *without* introducing dependencies on exception handl

Re: arrays: if(null == [ ])

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 t

Re: D dropped in favour of C# for PSP emulator

It is. That's why there's no contains with linear complexity. Andrei I missed that. However SortedRange needs better documentation. Before I wrote this, I tried to look it up and it took some time, because I was looking in std.algorithm but SortedRange resides in std.range. The only reference

Re: scope(exit) without exception handling?

On Wed, May 16, 2012 at 10:54:26PM +0200, Mehrdad wrote: [...] > Haha maybe, idk. I just wrote what I wrote so that I could use it > like: > > noThrow({ > // giant block of code > }); > > > to execute it as nothrow. Whoa, this code works: import std.math; import std.stdio

Re: The more interesting question

Le 16/05/2012 22:19, Alex Rønne Petersen a écrit : On 16-05-2012 22:00, deadalnix wrote: Le 16/05/2012 12:10, Timon Gehr a écrit : On 05/16/2012 12:29 AM, deadalnix wrote: Le 15/05/2012 20:34, Alex Rønne Petersen a écrit : Besides, this is probably not going to change anyway. We're focusing o

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 16:38:54 -0400, Artur Skawina wrote: On 05/16/12 22:15, Steven Schveighoffer wrote: I still don't get the need to "add" this to ranges. The streaming API works fine on its own. This is not an argument against a streaming API (at least not for me), but for efficient

Re: scope(exit) without exception handling?

On Wednesday, 16 May 2012 at 20:48:27 UTC, H. S. Teoh wrote: What about: auto noThrow(T,U...)(scope T function(U) t) nothrow { return (cast(T function(U) nothrow)t)(); } auto noThrow(T,U...)(scope T delegate(U) t) nothrow { return (cast(T

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 16:30:43 -0400, H. S. Teoh wrote: On Wed, May 16, 2012 at 04:15:22PM -0400, Steven Schveighoffer wrote: On Wed, 16 May 2012 15:38:02 -0400, H. S. Teoh wrote: [...] >One direction that _could_ be helpful, perhaps, is to extend the concept >of range to include, let's t

Re: scope(exit) without exception handling?

On Wed, May 16, 2012 at 10:41:06PM +0200, Mehrdad wrote: > Oh, and I just invented a most *lovely* cast: :P > > auto noThrow(T)(scope T function() t) nothrow > { return (cast(T function() nothrow)t)(); } > > auto noThrow(T)(scope T delegate() t) nothrow > { return (cast(T delegate() nothrow)t)()

Re: The more interesting question

On Wed, 16 May 2012 16:19:36 -0400, Alex Rønne Petersen wrote: Theoretically, yes, practically, not really. void myLog(string msg) { printf(msg); } Wait, this should be an error. You need toStringz there. -Steve

Re: scope(exit) without exception handling?

Oh, and I just invented a most *lovely* cast: :P auto noThrow(T)(scope T function() t) nothrow { return (cast(T function() nothrow)t)(); } auto noThrow(T)(scope T delegate() t) nothrow { return (cast(T delegate() nothrow)t)(); }

Re: deprecating std.stream, std.cstream, std.socketstream

One direction that _could_ be helpful, perhaps, is to extend the concept of range to include, let's tentatively call it, a ChunkedRange. Basically a ChunkedRange implements the usual InputRange operations (empty, front, popfront) but adds the following new primitives: - bool hasAtLeast(R)(R ra

Re: 2D (or higher) equivalent of ranges?

On Wed, May 16, 2012 at 10:32:24PM +0200, Philippe Sigaud wrote: > On Wed, May 16, 2012 at 8:09 PM, H. S. Teoh wrote: > > Lately I've been considering how to generalize multi-dimensional > > arrays along the same lines as std.range. > > Maybe that could interest you: > > http://svn.dsource.org/p

Re: deprecating std.stream, std.cstream, std.socketstream

On 05/16/12 21:38, H. S. Teoh wrote: > On Wed, May 16, 2012 at 12:48:49PM -0500, Andrei Alexandrescu wrote: >> On 5/16/12 12:34 PM, Steven Schveighoffer wrote: >>> In other words, ranges aren't enough. >> >> This is copiously clear to me, but the way I like to think about it >> is by extending the

Re: scope(exit) without exception handling?

Hmmm... when I remove the reference to SNN.lib, the code auto scoped() nothrow { struct S { ~this() { } } S s; return s; } void main() { auto s = scoped(); } tells me Error 42: Symbol Undefined __d_framehandler

Re: 2D (or higher) equivalent of ranges?

On Wed, May 16, 2012 at 8:09 PM, H. S. Teoh wrote: > Lately I've been considering how to generalize multi-dimensional arrays > along the same lines as std.range. Maybe that could interest you: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/rangeofranges.html (code is easier to see h

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, May 16, 2012 at 04:15:22PM -0400, Steven Schveighoffer wrote: > On Wed, 16 May 2012 15:38:02 -0400, H. S. Teoh > wrote: [...] > >One direction that _could_ be helpful, perhaps, is to extend the concept > >of range to include, let's tentatively call it, a ChunkedRange. > >Basically a Chunke

Re: The more interesting question

On 16-05-2012 22:00, deadalnix wrote: Le 16/05/2012 12:10, Timon Gehr a écrit : On 05/16/2012 12:29 AM, deadalnix wrote: Le 15/05/2012 20:34, Alex Rønne Petersen a écrit : Besides, this is probably not going to change anyway. We're focusing on stabilizing the language, not changing it. This

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 15:38:02 -0400, H. S. Teoh wrote: On Wed, May 16, 2012 at 12:48:49PM -0500, Andrei Alexandrescu wrote: On 5/16/12 12:34 PM, Steven Schveighoffer wrote: >In other words, ranges aren't enough. This is copiously clear to me, but the way I like to think about it is by extend

Re: The more interesting question

Le 16/05/2012 12:10, Timon Gehr a écrit : On 05/16/2012 12:29 AM, deadalnix wrote: Le 15/05/2012 20:34, Alex Rønne Petersen a écrit : Besides, this is probably not going to change anyway. We're focusing on stabilizing the language, not changing it. This always have been a design mistake to a

digitalmars-d@puremagic.com

On Wednesday, 16 May 2012 at 18:17:50 UTC, Walter Bright wrote: On 5/16/2012 2:40 AM, Mehrdad wrote: The trouble with 'sticking to D code' is that, well, I can't... it's naked... Just insert an asm call to a function that returns the address of foo. Hmmm... interesting idea. Not a real fan

Re: New Traits

On 2012-05-16 19:04, Justin Whear wrote: Does codeof work with lambda literals? If so, I'm envisioning a LINQ-to- SQL-esque library. That would be awesome to do. Actually, if D had operator overloading that worked a bit more like it does in C++ that would be sufficient in most cases. -- /J

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, May 16, 2012 at 12:48:49PM -0500, Andrei Alexandrescu wrote: > On 5/16/12 12:34 PM, Steven Schveighoffer wrote: > >In other words, ranges aren't enough. > > This is copiously clear to me, but the way I like to think about it > is by extending the notion of range (with notions such as e.g.

Re: The more interesting question

On Wed, 16 May 2012 14:32:44 -0400, H. S. Teoh wrote: Right, which is why D's arrays (or rather, slices) are closer to the second model than the first. Actually, arrays only exist in the GC, right? Even an "explicitly declared" array is really just a slice, that just happens to reference the

Re: deprecating std.stream, std.cstream, std.socketstream

On Wednesday, 16 May 2012 at 17:48:52 UTC, Andrei Alexandrescu wrote: This is copiously clear to me, but the way I like to think about it is by extending the notion of range (with notions such as e.g. BufferedRange, LookaheadRange, and such) I tried this in cgi.d somewhat recently. It ended up

Re: The more interesting question

On Wed, May 16, 2012 at 02:03:44PM -0400, Steven Schveighoffer wrote: > On Wed, 16 May 2012 13:52:57 -0400, H. S. Teoh > wrote: [...] > >It depends upon one's mental model of what an array is. > > > >If you think of an array as a container that exists apart from its > >contents, then you'd expect

digitalmars-d@puremagic.com

On 5/16/2012 2:40 AM, Mehrdad wrote: The trouble with 'sticking to D code' is that, well, I can't... it's naked... Just insert an asm call to a function that returns the address of foo.

Re: The more interesting question

On Wed, 16 May 2012 13:52:57 -0400, H. S. Teoh wrote: On Wed, May 16, 2012 at 01:36:27PM -0400, Steven Schveighoffer wrote: On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh wrote: >On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: >[...] >>For example: >> >>auto str = "ab

2D (or higher) equivalent of ranges?

Lately I've been considering how to generalize multi-dimensional arrays along the same lines as std.range. The motivation for this is that I'm designing a generic interface for manipulating n-dimensional data, and it seems too implementation- specific to impose a particular representation of an n-

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 13:48:49 -0400, Andrei Alexandrescu wrote: On 5/16/12 12:34 PM, Steven Schveighoffer wrote: In other words, ranges aren't enough. This is copiously clear to me, but the way I like to think about it is by extending the notion of range (with notions such as e.g. Buffe

Re: deprecating std.stream, std.cstream, std.socketstream

On 5/16/12 12:34 PM, Steven Schveighoffer wrote: In other words, ranges aren't enough. This is copiously clear to me, but the way I like to think about it is by extending the notion of range (with notions such as e.g. BufferedRange, LookaheadRange, and such) instead of developing an abstract

Re: deprecating std.stream, std.cstream, std.socketstream

tbh, I've found byChunk to be less than worthless in my experience; it's a liability because I still have to wrap it somehow to real real world files. Consider reading a series of strings in the format ,[...]. I'd like it to be this simple (neglecting priming the loop): string[] s; while(!file.

Re: The more interesting question

On 16-05-2012 19:36, Steven Schveighoffer wrote: On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh wrote: On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: [...] For example: auto str = "abcabc"; assert(str[0..3] == str[3..$]); // pass assert(str[0..3] is str[3..$]); // fail

Re: The more interesting question

On Wed, May 16, 2012 at 01:36:27PM -0400, Steven Schveighoffer wrote: > On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh > wrote: > > >On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: > >[...] > >>For example: > >> > >>auto str = "abcabc"; > >>assert(str[0..3] == str[3..$]); //

Re: scope(exit) without exception handling?

On Wed, 16 May 2012 13:19:01 -0400, David Nadlinger wrote: On Wednesday, 16 May 2012 at 13:10:05 UTC, Steven Schveighoffer wrote: I don't see exception handling in the generated code (at least I don't see the _d_local_unwind2), I wonder a) if this is more efficient than scope(exit), and b

Re: The more interesting question

On Wed, 16 May 2012 13:17:17 -0400, Gor Gyolchanyan wrote: On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer wrote: On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan < gor.f.gyolchan...@gmail.com> wrote: if("" != []) assert("".length != 0); Will this fail? No. Ambiguities only

Re: The more interesting question

On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh wrote: On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: [...] For example: auto str = "abcabc"; assert(str[0..3] == str[3..$]); // pass assert(str[0..3] is str[3..$]); // fail which is very counterintuitive. [...] I don'

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 13:23:07 -0400, Walter Bright wrote: On 5/16/2012 10:18 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 11:59:37 -0400, Walter Bright wrote: On 5/16/2012 7:38 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 09:50:12 -0400, Walter Bright wrote: On 5/15/2

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 13:21:37 -0400, Walter Bright wrote: On 5/16/2012 9:41 AM, Stewart Gordon wrote: On 16/05/2012 16:59, Walter Bright wrote: On 5/16/2012 7:38 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 09:50:12 -0400, Walter Bright wrote: On 5/15/2012 3:34 PM, Nathan M. Swa

Re: deprecating std.stream, std.cstream, std.socketstream

On 5/16/2012 10:18 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 11:59:37 -0400, Walter Bright wrote: On 5/16/2012 7:38 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 09:50:12 -0400, Walter Bright wrote: On 5/15/2012 3:34 PM, Nathan M. Swan wrote: I do agree for e.g. with binar

Re: deprecating std.stream, std.cstream, std.socketstream

On 5/16/2012 9:41 AM, Stewart Gordon wrote: On 16/05/2012 16:59, Walter Bright wrote: On 5/16/2012 7:38 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 09:50:12 -0400, Walter Bright wrote: On 5/15/2012 3:34 PM, Nathan M. Swan wrote: I do agree for e.g. with binary data some data can't b

Re: scope(exit) without exception handling?

On Wednesday, 16 May 2012 at 13:10:05 UTC, Steven Schveighoffer wrote: I don't see exception handling in the generated code (at least I don't see the _d_local_unwind2), I wonder a) if this is more efficient than scope(exit), and b) if so, why can't the compiler do this automatically? I think

Re: The more interesting question

On Wed, May 16, 2012 at 09:17:17PM +0400, Gor Gyolchanyan wrote: > On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer > wrote: > > > On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan < > > gor.f.gyolchan...@gmail.com> wrote: > > > > > >> if("" != []) assert("".length != 0); > >> > >> Will thi

Re: deprecating std.stream, std.cstream, std.socketstream

On Wed, 16 May 2012 11:59:37 -0400, Walter Bright wrote: On 5/16/2012 7:38 AM, Steven Schveighoffer wrote: On Wed, 16 May 2012 09:50:12 -0400, Walter Bright wrote: On 5/15/2012 3:34 PM, Nathan M. Swan wrote: I do agree for e.g. with binary data some data can't be read with ranges (whe

Re: The more interesting question

On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer wrote: > On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan < > gor.f.gyolchan...@gmail.com> wrote: > > >> if("" != []) assert("".length != 0); >> >> Will this fail? >> > > No. Ambiguities only come into play when you use 'is'. I highly > re

Re: The more interesting question

On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: [...] > For example: > > auto str = "abcabc"; > assert(str[0..3] == str[3..$]); // pass > assert(str[0..3] is str[3..$]); // fail > > which is very counterintuitive. [...] I don't find that counterintuitive at all. To me, 'is'

Re: New Traits

On Tue, May 15, 2012 at 11:09 PM, John Maschmeyer wrote: > On Tuesday, 15 May 2012 at 17:18:57 UTC, Philippe Sigaud wrote: >> >> Can you give us a simple example of what codeof produces? How does it >> deal with functions overloads? (examples) > * Wonderful. I'm already salivating, e

Re: New Traits

On Tue, 15 May 2012 01:13:27 +0200, John Maschmeyer wrote: > I implemented some new traits that seemed to have a lot of interest > recently. > > I've implemented parameterNames, isPublic, isPrivate, > isProtected, isPackge, isExport, and codeof traits. > > parameterNames lets you get access to t

Re: The more interesting question

On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan wrote: if("" != []) assert("".length != 0); Will this fail? No. Ambiguities only come into play when you use 'is'. I highly recommend not using 'is' for arrays unless you really have a good reason, since two slices can be 'equal' b

Re: Request for Review: DI Generation Improvements

On 16-05-2012 19:00, Adam Wilson wrote: On Wed, 16 May 2012 05:46:44 -0700, Steven Schveighoffer wrote: On Tue, 15 May 2012 05:51:44 -0400, kenji hara wrote: Old days import/core/thread.di was generated from src/core/thread.d . Current import/core/thread.di is generated from src/core/thread

  1   2   >