Re: exit(1)?
On 2015-12-17 06:11, Jakob Ovrum wrote: Ouch, that's not good. `exit` is not a good way to terminate a D program. It doesn't call destructors, including module destructors. The example should be restructured to `return 1;` from `main`. I agree with that, but why don't the runtime register a function with "atexit" that cleans up everything? -- /Jacob Carlborg
Re: No documentation for core.sys?
On 2015-12-17 04:47, Jakob Ovrum wrote: core.sys contains packages with system-specific D interface files (ports of header files). As with core.stdc, refer to the documentation for the equivalent C header. core.stdc is documented, in the sense that empty doc comments have been added to all symbols to make them show up in the docs [1]. I think the same should be done for core.sys as well. Then at least you know it exists and then can look up the documentation for the C header file for more information. [1] I think it was Steven Schveighoffer that did that enormous work. -- /Jacob Carlborg
Re: Why should file names intended for executables be valid identifiers?
On 2015-12-17 05:26, Shriramana Sharma wrote: Sorry but I don't get this fully: can't a hyphen be part of such mangled names? Aren't they just strings that the linker hashes or something? (My knowledge of compiler/executable internals is limited.) I'm not sure about a hyphen but a dollar sign is allowed for example. And any reflection of the module name would also be just a string which need not be a valid identifier no? I would guess it's to simplify the compiler. Funny thing: Ruby allows you to have names of methods that you cannot declare and cannot call :). The trick is to use metaprogramming and reflection to declare and call the methods. -- /Jacob Carlborg
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 06:04:14 UTC, Jeremy DeHaan wrote: And I guess what I was talking about before is that using a factory method feels klunky to me. If the things I am wrapping had been written in D they could use default initialization, so it feels wrong to do otherwise. I also just don't really like factory methods. They feel like a workaround that the end user has to deal with. But that's just me. If the type you're wrapping would still be accessed through a reference type, then that reference type would have exactly the same situation. But yeah, it would allow you to make it a value type.
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 04:59:20 UTC, Jakob Ovrum wrote:
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
http://dpaste.com/3FH3W13
Also, I would be wary of lazy initialization. We have bad
experiences with it for AAs and standard containers. A typical
example would be:
void foo(Wrapper w)
{
...
w.doTheThing();
...
}
void main()
{
Wrapper w;
foo();
w.inspect(); // `w` is still a null reference here
}
Thanks for the heads up. I'll think more on this, but you made a
good point here.
And I guess what I was talking about before is that using a
factory method feels klunky to me. If the things I am wrapping
had been written in D they could use default initialization, so
it feels wrong to do otherwise. I also just don't really like
factory methods. They feel like a workaround that the end user
has to deal with. But that's just me.
Re: exit(1)?
On Thursday, 17 December 2015 at 05:02:50 UTC, Shriramana Sharma wrote: http://dlang.org/phobos/std_getopt.html has a line in an example saying exit(1); Surely this works only if core.stdc.stdlib is imported? Should the example be modified to show the import? And is exit() the canonical way to exit the current process even in D? Ouch, that's not good. `exit` is not a good way to terminate a D program. It doesn't call destructors, including module destructors. The example should be restructured to `return 1;` from `main`.
exit(1)?
http://dlang.org/phobos/std_getopt.html has a line in an example saying exit(1); Surely this works only if core.stdc.stdlib is imported? Should the example be modified to show the import? And is exit() the canonical way to exit the current process even in D? -- Shriramana Sharma, Penguin #395953
Re: Testing if a file is connected to a terminal
Jakob Ovrum wrote: > Where's the reference documentation? There's a README: http://code.dlang.org/packages/consoled, and the source does seem to have DDoc comments... -- Shriramana Sharma, Penguin #395953
Re: Testing if a file is connected to a terminal
On Thursday, 17 December 2015 at 04:05:57 UTC, Adam D. Ruppe wrote: On Thursday, 17 December 2015 at 03:59:27 UTC, Jakob Ovrum wrote: There are some terminal libraries on Github (like consoled) but I have to say I think they're uninspiring in terms of quality and presentation. Can you be any more specific about that? Where's the reference documentation?
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan wrote: Thanks. I guess what bugs me is that I always try to hide the fact that the API is a wrapper around C stuff, ie, I want to make people feel as though they're using idiomatic D. Doing something like this makes it feel like less idiomatic D and more like a wrapper. I think I have a solution that I like in my own case though. Right now I'm considering something like this: http://dpaste.com/3FH3W13 I completely understand your sentiment, but I don't see how default construction factors into it. D libraries that *aren't* wrappers around C libraries have the same restriction and have to make the same interface choices. Or did you mean something else? Your code looks good, but make sure you either disable postblit or implement the postblit operator appropriately. The Rule of Three applies well to D.
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
http://dpaste.com/3FH3W13
Also, I would be wary of lazy initialization. We have bad
experiences with it for AAs and standard containers. A typical
example would be:
void foo(Wrapper w)
{
...
w.doTheThing();
...
}
void main()
{
Wrapper w;
foo();
w.inspect(); // `w` is still a null reference here
}
Re: No documentation for core.sys?
On Thursday, 17 December 2015 at 04:23:30 UTC, Shriramana Sharma wrote: Jakob Ovrum wrote: As with core.stdc, refer to the documentation for the equivalent C header. I only know of even core.stdc's existence since I've been poking into the Phobos sources. At least the Phobos documentation should mention that such modules exist. Maybe. The thing is, the bindings in core.sys have been built on an as-needed (by druntime or Phobos) basis, so some of them are incomplete and some headers are probably missing. That said, I'm not very familiar with it, so maybe the current status is different. I know for one thing that core.sys.windows recently had a major overhaul. [sigh] This is why D's API version is still 0, as in 2.0.69.2 (at least my interpretation of the weird zero-prefixed numbering being used). Uh, hyperbole much? https://github.com/D-Programming-Language/druntime/pull/1402
Re: Why should file names intended for executables be valid identifiers?
Adam D. Ruppe wrote: > It still has a module name that can be used in reflection, must > be used in name disambiguation (at the linker level if nothing > else, any functions are mangled with the module name so they > don't conflict with C functions with the same name), and other > things. Sorry but I don't get this fully: can't a hyphen be part of such mangled names? Aren't they just strings that the linker hashes or something? (My knowledge of compiler/executable internals is limited.) And any reflection of the module name would also be just a string which need not be a valid identifier no? -- Shriramana Sharma, Penguin #395953
Re: No documentation for core.sys?
Jakob Ovrum wrote: > As with core.stdc, refer to the > documentation for the equivalent C header. I only know of even core.stdc's existence since I've been poking into the Phobos sources. At least the Phobos documentation should mention that such modules exist. I note that in the proposed library documentation, core.stdc is mentioned: https://dlang.org/library/index.html, but core.sys.posix is not... [sigh] This is why D's API version is still 0, as in 2.0.69.2 (at least my interpretation of the weird zero-prefixed numbering being used). -- Shriramana Sharma, Penguin #395953
Re: Error 42: Symbol Undefined __lseeki64
On Wednesday, 16 December 2015 at 18:30:41 UTC, Byron Heads wrote:
On Wednesday, 16 December 2015 at 18:21:33 UTC, Byron Heads
wrote:
On Wednesday, 16 December 2015 at 18:14:35 UTC, Byron Heads
wrote:
[...]
Commenting out
gzclose(fpGZip);
allows it to compile..
Submitted reduced case as a bug:
https://issues.dlang.org/show_bug.cgi?id=15457
import etc.c.zlib;
void main() {
gzclose(null);
}
I searched the function "__lseek64" under /usr/include/dmd" with
"grep -R __lseek64", but nothing is found. I work on Linux
64-bit. So, I guess it is either Windows related, or 32bit dmd
related. "lseek64" is found in "unistd.d", but this doesn't solve
any problem.
Re: Testing if a file is connected to a terminal
On Thursday, 17 December 2015 at 03:59:27 UTC, Jakob Ovrum wrote: There are some terminal libraries on Github (like consoled) but I have to say I think they're uninspiring in terms of quality and presentation. Can you be any more specific about that?
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 03:43:58 UTC, Jakob Ovrum wrote: On Thursday, 17 December 2015 at 03:31:37 UTC, Jeremy DeHaan wrote: Hi all. I'm interfacing to some C code which include an opaque type and some C functions that create and work with a pointer to that type. I want to wrap up everything in a struct, and the only thing that seems to bug me is initialization. Since it is C code, I obviously can't read the function that creates the opaque type. Not only that, I can't define a default constructor. What are my options here? This is for an API that is intended to be used by people other than myself, so I'd like to use something that doesn't look ugly or isn't a hack. I really don't like the idea of using a factory method or overriding opCall. Am I basically out of luck and need to resort to one of these methods? Using a factory function alongside @disable this(); is the canonical way to do this. Although, if your struct is a reference type, you can simply allow default construction and have it mean a null reference. Using static opCall here is just a factory function with special syntax, but I think it does more harm than good. Thanks. I guess what bugs me is that I always try to hide the fact that the API is a wrapper around C stuff, ie, I want to make people feel as though they're using idiomatic D. Doing something like this makes it feel like less idiomatic D and more like a wrapper. I think I have a solution that I like in my own case though. Right now I'm considering something like this: http://dpaste.com/3FH3W13
Re: Testing if a file is connected to a terminal
On Thursday, 17 December 2015 at 03:38:31 UTC, Shriramana Sharma wrote: Is there a canonical way to test in D whether stdout/stderr (or in general, a std.stdio.File) refers to a terminal or not? https://www.google.co.in/search?q=terminal&sitesearch=dlang.org/phobos turns out nothing. I knew of C's (or rather POSIX's) isatty, and after some digging I found isatty defined under core.sys.posix.unistd, and I suppose I can just pass to it the output of std.stdio.File.getFP. Is there any other way to do the desired test? Or is this the recommended way? We don't have any terminal functionality in Phobos at this time, so using isatty directly is the way to go. There are some terminal libraries on Github (like consoled) but I have to say I think they're uninspiring in terms of quality and presentation.
Re: No documentation for core.sys?
On Thursday, 17 December 2015 at 03:40:02 UTC, Shriramana Sharma wrote: In my recent search for D's equivalent of isatty, I found out that there is a core.sys.posix module only by rgrepping under /usr/include/dmd. Why isn't there a documentation page http://dlang.org/phobos/core_sys.html whereas lots of other core.* modules are documented? core.sys contains packages with system-specific D interface files (ports of header files). As with core.stdc, refer to the documentation for the equivalent C header.
No documentation for core.sys?
In my recent search for D's equivalent of isatty, I found out that there is a core.sys.posix module only by rgrepping under /usr/include/dmd. Why isn't there a documentation page http://dlang.org/phobos/core_sys.html whereas lots of other core.* modules are documented? -- Shriramana Sharma, Penguin #395953
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 03:31:37 UTC, Jeremy DeHaan wrote: Hi all. I'm interfacing to some C code which include an opaque type and some C functions that create and work with a pointer to that type. I want to wrap up everything in a struct, and the only thing that seems to bug me is initialization. Since it is C code, I obviously can't read the function that creates the opaque type. Not only that, I can't define a default constructor. What are my options here? This is for an API that is intended to be used by people other than myself, so I'd like to use something that doesn't look ugly or isn't a hack. I really don't like the idea of using a factory method or overriding opCall. Am I basically out of luck and need to resort to one of these methods? Using a factory function alongside @disable this(); is the canonical way to do this. Although, if your struct is a reference type, you can simply allow default construction and have it mean a null reference. Using static opCall here is just a factory function with special syntax, but I think it does more harm than good.
Testing if a file is connected to a terminal
Is there a canonical way to test in D whether stdout/stderr (or in general, a std.stdio.File) refers to a terminal or not? https://www.google.co.in/search?q=terminal&sitesearch=dlang.org/phobos turns out nothing. I knew of C's (or rather POSIX's) isatty, and after some digging I found isatty defined under core.sys.posix.unistd, and I suppose I can just pass to it the output of std.stdio.File.getFP. Is there any other way to do the desired test? Or is this the recommended way? -- Shriramana Sharma, Penguin #395953
Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
Hi all. I'm interfacing to some C code which include an opaque type and some C functions that create and work with a pointer to that type. I want to wrap up everything in a struct, and the only thing that seems to bug me is initialization. Since it is C code, I obviously can't read the function that creates the opaque type. Not only that, I can't define a default constructor. What are my options here? This is for an API that is intended to be used by people other than myself, so I'd like to use something that doesn't look ugly or isn't a hack. I really don't like the idea of using a factory method or overriding opCall. Am I basically out of luck and need to resort to one of these methods?
Re: isBidirectionalRange fails for unknown reasons
On Wednesday, 16 December 2015 at 20:43:02 UTC, Jack Stouffer
wrote:
...
You can also use return type covariance:
class ReferenceBidirectionalRange(T) : ReferenceForwardRange!T
{
this(Range)(Range r) if (isInputRange!Range) { super(r); }
final override @property typeof(this) save() { return new
typeof(this)(_payload); }
final @property ref T back(){ return _payload.back; }
final void popBack(){ _payload.popBack(); }
}
ReferenceBidirectionalRange!T is a subtype of
ReferenceForwardRange!T, so the override is legal.
Re: isBidirectionalRange fails for unknown reasons
On Wednesday, 16 December 2015 at 21:40:44 UTC, anonymous wrote:
The `.save` primitive of forward ranges must return the very
same type that the range has. But your
ReferenceBidirectionalRange!T.save returns a
ReferenceForwardRange!T, because it's inherited. That makes
isForwardRange!(ReferenceBidirectionalRange!T) fail, and
everything that depends on it.
You can override `save` in ReferenceBidirectionalRange or try
something clever like using a template this parameter:
@property auto save(this This)() {return new This( _payload);}
Thanks! That did the trick.
Re: isBidirectionalRange fails for unknown reasons
On 16.12.2015 21:43, Jack Stouffer wrote:
I'm trying to add a ReferenceBidirectionalRange range type to
std.internal.test.dummyrange so I can test some range code I'm writing,
but I've hit a wall and I'm not sure why. For some reason, the
isBidirectionalRange check fails even though back and popBack are
present. Any help here would be appreciated.
[...]
class ReferenceForwardRange(T) : ReferenceInputRange!T
{
this(Range)(Range r) if (isInputRange!Range) { super(r); }
final @property ReferenceForwardRange save()
{return new ReferenceForwardRange!T( _payload); }
}
class ReferenceBidirectionalRange(T) : ReferenceForwardRange!T
{
this(Range)(Range r) if (isInputRange!Range) { super(r); }
final @property ref T back(){ return _payload.back; }
final void popBack(){ _payload.popBack(); }
}
The `.save` primitive of forward ranges must return the very same type
that the range has. But your ReferenceBidirectionalRange!T.save returns
a ReferenceForwardRange!T, because it's inherited. That makes
isForwardRange!(ReferenceBidirectionalRange!T) fail, and everything that
depends on it.
You can override `save` in ReferenceBidirectionalRange or try something
clever like using a template this parameter:
@property auto save(this This)() {return new This( _payload);}
Re: isBidirectionalRange fails for unknown reasons
On Wednesday, 16 December 2015 at 20:43:02 UTC, Jack Stouffer
wrote:
unittest
{
static assert(isInputRange!(ReferenceInputRange!int)); //
works
static assert(isForwardRange!(ReferenceForwardRange!int));
// works
static
assert(isBidirectionalRange!(ReferenceBidirectionalRange!int));
//fails
}
Also, this works just fine
=
unittest
{
auto a = new ReferenceBidirectionalRange!int([1,2]);
a.popBack();
a.back.writeln; // prints 1
}
isBidirectionalRange fails for unknown reasons
I'm trying to add a ReferenceBidirectionalRange range type to
std.internal.test.dummyrange so I can test some range code I'm
writing, but I've hit a wall and I'm not sure why. For some
reason, the isBidirectionalRange check fails even though back and
popBack are present. Any help here would be appreciated.
the code:
import std.range;
class ReferenceInputRange(T)
{
import std.array : array;
this(Range)(Range r) if (isInputRange!Range) { _payload =
array(r); }
final @property ref T front(){ return _payload.front; }
final void popFront(){ _payload.popFront(); }
final @property bool empty(){ return _payload.empty; }
protected T[] _payload;
}
class ReferenceForwardRange(T) : ReferenceInputRange!T
{
this(Range)(Range r) if (isInputRange!Range) { super(r); }
final @property ReferenceForwardRange save()
{return new ReferenceForwardRange!T( _payload); }
}
class ReferenceBidirectionalRange(T) : ReferenceForwardRange!T
{
this(Range)(Range r) if (isInputRange!Range) { super(r); }
final @property ref T back(){ return _payload.back; }
final void popBack(){ _payload.popBack(); }
}
unittest
{
static assert(isInputRange!(ReferenceInputRange!int)); //
works
static assert(isForwardRange!(ReferenceForwardRange!int)); //
works
static
assert(isBidirectionalRange!(ReferenceBidirectionalRange!int));
//fails
}
Re: Implicit Interface Deduction
On Sunday, 13 December 2015 at 22:09:47 UTC, Faux Amis wrote:
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {}
interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC
// is not really scalable ;)
void main()
{
IAB c = new C(); // This doesn't work.
}
// Any suggestions?
I believe you can use std.typecons.wrap for this.
import std.typecons: wrap;
import std.stdio;
interface IA
{
void quack();
}
interface IB
{
int divBy2(int n);
}
interface IAB: IA, IB
{
}
class Test: IA, IB
{
override void quack()
{
writeln("quack!");
}
override int divBy2(int n)
{
return n / 2;
}
}
void main()
{
auto t = new Test();
IAB tAsIAB = t.wrap!IAB;
tAsIAB.quack();
writeln(tAsIAB.divBy2(4));
assert(!is(Test : IAB));
assert(is(tAsIAB: IAB));
}
Re: Error 42: Symbol Undefined __lseeki64
On Wednesday, 16 December 2015 at 18:21:33 UTC, Byron Heads wrote:
On Wednesday, 16 December 2015 at 18:14:35 UTC, Byron Heads
wrote:
On Wednesday, 16 December 2015 at 17:23:15 UTC, Byron Heads
wrote:
Seeing this issue on 2.069.2 using etc.c.zlib.
C:\d\dmd2\windows\bin\..\lib\phobos.lib(gzlib)
Error 42: Symbol Undefined __lseeki64
The code was compiling in 2.067. Not clear on where to look
to fix this issue.
I can reproduce with this code...
Windows dmd 2.069.2 32bit
import std.stream;
import std.exception;
// todo: add bzip support..
class GZipBufferedFile : BufferedFile {
private:
GZipFile gZipFile;
/**
* GZipFile stream, safly opens and closes a gzip file,
also will correctly read from the zip file
*/
class GZipFile : File {
import std.c.stdio;
import etc.c.zlib;
FILE* fp;
gzFile fpGZip;
/**
* Use gzopen to open the zip file
*/
this(string filename) {
fp = fopen(filename.toStringz, "rb");
enforce(fp !is null, "Failed to open file
'%s'".format(filename));
version(Windows) {
fpGZip = gzdopen(fp._file, "rb");
super(fpGZip, FileMode.In);
} else {
fpGZip = gzdopen(fileno(fp), "rb");
super(cast(int)fpGZip, FileMode.In);
}
seekable = true;
// Still not supported... sigh
//gzbuffer(fpGZip, 1024 * 1024);
}
ulong tell() {
fflush(fp);
return ftell(fp);
}
/**
* read data block with gzread
*/
override size_t readBlock(void* buffer, size_t size) {
assertReadable();
size = gzread(fpGZip, buffer, cast(uint)size);
if (size == -1) {
size = 0;
}
// use gzeof to test for end of file
readEOF = fpGZip.gzeof != 0;
return size;
}
/**
* make sure we close with gzclose
*/
override void close() {
gzclose(fpGZip);
fpGZip = null;
fp = null;
}
}
public:
this(string filename) {
gZipFile = new GZipFile(filename);
super(gZipFile);
}
ulong tell() {
return gZipFile.tell;
}
}
void main() {
}
Commenting out
gzclose(fpGZip);
allows it to compile..
Submitted reduced case as a bug:
https://issues.dlang.org/show_bug.cgi?id=15457
import etc.c.zlib;
void main() {
gzclose(null);
}
Re: Error 42: Symbol Undefined __lseeki64
On Wednesday, 16 December 2015 at 18:14:35 UTC, Byron Heads wrote:
On Wednesday, 16 December 2015 at 17:23:15 UTC, Byron Heads
wrote:
Seeing this issue on 2.069.2 using etc.c.zlib.
C:\d\dmd2\windows\bin\..\lib\phobos.lib(gzlib)
Error 42: Symbol Undefined __lseeki64
The code was compiling in 2.067. Not clear on where to look
to fix this issue.
I can reproduce with this code...
Windows dmd 2.069.2 32bit
import std.stream;
import std.exception;
// todo: add bzip support..
class GZipBufferedFile : BufferedFile {
private:
GZipFile gZipFile;
/**
* GZipFile stream, safly opens and closes a gzip file,
also will correctly read from the zip file
*/
class GZipFile : File {
import std.c.stdio;
import etc.c.zlib;
FILE* fp;
gzFile fpGZip;
/**
* Use gzopen to open the zip file
*/
this(string filename) {
fp = fopen(filename.toStringz, "rb");
enforce(fp !is null, "Failed to open file
'%s'".format(filename));
version(Windows) {
fpGZip = gzdopen(fp._file, "rb");
super(fpGZip, FileMode.In);
} else {
fpGZip = gzdopen(fileno(fp), "rb");
super(cast(int)fpGZip, FileMode.In);
}
seekable = true;
// Still not supported... sigh
//gzbuffer(fpGZip, 1024 * 1024);
}
ulong tell() {
fflush(fp);
return ftell(fp);
}
/**
* read data block with gzread
*/
override size_t readBlock(void* buffer, size_t size) {
assertReadable();
size = gzread(fpGZip, buffer, cast(uint)size);
if (size == -1) {
size = 0;
}
// use gzeof to test for end of file
readEOF = fpGZip.gzeof != 0;
return size;
}
/**
* make sure we close with gzclose
*/
override void close() {
gzclose(fpGZip);
fpGZip = null;
fp = null;
}
}
public:
this(string filename) {
gZipFile = new GZipFile(filename);
super(gZipFile);
}
ulong tell() {
return gZipFile.tell;
}
}
void main() {
}
Commenting out
gzclose(fpGZip);
allows it to compile..
Re: Error 42: Symbol Undefined __lseeki64
On Wednesday, 16 December 2015 at 17:23:15 UTC, Byron Heads wrote:
Seeing this issue on 2.069.2 using etc.c.zlib.
C:\d\dmd2\windows\bin\..\lib\phobos.lib(gzlib)
Error 42: Symbol Undefined __lseeki64
The code was compiling in 2.067. Not clear on where to look to
fix this issue.
I can reproduce with this code...
Windows dmd 2.069.2 32bit
import std.stream;
import std.exception;
// todo: add bzip support..
class GZipBufferedFile : BufferedFile {
private:
GZipFile gZipFile;
/**
* GZipFile stream, safly opens and closes a gzip file, also
will correctly read from the zip file
*/
class GZipFile : File {
import std.c.stdio;
import etc.c.zlib;
FILE* fp;
gzFile fpGZip;
/**
* Use gzopen to open the zip file
*/
this(string filename) {
fp = fopen(filename.toStringz, "rb");
enforce(fp !is null, "Failed to open file
'%s'".format(filename));
version(Windows) {
fpGZip = gzdopen(fp._file, "rb");
super(fpGZip, FileMode.In);
} else {
fpGZip = gzdopen(fileno(fp), "rb");
super(cast(int)fpGZip, FileMode.In);
}
seekable = true;
// Still not supported... sigh
//gzbuffer(fpGZip, 1024 * 1024);
}
ulong tell() {
fflush(fp);
return ftell(fp);
}
/**
* read data block with gzread
*/
override size_t readBlock(void* buffer, size_t size) {
assertReadable();
size = gzread(fpGZip, buffer, cast(uint)size);
if (size == -1) {
size = 0;
}
// use gzeof to test for end of file
readEOF = fpGZip.gzeof != 0;
return size;
}
/**
* make sure we close with gzclose
*/
override void close() {
gzclose(fpGZip);
fpGZip = null;
fp = null;
}
}
public:
this(string filename) {
gZipFile = new GZipFile(filename);
super(gZipFile);
}
ulong tell() {
return gZipFile.tell;
}
}
void main() {
}
Re: Segfault while compiling simple program
I tested it on linux (64-bit distro), and it segfaults as well:
-
$ echo "struct S { ushort a, b; ubyte c, d; } struct T { ushort
e; S s; }" > test.d
$ dmd -v test.d
binarydmd
version v2.069.0
config/etc/dmd.conf
parse test
importall test
importobject(/usr/include/dmd/druntime/import/object.d)
semantic test
Segmentation fault
$ uname -r
3.13.0-37-generic
$ cat /etc/issue
Linux Mint 17.1 Rebecca \n \l
$ dmd --version
DMD64 D Compiler v2.069.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
-
It doesn't crash if compiled in 32-bit:
-
$ dmd -v -m32 test.d
binarydmd
version v2.069.0
config/etc/dmd.conf
parse test
importall test
importobject(/usr/include/dmd/druntime/import/object.d)
semantic test
semantic2 test
semantic3 test
code test
gcc test.o -o test -m32 -L/usr/lib/i386-linux-gnu -Xlinker
--export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic
-lpthread -lm -lrt -ldl
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/crt1.o: In
function `_start':
(.text+0x18): undefined reference to `main'
collect2: error: ld returned 1 exit status
--- errorlevel 1
-
Using ubyte[2] or swapping the fields also solve the issue as
mentioned above.
I also reproduce the issue using DMD v2.069.2.
So it may be good to add that information in the bug-report.
Error 42: Symbol Undefined __lseeki64
Seeing this issue on 2.069.2 using etc.c.zlib. C:\d\dmd2\windows\bin\..\lib\phobos.lib(gzlib) Error 42: Symbol Undefined __lseeki64 The code was compiling in 2.067. Not clear on where to look to fix this issue.
Re: Implicit Interface Deduction
On Mon 14/12/2015 02:45, Chris Wright wrote:
On Sun, 13 Dec 2015 23:09:47 +0100, Faux Amis wrote:
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {} interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC // is not really scalable ;)
void main()
{
IAB c = new C(); // This doesn't work.
}
// Any suggestions?
If you really can't modify the declaration to suit, there are two options.
The first is to use casts. If a function would require something that's
both IA and IB, it takes an IA and casts to IB. It can use contracts to
ensure that things are of the right type. Ugly, but it works.
The second is to use templates to generate the interface you need and
appropriate wrapper classes. Then you need to manually wrap variables in
those generated wrapper classes wherever you need to pass them. You'll
end up with an API like:
alias IABC = Union!(IA, IB, IC);
void foo(IABC.Interface iabc) {}
auto c = new C;
foo(IABC.wrap(c));
If you really want to go this way, std.typecons might help. Or I hacked
up something horrific here: http://dpaste.dzfl.pl/0464f723580f
The thing is, I would like to define my class by its basic components.
It makes it very clear what type of functionality it exposes.
I do not see how the Union template is different from
interface IABC : IA, IB, IC
Maybe I don't get :(
Re: Implicit Interface Deduction
On Mon 14/12/2015 00:27, Ali Çehreli wrote:
On 12/13/2015 02:09 PM, Faux Amis wrote:
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {}
interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC
// is not really scalable ;)
It is not automatic at least because of implementation details: The
compiler should not generate a vtbl for every possible interface.
Is it acceptable to add IAB and IBC to C? If so, this works:
import std.stdio;
class C : IA, IB, IC, IAB, IBC {
void a() { writeln(__FUNCTION__); }
void b() { writeln(__FUNCTION__); }
void c() { writeln(__FUNCTION__); }
}
Ali
So, you would just add the combined interfaces to the definition.
Maybe with some nice separation this would be acceptable.
class C : IA, IB, IC,
IAB, IBC // implicit
{
// body
}
Enforcement would be difficult.
Forgetting IB, for instance, will still compile.
Re: Segfault while compiling simple program
On 2015-12-16 11:51, John Colvin wrote: I'd say list it as 'all', chances are it crashes the same on linux as well. If it's an ICE, it's very likely it applies to all platforms. Unless you get an assert/crash in a platform specific file in DMD. -- /Jacob Carlborg
Re: I Did It! Calling D Library from Objective C in XCode on OSX
On 2015-12-16 10:19, John Colvin wrote: How exactly would it do that? I guess it could parse some output from dmd to check that it's looking in the right directories, that would be a nice enhancement. Not sure, but for one thing, don't put any files any global directories. That is, don't put dmd.conf in /etc, don't put phobos in /usr/lib and so on. How does it do that? It adds DMD to the beginning of the PATH environment variable and doesn't rely on any global files. DVM seems useful if you really need multiple versions of DMD installed, but in general I don't like having a special installer tool for each piece of software, each with its own way of doing things. I can see the point of that. But with the current update rate of D and the fact it breaks my code in each single release, I think being able to have multiple versions of DMD installed is crucial. Another advantage is that DVM is cross-platform. If you're using multiple platforms you can use the same way to install DMD on all the platforms. -- /Jacob Carlborg
Re: How to split a string/array with multiple separators?
On Wednesday, 16 December 2015 at 14:47:26 UTC, Dragos Carp wrote:
On Wednesday, 16 December 2015 at 14:18:28 UTC, Borislav
Kosharov wrote:
I want to split a string using multiple separators. In
std.array the split function has a version where it takes a
range as a separator, but it works differently than what I
want. Say if I call it with " -> " it will search for the
whole thing together. I want to pass split a list of
separators say [":", ",", ";"] and if it finds any of those to
split it.
Sorry if this questions is stupid but I cant find how to do it.
void main()
{
import std.stdio: writeln;
writeln("abc,def;ghi".splitter!(a =>
!":,;".find(a).empty).array);
}
The call to `array` is unnecessary in this example, and you can
use the shorter `canFind`:
writeln("abc,def;ghi".splitter!(a => ":,;".canFind(a)));
Re: How to split a string/array with multiple separators?
On Wednesday, 16 December 2015 at 14:18:28 UTC, Borislav Kosharov
wrote:
I want to split a string using multiple separators. In
std.array the split function has a version where it takes a
range as a separator, but it works differently than what I
want. Say if I call it with " -> " it will search for the whole
thing together. I want to pass split a list of separators say
[":", ",", ";"] and if it finds any of those to split it.
Sorry if this questions is stupid but I cant find how to do it.
void main()
{
import std.stdio: writeln;
writeln("abc,def;ghi".splitter!(a =>
!":,;".find(a).empty).array);
}
How to split a string/array with multiple separators?
I want to split a string using multiple separators. In std.array the split function has a version where it takes a range as a separator, but it works differently than what I want. Say if I call it with " -> " it will search for the whole thing together. I want to pass split a list of separators say [":", ",", ";"] and if it finds any of those to split it. Sorry if this questions is stupid but I cant find how to do it.
Re: Segfault while compiling simple program
I use dpaste to test compilation on linux.
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 10:15:49 UTC, Saurabh Das wrote:
On Wednesday, 16 December 2015 at 10:07:38 UTC, Saurabh Das
wrote:
On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli
wrote:
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a
workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
We are using it to communicate with Excel, so swapping it is
not an option.
I'll report it as a compiler bug. In the meantime, this is a
workaround worked for me:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte[2] cols;
}
Filed: https://issues.dlang.org/show_bug.cgi?id=15455
Under OS, I've selected Mac OS X since only 1 OS selection is
allowed. Is the convention to select 'Other' in cases where
ICEs are observed in multiple OSes?
Thanks,
Saurabh
I think it's more normal to select 'all' once it affects more
than one. OS X only bugs are likely to get less attention because
developers don't necessarily have the necessary machines to
quickly test on. 'other' might be interpreted as something
obscure. I'd say list it as 'all', chances are it crashes the
same on linux as well.
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 10:07:38 UTC, Saurabh Das wrote:
On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli
wrote:
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a
workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
We are using it to communicate with Excel, so swapping it is
not an option.
I'll report it as a compiler bug. In the meantime, this is a
workaround worked for me:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte[2] cols;
}
Filed: https://issues.dlang.org/show_bug.cgi?id=15455
Under OS, I've selected Mac OS X since only 1 OS selection is
allowed. Is the convention to select 'Other' in cases where ICEs
are observed in multiple OSes?
Thanks,
Saurabh
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli wrote:
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a
workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
We are using it to communicate with Excel, so swapping it is not
an option.
I'll report it as a compiler bug. In the meantime, this is a
workaround worked for me:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte[2] cols;
}
Re: Segfault while compiling simple program
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 09:26:33 UTC, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Windows (dmd 2.069.2)
==
dmd -v -m64 dprob.d
binary C:\D\dmd2\windows\bin\dmd.exe
version v2.069.2
config C:\D\dmd2\windows\bin\sc.ini
parse xlcall_wrap2
importall xlcall_wrap2
import object
(C:\D\dmd2\windows\bin\src\druntime\import\object.d)
semantic xlcall_wrap2
object.Error@(0): assert(0) or HLT instruction
0x0040496F
0x00404CF8
0x004CF2B6
0x004565A7
0x0044EAB0
0x004BF99E
0x74F757F9 in MultiByteToWideChar
0x76F2139E in RtlQueryProcessDebugInformation
0x76F21340 in RtlQueryProcessDebugInformation
0x76F21190 in RtlQueryProcessDebugInformation
What gives?
Saurabh
Any compiler crash is a bug, please report at issues.dlang.org
While you wait for it to be fixed, try swapping reflist and count
and you should find it doesn't crash. You should probably do
anyway to avoid wasting space in the struct
(http://www.catb.org/esr/structure-packing/)
Segfault while compiling simple program
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Windows (dmd 2.069.2)
==
dmd -v -m64 dprob.d
binary C:\D\dmd2\windows\bin\dmd.exe
version v2.069.2
config C:\D\dmd2\windows\bin\sc.ini
parse xlcall_wrap2
importall xlcall_wrap2
import object
(C:\D\dmd2\windows\bin\src\druntime\import\object.d)
semantic xlcall_wrap2
object.Error@(0): assert(0) or HLT instruction
0x0040496F
0x00404CF8
0x004CF2B6
0x004565A7
0x0044EAB0
0x004BF99E
0x74F757F9 in MultiByteToWideChar
0x76F2139E in RtlQueryProcessDebugInformation
0x76F21340 in RtlQueryProcessDebugInformation
0x76F21190 in RtlQueryProcessDebugInformation
What gives?
Saurabh
Re: I Did It! Calling D Library from Objective C in XCode on OSX
On Wednesday, 16 December 2015 at 07:46:53 UTC, Jacob Carlborg wrote: On 2015-12-15 15:43, John Colvin wrote: I have no idea how you got something in /Library/D, but it doubt it was from homebrew. The native installer installs into /Library/D. Well that probably explains the problem then. Possible, but more likely a leftover from installing dmd some other way. Seems to be the case in 90% of "I installed dmd using X and it didn't work". Shouldn't an installer make sure the files it installed is the files being used? How exactly would it do that? I guess it could parse some output from dmd to check that it's looking in the right directories, that would be a nice enhancement. I wouldn't want it to try and do much to fix the situation if it didn't work, that would be too intrusive. The important thing is not to mix and match installers unless you know how they work. DVM will take precedence :) How does it do that? DVM seems useful if you really need multiple versions of DMD installed, but in general I don't like having a special installer tool for each piece of software, each with its own way of doing things.
