Re: indexing a tuple containing a struct strange result
On Monday, 24 June 2013 at 05:31:29 UTC, Ali Çehreli wrote:
On 06/23/2013 10:07 PM, Ali Çehreli wrote:
I think it is a compiler bug.
Make that a Phobos bug. :)
The following is a reduced program that exhibits the problem.
The presence or absence of the unused member function makes a
difference:
import std.typecons;
struct S
{
int x;
// Bizarre: Comment-out this function to pass the assert in
main.
Tuple!(S) unused()
{
return tuple(S(7));
}
}
void main()
{
auto s = S(8);
assert(tuple(s).expand[0] == S(8));
}
Ali
Actually I hadn't tried with free functions, but this test
captures my problem. I'll file it now. Thanks!
QTD on Ubuntu
Hi, I am having problems compiling qtd on Ubuntu 12.04. QtD needs Qt4, however I also have Qt5 installed. By default cmake grabs version 5 which of course produces error messages. In case anyone knows a quick fix (cmake flag, or a qmake flag etc.) please let me know. Thanks a million!
eof
Hi,everyone, I am learning D.I installed a plugin-visusl D to visual studio 2008.I am very confused that ctrl+z didn't teminate the input of console,it result in a dead loop.When reading from a txt file,a extra line will be read and usually it result in a wrong result.Is there anyone who has experienced such a situation and can tell me what I should pay attention to. Thanks a lot. lx
Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
I am getting lots of errors when compiling with -w:
// https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L144
this(T)(T vec) if(is_vector!T is(T.vt : vt) (T.dimension =
dimension)) {
vector = vec.vector[0..dimension];
}
this line produces following warning:
gl3n/linalg.d(144): Warning: explicit element-wise assignment
(this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension] is
better than this.vector = vec.vector[cast(ulong)0..cast(ulong)dimension]
Why does dmd produce this warning? (this is new in 2.063) Why is
assigning elementwise better?
Trouble with lockstep
Hello,
I have code which generates a histogram from an array and prints
out the histogram bins/counts. However I cannot get the code to
iterate and print
out the histogram to work. The following is a minimal example:
import std.range;
import std.stdio;
void main()
{
ubyte[] data =
[17,32,32,32,38,39,39,47,47,47,47,109,111,111,128];
uint[ubyte.max - ubyte.min] bins;
foreach(ubyte val; data) bins[val]++;
foreach( idx, count; lockstep( iota!ubyte(ubyte.min,
ubyte.max), bins ) )
{
if(count 0 ) {
writeln(Bin = , idx, count = , count );
}
}
}
Alternately: http://dpaste.com/hold/1267929/
I get the following error messages which I cannot decipher.
test.d(11): Error: template std.range.lockstep does not match any
function template declaration. Candidates are:
/usr/include/dmd/phobos/std/range.d(4724):
std.range.lockstep(Ranges...)(Ranges ranges) if
(allSatisfy!(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range.d(4730):
std.range.lockstep(Ranges...)(Ranges ranges, StoppingPolicy s) if
(allSatisfy!(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range.d(4724): Error: template
std.range.lockstep cannot deduce template function from argument
types !()(Result, uint[255LU])
Failed: 'dmd' '-v' '-o-' 'test.d' '-I.'
Can anyone identify what I am doing wrong. Also I am curious to
know why std.range includes both Lockstep and lockstep - they
seem like the same thing.
Craig
Re: Trouble with lockstep
On 06/24/2013 03:05 PM, Craig Dillabaugh wrote: Can anyone identify what I am doing wrong. Also I am curious to know why std.range includes both Lockstep and lockstep - they seem like the same thing. lockstep is a helper function that returns an instance of Lockstep. The reason is that if you instantiate a struct/class template directly you have to explicitly state the template parameters. A function template call can infer the template parameters and use them to instantiate a class instance.
Re: QTD on Ubuntu
On Monday, June 24, 2013 12:04:51 Chris wrote: Hi, I am having problems compiling qtd on Ubuntu 12.04. QtD needs Qt4, however I also have Qt5 installed. By default cmake grabs version 5 which of course produces error messages. In case anyone knows a quick fix (cmake flag, or a qmake flag etc.) please let me know. Thanks a million! As I understand it, QtD is unfortunately unmaintained and is effectively a dead project. So, I wouldn't expect it to compile regardless of your Qt version. That being said, looking at the the cmake docs ( http://www.cmake.org/cmake/help/v2.8.11/cmake.html ), it looks like you might be able to get it to choose Qt4 by setting DESIRED_QT_VERSION - probably by passing -DDESIRED_QT_VERSION=4.9.10 (or whatever the version is) to cmake. - Jonathan M Davis
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
On Monday, June 24, 2013 16:07:19 David wrote:
I am getting lots of errors when compiling with -w:
// https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L144
this(T)(T vec) if(is_vector!T is(T.vt : vt) (T.dimension =
dimension)) {
vector = vec.vector[0..dimension];
}
this line produces following warning:
gl3n/linalg.d(144): Warning: explicit element-wise assignment
(this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension] is
better than this.vector = vec.vector[cast(ulong)0..cast(ulong)dimension]
Why does dmd produce this warning? (this is new in 2.063) Why is
assigning elementwise better?
According to the changelog ( http://dlang.org/changelog.html ), it sounds like
it's because doing an element-wise copy is arbitrarily expensive (probably
meaning O(n) rather than O(1)), so it potentially gave the false impression of
being a simple, cheap assignment if the slicing syntax wasn't used. But I
don't know what exactly went into that decision beyond what's listed in the
changelog.
- Jonathan M Davis
Re: Trouble with lockstep
lockstep(iota!ubyte(ubyte.min, ubyte.max), bins[]) Works, but this leaves you with other errors, I couldn't find a solution for. Something seems to be wrong with opApply of lockstep. Or maybe I miss something obvious...
Re: eof
lx: I am very confused that ctrl+z didn't teminate the input of console,it result in a dead loop. I think this is a library bug, I noticed it some times, but I didn't file it. Maybe it's worth filing in Bugzilla. When reading from a txt file,a extra line will be read and usually it result in a wrong result. Can you show the code? Bye, bearophile
Re: Trouble with lockstep
On Monday, 24 June 2013 at 14:15:55 UTC, Joseph Rushton Wakeling wrote: On 06/24/2013 03:05 PM, Craig Dillabaugh wrote: Can anyone identify what I am doing wrong. Also I am curious to know why std.range includes both Lockstep and lockstep - they seem like the same thing. lockstep is a helper function that returns an instance of Lockstep. The reason is that if you instantiate a struct/class template directly you have to explicitly state the template parameters. A function template call can infer the template parameters and use them to instantiate a class instance. Thanks. That makes sense ... I think.
Re: Trouble with lockstep
Craig Dillabaugh: foreach( idx, count; lockstep( iota!ubyte(ubyte.min, ubyte.max), bins ) ) Also note that doesn't iterate the whole ubyte range. Maybe we need another iota range for that, with a different name or with an optional template argument string like [] as std.random.uniform. Opinions welcome. Bye, bearophile
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
David: Why does dmd produce this warning? (this is new in 2.063) Why is assigning elementwise better? The short answer is: do as the compiler suggests you, and be very happy the compiler avoids you some bugs. The explanation is longer. In brief, it's much better to avoid some bugs and to make the D semantics more clear, to denote all vector ops, including the assignment with a []. Bye, bearophile
Re: Trouble with lockstep
On Monday, 24 June 2013 at 14:33:48 UTC, bearophile wrote: Craig Dillabaugh: foreach( idx, count; lockstep( iota!ubyte(ubyte.min, ubyte.max), bins ) ) Also note that doesn't iterate the whole ubyte range. Maybe we need another iota range for that, with a different name or with an optional template argument string like [] as std.random.uniform. Opinions welcome. Bye, bearophile Opps. Of course. The optional template argument sounds like a good idea. Any idea why the original wouldn't compile though? Craig
Re: QTD on Ubuntu
On Monday, 24 June 2013 at 14:18:52 UTC, Jonathan M Davis wrote: On Monday, June 24, 2013 12:04:51 Chris wrote: Hi, I am having problems compiling qtd on Ubuntu 12.04. QtD needs Qt4, however I also have Qt5 installed. By default cmake grabs version 5 which of course produces error messages. In case anyone knows a quick fix (cmake flag, or a qmake flag etc.) please let me know. Thanks a million! As I understand it, QtD is unfortunately unmaintained and is effectively a dead project. So, I wouldn't expect it to compile regardless of your Qt version. That being said, looking at the the cmake docs ( http://www.cmake.org/cmake/help/v2.8.11/cmake.html ), it looks like you might be able to get it to choose Qt4 by setting DESIRED_QT_VERSION - probably by passing -DDESIRED_QT_VERSION=4.9.10 (or whatever the version is) to cmake. - Jonathan M Davis Thanks! I'll have a look. A pity QtD is no longer maintained. Ubuntu is using the Qt for mobile apps now (cf. http://developer.ubuntu.com/get-started/) and probably for the desktop too.
Re: Trouble with lockstep
David: Something seems to be wrong with opApply of lockstep. Or maybe I miss something obvious... I have suggested to remove lockstep from Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=8155 Why don't you try to use std.range.zip? Bye, bearophile
Re: Trouble with lockstep
On Monday, 24 June 2013 at 14:56:41 UTC, bearophile wrote:
David:
Something seems to be wrong with opApply of lockstep.
Or maybe I miss something obvious...
I have suggested to remove lockstep from Phobos:
http://d.puremagic.com/issues/show_bug.cgi?id=8155
Why don't you try to use std.range.zip?
Bye,
bearophile
Funny you should mention that, I vaguely recalled you old thread,
and replaced lockstep with zip.
After making the following changes:
uint[ubyte.max - ubyte.min+1] bins;
...
foreach( e; zip( iota(ubyte.min, ubyte.max+1), bins ) )
{
if(count 0 ) {
writeln(Bin = , e[0], count = , e[1] );
}
}
I now get the error (which seems to be the same problem I had
before - see the last error):
test.d(11): Error: template std.range.zip does not match any
function template declaration. Candidates are:
/usr/include/dmd/phobos/std/range.d(4451):
std.range.zip(Ranges...)(Ranges ranges) if (Ranges.length
allSatisfy!(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range.d(4458):
std.range.zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if
(Ranges.length allSatisfy!(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range.d(4451): Error: template
std.range.zip cannot deduce template function from argument types
!()(Result, uint[256LU])
Re: Trouble with lockstep
Craig Dillabaugh:
I now get the error (which seems to be the same problem I had
before - see the last error):
...
/usr/include/dmd/phobos/std/range.d(4451): Error: template
std.range.zip cannot deduce template function from argument
types
!()(Result, uint[256LU])
Most range/algorithm functions unfortunately don't accept a fixes
size array. So you have to slice it:
void main() {
import std.stdio, std.range;
ubyte[] data = [17, 32, 32, 32, 38, 39, 39, 47,
47, 47, 47, 109, 111, 111, 128];
uint[ubyte.max - ubyte.min + 1] bins;
foreach (immutable val; data)
bins[val]++;
foreach (uint idx, count; iota(ubyte.min, ubyte.max +
1).zip(bins[]))
if (count 0)
writeln(Bin = , idx, count = , count);
}
Bye,
bearophile
Re: Trouble with lockstep
On 06/24/2013 03:05 PM, Craig Dillabaugh wrote:
I get the following error messages which I cannot decipher.
Oddly enough, I'm also getting lockstep-related error messages at compile-time:
/opt/gdc/include/d/4.8.1/std/range.d:4716: Error: delegate dg (ref double, ref
ulong) is not callable using argument types (double, ulong)
test.d:122: Error: opApply() function for Lockstep!(Result, ulong[]) must return
an int
/opt/gdc/include/d/4.8.1/std/range.d:4717: Error: delegate dg (ulong, ref
double, ref ulong) is not callable using argument types (ulong, double, ulong)
test.d:122 is a foreach over a lockstep:
foreach(r, x; itemDegree) ...
where itemDegree is generated by the following function:
auto degreeRank(NodeT)(NodeT nodes)
{
size_t[] x;
foreach(node; nodes)
x ~= node.links.length;
x.sort;
auto r = iota(1.0, 0, -1.0/x.length);
return lockstep(r, x);
}
By the way, yes, I know I can probably find a better and more efficient way to
generate x than what's there. It's what I wrote some time ago and never had a
pressing enough need to improve. :-P
Re: Trouble with lockstep
On Monday, 24 June 2013 at 15:15:46 UTC, bearophile wrote:
Craig Dillabaugh:
clip
Most range/algorithm functions unfortunately don't accept a
fixes size array. So you have to slice it:
void main() {
import std.stdio, std.range;
ubyte[] data = [17, 32, 32, 32, 38, 39, 39, 47,
47, 47, 47, 109, 111, 111, 128];
uint[ubyte.max - ubyte.min + 1] bins;
foreach (immutable val; data)
bins[val]++;
foreach (uint idx, count; iota(ubyte.min, ubyte.max +
1).zip(bins[]))
if (count 0)
writeln(Bin = , idx, count = , count);
}
Bye,
bearophile
Thanks. Now it works, if I use .zip().
Re: InstanceOf
On Sun, 23 Jun 2013 11:29:10 -0400, Lemonfiend le...@fie.nd wrote:
On Sunday, 23 June 2013 at 15:15:16 UTC, Jacob Carlborg wrote:
On 2013-06-23 13:26, Lemonfiend wrote:
foreach (I i; array) {
if (B b = cast(B) i) { ... }
}
Thanks all 3 of you for the quick and identical answers. :)
It had not occurred to me to use a cast for this, but indeed the
language ref says the same:
In order to determine if an object o is an instance of a class B use a
cast
It does a bit inelegant to me.. Or are casts simply extremely cheap?
You can do something like this as well:
if (i.classinfo is B.classinfo) { }
But doing the cast is more efficient if you want to use the object of
as the type you're checking for.
Using the .classinfo is what I looked at before asking here.
However, according to the specs:
.classinfo applied to an interface gives the information for the
interface, not the class it might be an instance of.
So the i.classinfo and B.classinfo would be different?
1. Use typeid(i), not i.classinfo, classinfo is old-style.
2. Yes, typeid(i) will give you interface class info, or maybe even
derived interface class info. It's a simple indirection, whereas a cast
must go through a pointer offset stored in the interface typeinfo in order
to get true class info.
3. typeid(i) on one DLL may be different than typeid(i) on another. It is
not valid to compare the references directly
On 2, see test code:
http://dpaste.dzfl.pl/97f5866d
-Steve
Re: Can call static method with null reference
On Sun, 23 Jun 2013 06:09:19 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Sunday, June 23, 2013 12:02:42 Namespace wrote:
Also I don't know why I should call static methods from an
instance. What's the purpose?
It's stupid and pointless as far as I can tell, but I believe that C++,
Java,
C#, and D all do it, so as stupid as it is, it's a common stupidity. I
certainly wish that we could change it, but I wouldn't expect Walter to
agree
to the change, since it would break at least some existing code, and I
suspect
that he doesn't consider the fact that you can call static functions on
instances to be a problem. That's not the sort of thing that he generally
seems to think is an issue. It's almost always stuff that causes actual
bugs
that he agrees to change and not things that are aesthetically
displeasing or
which could theoretically cause bugs.
I actually had a bug caused by this.
But the reason is simply duck typing.
For example:
class InfiniteRange
{
...
static bool empty() { return false; }
}
My suggestion to fix this has always been: only allow static calls on
instance variables via opt-in. e.g.:
class InfiniteRange
{
static bool empty() { return false; }
alias InfiniteRange.empty this.empty; // just an example
}
This allows all the benefit, but none of the bug-prone problems.
-Steve
Re: Trouble with lockstep
On Monday, 24 June 2013 at 15:29:21 UTC, Joseph Rushton Wakeling
wrote:
On 06/24/2013 03:05 PM, Craig Dillabaugh wrote:
I get the following error messages which I cannot decipher.
Oddly enough, I'm also getting lockstep-related error messages
at compile-time:
/opt/gdc/include/d/4.8.1/std/range.d:4716: Error: delegate dg
(ref double, ref
ulong) is not callable using argument types (double, ulong)
test.d:122: Error: opApply() function for Lockstep!(Result,
ulong[]) must return
an int
/opt/gdc/include/d/4.8.1/std/range.d:4717: Error: delegate dg
(ulong, ref
double, ref ulong) is not callable using argument types (ulong,
double, ulong)
test.d:122 is a foreach over a lockstep:
foreach(r, x; itemDegree) ...
where itemDegree is generated by the following function:
auto degreeRank(NodeT)(NodeT nodes)
{
size_t[] x;
foreach(node; nodes)
x ~= node.links.length;
x.sort;
auto r = iota(1.0, 0, -1.0/x.length);
return lockstep(r, x);
}
By the way, yes, I know I can probably find a better and more
efficient way to
generate x than what's there. It's what I wrote some time ago
and never had a
pressing enough need to improve. :-P
I think my original attempt compiled at home (where I was using
and older version 2.062), but I couldn't compile it at work with
the latest DMD (2.063). I didn't mention it in the original post
because I couldn't recall for sure if I had successfully compiled
it. You appear to be using GDC, but maybe this has something to
do with recent changes.
Re: Trouble with lockstep
On 06/24/2013 07:05 AM, Craig Dillabaugh wrote:
The following is a minimal example:
Further reduced:
import std.range;
void main()
{
lockstep(iota(0, 10), [ 1 ]);
}
Strangely, the error message points at two comment lines in my
installation of 2.063:
/usr/include/dmd/phobos/std/range.d(4716): Error: delegate dg (ref int,
ref int) is not callable using argument types (int, int)
/usr/include/dmd/phobos/std/range.d(4717): Error: delegate dg (ulong,
ref int, ref int) is not callable using argument types (ulong, int, int)
Lines 4716 and 4717 are the two lines of the following comment:
// For generic programming, make sure Lockstep!(Range) is well defined for a
// single range.
template Lockstep(Range)
{
alias Range Lockstep;
}
Ali
Re: indexing a tuple containing a struct strange result
On 06/23/2013 11:11 PM, cal wrote: I'll file it now. Thanks! Thanks for filing: http://d.puremagic.com/issues/show_bug.cgi?id=10458 Ali
Re: Can call static method with null reference
On Sunday, 23 June 2013 at 10:09:39 UTC, Jonathan M Davis wrote: Also I don't know why I should call static methods from an instance. What's the purpose? It's stupid and pointless as far as I can tell, but I believe that C++, Java, C#, and D all do it, so as stupid as it is, it's a common stupidity Java prevents it, I'm pretty sure C# picked that up from Java. (Unless Java has changed since 1.5)
Re: Trouble with lockstep
On Monday, 24 June 2013 at 16:03:17 UTC, Ali Çehreli wrote:
On 06/24/2013 07:05 AM, Craig Dillabaugh wrote:
The following is a minimal example:
Further reduced:
import std.range;
void main()
{
lockstep(iota(0, 10), [ 1 ]);
}
Strangely, the error message points at two comment lines in my
installation of 2.063:
/usr/include/dmd/phobos/std/range.d(4716): Error: delegate dg
(ref int, ref int) is not callable using argument types (int,
int)
/usr/include/dmd/phobos/std/range.d(4717): Error: delegate dg
(ulong, ref int, ref int) is not callable using argument types
(ulong, int, int)
Lines 4716 and 4717 are the two lines of the following comment:
// For generic programming, make sure Lockstep!(Range) is well
defined for a
// single range.
template Lockstep(Range)
{
alias Range Lockstep;
}
Ali
Well, I guess my example wasn't so minimal after all :o)
So is this worthy of a bug report then?
Re: Problems building docs
On Sat, Jun 22, 2013 at 08:11:25PM +0100, Joseph Rushton Wakeling wrote: Hello all, I'm having problems building the docs. I've got the latest d-programming-language.org checked out, and have tried to build with make -f posix.mak. The basic html part builds fine, but it falls over when trying to build phobos-prerelease with the error: Did you manage to get it working? Sorry for the late reply, I was busy all weekend. I find that a lot of D makefiles assume this directory structure: parent parent/d-programming-language.org parent/d-programming-language.org/web parent/d-programming-language.org/dmd parent/d-programming-language.org/druntime parent/d-programming-language.org/phobos You might want to try organizing your directory tree to look something like the above; that may help you. For me personally, I find that nesting dmd/druntime/phobos inside the git checkout of d-programming-language.org a tad ugly, so I use this instead: parent/d-programming-language.org parent/d-programming-language.org/web parent/dmd parent/druntime parent/phobos But then building docs for phobos will put it in parent/web, and you have to manually merge it into where it's supposed to be. Or just cp -rp both web subdirs into the same place where your HTTP server expects them, and let the filesystem do the merging for you. T -- It only takes one twig to burn down a forest.
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
Am 24.06.2013 16:30, schrieb bearophile: David: Why does dmd produce this warning? (this is new in 2.063) Why is assigning elementwise better? The short answer is: do as the compiler suggests you, and be very happy the compiler avoids you some bugs. The problem is, I wrote this code on purpose and I *want* it to work like that, and I evenn need it to work like that (a few lines above in construct), but this currently blocks gl3n from beeing updated for Fedora. The explanation is longer. In brief, it's much better to avoid some bugs and to make the D semantics more clear, to denote all vector ops, including the assignment with a []. What kind of bugs does it avoid? I can't think of a single bug which could happen... (Ranges/Lengths are checked at runtime...)
Re: std.process: how to process stdout chunk by chunk without waiting for process termination
Timothee Cour wrote:
On Tue, Jun 18, 2013 at 3:00 PM, Steven Schveighoffer
schvei...@yahoo.comwrote:
On Tue, 18 Jun 2013 17:41:57 -0400, Timothee Cour
thelastmamm...@gmail.com wrote:
I'd like to do the following:
auto pipes = pipeShell(command, Redirect.stdout | Redirect.stderr);
while(true){
version(A1)
string line=pipes.stdout.readln;
version(A2)
auto line=pipes.stdout.readChunk(**10);
version(A3)
auto line=pipes.stdout.readChar();
// do something with line
if(tryWait(pipes.pid).**terminated)
break;
}
The problem is that 'string line=pipes.stdout.readln;' seems to block
until
the process is terminated, ie if the command is a long running command
that
prints a line every 1 second for 10 seconds, this program will wait 10
seconds before starting the processing.
I also tried with rawRead, readf, fgetc but couldn't make it work.
I'm on OSX, if that matters.
Is there any way to achieve this?
I think the issue is on the child process side. If you are using
buffered I/O you have to flush the buffer.
yes
For instance, if the child is using D writeln or C printf, and you are
using stdout, then it will only flush after writing 4096 bytes. You can
flush early by calling flush on stdout, or fflush in C. Note that C will
auto-detect if it is an interactive console, and flush via newlines
instead. So running the same program from the console will flush every
line!
Alternatively, you can set the flush policy to flush after every line.
See here:
https://developer.apple.com/**library/ios/#documentation/**
System/Conceptual/ManPages_**iPhoneOS/man3/setvbuf.3.htmlhttps://developer.apple.com/library/ios/#documentation/System/Conceptual/ManPages_iPhoneOS/man3/setvbuf.3.html
And here:
http://dlang.org/phobos/std_**stdio.html#.File.setvbufhttp://dlang.org/phobos/std_stdio.html#.File.setvbuf
-Steve
Thanks, that does indeed work if I have source code for the child program
and I can run 'std.stdio.stdout.setvbuf(buffer, _IOLBF);' right after
main. However I want to make it work without modifying source of child
program.
I tried
http://stackoverflow.com/questions/1401002/trick-an-application-into-
thinking-its-stdin-is-interactive-not-a-pipewith
script:
auto pipes = pipeShell(script -q /dev/null program, Redirect.stdout |
Redirect.stderr);
that works but has issues : only buffers stdout, not stderr; and I may not
want to redirect stderr to stdout; also it won't work in more complex
cases, eg if program contains '|' etc, and it requires replacing \r\n by
\n.
I tried replacing fork with forkpty inside std.process. That doesn't seem
to work: calling isatty(1),isatty(2) on child process still returns 0.
Not sure why.
I tried calling stdout.setvbuf(buffer, _IOLBF); right after child process
creation in std.process (after the fork with case 0); doesn't work either.
I ran into this also. My solution is the makeShell() function at
https://github.com/klamonte/d-tui/blob/master/tterminal.d . I'd like to see
forkpty in phobos myself, so I just opened bug 10464 for that request.
Re: InstanceOf
On Monday, 24 June 2013 at 15:46:05 UTC, Steven Schveighoffer
wrote:
On Sun, 23 Jun 2013 11:29:10 -0400, Lemonfiend le...@fie.nd
wrote:
On Sunday, 23 June 2013 at 15:15:16 UTC, Jacob Carlborg wrote:
On 2013-06-23 13:26, Lemonfiend wrote:
foreach (I i; array) {
if (B b = cast(B) i) { ... }
}
Thanks all 3 of you for the quick and identical answers. :)
It had not occurred to me to use a cast for this, but indeed
the
language ref says the same:
In order to determine if an object o is an instance of a
class B use a
cast
It does a bit inelegant to me.. Or are casts simply
extremely cheap?
You can do something like this as well:
if (i.classinfo is B.classinfo) { }
But doing the cast is more efficient if you want to use the
object of as the type you're checking for.
Using the .classinfo is what I looked at before asking here.
However, according to the specs:
.classinfo applied to an interface gives the information for
the interface, not the class it might be an instance of.
So the i.classinfo and B.classinfo would be different?
1. Use typeid(i), not i.classinfo, classinfo is old-style.
2. Yes, typeid(i) will give you interface class info, or maybe
even derived interface class info. It's a simple indirection,
whereas a cast must go through a pointer offset stored in the
interface typeinfo in order to get true class info.
3. typeid(i) on one DLL may be different than typeid(i) on
another. It is not valid to compare the references directly
On 2, see test code:
http://dpaste.dzfl.pl/97f5866d
-Steve
This method would not work for my example, since it would get the
interface, not a class.
But if I were to maintain an array of some base class instead, it
would.
Very interesting! Thanks.
Re: Can call static method with null reference
On Monday, June 24, 2013 11:51:52 Steven Schveighoffer wrote:
My suggestion to fix this has always been: only allow static calls on
instance variables via opt-in. e.g.:
class InfiniteRange
{
static bool empty() { return false; }
alias InfiniteRange.empty this.empty; // just an example
}
This allows all the benefit, but none of the bug-prone problems.
I would _love_ to make that fix, but the trick is convincing Walter (since the
chance risks breaking code). Or maybe it's one of those things that convincing
Kenji to implement it would be enough, since it could sneak in that way? I
don't know. Regardless, I think that we'd be better off if we made the change.
- Jonathan M Davis
Re: Can call static method with null reference
On Monday, June 24, 2013 19:13:45 Jesse Phillips wrote: On Sunday, 23 June 2013 at 10:09:39 UTC, Jonathan M Davis wrote: Also I don't know why I should call static methods from an instance. What's the purpose? It's stupid and pointless as far as I can tell, but I believe that C++, Java, C#, and D all do it, so as stupid as it is, it's a common stupidity Java prevents it, I'm pretty sure C# picked that up from Java. (Unless Java has changed since 1.5) I was certain that I'd checked it at one point and determined that Java allowed it, but I could be wrong. It's certainly better if I am, since it's a bad design decision to allow static functions to be called on instances IMHO. - Jonathan M Davis
Possble bug ? Adding
Hello, guys ! http://dpaste.1azy.net/8917c253 Thanks. Regards.
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
David:
What kind of bugs does it avoid?
I can't think of a single bug which could happen...
(Ranges/Lengths are checked at runtime...)
Some reasons:
- Syntax uniformity: similar behaviours should look similar. This
is a general rule of language design, that avoids troubles you
don't even know. All array ops use [], so it's right for vector
assignment to use them.
- The second rule is that in a language as D we want to denote
different code complexities with different code. This is the
reason given in the Changelog, and it explains while length and
walkLength have different names.
In past you were not able to tell from a look at the syntax
what's happening:
void main() {
int[][3] x;
int[]y;
int[]z;
x[] = z; // copies just the z pointer
y[] = z; // copies the elements in z
}
More details:
http://d.puremagic.com/issues/show_bug.cgi?id=7444
Coming from this older:
http://d.puremagic.com/issues/show_bug.cgi?id=3971
You are welcome,
bearophile
Re: Trouble with lockstep
Craig Dillabaugh: Also note that doesn't iterate the whole ubyte range. Maybe we need another iota range for that, with a different name or with an optional template argument string like [] as std.random.uniform. Opinions welcome. Bye, bearophile Opps. Of course. The optional template argument sounds like a good idea. http://d.puremagic.com/issues/show_bug.cgi?id=10466 Bye, bearophile
Re: Possble bug ? Adding
On 2013-06-24, 22:30, Temtaime wrote: Hello, guys ! http://dpaste.1azy.net/8917c253 I'm not sure I've seen this bug before, but yes, it is one. The cause is that the grammar for the new alias syntax is apparently not complete. Please file: http://d.puremagic.com/issues/enter_bug.cgi -- Simen
Re: eof
I am very confused that ctrl+z didn't teminate the input of console,it result in a dead loop. I think this is a library bug, I noticed it some times, but I didn't file it. Maybe it's worth filing in Bugzilla. I have added this bug report, is this the issue you are seeing/having? http://d.puremagic.com/issues/show_bug.cgi?id=10467 Bye, bearophile
Re: Trouble with lockstep
On 06/24/2013 11:01 AM, Craig Dillabaugh wrote: So is this worthy of a bug report then? Yes, please. Ali
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
On 06/24/2013 12:17 PM, David wrote: The problem is, I wrote this code on purpose and I *want* it to work like that, and I evenn need it to work like that (a few lines above in construct), but this currently blocks gl3n from beeing updated for Fedora. You are right because 'vector' is a fixed-length array. So, the following two have the same effect: vector = vec.vector[0..dimension]; vector[] = vec.vector[0..dimension]; I don't know whether that is by design. One can argue that array-wise syntax should be recommended only for slices. In any case, as bearophile says, uniformity is always helpful. Ali
Re: eof
On Monday, 24 June 2013 at 21:13:31 UTC, bearophile wrote: I am very confused that ctrl+z didn't teminate the input of console,it result in a dead loop. I think this is a library bug, I noticed it some times, but I didn't file it. Maybe it's worth filing in Bugzilla. I have added this bug report, is this the issue you are seeing/having? http://d.puremagic.com/issues/show_bug.cgi?id=10467 Bye, bearophile I don't think this is a bug (I replied on the bug report): terminating the stream doesn't mean terminating the program, and if the program doesn't know how to handle a closed/eof/error'd stdin, it will just loop... This FAQ link explains it pretty well for C++, which is pretty much the same thing as in D: http://www.parashift.com/c++-faq/stream-input-failure.html (the next few points are relevant too). We could argue the design isn't optimal, yes, but it's not bugged.
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
Ali Çehreli: So, the following two have the same effect: vector = vec.vector[0..dimension]; vector[] = vec.vector[0..dimension]; The first syntax will be deprecated and later it will become an error. Bye, bearophile
Re: eof
monarch_dodra: I don't think this is a bug I see. Then lx will have to explain the problem better. (I replied on the bug report): I have given an answer, comparing to Python. I think the current Phobos behavour is bad. Bye, bearophile
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
On 06/24/2013 03:12 PM, bearophile wrote:
Ali Çehreli:
So, the following two have the same effect:
vector = vec.vector[0..dimension];
vector[] = vec.vector[0..dimension];
The first syntax will be deprecated and later it will become an error.
I am confused. Even if the right-hand expression were a fixed-length
array? If so, then we wouldn't speak of their being value types. (?)
a = b;// should be fine
Otherwise, fixed-length arrays would become weird types that cannot be
used in assignment operations.
I just read the change log. Either it is incorrect or the change is
implemented inccorrectly because it is supposed to be about the
right-hand side. So, OP's code is correct after all.
Here is the excerpt from the change log:
excerpt
Array copy operations now always require using the slice syntax:
The right-hand-side of an array copy operation now requires using the
slice syntax:
void main()
{
int[][2] x;
int[] y;
int[] z;
x[] = z;// copies z (pointer + length) 2 times to x
y[] = z;// copies each element of z into y (compiler emits warning)
}
If the user intended to write such code they must use the slice syntax
for both the source and target arrays:
void main()
{
int[][2] x;
int[] y;
int[] z;
y[] = z[]; // copies each element of z into y (no warnings)
}
Rationale:
The compiler will emit a warning to make the user aware that the copy
operation is arbitrarily expensive.
/excerpt
Ali
Re: Trouble with lockstep
On 6/24/13, Ali Çehreli acehr...@yahoo.com wrote: Strangely, the error message points at two comment lines in my installation of 2.063: It's a regression which I've caused. I've made a fixup pull: http://d.puremagic.com/issues/show_bug.cgi?id=10468 I'm very sorry for this mishap.
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
Ali Çehreli:
I am confused. Even if the right-hand expression were a
fixed-length array? If so, then we wouldn't speak of their
being value types. (?)
a = b;// should be fine
Otherwise, fixed-length arrays would become weird types that
cannot be used in assignment operations.
I just read the change log. Either it is incorrect or the
change is implemented inccorrectly because it is supposed to be
about the right-hand side. So, OP's code is correct after all.
Sorry, my mistake, I have confused the two things a bit,
regarding the position of the [].
Currently this code gives no warnings:
void main() {
int[3] a, b;
a = b;
}
This topic is discussed a little in Issue 7444.
Bye,
bearophile
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
On 06/24/2013 04:11 PM, bearophile wrote:
Currently this code gives no warnings:
void main() {
int[3] a, b;
a = b;
}
This topic is discussed a little in Issue 7444.
http://d.puremagic.com/issues/show_bug.cgi?id=7444#c3
Summary:
1) Single element on the right-hand side is disallowed unless lhs is
all elements. One must write the following (sa is static array and
da is dynamic array):
sa[] = e;
da[] = e;
2) Mixing static array and dynamic array on both sides of = is disallowed:
sa[] = da[]; // fine: both dynamic arrays
da[] = sa[]; // ditto
da = sa[]; // ditto
sa[] = da; // ditto
Ali
Re: Warning: explicit element-wise assignment (this.vector)[] = vec.vector[cast(ulong)0..cast(ulong)dimension]
On 06/24/2013 05:16 PM, Ali Çehreli wrote: 2) Mixing static array and dynamic array on both sides of = is disallowed: da[] = sa[]; // ditto da = sa[]; // ditto And I didn't mean that those two have the same meaning. The former is copy all elements, and the latter is refer to all of sa's elements. Ali
typeof map
Is it by design that the code below does not compile?
import std.algorithm, std.range;
void main() {
typeof(iota(10).map!(a=a)) x = iota(10).map!(a=a);
}
Error message (DMD git-latest on DPaste):
Error: constructor f755.main.MapResult!(__lambda2,
Result).MapResult.this (Result input) is not callable using
argument types (MapResult!(__lambda4, Result))
Error: cannot implicitly convert expression (map(iota(10))) of
type MapResult!(__lambda4, Result) to Result
Re: typeof map
I think it's because each lambda litteral is treated unique.
can dmd be changed to recognize identical lambda litterals as identical? Is
there any particular issue making that difficult?
it already recognizes identical string literals as identical
On Mon, Jun 24, 2013 at 7:45 PM, cal callumena...@gmail.com wrote:
Is it by design that the code below does not compile?
import std.algorithm, std.range;
void main() {
typeof(iota(10).map!(a=a)) x = iota(10).map!(a=a);
}
Error message (DMD git-latest on DPaste):
Error: constructor f755.main.MapResult!(__**lambda2,
Result).MapResult.this (Result input) is not callable using argument types
(MapResult!(__lambda4, Result))
Error: cannot implicitly convert expression (map(iota(10))) of type
MapResult!(__lambda4, Result) to Result
Re: typeof map
On Tue, Jun 25, 2013 at 04:45:33AM +0200, cal wrote:
Is it by design that the code below does not compile?
import std.algorithm, std.range;
void main() {
typeof(iota(10).map!(a=a)) x = iota(10).map!(a=a);
}
[...]
The workaround is to use 'auto', then alias its type:
auto x = iota(10).map!(a=a);
alias IotaType = typeof(x);
But yeah it would be nice if the original code worked.
T
--
Tell me and I forget. Teach me and I remember. Involve me and I understand. --
Benjamin Franklin
