On Sat, 05 Mar 2011 13:31:22 -0500, dsimcha wrote:
On 3/5/2011 1:27 PM, Lars T. Kyllingstad wrote:
Does this mean that it can save to vector formats now, or just that you
intend to add that functionality? EPS would be awesome, because it's
pretty much the only thing you can use directly with
Daniel Gibson napisał:
You'd need a fridge with two doors: one in the front, one in the back. Insert
new food in the front, get food to eat from the back (or the other way round).
But reinsert opened food in the back (or, in the alternative case, in the
front).
Or a cylinder-shaped
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what everybody expects? I'm not sure, but another possibility
would be to treat these as if dir/subdir/. is passed. What is the
result
On Sunday 06 March 2011 00:37:15 Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what everybody expects? I'm not sure, but another possibility
would be to
On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote:
As mentioned in the std.path.getName(): Screwy by design? thread, I
started working on a rewrite of std.path a long time ago, but I got
sidetracked by other things. The recent discussion got me working on it
again, and it turned
Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?
Some of the potential benefits:
Legibility, understandability and
On Sun, 06 Mar 2011 01:21:56 -0800, Jonathan M Davis wrote:
On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote:
As mentioned in the std.path.getName(): Screwy by design? thread, I
started working on a rewrite of std.path a long time ago, but I got
sidetracked by other things. The
On Sunday 06 March 2011 02:59:25 Jim wrote:
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not? Should we
perhaps seek to have a consistent naming convention for all identifier
names in Phobos?
Some of the
On Sunday 06 March 2011 03:36:50 Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 01:21:56 -0800, Jonathan M Davis wrote:
On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote:
As mentioned in the std.path.getName(): Screwy by design? thread, I
started working on a rewrite of std.path
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what everybody expects? I'm not sure, but another possibility
would
Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
I would say:
basename (dir/subdir/) - (or .)
dirname (dir/subdir/) - dir/subdir
basename (dir/subdir) -
On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote:
On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:ikofkc$322$1...@digitalmars.com...
On Sunday 06 March 2011 04:11:35 Lars T. Kyllingstad wrote:
On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote:
On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet
On Sunday 06 March 2011 03:56:53 Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what
On Sat, 05 Mar 2011 16:32:55 +, Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:ikofkc$322$1...@digitalmars.com...
As mentioned in the std.path.getName(): Screwy by design? thread,
Jim Wrote:
Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?
Some of the potential benefits:
Legibility,
Jim Wrote:
Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?
Some of the potential benefits:
Legibility,
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:ikvsq5$1qr9$2...@digitalmars.com...
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
Jim bitcir...@yahoo.com wrote in message
news:ikvped$1o35$1...@digitalmars.com...
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming convention for all
identifier
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
threads[i] = new Thread (
Russel Winder rus...@russel.org.uk wrote:
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
OK, this one surprised me, all that remains is for me to find out why it
shouldn't have done:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ; } )
( 0.0 , outputData )
David,
I am not sure how properly to report this in this review period . . .
If I use:
taskPool.reduce ! ( a + b ) ( 0.0 , outputData )
then it works. If however I try:
taskPool.reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
I get:
On 03/06/2011 01:35 AM, Nick Sabalausky wrote:
spirdenis.s...@gmail.com wrote in message
news:mailman.2213.1299361218.4748.digitalmar...@puremagic.com...
On 03/05/2011 09:57 PM, Nick Sabalausky wrote:
* currentDirSymbol, currentDirSym, curDirSymbol
currDirSymbol, But I'd be fine with the
http://d.puremagic.com/issues/show_bug.cgi?id=5710
It's a DMD issue. I've been meaning to report it for a while.
Unfortunately making a workaround for it would be a huge PITA at best
and impossible in the toughest use cases.
On 3/6/2011 9:12 AM, Russel Winder wrote:
David,
I am not sure
On 03/06/2011 09:37 AM, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
I think all your questions are sensible, Rainer.
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what everybody expects? I'm not
On 03/06/2011 12:50 PM, Jérôme M. Berger wrote:
Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
I would say:
basename (dir/subdir/) - (or .)
dirname
On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
directory(dir/subdir/) -- dir
Is this what everybody
Russel Winder:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ; }
) ( 0.0 , outputData )
import std.stdio, std.algorithm, std.range;
void main() {
auto
Nick Sabalausky Wrote:
Jim bitcir...@yahoo.com wrote in message
news:ikvped$1o35$1...@digitalmars.com...
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming
On 03/06/2011 02:43 PM, Russel Winder wrote:
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
On 3/6/11 6:31 AM, Lars T. Kyllingstad wrote:
In summary, it seems currentDirSymbol, baseName, dirName and driveName
are clear winners. Less clear, but still voted for by the majority, are
extension and stripExtension. It is a tie between dirSep and
dirSeparator.
Below are the votes I
On 03/06/2011 03:03 PM, Russel Winder wrote:
PS If you ask why not:
reduce ! ( a+b ) ( 0.0 , outputData )
I find this somehow unacceptable. It's the string, its not a function.
Fine, my problem, but that still leaves the above.
You are not the only one ;-). The ugliest trick I
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
basename(dir/subdir/) -- subdir
On 3/6/11 9:27 AM, foobar wrote:
Nick Sabalausky Wrote:
Jimbitcir...@yahoo.com wrote in message
news:ikvped$1o35$1...@digitalmars.com...
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not?
Should we perhaps seek to
On 03/06/2011 04:27 PM, foobar wrote:
Are there other concerns?
I think that every individual variable, function and type in Phobos should
use the naming convention of whatever random language the author happened to
be thinking of when they wrote it. That way Phobos won't seem messy.
On 3/6/11, Caligo iteronve...@gmail.com wrote:
Kind of off-topic, but does anyone know if GDC is still scheduled to be
included in GCC 4.7?
Dunno. But this raises an interesting observation. If GDC gets
included in the GCC mainline, I wonder if the MinGW and TDM-MinGW
teams will start getting
Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
What about file.? I tried it on NTFS, but trailing '.' seems to always
be cut off. Is it possible to create such a file on unix systems? If
yes, you won't be able to recreate it from the result of basename()
On Sun, 2011-03-06 at 09:33 -0500, dsimcha wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5710
It's a DMD issue. I've been meaning to report it for a while.
Unfortunately making a workaround for it would be a huge PITA at best
and impossible in the toughest use cases.
OK, I signed
Andrei Alexandrescu Wrote:
On 3/6/11 9:27 AM, foobar wrote:
Nick Sabalausky Wrote:
Jimbitcir...@yahoo.com wrote in message
news:ikvped$1o35$1...@digitalmars.com...
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated
spir Wrote:
On 03/06/2011 04:27 PM, foobar wrote:
Are there other concerns?
I think that every individual variable, function and type in Phobos
should
use the naming convention of whatever random language the author
happened to
be thinking of when they wrote it. That way
On Sun, 2011-03-06 at 10:08 -0500, bearophile wrote:
Russel Winder:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ;
} ) ( 0.0 , outputData )
import
foobar f...@bar.com wrote:
I would also add to the above excellent point that in order to
prevent unworthy people of programming in the holly
You have a typo there.
Andrei
Well than I must be unworthy of the D community. I must flee before you
come chasing me with pitchforks...
A
On Sun, 2011-03-06 at 14:57 +0100, Simen kjaeraas wrote:
[ . . . ]
You should use std.range.iota(0,numberOfThreads) instead of
0..numberOfThreads. Having a..b return a general interval range
has been proposed numerous times, but nothing has been implemented as
of yet.
Thanks for this pointer.
On Sun, 2011-03-06 at 16:25 +0100, spir wrote:
[ . . . ]
Without trying to study the code's detainls: ( 0 .. numberOfThreads ) has
very few chances to be accepted by the parser ;-)
Note: there is no interval literal in D. Instead uses of i..j in slicing and
foreach both are pure syntactic
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
So I think it's not worth adding to D.
But if you don't agree... talk.
Bye,
bearophile
If I do:
auto tasks = new Tid[numberOfTasks] ;
foreach ( i ; 0 .. numberOfTasks ) { tasks[i] = spawn ( partialSum ,
thisTid , i , sliceSize , delta ) ; }
everything workls as desired, I get parallelism and appropriate scaling.
However if I try:
auto tasks = map ! ( ( i ) { return
Russel Winder rus...@russel.org.uk wrote:
So why does:
reduce ! ( function double ( double a , double b ) { return a +
b ; } ) ( 0.0 , outputData )
fail? It implies that a function literal and a lambda are significantly
different things as far as the compiler is concerned.
Well,
On Mar 7, 11 00:18, bearophile wrote:
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy,
On Mar 7, 11 00:45, Simen kjaeraas wrote:
Russel Winder rus...@russel.org.uk wrote:
So why does:
reduce ! ( function double ( double a , double b ) { return a + b ; }
) ( 0.0 , outputData )
fail? It implies that a function literal and a lambda are significantly
different things as far as the
On 22/02/2011 15:00, phobophile wrote:
A legitimate question - where are the D3 plans? Any language not in active
development
(no don't mean phobos, not toolchain) is dead.
snip
And D is in active development, in the form of fixing bugs and clearing up spec issues,
slow as the progress may
I am wondering if this is a bug to be reported or (more likely) I have
just done the wrong thing.
The statements:
auto inputData = new Tuple ! ( int , int , double ) [ numberOfTasks ] ;
foreach ( i ; 0 .. numberOfTasks ) { inputData[i] = tuple ( i , cast (
int ) ( sliceSize ) ,
KennyTM~:
If we had UFCS this could be written as,
UFCS is a huge hack that I hope to never see in D :-)
Compared to it, the bad-looking $infix syntax I've just shown is tidy and safe.
Bye,
bearophile
Russel Winder rus...@russel.org.uk wrote:
That said, the above looks like it should work, and I'm not sure why it
doesn't.
Obviously (now :-) because the context requires a delegate not a
function -- it is just that the error message doesn't say that in terms
that don't relate to the code
On 05/03/2011 12:11, Iain Buclaw wrote:
Is this behaviour correct? Should it even be legal to blindly allow access to
members/fields via the .outer context pointer (that may not even be there as
shown in this instance)?
class Outer
{
int w = 3;
void method()
{
int x = 4;
bearophile:
UFCS is a huge hack that I hope to never see in D :-)
How is it a hack? I can understand there being implementation problems
that can make it undesirable to add, but calling it hack?
It's one of the most elegant syntax proposals I've ever seen! It
unifies objects and other functions
bearophile bearophileh...@lycos.com wrote:
So I think it's not worth adding to D.
But if you don't agree... talk.
This is basically already possible in D:
struct InfixOperator( alias fn ) {
auto opBinaryRight( string op : /, T )( T lhs ) {
struct crazy {
T value;
Russel Winder:
Perhaps this needs review. All modern language now have this as an
integral way of describing a sequence of values.
We have discussed about this not too much time ago. See the enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=5395
D language design is too much
Simen kjaeraas simen.kja...@gmail.com wrote:
This is basically already possible in D:
Please do note that this was intended more as a challenge
to myself than as a legitimate Good Idea.
--
Simen
Jonathan M Davis Wrote:
On Sunday 06 March 2011 02:59:25 Jim wrote:
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not? Should we
perhaps seek to have a consistent naming convention for all identifier
names in
Simen kjaeraas:
This is basically already possible in D:
I suggest you to stop using the single underscore as identifier.
unittest {
assert( 2 /_!add/ 3 == 5 );
}
OK. Now let's go back to Haskell :-)
Thank you for your answer,
bye,
bearophile
On 05/03/2011 12:11, Iain Buclaw wrote:
Is this behaviour correct? Should it even be legal to blindly allow access to
members/fields via the .outer context pointer (that may not even be there as
shown in this instance)?
snip
Bug filed:
http://d.puremagic.com/issues/show_bug.cgi?id=5711
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more
Lars T. Kyllingstad Wrote:
On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote:
On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
Jim wrote:
Jonathan M Davis Wrote:
On Sunday 06 March 2011 02:59:25 Jim wrote:
Okay, so there's a discussion about identifier names in the proposed
std.path replacement -- should they be abbreviated or not? Should we
perhaps seek to have a consistent naming convention for all identifier
names
On 3/6/11 10:44 AM, Russel Winder wrote:
If I do:
auto tasks = new Tid[numberOfTasks] ;
foreach ( i ; 0 .. numberOfTasks ) { tasks[i] = spawn ( partialSum ,
thisTid , i , sliceSize , delta ) ; }
everything workls as desired, I get parallelism and appropriate scaling.
However if I try:
On 3/6/11 11:25 AM, Simen kjaeraas wrote:
Russel Winder rus...@russel.org.uk wrote:
That said, the above looks like it should work, and I'm not sure why it
doesn't.
Obviously (now :-) because the context requires a delegate not a
function -- it is just that the error message doesn't say that
On 03/06/2011 04:54 PM, foobar wrote:
Andrei Alexandrescu Wrote:
On 3/6/11 9:27 AM, foobar wrote:
Nick Sabalausky Wrote:
Jimbitcir...@yahoo.com wrote in message
news:ikvped$1o35$1...@digitalmars.com...
Okay, so there's a discussion about identifier names in the proposed
std.path
On 03/06/2011 04:41 PM, Rainer Schuetze wrote:
Lars T. Kyllingstad wrote:
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
What about file.? I tried it on NTFS, but trailing '.' seems to always
be cut off. Is it possible to create such a file on unix systems? If
yes, you won't be
On 6/03/11 2:03 PM, Russel Winder wrote:
PS If you ask why not:
reduce ! ( a+b ) ( 0.0 , outputData )
I find this somehow unacceptable. It's the string, its not a function.
Fine, my problem, but that still leaves the above.
You probably know this already, but just in case...
The
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vrxix902vxi10f@biotronic-laptop...
foobar f...@bar.com wrote:
I would also add to the above excellent point that in order to
prevent unworthy people of programming in the holly
You have a typo there.
Andrei
Well than I must
On Sun, 06 Mar 2011 10:37:15 +0200, Rainer Schuetze r.sagita...@gmx.de
wrote:
What about file.? I tried it on NTFS, but trailing '.' seems to always
be cut off.
It's possible to create files and directories with one trailing dot on
Windows/NTFS. FAR Manager allows doing this, for
On Sun, 06 Mar 2011 09:29:27 -0600, Andrei Alexandrescu wrote:
On 3/6/11 6:31 AM, Lars T. Kyllingstad wrote:
In summary, it seems currentDirSymbol, baseName, dirName and driveName
are clear winners. Less clear, but still voted for by the majority,
are extension and stripExtension. It is a
On 3/6/11, Vladimir Panteleev vladi...@thecybershadow.net wrote:
.exe is an executable file with no name. It's perfectly valid.
Although for some reason Explorer never lets you do that. Well, I have
a hotkey for creating filenames so I just let autohotkey create the
file such as .file. Doing
Jérôme M. Berger jeber...@free.fr wrote in message
news:il0f04$2ts8$1...@digitalmars.com...
This does not make sense because there is no way to tell whether
foo/bar is intended as a file name or a dir name. IMO the only
sensible thing to do is to split on the last path separator:
everything to
Vladimir Panteleev vladi...@thecybershadow.net wrote in message
news:op.vrxw6dmltuz...@cybershadow.mshome.net...
On Sun, 06 Mar 2011 10:37:15 +0200, Rainer Schuetze r.sagita...@gmx.de
wrote:
What about file.? I tried it on NTFS, but trailing '.' seems to always
be cut off.
It's possible
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:il09fp$2h5d$1...@digitalmars.com...
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
What about extending the notion of 'device' (see other post) to cover
'http://' and ftp://;?
Would it be complicated?
I don't think
On Sunday 06 March 2011 13:49:59 Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:il09fp$2h5d$1...@digitalmars.com...
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
What about extending the notion of 'device' (see other post) to cover
'http://'
Sun, 06 Mar 2011 20:24:12 +, Peter Alexander wrote:
On 6/03/11 2:03 PM, Russel Winder wrote:
PS If you ask why not:
reduce ! ( a+b ) ( 0.0 , outputData )
I find this somehow unacceptable. It's the string, its not a function.
Fine, my problem, but that still leaves the above.
retard:
It also generates a bit of redundant code for each template instantiation.
No solution for this has been proposed afaik.
From a recent answer, I think Walter hopes in a magic solution for this bunch
of problems.
In past I have shown some possible attacks against this bunch of
On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote:
bearophile:
UFCS is a huge hack that I hope to never see in D :-)
How is it a hack? I can understand there being implementation problems
that can make it undesirable to add, but calling it hack?
It's one of the most elegant syntax
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in
On Sunday 06 March 2011 06:03:31 Russel Winder wrote:
OK, this one surprised me, all that remains is for me to find out why it
shouldn't have done:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a
On Sunday 06 March 2011 05:57:12 Simen kjaeraas wrote:
You should use std.range.iota(0,numberOfThreads) instead of
0..numberOfThreads. Having a..b return a general interval range
has been proposed numerous times, but nothing has been implemented as
of yet.
I'm sure that part of the problem is
Jonathan M Davis:
And really, the term hack is very imprecise and often subjective.
It's the sort of accusation that pretty much kills any legitimate debate.
You are right, sorry for using a so subjective term. I will avoid it.
Bye,
bearophile
On Sunday 06 March 2011 04:31:20 Lars T. Kyllingstad wrote:
On Sat, 05 Mar 2011 16:32:55 +, Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote:
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message
news:ikofkc$322$1...@digitalmars.com...
On 03/06/2011 10:49 PM, Nick Sabalausky wrote:
Lars T. Kyllingstadpublic@kyllingen.NOSPAMnet wrote in message
news:il09fp$2h5d$1...@digitalmars.com...
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
What about extending the notion of 'device' (see other post) to cover
'http://' and ftp://;?
On Sunday 06 March 2011 07:29:27 Andrei Alexandrescu wrote:
I think whatever you choose will not please everybody, so just choose
something and stick with it. Regarding all the extension naming stuff, I
suggest you go with the suffix nomenclature which is more general and
applicable to all
On 03/07/2011 01:44 AM, Jonathan M Davis wrote:
I think whatever you choose will not please everybody, so just choose
something and stick with it. Regarding all the extension naming stuff, I
suggest you go with the suffix nomenclature which is more general and
applicable to all OSs.
I
(De-lurking; I've been interested in D for a while, but my programming
is almost exclusively in C -- generally C99.)
Does D have the equivalent of C99's designated initializers?
Were I to attempt something like this in C, the code would go something
like this:
int foo(int height, int
On Sunday 06 March 2011 16:54:41 spir wrote:
On 03/07/2011 01:44 AM, Jonathan M Davis wrote:
I think whatever you choose will not please everybody, so just choose
something and stick with it. Regarding all the extension naming
stuff, I suggest you go with the suffix nomenclature
Jonathan M Davis:
I'm sure that part of the problem is the fact that a .. b is also used in
slicing, where it does not mean the same thing
It means the same thing, with a interval literal.
- that and iota works just fine,
Currently it has a design bug that I've underlined.
and
I have discussed this topic already once in past, but I want to talk some more
about it. Lately I am using Haskell a bit, and I'm appreciating this very
simple feature. In D it's not as useful as in Haskell because D allows nested
functions, that are one of its main purposes, but it's a cute
However, are you indicating that we should
never have more than one module in review at a time? I see some benefit in
spreading them out, on the other hand, if we have multiple modules ready for
review, it seems like we could be slowing down progress unnecessarily if we
ruled that we could only
On Sunday 06 March 2011 17:20:33 bearophile wrote:
Jonathan M Davis:
I'm sure that part of the problem is the fact that a .. b is also used in
slicing, where it does not mean the same thing
It means the same thing, with a interval literal.
- that and iota works just fine,
Currently
Joel C. Salomon:
Does D have the equivalent of C99's designated initializers?
D2 currently allows code like this (but I don't know if this will be
deprecated, for me sometimes is not easy to remember all things that will be
deprecated):
struct Foo { int x, y, z; }
Foo f1 = { x:1, y:2 };
Foo
On 3/6/11 6:04 PM, Jonathan M Davis wrote:
On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote:
bearophile:
UFCS is a huge hack that I hope to never see in D :-)
How is it a hack? I can understand there being implementation problems
that can make it undesirable to add, but calling it hack?
On Sunday 06 March 2011 16:57:17 Joel C. Salomon wrote:
(De-lurking; I've been interested in D for a while, but my programming
is almost exclusively in C -- generally C99.)
Does D have the equivalent of C99's designated initializers?
Were I to attempt something like this in C, the code
On Sun, 06 Mar 2011 09:33:05 -0500, dsimcha dsim...@yahoo.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5710
It's a DMD issue. I've been meaning to report it for a while.
Unfortunately making a workaround for it would be a huge PITA at best
and impossible in the toughest use
1 - 100 of 163 matches
Mail list logo
