Segmentation fault after having a certain number of elements in an array?
I'll be trying to narrow it down even more tomorrow, but I was
hoping somone here might have some insight into this weird issue
I am having.
I have a dynamic array of shorts that I had been trying to append
to (capturing sound data). I kept getting a segfault when doing
the append, and have narrowed it down to getting a segfault when
the length of the array is equal to or greater than 1024.
It looks wonky because of my many tests, but this is the code
that was causing the segfault:
override bool onProcessSamples(const(short)[] samples)
{
import std.stdio;
for(int i = 0; iIt will print all the numbers, endikng with 1023, and then it
shows "Segmentation fault" and if I comment out the writeln line
it just shows the Segmentation fault line. Similar code that
would cause the length to be at 1024 or higher will also cause a
segfault.
The class that this method belongs to is wraped up in a C++
interface and it gets called C++ side.
Also, if I set the length to 1024 or higher in the class
constructor or if I create a different array elsewhere and set
its length to 1024 or higher, I don't get the segfault anymore.
As far as I can tell, this only happens because it is called in
C++ code. It doesn't appear to happen on my system at all if I do
anything like this outside of my C++ interoperating. So far my
fix is to set the length of the array to 1024, and then right
away set it back to 0 in the class' constructor, but I'd like to
get this to work without any strange hacks.
Re: Segmentation fault after having a certain number of elements in an array?
I should also mention that this is on Linux. I haven't tried on OSX or Windows yet.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: for(int i = 0; i m_samples.length +=1; You are testing i against an ever-increasing limit aren't you, so it's an infinite loop.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 09:24:51 UTC, Paul wrote: On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: for(int i = 0; i m_samples.length +=1; You are testing i against an ever-increasing limit aren't you, so it's an infinite loop. Not really. When the function is called, the length of "samples" (Incoming sound data) is usually around 4000. "m_samples" (the total samples recorded) doesn't make it past 1024 in length without segfaulting. It probably doesn't matter, but the array passed to this function is actually a slice created from a pointer and length generated in the C++ side.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 09:24:51 UTC, Paul wrote: You are testing i against an ever-increasing limit aren't you, so it's an infinite loop. Read more carefully. samples is unmodified, it's m_samples whose length is changed.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: I'll be trying to narrow it down even more tomorrow, but I was hoping somone here might have some insight into this weird issue I am having. Could you upload the code to somewhere? With only a small snippet, it's hard to get any clue.
Re: The package feature is ignored when the file name is package.di
On Saturday, December 13, 2014 02:34:21 Jeremy DeHaan via Digitalmars-d-learn wrote: > Is this on purpose? Granted, I almost never use interface files, > but I had a whim to use them for what I was working on today. > > Everything worked fine when I renamed the file to package.d, but > apparently package.di is not acceptible. It probably was never considered. But given that all that's really supposed to be put in a package.d file is public imports, it's not like supporting package.di really adds much, though arguably it should work for consistency's sake. - Jonathan M Davis
Re: std.array oddness
ketmar: no, you are using `.byLine` incorrectly. ;-) `.byLine` reuses it's internal buffer for each line, so you have to copy that buffer. A simple solution is to use byLineCopy (that unfortunately should have been the default behavior since the beginning). Bye, bearophile
repack ubyte[] to use only 7 bits
Is there a standard way to do this? The code below is untested, as I
haven't yet written the x7to8 routine, and came up with a better way to
do what this was to accomplish, but it feels as if this should be
somewhere in the standard library, if I could only find it.
/** Repack the data from an array of ubytes into an array of ubytes of
* which only the last 7 are significant. The high bit will be set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 => 0xfe = 1110, 0x00 =
//1 => 0x7f = 0111, 0x00 =
//2 => 0x3f = 0011, 0x80 = 1000
//3 => 0x1f = 0001, 0xc0 = 1100
//4 => 0x0f = , 0xe0 = 1110
//5 => 0x07 = 0111, 0xf0 =
//6 => 0x03 = 0011, 0xf8 = 1000
//7 => 0x01 = 0001, 0xfc = 1100
if (bin.length < 1)returnbout;
intfByte, fBit;
while(fByte < bin.length)
{if (fByte + 1 == bin.length && fBit > 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] & 0x7f;
break;
case2:
ubyteb1=(bin[fByte] & 0x3f) << 1;
ubyteb2=(bin[fByte + 1] & 0x80) >>> 7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] & 0x1f) << 2;
ubyteb2=(bin[fByte + 1] & 0xc0) >>> 6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] & 0x0f) << 3;
ubyteb2=(bin[fByte + 1] & 0xe0) >>> 5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] & 0x07) << 4;
ubyteb2=(bin[fByte + 1] & 0xf0) >>> 4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] & 0x03) << 5;
ubyteb2=(bin[fByte + 1] & 0xf8) >>> 3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] & 0x01) << 6;
ubyteb2=(bin[fByte + 1] & 0xfc) >>> 2;
b~= (b1 | b2);
break;
default:
assert (false, "This path should never be taken");
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit > 7)
{fByte++;
fBit -=7;
}
}
}
Re: std.array oddness
On Sat, 13 Dec 2014 10:01:49 + bearophile via Digitalmars-d-learn wrote: > > no, you are using `.byLine` incorrectly. ;-) `.byLine` reuses > > it's > > internal buffer for each line, so you have to copy that buffer. > > A simple solution is to use byLineCopy (that unfortunately should > have been the default behavior since the beginning). that thing is not documented on dlang.org (i assume that it's from upcoming 2.067). signature.asc Description: PGP signature
Re: std.bitmanip - bitshift?
On Friday, 12 December 2014 at 19:35:26 UTC, Steven Schveighoffer wrote: On 12/12/14 2:17 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Fri, Dec 12, 2014 at 11:13:38AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/12/14 8:39 AM, Trollgeir wrote: http://dlang.org/phobos/std_bitmanip.html Does anyone know how to bit-shift a BitArray? I'm trying to make spikes in a neural network travel along the bits as they have various lengths. That is a surprising omission from a bit-oriented type... You also cannot opSlice a BitArray. Nice for enhancement requests, if you want to add them to the issue tracker. [...] I've started working on an implementation of this... but it's not very clear what the correct semantics should be. For example, if my starting BitArray b is 1101, say, what should be the result after b>>=1? Should it be 0110, 110, or 01101? 0110 In other words, I would assume the same semantics as an unsigned int. In other other words, it's like each bit moves one to the right, and the bit that has no source gets a 0. There's a dedicated >>> operator for unsigned right shift, the normal >> operator does a signed right shift, i.e. it copies the left-most bit: http://dlang.org/expression#ShiftExpression IMO, for consistency, bitarray should behave the same. It may be useful to add some other functions, such as roll, which would move bits that fall off the end back onto the top. Yes, that would be useful.
Re: repack ubyte[] to use only 7 bits
On Saturday, 13 December 2014 at 10:09:27 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
Is there a standard way to do this? The code below is
untested, as I haven't yet written the x7to8 routine, and came
up with a better way to do what this was to accomplish, but it
feels as if this should be somewhere in the standard library,
if I could only find it.
/** Repack the data from an array of ubytes into an array of
ubytes of
* which only the last 7 are significant. The high bit will be
set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 => 0xfe = 1110, 0x00 =
//1 => 0x7f = 0111, 0x00 =
//2 => 0x3f = 0011, 0x80 = 1000
//3 => 0x1f = 0001, 0xc0 = 1100
//4 => 0x0f = , 0xe0 = 1110
//5 => 0x07 = 0111, 0xf0 =
//6 => 0x03 = 0011, 0xf8 = 1000
//7 => 0x01 = 0001, 0xfc = 1100
if (bin.length < 1)returnbout;
intfByte, fBit;
while(fByte < bin.length)
{if (fByte + 1 == bin.length && fBit > 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] & 0x7f;
break;
case2:
ubyteb1=(bin[fByte] & 0x3f) << 1;
ubyteb2=(bin[fByte + 1] & 0x80) >>>
7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] & 0x1f) << 2;
ubyteb2=(bin[fByte + 1] & 0xc0) >>>
6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] & 0x0f) << 3;
ubyteb2=(bin[fByte + 1] & 0xe0) >>>
5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] & 0x07) << 4;
ubyteb2=(bin[fByte + 1] & 0xf0) >>>
4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] & 0x03) << 5;
ubyteb2=(bin[fByte + 1] & 0xf8) >>>
3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] & 0x01) << 6;
ubyteb2=(bin[fByte + 1] & 0xfc) >>>
2;
b~= (b1 | b2);
break;
default:
assert (false, "This path should never be
taken");
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit > 7)
{fByte++;
fBit -=7;
}
}
}
Are you trying to make a "kind-of" Variable-Length quantity
encoder ?
eg:
0b10101110: last bit not set, integrate 0b10101110 and stop
reading.
0b10011001: last bit set, integrate 0b10011000 and continue to
next byte.
http://en.wikipedia.org/wiki/Variable-length_quantity
except that this algo limits the length to 24 bits. It was used a
lot with
MIDI, at a time when hardware memory was costly (eg inside
hardware synthesizer or workstations).
Re: repack ubyte[] to use only 7 bits
On Saturday, 13 December 2014 at 11:20:21 UTC, Manolo wrote:
On Saturday, 13 December 2014 at 10:09:27 UTC, Charles Hixson
via Digitalmars-d-learn wrote:
Is there a standard way to do this? The code below is
untested, as I haven't yet written the x7to8 routine, and came
up with a better way to do what this was to accomplish, but it
feels as if this should be somewhere in the standard library,
if I could only find it.
/** Repack the data from an array of ubytes into an array of
ubytes of
* which only the last 7 are significant. The high bit will be
set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 => 0xfe = 1110, 0x00 =
//1 => 0x7f = 0111, 0x00 =
//2 => 0x3f = 0011, 0x80 = 1000
//3 => 0x1f = 0001, 0xc0 = 1100
//4 => 0x0f = , 0xe0 = 1110
//5 => 0x07 = 0111, 0xf0 =
//6 => 0x03 = 0011, 0xf8 = 1000
//7 => 0x01 = 0001, 0xfc = 1100
if (bin.length < 1)returnbout;
intfByte, fBit;
while(fByte < bin.length)
{if (fByte + 1 == bin.length && fBit > 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] & 0x7f;
break;
case2:
ubyteb1=(bin[fByte] & 0x3f) << 1;
ubyteb2=(bin[fByte + 1] & 0x80) >>>
7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] & 0x1f) << 2;
ubyteb2=(bin[fByte + 1] & 0xc0) >>>
6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] & 0x0f) << 3;
ubyteb2=(bin[fByte + 1] & 0xe0) >>>
5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] & 0x07) << 4;
ubyteb2=(bin[fByte + 1] & 0xf0) >>>
4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] & 0x03) << 5;
ubyteb2=(bin[fByte + 1] & 0xf8) >>>
3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] & 0x01) << 6;
ubyteb2=(bin[fByte + 1] & 0xfc) >>>
2;
b~= (b1 | b2);
break;
default:
assert (false, "This path should never be
taken");
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit > 7)
{fByte++;
fBit -=7;
}
}
}
Are you trying to make a "kind-of" Variable-Length quantity
encoder ?
eg:
0b10101110: last bit not set, integrate 0b10101110 and stop
reading.
0b10011001: last bit set, integrate 0b10011000 and continue to
next byte.
http://en.wikipedia.org/wiki/Variable-length_quantity
except that this algo limits the length to 24 bits. It was used
a lot with
MIDI, at a time when hardware memory was costly (eg inside
hardware synthesizer or workstations).
Sorry, lack or accuraccy: the maximum value represented was a 24
bit unsigned integer, but the data length was 32 bit for this
value.
The thing is that the format included various fields, but because
of the memory price the algo saved space when values where less
than 0X7F, because only one byte was needed. Nowadays such as
format would allow for example always 4 bytes to describes the
data length:
nowadays:
data len "L" | data
0 1 2 3 | 4 ... L-1
so "nowadays", we can afford 4 bytes to say that a field length
is 1
olddays:
variable len VL | data
1 to ? | VL ... VL-1
"olddays", they used only one byte to say that a field length is
1.
fibers and ranges: what's wrong here?
import std.stdio, core.thread;
struct Tree{
int val;
Tree[] tree;
}
struct TreeRange{
Tree curtree;
bool empty;
Fiber worker;
this(Tree t){
worker = new Fiber(&fiberFunc);
curtree = t;
popFront();
}
void fiberFunc(){
Tree t = curtree;
Fiber.yield();
foreach(child; t.tree){
curtree = child;
fiberFunc();
}
}
int front(){ return curtree.val; };
void popFront() {
worker.call();
empty = worker.state == Fiber.State.TERM;
}
}
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
auto tr1 = TreeRange(tt);
foreach(v; tr1){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
writeln();
}
output:
5, 5, 5, 5, 5,
5, 7, 11, 4, 10,
Is it supposed to work?
Re: std.array oddness
On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via Digitalmars-d-learn wrote: .map!"a.idup" That can be just .map!idup.
Re: std.array oddness
On Sat, 13 Dec 2014 12:07:27 + thedeemon via Digitalmars-d-learn wrote: > On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via > Digitalmars-d-learn wrote: > > .map!"a.idup" > > That can be just .map!idup. it depends of compiler version, as `idup` was a property some time ago. better be safe than sorry. signature.asc Description: PGP signature
Re: fibers and ranges: what's wrong here?
When you assigning the worker in TreeRange, you create a delegate
that captures the current TreeRange or 'this'.
---
worker = new Fiber(&fiberFunc);
---
foreach is defined as
(http://dlang.org/statement.html#ForeachStatement):
---
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e = __r.front;
...
}
---
__r is a copy of your range that still refers to the original
worker which in turn refers to your original range. So when you
popFront, the worker will advance the original range and if you
call front you get the element from __r - unadvanced.
That's my best guess.
Re: fibers and ranges: what's wrong here?
On 13.12.14 13:01, zeljkog wrote:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
auto tr1 = TreeRange(tt);
foreach(v; tr1){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
writeln();
}
Sorry, this works:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
foreach(v; TreeRange(tt)){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
writeln();
}
I needed this:
struct TreeRange{
this (this){ throw new Exception("TreeRange is noncopyable!"); }
...
}
Or use class :)
Re: fibers and ranges: what's wrong here?
On Saturday, 13 December 2014 at 12:26:49 UTC, zeljkog wrote:
On 13.12.14 13:01, zeljkog wrote:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
auto tr1 = TreeRange(tt);
foreach(v; tr1){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
writeln();
}
Sorry, this works:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
foreach(v; TreeRange(tt)){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
writeln();
}
I needed this:
struct TreeRange{
this (this){ throw new Exception("TreeRange is
noncopyable!"); }
...
}
Or use class :)
Have a look at @disable.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 09:47:40 UTC, Artem Tarasov wrote: On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: I'll be trying to narrow it down even more tomorrow, but I was hoping somone here might have some insight into this weird issue I am having. Could you upload the code to somewhere? With only a small snippet, it's hard to get any clue. Yes, but it might take some time. I'll have to make a reduced c++ and D portion. I'll see what I can manage.
Wrapping multiple extern (C) declarations in a template
I'm writing bindings to a rather big C library where the return
values of almost all functions indicate the possibility of an
error (exception).
Assuming there's a C header, "foo.h" with functions "f1", "f2",
etc, I want to have a corresponding D module, "foo.d" which would
provide the "f1", "f2" that wrap the C functions and throw
exceptions if an error is encountered (which is implemented in an
errorCheck template which checks the return value and then gets
the exception info via C API).
My current naive solution looks like this:
/* foo.h */
int f1(...);
int f2(...);
*** foo.d ***
private extern (C) nothrow {
pragma(mangle, "f1")
int c_f(...);
public alias errorCheck!c_f1 f1;
pragma(mangle, "f2")
int c_f2(...);
public alias errorCheck!c_f2 f2;
}
This way, one can "import foo" and use the same API as in C, but
with proper exception handling.
Since there is almost a thousand declarations, this leads to a
lot of manual work and boilerplate. I guess the wrapping part
itself (aliasing the wrapped functions) could be automated via a
mixin template, but how would one go around repetitive
pragma(mangle) (which I thought is needed so that private extern
declarations have different names and don't clash with the
wrapped ones )?
Re: Wrapping multiple extern (C) declarations in a template
On Saturday, 13 December 2014 at 16:34:42 UTC, aldanor wrote:
I'm writing bindings to a rather big C library where the return
values of almost all functions indicate the possibility of an
error (exception).
Assuming there's a C header, "foo.h" with functions "f1", "f2",
etc, I want to have a corresponding D module, "foo.d" which
would provide the "f1", "f2" that wrap the C functions and
throw exceptions if an error is encountered (which is
implemented in an errorCheck template which checks the return
value and then gets the exception info via C API).
My current naive solution looks like this:
/* foo.h */
int f1(...);
int f2(...);
*** foo.d ***
private extern (C) nothrow {
pragma(mangle, "f1")
int c_f(...);
public alias errorCheck!c_f1 f1;
pragma(mangle, "f2")
int c_f2(...);
public alias errorCheck!c_f2 f2;
}
This way, one can "import foo" and use the same API as in C,
but with proper exception handling.
Since there is almost a thousand declarations, this leads to a
lot of manual work and boilerplate. I guess the wrapping part
itself (aliasing the wrapped functions) could be automated via
a mixin template, but how would one go around repetitive
pragma(mangle) (which I thought is needed so that private
extern declarations have different names and don't clash with
the wrapped ones )?
Personally i wouldn't go this route. I would create foo.d as a C
to D translation only so it can be imported and used like in C.
Then i would create another module which imports this to create
your new OOP API adding features and excepions, etc.
This allows the best of both worlds, keep the C api intact for
use in D and create a new clean OOP API for whatever your needs
are.
Re: Are there any methods like isDestroyed or isDisposed to detect whether some object is destroyed or not?
"Andrey Derzhavin" writes:
> Hello!
>
> We have object, for example, objA.
>
> ObjectAType objA = new ObjectAType(...);
>
> // we have a many references to objA
>
> void someFunction1(...)
> {
>// destroying the objA
>destroy(one_of_the_refToObjA);
>
>//
> }
>
>
> void someFunction2()
> {
>// "segmentation fault" if the objA is destroyed
>another_refToObjA.method1();
>
>// I need a safe way (without using signals) to detect whether
> object
>// destroyed or not, like this
>// if (!isDestroyed(another_refToObjA))
>// another_refToObjA.method1();
>
> }
>
> // call functions
> someFunction1(..);
>
> // . some other operations...
>
> // the objectA (objA) is destroyed, but debugger shows us a not null
> reference
> // to that objA. However, when we try to call some methods of objectA
> or
> // try to use it's variables we get a "segmentation fault" error (in
> // someFunction2, when objA is destroyed).
> someFunction2(...);
>
> Thanks.
Maybe this would work for you. If you own your ObjectAType class, you
could add an ok flag. destroy() sets all members to .init value and
TDPL says this will be the case (lookup "clear" which was renamed
"destroy").
import std.stdio;
class ObjectAType {
bool ok;
this() {ok = true;}
}
void main()
{
auto a = new ObjectAType;
assert(a.ok);
destroy(a);
assert(!a.ok); // a has been destroyed.
}
--
dano
Re: scope block do not handle failure, but try-catch does
If I right understand scope is not good for checking if one of
function is fail.
For example:
string dbpass = config.getKey("dbpass");
string dbpass = config.getKey("dbpass");
string dbhost = config.getKey("dbhost");
string dbport = config.getKey("dbport");
if I will try to add scope(failure) writeln("bla-bla-bla") after
every function I will execute all writeln("bla-bla-bla") even if
second function, for example, are failed.
Is there any other way to do not wrap all function in try-catch
block, but check if they was failed in short form?
Re: Wrapping multiple extern (C) declarations in a template
Personally i wouldn't go this route. I would create foo.d as a C to D translation only so it can be imported and used like in C. Then i would create another module which imports this to create your new OOP API adding features and excepions, etc. This allows the best of both worlds, keep the C api intact for use in D and create a new clean OOP API for whatever your needs are. I've actually done it this way initially, as well, however there are certain problems. Let's say there's a "foo.d" that contains raw bindings to "foo.h" (enums, structs, extern variables, function declarations, a whole load of stuff) -- everything but the functions is already fine but all functions need to be wrapped. If I now want to have exactly the same module but with all function declarations wrapped as described above, I have to public import it in another module and then do some template magic. However, it wouldn't be possible to retain the same function names since they've been imported to the namespace (it's then also not possible to extern them as private initially since then you won't be able to import/wrap them in a different module). Hence the idea of mixing the wrapping template in the initial .d header. I guess another way would be to split each header into functions / non-functions part, and private import + wrap the first part and public import the second part into a D-ready module. It just sounds like a whole lot of boilerplate so I was hoping there would be some magic automated way of doing something similar (maybe creating a custom "import" template that "imports" non-functions via aliasing and wraps functions)...
Re: scope block do not handle failure, but try-catch does
I reread docs and understood that scope not for such case.
Next code is do what I need:
try
{
string dbname = config.getKey("dbname");
string dbpass = config.getKey("dbpass");
string dbhost = config.getKey("dbhost");
string dbport = config.getKey("dbport");
}
catch (Exception msg)
{
writeln("Can't parse config: %s", msg.msg);
}
Re: repack ubyte[] to use only 7 bits
On 12/13/2014 03:20 AM, Manolo via Digitalmars-d-learn wrote:
On Saturday, 13 December 2014 at 10:09:27 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
Is there a standard way to do this? The code below is untested, as I
haven't yet written the x7to8 routine, and came up with a better way
to do what this was to accomplish, but it feels as if this should be
somewhere in the standard library, if I could only find it.
/** Repack the data from an array of ubytes into an array of ubytes of
* which only the last 7 are significant. The high bit will be set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 => 0xfe = 1110, 0x00 =
//1 => 0x7f = 0111, 0x00 =
//2 => 0x3f = 0011, 0x80 = 1000
//3 => 0x1f = 0001, 0xc0 = 1100
//4 => 0x0f = , 0xe0 = 1110
//5 => 0x07 = 0111, 0xf0 =
//6 => 0x03 = 0011, 0xf8 = 1000
//7 => 0x01 = 0001, 0xfc = 1100
if (bin.length < 1)returnbout;
intfByte, fBit;
while(fByte < bin.length)
{if (fByte + 1 == bin.length && fBit > 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] & 0x7f;
break;
case2:
ubyteb1=(bin[fByte] & 0x3f) << 1;
ubyteb2=(bin[fByte + 1] & 0x80) >>> 7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] & 0x1f) << 2;
ubyteb2=(bin[fByte + 1] & 0xc0) >>> 6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] & 0x0f) << 3;
ubyteb2=(bin[fByte + 1] & 0xe0) >>> 5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] & 0x07) << 4;
ubyteb2=(bin[fByte + 1] & 0xf0) >>> 4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] & 0x03) << 5;
ubyteb2=(bin[fByte + 1] & 0xf8) >>> 3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] & 0x01) << 6;
ubyteb2=(bin[fByte + 1] & 0xfc) >>> 2;
b~= (b1 | b2);
break;
default:
assert (false, "This path should never be taken");
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit > 7)
{fByte++;
fBit -=7;
}
}
}
Are you trying to make a "kind-of" Variable-Length quantity encoder ?
eg:
0b10101110: last bit not set, integrate 0b10101110 and stop reading.
0b10011001: last bit set, integrate 0b10011000 and continue to next byte.
http://en.wikipedia.org/wiki/Variable-length_quantity
except that this algo limits the length to 24 bits. It was used a lot
with
MIDI, at a time when hardware memory was costly (eg inside hardware
synthesizer or workstations).
What I was trying to do was pack things into 7 bits so I could recode
0's as 128. I finally thought clearly about it and realized that I only
needed to use one particular byte value (I chose 127) to duplicate so I
could repack things with a string of 0's replaced by 127 followed by the
length (up to 126) of zeros, and for 127 itself I'd just emit 127
twice. This was to pack binary data into a string that C routines
wouldn't think had ended partway through. (If I get more than 127 zeros
in a row, I just have more than one packing code.)
SQLLite driver
On the code.dlang.org I found SQLLite driver https://github.com/biozic/d2sqlite3 Look like it's not ready for Windows: pragma(msg, "\nWARNING !!!\nDevelopped for POSIX systems only.\nNot tested on Windows.\n"); I tried to add import to my project and I got next errors: C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(49 ): Error: 'std.conv.to!string.to!(immutable(char)*).to' is not nothrow C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(47 ): Error: function 'd2sqlite3.Sqlite3.versionString' is nothrow yet may throw C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(30 5): Error: 'std.conv.to!string.to!(immutable(char)*).to' is not nothrow FAIL C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\.dub\build\libra ry-debug-windows-x86-dmd_2065-008207FF175573C9097C24CC59516A1C\ d2sqlite3 static Library Error executing command run: dmd failed with exit code 1. Is there any other SQLLite drivers ready to use for D?
Re: Wrapping multiple extern (C) declarations in a template
On Saturday, 13 December 2014 at 19:03:42 UTC, aldanor wrote: Let's say there's a "foo.d" that contains raw bindings to "foo.h" (enums, structs, extern variables, function declarations, a whole load of stuff) -- everything but the functions is already fine but all functions need to be wrapped. If I now want to have exactly the same module but with all function declarations wrapped as described above, I have to public import it in another module and then do some template magic. However, it wouldn't be possible to retain the same function names since they've been imported to the namespace (it's then also not possible to extern them as private initially since then you won't be able to import/wrap them in a different module). Hence the idea of mixing the wrapping template in the initial .d header. I guess another way would be to split each header into functions / non-functions part, and private import + wrap the first part and public import the second part into a D-ready module. It just sounds like a whole lot of boilerplate so I was hoping there would be some magic automated way of doing something similar (maybe creating a custom "import" template that "imports" non-functions via aliasing and wraps functions)... I don't think there is an easy way to do this. foo.d contains all the converted C code. Then bar.d *privately* imports foo.d and adds exceptions. I would use bar.d to improve the interface to the library not mearly wrapping functions (even though that's essentially what is happening). foo.d is the C interface. bar.d is your new OOP API complete with exceptions.
Re: repack ubyte[] to use only 7 bits
On Saturday, 13 December 2014 at 19:52:33 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
On 12/13/2014 03:20 AM, Manolo via Digitalmars-d-learn wrote:
On Saturday, 13 December 2014 at 10:09:27 UTC, Charles Hixson
via Digitalmars-d-learn wrote:
Is there a standard way to do this? The code below is
untested, as I haven't yet written the x7to8 routine, and
came up with a better way to do what this was to accomplish,
but it feels as if this should be somewhere in the standard
library, if I could only find it.
/** Repack the data from an array of ubytes into an array of
ubytes of
* which only the last 7 are significant. The high bit will
be set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 => 0xfe = 1110, 0x00 =
//1 => 0x7f = 0111, 0x00 =
//2 => 0x3f = 0011, 0x80 = 1000
//3 => 0x1f = 0001, 0xc0 = 1100
//4 => 0x0f = , 0xe0 = 1110
//5 => 0x07 = 0111, 0xf0 =
//6 => 0x03 = 0011, 0xf8 = 1000
//7 => 0x01 = 0001, 0xfc = 1100
if (bin.length < 1)returnbout;
intfByte, fBit;
while(fByte < bin.length)
{if (fByte + 1 == bin.length && fBit > 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] & 0x7f;
break;
case2:
ubyteb1=(bin[fByte] & 0x3f) << 1;
ubyteb2=(bin[fByte + 1] & 0x80)
>>> 7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] & 0x1f) << 2;
ubyteb2=(bin[fByte + 1] & 0xc0)
>>> 6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] & 0x0f) << 3;
ubyteb2=(bin[fByte + 1] & 0xe0)
>>> 5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] & 0x07) << 4;
ubyteb2=(bin[fByte + 1] & 0xf0)
>>> 4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] & 0x03) << 5;
ubyteb2=(bin[fByte + 1] & 0xf8)
>>> 3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] & 0x01) << 6;
ubyteb2=(bin[fByte + 1] & 0xfc)
>>> 2;
b~= (b1 | b2);
break;
default:
assert (false, "This path should never be
taken");
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit > 7)
{fByte++;
fBit -=7;
}
}
}
Are you trying to make a "kind-of" Variable-Length quantity
encoder ?
eg:
0b10101110: last bit not set, integrate 0b10101110 and stop
reading.
0b10011001: last bit set, integrate 0b10011000 and continue to
next byte.
http://en.wikipedia.org/wiki/Variable-length_quantity
except that this algo limits the length to 24 bits. It was
used a lot with
MIDI, at a time when hardware memory was costly (eg inside
hardware synthesizer or workstations).
What I was trying to do was pack things into 7 bits so I could
recode 0's as 128. I finally thought clearly about it and
realized that I only needed to use one particular byte value (I
chose 127) to duplicate so I could repack things with a string
of 0's replaced by 127 followed by the length (up to 126) of
zeros, and for 127 itself I'd just emit 127 twice. This was to
pack binary data into a string that C routines wouldn't think
had ended partway through. (If I get more than 127 zeros in a
row, I just have more than one packing code.)
Sorry, I misunderstood the thing.
Re: Are there any methods like isDestroyed or isDisposed to detect whether some object is destroyed or not?
import std.stdio;
class ObjectAType {
bool ok;
this() {ok = true;}
}
void main()
{
auto a = new ObjectAType;
assert(a.ok);
destroy(a);
assert(!a.ok); // a has been destroyed.
}
This method of detection of collected objects is what I needed.
Thanks to everybody for your advise.
All Unordered Pairs of Elements in a Range
Is there a Phobos method/range for selecting all pairs out of a range without caring about the ordering within each pair? Example: [1,2,3] => [(1,2), (2,3), (3,1)]
Re: Wrapping multiple extern (C) declarations in a template
On 12/14/2014 4:03 AM, aldanor wrote: However, it wouldn't be possible to retain the same function names since they've been imported to the namespace (it's then also not possible to extern them as private initially since then you won't be able to import/wrap them in a different module). Hence the idea of mixing the wrapping template in the initial .d header. Assuming the C library can be compiled as a shared library, you can load it dynamically. This will allow you to call the function names whatever you want. Declare them all as function pointers, import them privately in your wrapper module and give your wrapper functions names matching the C API.
Re: All Unordered Pairs of Elements in a Range
On Sat, Dec 13, 2014 at 10:24:50PM +, "Nordlöw" via Digitalmars-d-learn wrote: > Is there a Phobos method/range for selecting all pairs out of a range > without caring about the ordering within each pair? > > Example: > > [1,2,3] => [(1,2), (2,3), (3,1)] Sounds like: https://issues.dlang.org/show_bug.cgi?id=6788 T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
Re: All Unordered Pairs of Elements in a Range
On Saturday, 13 December 2014 at 23:08:13 UTC, H. S. Teoh via Digitalmars-d-learn wrote: [1,2,3] => [(1,2), (2,3), (3,1)] Sounds like: https://issues.dlang.org/show_bug.cgi?id=6788 Thx.
Re: SQLLite driver
On 14/12/2014 9:21 a.m., Suliman wrote: On the code.dlang.org I found SQLLite driver https://github.com/biozic/d2sqlite3 Look like it's not ready for Windows: pragma(msg, "\nWARNING !!!\nDevelopped for POSIX systems only.\nNot tested on Windows.\n"); I tried to add import to my project and I got next errors: C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(49 ): Error: 'std.conv.to!string.to!(immutable(char)*).to' is not nothrow C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(47 ): Error: function 'd2sqlite3.Sqlite3.versionString' is nothrow yet may throw C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\source\d2sqlite3.d(30 5): Error: 'std.conv.to!string.to!(immutable(char)*).to' is not nothrow FAIL C:\Users\Dima\AppData\Roaming\dub\packages\d2sqlite3-0.5.2\.dub\build\libra ry-debug-windows-x86-dmd_2065-008207FF175573C9097C24CC59516A1C\ d2sqlite3 static Library Error executing command run: dmd failed with exit code 1. Is there any other SQLLite drivers ready to use for D? Just to confirm, you are using dmd 2.065 right? Because 2.066.1 is latest version. Version 0.5.2 of that library looks to be for 2.066. Anyway, that library wraps sqlite to make it easier in D. There is bindings to sqlite in phobos [0]. [0] http://dlang.org/phobos/etc_c_sqlite3.html
Re: std.array oddness
On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via
Digitalmars-d-learn wrote:
auto names = File("names.txt")
.byLine!(char,char)(KeepTerminator.no, ',')
.map!"a.idup"
.array;
Awesome. "map!idup" does the trick.
I had looked at the "byLine" doc before posting, in particular,
this line:
"Note:
Each front will not persist after popFront is called, so the
caller must copy its contents (e.g. by calling to!string) if
retention is needed."
This explains the behavior though I didn't get it then. It's
talking about the "range" methods.
Following the component based stuff from Walter's article can be
brain-bendy. And in this case, requires careful reading of the
docs.
But I like it.
Thanks!
Re: SQLLite driver
Yes I used 2.0.65, but after updating compiler the situation did not resolved... http://www.everfall.com/paste/id.php?apd0bfs5z4eg
Re: SQLLite driver
On 14/12/2014 7:35 p.m., Suliman wrote: Yes I used 2.0.65, but after updating compiler the situation did not resolved... http://www.everfall.com/paste/id.php?apd0bfs5z4eg Ah oh, I remember this issue from 2.064 -> 2.065. Definitely hasn't been upgraded. https://github.com/biozic/d2sqlite3/issues/6
