Am Wed, 05 Jun 2013 22:35:59 -0400
schrieb "Jonathan M Davis" :
> std.compress.zlib;
> std.compress.lzw;
>
> At that point, it would be trivial to have a common module of some kind with
> shared functionality which has package access level.
>
> - Jonathan M Davis
+1
If package is ambiguous, m
On Thursday, June 06, 2013 08:09:38 Max Samukha wrote:
> On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
> > But I believe that package level access only works on the same
> > level, so you
> > couldn't have separate modules for compressing and
> > decompressing as was being
> > s
On 6/5/2013 5:13 PM, Walter Bright wrote:
On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/pull/2139
Well, I am destroyed. I need to do some more engineering. The problem is that
packages and modules have become conflated with this change.
Fixed
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
But I believe that package level access only works on the same
level, so you
couldn't have separate modules for compressing and
decompressing as was being
suggested.
'package' should be fixed so that 'package' declarations are
On Wednesday, 5 June 2013 at 22:03:05 UTC, Walter Bright wrote:
We can do an upgrade path as follows:
1. Introduce 'virtual' storage class. 'virtual' not only means
a method is virtual, but it is an *introducing* virtual, i.e.
it starts a new vtbl[] entry even if there's a virtual of the
sam
On Wednesday, June 05, 2013 22:17:49 H. S. Teoh wrote:
> On Wed, Jun 05, 2013 at 09:14:08PM -0400, Jonathan M Davis wrote:
> > On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> > > I think we accomplish this in a simpler way:
> > >
> > > 1. 'virtual' means a method is an "introducing" on
On Wednesday, 5 June 2013 at 13:19:33 UTC, Peter Lundgren wrote:
On Wednesday, 5 June 2013 at 07:17:50 UTC, Jacob Carlborg wrote:
I would suggestion using some kind of wrapper instead of doing
true monkey patching. Example:
class Wrapper
{
private Object o;
this (Object o) { this.o = o;
On Thursday, 6 June 2013 at 05:31:21 UTC, Rob T wrote:
Yes I agree that's much more intuitive.
Also having ability for methods to individually opt out of a
virtual: or final: block will be nice to have.
eg
virtual:
void a();
final void b();
...
This should satisfy everyone since you
On Thursday, 6 June 2013 at 05:19:32 UTC, H. S. Teoh wrote:
1. 'virtual' means a method is an "introducing" one.
2. 'override' means override with a non-final function.
3. 'final override' means a method overrides a base virtual
function with a final function.
4. 'final' by itself both mean fin
On Thursday, 6 June 2013 at 01:14:23 UTC, Jonathan M Davis wrote:
I would have expected something more like
1. 'virtual' means a method is an "introducing" one.
2. 'override' means override with a non-final function.
3. 'final override' means a method overrides a base virtual
function with a
f
On Wed, Jun 05, 2013 at 09:14:08PM -0400, Jonathan M Davis wrote:
> On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> > I think we accomplish this in a simpler way:
> >
> > 1. 'virtual' means a method is an "introducing" one.
> > 2. 'override' means a method overrides a base virtual func
On Wednesday, 5 June 2013 at 22:06:52 UTC, Vladimir Panteleev
wrote:
* Tango's FilePath class:
https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/FilePath.d
Note that Tango code should not be used for code intended for
Phobos unless all authors of that piece have stated they will
l
On Wednesday, 5 June 2013 at 20:52:24 UTC, Dylan Knutson wrote:
Dub is forced to define its own separate Path type because, as
its author states, using a string to represent a path "more
often than not results in hidden bugs."
You're miss quoting here. "usually will be places where the path
i
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
But I believe that package level access only works on the same
level, so you couldn't have separate modules for compressing
and decompressing as was being suggested. It would need to be
more like
std.compress.zlib;
std.compres
On Wednesday, 5 June 2013 at 22:06:09 UTC, Adam D. Ruppe wrote:
you know it might be a decent idea to change std.stdio to use
scoped imports and have the writeln that specializes on string
to not import anything else and see what happens on the hello
world case.
I think using scoped import sh
Am Thu, 06 Jun 2013 03:47:58 +0200
schrieb "bearophile" :
> When I want optimizations with this ldc I have used "-release
> -profile-verifier-noassert -O5". Is this good enough?
> I don't know why ldc2 doesn't have "-noboundscheck".
As fas as I know O4/O5 is currently not implemented and
often p
Am Wed, 05 Jun 2013 13:36:06 -0400
schrieb Andrei Alexandrescu :
> I think it's worth discussing the interface much more than the approach
> to modularization.
>
> Walter's algo traffics in InputRange!ubyte and offers an
> InputRange!ubyte. That makes sense in some situations, but often
> traf
On 2013-06-06 01:14:08 +, "Jonathan M Davis" said:
On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
I think we accomplish this in a simpler way:
1. 'virtual' means a method is an "introducing" one.
2. 'override' means a method overrides a base virtual function with a final
functi
On Thursday, June 06, 2013 04:10:26 Marco Leise wrote:
> Am Wed, 05 Jun 2013 18:31:22 -0400
>
> schrieb Andrei Alexandrescu :
> > https://github.com/D-Programming-Language/dmd/pull/2139
> >
> > Andrei
>
> To those who don't want to see a < 1000 lines module: Please
> consider that as soon as we'
Am Thu, 06 Jun 2013 00:00:19 +0200
schrieb "Adam D. Ruppe" :
> $ time make
> dmd -version=withoaut_custom_runtime_reflection
> -debug=allocations -m64 -debug -c object.d minimal.d invariant.d
> memory.d -gc -defaultlib= -debuglib=
> gcc minimal.o object.o invariant.o memory.o -o minimal -g -m64
Am Wed, 05 Jun 2013 18:31:22 -0400
schrieb Andrei Alexandrescu :
> https://github.com/D-Programming-Language/dmd/pull/2139
>
> Andrei
To those who don't want to see a < 1000 lines module: Please
consider that as soon as we'd merge multiple compression
algorithms into one file for the sake of mak
I have seen this code is about 6 times faster compiled with
ldc2 compared to dmd:
I run it with 1 command line argument.
Bye,
bearophile
David Nadlinger:
Alpha-quality binary packages are available as part of 0.11.0
Beta 3:
http://forum.dlang.org/post/mailman.871.1370475122.13711.digitalmars-d-...@puremagic.com
I have done few small tests:
With no optimization dmd compiles about twice faster (or more)
than ldc2.
When I wan
On 6/5/13 6:11 PM, Timothee Cour wrote:
currently std.demangle.demangle doesn't work with unicode (see example below)
If we decide to keep allowing unicode symbols (as opposed to just unicode
strings/comments), we must
address this issue. Will supporting this negatively impact performance (of b
On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> I think we accomplish this in a simpler way:
>
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means a method overrides a base virtual function with a final
> function.
> 3. 'override virtual' means override with a
On Thu, May 30, 2013 at 10:57 PM, Walter Bright
wrote:
> On 5/30/2013 5:00 PM, Peter Williams wrote:
>
>> On 31/05/13 05:07, Walter Bright wrote:
>>
>>> On 5/30/2013 4:24 AM, Manu wrote:
>>>
We don't all know English. Plenty of people don't.
I've worked a lot with Sony and Nintendo code/
On Thursday, 6 June 2013 at 01:00:36 UTC, Steven Schveighoffer
wrote:
This was circa 2003. Look at the state of Java from then. And
also consider that when the *decision* was made to make
non-virtual the default, was considerably before then.
-Steve
This is why I wrote that this may have b
On Wed, 05 Jun 2013 20:49:00 -0400, deadalnix wrote:
On Wednesday, 5 June 2013 at 20:01:06 UTC, Kapps wrote:
Anders Hejlsberg talks about why they decided to use final by default
in C# at http://www.artima.com/intv/nonvirtualP.html. See the
Non-Virtual is the Default section. They do this *
On Thursday, 6 June 2013 at 00:49:55 UTC, Walter Bright wrote:
4. none means final and non-overriding.
BTW be sure not to remove the final keyword, since having it to
undo a "virtual:" will still be useful to at least of us.
On Wednesday, June 05, 2013 15:16:56 Walter Bright wrote:
> On 6/5/2013 2:19 PM, Jonathan M Davis wrote:
> > On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
> >> On 6/5/2013 11:36 AM, David Nadlinger wrote:
> >>> It also doesn't utilize template constraints, reinvents
> >>> isRandomAccess
On Wednesday, 5 June 2013 at 22:50:27 UTC, Simen Kjaeraas wrote:
On 2013-06-06, 00:32, Adam D. Ruppe wrote:
But I want to clearify this #1:
class A { virtual void foo(); }
class B : A { virtual void foo(); }
With C# semantics (as has been suggested as a basis):
class A {
virtual void foo
On Wednesday, 5 June 2013 at 20:01:06 UTC, Kapps wrote:
Anders Hejlsberg talks about why they decided to use final by
default in C# at http://www.artima.com/intv/nonvirtualP.html.
See the Non-Virtual is the Default section. They do this
*because* they saw the drawbacks of Java's virtual by defa
On 6/5/2013 4:29 PM, Steven Schveighoffer wrote:
On Wed, 05 Jun 2013 18:56:28 -0400, Walter Bright
wrote:
On 6/5/2013 3:37 PM, Steven Schveighoffer wrote:
No, I think it introduces a new foo. Calling A.foo does not call B.foo. In
other words, it hides the original implementation, there are
David Nadlinger:
Whoops, I absentmindedly updated the time stamp, without
noticing that it actually caused the month to change. Should be
fixed now.
The page works now.
I'll try this LDC2.
For Windows I suggest to distribute a single 7zip that contains
both ldc and the needed gcc libs (poss
On Thursday, 6 June 2013 at 00:05:03 UTC, bearophile wrote:
It gives me a "page not found"
Whoops, I absentmindedly updated the time stamp, without noticing
that it actually caused the month to change. Should be fixed now.
David
On 6/5/13 7:39 PM, Manu wrote:
Thank you!
A hyperlink is always so much more substantial than a reasoned claim ;)
It's a hyperlink to an extensive argument. And assuming you refer to
yours as the reasoned claim, I'd have to raise a finger to parts of that
:o).
That being said, a gentleman m
On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/pull/2139
Well, I am destroyed. I need to do some more engineering. The problem is that
packages and modules have become conflated with this change.
David Nadlinger:
I just posted a small writeup describing the current situation
to my blog:
http://klickverbot.at/blog/2013/05/the-state-of-ldc-on-windows/
It gives me a "page not found"
Bye,
bearophile
Hi all,
As some of you might already know, LDC has come dangerously close
to being usable on Win32/MinGW recently.
I just posted a small writeup describing the current situation to
my blog:
http://klickverbot.at/blog/2013/05/the-state-of-ldc-on-windows/
Alpha-quality binary packages are av
Thank you!
A hyperlink is always so much more substantial than a reasoned claim ;)
On 6 Jun 2013 06:05, "Kapps" wrote:
> On Tuesday, 4 June 2013 at 04:07:10 UTC, Andrei Alexandrescu wrote:
>
>> Choosing virtual (or not) by default may be dubbed a mistake only in a
>> context. With the notable exc
On Wed, 05 Jun 2013 18:56:28 -0400, Walter Bright
wrote:
On 6/5/2013 3:37 PM, Steven Schveighoffer wrote:
No, I think it introduces a new foo. Calling A.foo does not call
B.foo. In
other words, it hides the original implementation, there are two vtable
entries
for foo.
At least, that
Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/pull/2139
Probably you already know the following things because they see,
similar solutions.
Python uses "__init__.py" instead of "package.d", it can also be
empty:
http://docs.python.org/2/tutorial/modules.html
__init__
On Wednesday, 5 June 2013 at 22:53:36 UTC, Paulo Pinto wrote:
Here it is described the C# semantics for virtual methods
http://msdn.microsoft.com/en-us/library/6fawty39.aspx
Ah thanks, I've done very little C# so this is all pretty new to
me.
This seems ok too, and actually now that I thin
On 6/5/2013 3:37 PM, Steven Schveighoffer wrote:
No, I think it introduces a new foo. Calling A.foo does not call B.foo. In
other words, it hides the original implementation, there are two vtable entries
for foo.
At least, that is how I understood the C# description from that post, and it
seem
Am 06.06.2013 00:37, schrieb Steven Schveighoffer:
On Wed, 05 Jun 2013 18:32:58 -0400, Adam D. Ruppe
wrote:
On Wednesday, 5 June 2013 at 22:03:05 UTC, Walter Bright wrote:
1. Introduce 'virtual' storage class. 'virtual' not only means a
method is virtual, but it is an *introducing* virtual, i
On 2013-06-06, 00:32, Adam D. Ruppe wrote:
But I want to clearify this #1:
class A { virtual void foo(); }
class B : A { virtual void foo(); }
With C# semantics (as has been suggested as a basis):
class A {
virtual void foo() {
writeln("A.foo");
}
}
class B : A {
virtual vo
On Wed, 05 Jun 2013 18:32:58 -0400, Adam D. Ruppe
wrote:
On Wednesday, 5 June 2013 at 22:03:05 UTC, Walter Bright wrote:
1. Introduce 'virtual' storage class. 'virtual' not only means a method
is virtual, but it is an *introducing* virtual, i.e. it starts a new
vtbl[] entry even if there'
On Wednesday, 5 June 2013 at 22:03:05 UTC, Walter Bright wrote:
1. Introduce 'virtual' storage class. 'virtual' not only means
a method is virtual, but it is an *introducing* virtual, i.e.
it starts a new vtbl[] entry even if there's a virtual of the
same name in the base classes. This means th
https://github.com/D-Programming-Language/dmd/pull/2139
Andrei
I'd like to point out some of the pitfalls of using a raw string
as a representation of a path, too.
You've got to manually normalize strings before any comparison is
done. Even a single directory delimer at the end of the string
means that the paths won't compare correctly. This takes a good
amo
On Wednesday, 5 June 2013 at 22:06:52 UTC, Vladimir Panteleev
wrote:
On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
Hello,
I'd like to open up the idea of Path being an object in
std.path. I've submitted a pull
(https://github.com/D-Programming-Language/phobos/pull/1333)
that
On 6/5/2013 2:23 PM, Jonathan M Davis wrote:
That was pretty much the point of DIP 37. If it was only about being able to
import packages, then you could just do foo/all.d and have all.d publicly
import all of the foo package - many people do this now. But DIP 37 will allow
us to do this in a way
On 6/5/2013 2:42 PM, Dmitry Olshansky wrote:
if you limit their hunger for std.stdio/std.format to unittests where
appropriate.
I agree that those two modules in particular need to be excised from being
imported willy-nilly.
On 6/5/2013 2:19 PM, Jonathan M Davis wrote:
On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
On 6/5/2013 11:36 AM, David Nadlinger wrote:
It also doesn't utilize template constraints, reinvents
isRandomAccessRange && hasSlicing under a poor name,
Didn't want to include all of Phobos
On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
Hello,
I'd like to open up the idea of Path being an object in
std.path. I've submitted a pull
(https://github.com/D-Programming-Language/phobos/pull/1333)
that adds a Path struct to std.path, "which exposes a much more
palatable
you know it might be a decent idea to change std.stdio to use
scoped imports and have the writeln that specializes on string to
not import anything else and see what happens on the hello world
case.
On Wednesday, 5 June 2013 at 21:15:06 UTC, Jonathan M Davis wrote:
And since it's an example, it makes even less sense.
Not if you want to show off D's compile speed! On my box,
compiling Walter's module with -c took:
~$ time dmd -c compress
real0m0.032s
user0m0.023s
sys 0m0.007
On 6/5/2013 2:55 PM, Walter Bright wrote:
On 6/5/2013 1:13 PM, Andrei Alexandrescu wrote:
On 6/5/13 4:01 PM, Kapps wrote:
Anders Hejlsberg talks about why they decided to use final by default in
C# at http://www.artima.com/intv/nonvirtualP.html. See the Non-Virtual
is the Default section. They
On 6/5/2013 1:13 PM, Andrei Alexandrescu wrote:
On 6/5/13 4:01 PM, Kapps wrote:
Anders Hejlsberg talks about why they decided to use final by default in
C# at http://www.artima.com/intv/nonvirtualP.html. See the Non-Virtual
is the Default section. They do this *because* they saw the drawbacks of
06-Jun-2013 01:36, Dmitry Olshansky пишет:
06-Jun-2013 01:14, Jonathan M Davis пишет:
On Wednesday, June 05, 2013 20:56:12 SomeDude wrote:
On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
It also doesn't utilize template constraints, reinvents
isRandomAccessRange && hasSlicing
06-Jun-2013 01:19, Jonathan M Davis пишет:
On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
On 6/5/2013 11:36 AM, David Nadlinger wrote:
It also doesn't utilize template constraints, reinvents
isRandomAccessRange && hasSlicing under a poor name,
Didn't want to include all of Phobos,
06-Jun-2013 01:14, Jonathan M Davis пишет:
On Wednesday, June 05, 2013 20:56:12 SomeDude wrote:
On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
It also doesn't utilize template constraints, reinvents
isRandomAccessRange && hasSlicing under a poor name, uses C
printf (!) in the
Kapps:
C# chose final-by-default not simply because of performance
issues but because of [...]
One of the best posts of this thread, Kapps :-)
And indeed, the care for versioning is one important part of C#
design.
Bye,
bearophile
On Wednesday, June 05, 2013 20:25:44 w0rp wrote:
> An the subject of std.algorithm being very large, I realised
> something. Once the import change is in that makes it possible to
> import sub-modules all at once, there will be some nice potential
> for splitting up std.algorithm a bit into sub-mod
On 6/5/2013 12:47 PM, Brad Roberts wrote:
Well, both bundle and parcel can be both nouns and verbs.
Then I propose we use the terms "dessertTopping" and "floorWax".
On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
> On 6/5/2013 11:36 AM, David Nadlinger wrote:
> > It also doesn't utilize template constraints, reinvents
> > isRandomAccessRange && hasSlicing under a poor name,
>
> Didn't want to include all of Phobos, which happens if you import std.ra
On 6/5/2013 1:29 PM, Idan Arye wrote:
We already have that function and it's called `chunks`:
Well, we'll have to then change 'InputRange' to 'spew'.
On Wednesday, June 05, 2013 13:37:10 Timothee Cour wrote:
> isn't that what DIP37 is supposed to address?
Yes. It will make it so that you have package.d with in the package, and it'll
have public imports for all of the stuff that you want to be imported when you
import the package. It also then
On 6/5/13 4:29 PM, Idan Arye wrote:
On Wednesday, 5 June 2013 at 19:47:57 UTC, Brad Roberts wrote:
On 6/5/13 12:34 PM, Andrei Alexandrescu wrote:
On 6/5/13 2:26 PM, Brad Anderson wrote:
On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
Right now we have joiner(), which giv
On Wednesday, June 05, 2013 20:56:12 SomeDude wrote:
> On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
> > It also doesn't utilize template constraints, reinvents
> > isRandomAccessRange && hasSlicing under a poor name, uses C
> > printf (!) in the examples, has random 2-3 letter
Am 05.06.2013 22:01, schrieb Kapps:
On Tuesday, 4 June 2013 at 04:07:10 UTC, Andrei Alexandrescu wrote:
Choosing virtual (or not) by default may be dubbed a mistake only in a
context. With the notable exception of C#, modern languages aim for
flexibility and then do their best to obtain performa
Oh ok. I thought you suspect a bug in Derelict.
On Wednesday, 5 June 2013 at 20:51:03 UTC, Namespace wrote:
It's not a bug:
http://dblog.aldacron.net/forum/index.php?topic=820.0
Hmm, that thread seems to address something else? I'm talking
about simply making an array of pointers to opaque structs, which
seems to be broken in general (see
On 6/5/2013 12:45 PM, H. S. Teoh wrote:
This is a maintenance nightmare, though.
A minor bit of tedium, yes. A nightmare, that's way overblowing things.
Neglecting it or making a typo results in a compile time lookup error, not
launching nuclear missiles.
I'd vote against it unless doing
There's a significant difference between a type which has a
value and units and
one which is basically just a string or array of strings
wrapped by another
type. Not that a Path struct is without value, but I think that
there's a very
large difference in the amount of value that the two provide.
It's not a bug:
http://dblog.aldacron.net/forum/index.php?topic=820.0
On 6/5/2013 11:36 AM, David Nadlinger wrote:
It also doesn't utilize template constraints, reinvents isRandomAccessRange &&
hasSlicing under a poor name,
Didn't want to include all of Phobos, which happens if you import std.range.
uses C printf (!) in the examples,
Again, trying to make it
On Wednesday, 5 June 2013 at 20:38:08 UTC, Adam D. Ruppe wrote:
On Wednesday, 5 June 2013 at 20:34:17 UTC, Johan F. wrote:
struct SDL_Texture;
Just guessing here, what happens if you make that
extern(C) struct SDL_Texture;
?
It doesn't change anything.
Also, is simply adding {} the rig
On Wed, Jun 5, 2013 at 1:34 PM, Jonathan M Davis wrote:
> On Wednesday, June 05, 2013 22:19:21 Dylan Knutson wrote:
> > > I don't have a strong opinion regarding Path object vs. string
> > > functions, and I agree both have advantages and disadvantages.
> > > But I would be opposed to having both.
On Wed, 05 Jun 2013 15:38:56 -0400, Andrei Alexandrescu
wrote:
On 6/5/13 2:42 PM, H. S. Teoh wrote:
Is that even necessary? We could just do this:
std/algorithm.d
module std.algorithm;
public import std.algorithm.search;
public import std.algorithm.compare;
public import std.algorit
On Wednesday, 5 June 2013 at 20:37:27 UTC, Timon Gehr wrote:
On 06/05/2013 10:34 PM, Johan F. wrote:
I'm fiddling around with SDL2 using Derelict3, and I'm trying
to make an
array of SDL_Texture pointers, like so:
SDL_Texture*[] frames;
... make texture ...
frames ~= texture;
Howe
On Wednesday, 5 June 2013 at 20:34:17 UTC, Johan F. wrote:
struct SDL_Texture;
Just guessing here, what happens if you make that
extern(C) struct SDL_Texture;
?
Also, is simply adding {} the right way of fixing it, or will
that possibly break something else?
This shouldn't break anyth
On 06/05/2013 10:34 PM, Johan F. wrote:
I'm fiddling around with SDL2 using Derelict3, and I'm trying to make an
array of SDL_Texture pointers, like so:
SDL_Texture*[] frames;
... make texture ...
frames ~= texture;
However, this yields the following error:
/Users/jaffe1/prog/De
isn't that what DIP37 is supposed to address?
On Wed, Jun 5, 2013 at 12:47 PM, H. S. Teoh wrote:
> On Wed, Jun 05, 2013 at 03:44:30PM -0400, Andrei Alexandrescu wrote:
> > On 6/5/13 3:38 PM, Andrei Alexandrescu wrote:
> > >On 6/5/13 2:42 PM, H. S. Teoh wrote:
> > >>Is that even necessary? We cou
I'm fiddling around with SDL2 using Derelict3, and I'm trying to
make an array of SDL_Texture pointers, like so:
SDL_Texture*[] frames;
... make texture ...
frames ~= texture;
However, this yields the following error:
/Users/jaffe1/prog/Derelict3/import/derelict/sdl2/types.d(1865):
On Wednesday, June 05, 2013 22:19:21 Dylan Knutson wrote:
> > I don't have a strong opinion regarding Path object vs. string
> > functions, and I agree both have advantages and disadvantages.
> > But I would be opposed to having both.
>
> Personally, I'd prefer to just use the Path struct in std.p
On Wednesday, 5 June 2013 at 19:47:57 UTC, Brad Roberts wrote:
On 6/5/13 12:34 PM, Andrei Alexandrescu wrote:
On 6/5/13 2:26 PM, Brad Anderson wrote:
On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei
Alexandrescu wrote:
Right now we have joiner(), which given several ranges of T,
offers a
rang
currently there's no way to perform cross-platform operations.
what about:
---
enum Platform{Posix,Windows}
version(Posix) enum PlatformDefault=Platform.Posix; else enum
PlatformDefault=Platform.Windows;
struct Path(T=PlatformDefault){}
void main(){
Path!(Platform.Posix) path="a\b";
auto path2=pa
I don't have a strong opinion regarding Path object vs. string
functions, and I agree both have advantages and disadvantages.
But I would be opposed to having both.
Personally, I'd prefer to just use the Path struct in std.path.
While a Path can be represented as a string, it's not the same
c
On 6/5/13 3:47 PM, Brad Roberts wrote:
Well, both bundle and parcel can be both nouns and verbs.
Hrm, yah. Not even sure what the relative frequencies are.
Andrei
On 6/5/13 4:01 PM, Kapps wrote:
Anders Hejlsberg talks about why they decided to use final by default in
C# at http://www.artima.com/intv/nonvirtualP.html. See the Non-Virtual
is the Default section. They do this *because* they saw the drawbacks of
Java's virtual by default and were able to learn
On Tuesday, 4 June 2013 at 04:07:10 UTC, Andrei Alexandrescu
wrote:
Choosing virtual (or not) by default may be dubbed a mistake
only in a context. With the notable exception of C#, modern
languages aim for flexibility and then do their best to obtain
performance. In the context of D in particu
On Wed, Jun 05, 2013 at 03:44:30PM -0400, Andrei Alexandrescu wrote:
> On 6/5/13 3:38 PM, Andrei Alexandrescu wrote:
> >On 6/5/13 2:42 PM, H. S. Teoh wrote:
> >>Is that even necessary? We could just do this:
> >>
> >>std/algorithm.d
> >>module std.algorithm;
> >>public import std.algorithm.
On Wednesday, 5 June 2013 at 19:49:05 UTC, H. S. Teoh wrote:
Oh? I thought the compiler would be smart enough to look for
"std/algorithm.d" when you say "import std.algorithm", and to
look for std/algorithm/*.d when there's trailing stuff
following "std.algorithm".
import testmod.test;
import
On Wed, Jun 05, 2013 at 12:47:44PM -0700, Brad Roberts wrote:
> On 6/5/13 12:34 PM, Andrei Alexandrescu wrote:
> >On 6/5/13 2:26 PM, Brad Anderson wrote:
> >>On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
> >>>Right now we have joiner(), which given several ranges of T, offer
On 6/5/13 12:34 PM, Andrei Alexandrescu wrote:
On 6/5/13 2:26 PM, Brad Anderson wrote:
On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
Right now we have joiner(), which given several ranges of T, offers a
range of T. Developing along that idea, we should have two opposite
On Wed, Jun 05, 2013 at 03:38:56PM -0400, Andrei Alexandrescu wrote:
> On 6/5/13 2:42 PM, H. S. Teoh wrote:
> >Is that even necessary? We could just do this:
> >
> >std/algorithm.d
> >module std.algorithm;
> >public import std.algorithm.search;
> >public import std.algorithm.compare;
> >pub
On 6/5/13 3:38 PM, Andrei Alexandrescu wrote:
On 6/5/13 2:42 PM, H. S. Teoh wrote:
Is that even necessary? We could just do this:
std/algorithm.d
module std.algorithm;
public import std.algorithm.search;
public import std.algorithm.compare;
public import std.algorithm.iteration;
public
On 6/5/13 2:42 PM, H. S. Teoh wrote:
Is that even necessary? We could just do this:
std/algorithm.d
module std.algorithm;
public import std.algorithm.search;
public import std.algorithm.compare;
public import std.algorithm.iteration;
public import std.algorithm.sort;
public import std.al
On 6/5/13 2:36 PM, David Nadlinger wrote:
On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
itemize() takes a range of ranges of T and offers a range of T. For
example, given a range of T[], offers a range of T.
joiner?
collect() takes a range of T and offers a range of T[
1 - 100 of 188 matches
Mail list logo
