Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 18:53:33 UTC, Gary Willoughby wrote: On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. If you change the way SDL is initialised it works. Instead of doing: SDL_Init(SDL_INIT_EVERYTHING); do: SDL_Init(0); SDL_InitSubSystem(SDL_INIT_TIMER); SDL_InitSubSystem(SDL_INIT_AUDIO); SDL_InitSubSystem(SDL_INIT_JOYSTICK); SDL_InitSubSystem(SDL_INIT_HAPTIC); SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER); SDL_InitSubSystem(SDL_INIT_EVENTS); Initialising the following exhibits the crash. // SDL_InitSubSystem(SDL_INIT_VIDEO); So there must be an incompatibility with the video subsystem and tcl/tk. So it seems. Thank you very much for helping me. You were a big help.
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/04/2014 12:26 PM, Steven Schveighoffer wrote: This looks like a dmd bug. Posted: https://issues.dlang.org/show_bug.cgi?id=13687 Ali
Re: UDA failling to build when using delegate
On 11/04/2014 01:58 PM, bioinfornatics wrote: >> test.d(40): Error: type Section!((letter) => letter == '>', >> (letter) => letter == '\x0a') has no value You have this line: @Section!(/* ... */) Although that is a type name, there is a bug somewhere and sometimes you have to use a 'value' as a UDA. (We talked about this recently but I don't remember the details.) So make it an object so that it is a 'value': @Section!(/* ... */)() (You have another instance of that.) You will have to deal with the next set of error messages now. :-/ Ali
Re: UDA failling to build when using delegate
On Tuesday, 4 November 2014 at 00:32:52 UTC, bioinfornatics wrote: On Monday, 3 November 2014 at 23:53:53 UTC, bioinfornatics wrote: Dear, why this code fail to build http://dpaste.dzfl.pl/8ef3898b05d2 ? I try to have a structure which is used to fill information from a file. And I use UDA to tell : to get this field you need to read from x to y using a delegate. thanks for your advise with ldc and dmdfe 2.066 i got: $ ldc2 test.d test.d(40): Error: type Section!((letter) => letter == '>', (letter) => letter == '\x0a') has no value tuple((Section!((letter) => letter == '>', (letter) => letter == '\x0a'))) Section!((letter) => letter == '>', (letter) => letter == '\x0a') test.d(92): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(99): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(101): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(109): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(43): Error: type Section!((letter) => letter >= 'A' && letter <= 'z', (letter) => letter == '\x0a') has no value tuple((Section!((letter) => letter >= 'A' && letter <= 'z', (letter) => letter == '\x0a'))) Section!((letter) => letter >= 'A' && letter <= 'z', (letter) => letter == '\x0a') test.d(92): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(99): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(101): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(109): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(7): Error: template instance test.Parser!(Fasta, ByChunk) error instantiating No one can to help about uda?
Re: Efficient file search and extract
On Tuesday, November 04, 2014 20:12:21 Sativa via Digitalmars-d-learn wrote:
> Is there a very easy way to search a file for a string, then
> extract to a new file everything from that match on to the end of
> the file?
>
> I basically want to remove a header from a file(it's length is
> not fixed though).
>
> It seems I'm having to convert bytes to chars to strings and back
> and all that mess, which is not very elegant.
By far the easiest would be something like
import std.algorithm;
import std.file;
auto fileContents = std.file.readText("filename");
auto found = fileContents.find(stringImLookingFor);
std.file.write("filename", found);
though that requires reading the entire file into memory at once. If you're
dealing with a text file, that probably isn't a problem though, and any
sane alternatives would require writing to a new file and then moving that
file to replace the old one, which is more involved. But std.stdio.File and
std.stdio.File.byLine can be used to read the file one line at a time, in
which case you'd just not write any of the lines until you found a line with
the string that you were looking for, in which case you'd write the part of
the line that you wanted to a file, and then write every line after that to
the file. Or you could use std.mmfile.MmFile to read the whole file as a
memory buffer, use find on that to find the portion that you want and then
write it to disk (probably with std.file.write), but that definitely
requires some casting and probably only makes sense if you want to be able
to use find on the whole file at once without necessarily bringing the
entire file into memory at once. Personally, I'd just use std.file.readText
and std.file.write though. It's simple, and it would only be a problem if
you were dealing with a very large file (which text files normally aren't).
- Jonathan M Davis
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/04/2014 12:41 PM, Steven Schveighoffer wrote:
> Yep. I debugged it. It's calling toHash instead.
Yeah, you were spot on. :) I did a different experiment. I added a
number of functions to the interface (before virtualCheck()) and
implementations to the class:
interface I
{
// ...
bool a();
bool b();
bool c();
bool d();
bool virtualCheck();
}
class C : I
{
// ...
bool a() { return false; }
bool b() { return false; }
bool c() { return false; }
bool d() { return false; }
}
Adding only a() calls C's precondition unconditionally (because it
pushes virtualCheck() to the next slot in vtbl.)
Adding a() and b() has the same effect.
Adding a(), b(), and c() prints I.foo.in indefinitely. :)
Finally, adding a(), b(), c(), and d() seems to bring the expected
behavior. :)
Ali
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/4/14 3:26 PM, Steven Schveighoffer wrote:
On 11/4/14 3:01 PM, Ali Çehreli wrote:
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln("I.foo.in");
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln("C.foo.in");
}
body
{}
bool virtualCheck()
{
writeln("C.virtualCheck");
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
<-- Where is C.virtualCheck?
<-- Where is C.foo.in?
Ali
This looks like a dmd bug. My theory is that the call to virtualCheck is
going to the WRONG vtbl address. I have seen stuff like this before. It
likely is calling something like toString. You would have to debug to
figure it out.
So what I think happens is it calls the wrong virtual function, which
returns non-zero always, and obviously doesn't print anything, and then
continues on. I added a writeln("after virtual check") to the in
contract of I.foo, and it writes that too.
Yep. I debugged it. It's calling toHash instead.
Proof (the weird casting thing is because I wanted to call writeln from
toHash, but toHash is nothrow and writeln is not) :
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* * base's and the derived's in contracts 50% of the time
* * because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln("I.foo.in");
/* This check succeeds without calling virtualCheck! */
assert(this.virtualCheck());
writeln("after virtual check");
}
bool virtualCheck();
}
void printToHash() { writeln("in toHash");}
class C : I
{
void foo()
in {
writeln("C.foo.in");
}
body
{}
bool virtualCheck()
{
writeln("C.virtualCheck");
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
override size_t toHash() @trusted
{
auto f = cast(void function() nothrow)&printToHash;
f();
return 1;
}
}
output:
I.foo.in
in toHash
after virtual check
Please report to bugzilla.
-Steve
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/4/14 3:01 PM, Ali Çehreli wrote:
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln("I.foo.in");
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln("C.foo.in");
}
body
{}
bool virtualCheck()
{
writeln("C.virtualCheck");
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
<-- Where is C.virtualCheck?
<-- Where is C.foo.in?
Ali
This looks like a dmd bug. My theory is that the call to virtualCheck is
going to the WRONG vtbl address. I have seen stuff like this before. It
likely is calling something like toString. You would have to debug to
figure it out.
So what I think happens is it calls the wrong virtual function, which
returns non-zero always, and obviously doesn't print anything, and then
continues on. I added a writeln("after virtual check") to the in
contract of I.foo, and it writes that too.
-Steve
Efficient file search and extract
Is there a very easy way to search a file for a string, then extract to a new file everything from that match on to the end of the file? I basically want to remove a header from a file(it's length is not fixed though). It seems I'm having to convert bytes to chars to strings and back and all that mess, which is not very elegant.
Re: The interface's 'in' contract passes if it makes a virtual function call
Ali Çehreli: Perhaps I am expecting too much from the current 'in' contract design and implementation. ;) The "in contract" is named pre-condition, or precondition. Bye, bearophile
The interface's 'in' contract passes if it makes a virtual function call
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln("I.foo.in");
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln("C.foo.in");
}
body
{}
bool virtualCheck()
{
writeln("C.virtualCheck");
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
<-- Where is C.virtualCheck?
<-- Where is C.foo.in?
Ali
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. If you change the way SDL is initialised it works. Instead of doing: SDL_Init(SDL_INIT_EVERYTHING); do: SDL_Init(0); SDL_InitSubSystem(SDL_INIT_TIMER); SDL_InitSubSystem(SDL_INIT_AUDIO); SDL_InitSubSystem(SDL_INIT_JOYSTICK); SDL_InitSubSystem(SDL_INIT_HAPTIC); SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER); SDL_InitSubSystem(SDL_INIT_EVENTS); Initialising the following exhibits the crash. // SDL_InitSubSystem(SDL_INIT_VIDEO); So there must be an incompatibility with the video subsystem and tcl/tk.
Re: rndtonl
I think rndtonl is a C library function that isn't always present in the system. It doesn't work on my computer either and I can't find any documentation about it. It is probably not meant to be called by end users.
Re: Reading unicode string with readf ("%s")
On Tuesday, 4 November 2014 at 18:09:48 UTC, Ivan Kazmenko wrote: On Monday, 3 November 2014 at 20:10:02 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 19:47:17 UTC, Ivan Kazmenko wrote: So, if there is an idiomatic way to read the whole file into a string which is Unicode-compatible, it would be great to learn that, too. Maybe something like this: import std.stdio; import std.array; import std.conv; string text = stdin .byLine(KeepTerminator.yes) .join() .to!(string); And thanks for a short alternative! At first glance, looks like it sacrifices a bit of efficiency on the way: the "remove-line-breaks, then add-line-breaks" path looks redundant. Still, it does not store intermediate splitted representation, so the inefficiency is in fact not catastrophic, right? And sorry, I didn't read that correctly. Using byLine with KeepTerminator.yes and join with nothing, it does not alter line breaks at all. So, the efficiency of this is entirely up to whether optimizer is able to detect that the break/join sequence is a operation.
rndtonl
what am I doing wrong here?
import std.math;
import std.stdio;
void main()
{
real fac;
fac=1.2;
fac=rndtonl(fac);
}
[root@fedorabox util]# dmd bug.d
bug.o: In function `_Dmain':
bug.d:(.text._Dmain+0x3b): undefined reference to `rndtonl'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 18:22:49 UTC, Gary Willoughby wrote: On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. Have you got a copy of the dub.json file you use? Ah, no matter, i've got all the libs installed and linking now.
Re: Reading unicode string with readf ("%s")
On Tuesday, 4 November 2014 at 13:01:48 UTC, anonymous wrote:
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko wrote:
Hi!
The following code does not correctly handle Unicode strings.
-
import std.stdio;
void main () {
string s;
readf ("%s", &s);
write (s);
}
-
Example input ("Test." in cyrillic):
-
Тест.
-
(hex: D0 A2 D0 B5 D1 81 D1 82 2E 0D 0A)
Example output:
-
ТеÑÑ.
-
(hex: C3 90 C2 A2 C3 90 C2 B5 C3 91 C2 81 C3 91 C2 82 2E 0D 0A)
Here, the input bytes are handled separately: D0 -> C3 90, A2
-> C2 A2, etc.
On the bright side, reading the file with readln works
properly.
Is this an expected shortcoming of "%s"-reading a string?
No.
Could it be made to work somehow?
Yes. std.stdio.LockingTextReader is to blame:
void main()
{
import std.stdio;
auto ltr = LockingTextReader(std.stdio.stdin);
write(ltr);
}
$ echo Тест | rdmd test.d
ТеÑÑ
LockingTextReader has a dchar front. But it doesn't do any
decoding. The dchar front is really a char front.
Is it worth a bug report?
Yes.
Ivan Kazmenko.
You nailed it!
Reported the bug in original form:
https://issues.dlang.org/show_bug.cgi?id=13686
Perhaps your reduction would be useful.
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. Have you got a copy of the dub.json file you use?
Re: Reading unicode string with readf ("%s")
On Tuesday, 4 November 2014 at 11:46:24 UTC, Kagamin wrote: https://issues.dlang.org/show_bug.cgi?id=12990 this? Similar, but not quite that. Bugs 12990 and 1448 (linked from there) seem to have Windows console as an important part of the process. For me, the example does not work even with files, either redirected via "test.exe two.txt" or using File structs inside D program. Still, thank you for the link!
Re: Reading unicode string with readf ("%s")
On Monday, 3 November 2014 at 20:10:02 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 19:47:17 UTC, Ivan Kazmenko wrote: So, if there is an idiomatic way to read the whole file into a string which is Unicode-compatible, it would be great to learn that, too. Maybe something like this: import std.stdio; import std.array; import std.conv; string text = stdin .byLine(KeepTerminator.yes) .join() .to!(string); And thanks for a short alternative! At first glance, looks like it sacrifices a bit of efficiency on the way: the "remove-line-breaks, then add-line-breaks" path looks redundant. Still, it does not store intermediate splitted representation, so the inefficiency is in fact not catastrophic, right?
Re: Reading unicode string with readf ("%s")
On Monday, 3 November 2014 at 20:03:03 UTC, Ali Çehreli wrote:
On 11/03/2014 11:47 AM, Ivan Kazmenko wrote:
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko
wrote:
readf ("%s", &s);
Worth noting: this reads to end-of-file (not end-of-line or
whitespace),
and reading the whole file into a string was what I indeed
expected it
to do.
So, if there is an idiomatic way to read the whole file into a
string
which is Unicode-compatible, it would be great to learn that,
too.
I don't know the answer to the Unicode issue with readf but you
can read the file by chunks:
import std.stdio;
import std.array;
import std.exception;
string readAll(File file)
{
char[666] buffer;
char[] contents;
char[] piece;
do {
piece = file.rawRead(buffer);
contents ~= piece;
} while (!piece.empty);
return assumeUnique(contents);
}
void main () {
string s = stdin.readAll();
write (s);
}
Ali
Thank you for suggesting an alternative!
Looks like it would be an efficient one, too.
I believe it can be made a bit more efficient if using an
appender, right?
Still, that's a lot of code for a minute scripting task, albeit
one has to write the readAll function only once.
Re: Pointer across threads
There is assumeUnique which effectively does cast to immutable but is more clear to the reader in a sense why breaking type system was considered legit. I recommend using it over raw cast.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 16:07:11 UTC, thedeemon wrote: On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? "immutable" is part of the static type system, it's a label that only exists and makes sense at compile time, for compiler and the programmer. Casting a mutable data pointer to immutable data pointer is a no-op, just a copy of pointer. Address stays the same, data stays the same. So if you mutate the data it will lead to "immutable" data being changed just because it's not really immutable, you've just fooled yourself when doing the cast. That's what I was thinking too.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? "immutable" is part of the static type system, it's a label that only exists and makes sense at compile time, for compiler and the programmer. Casting a mutable data pointer to immutable data pointer is a no-op, just a copy of pointer. Address stays the same, data stays the same. So if you mutate the data it will lead to "immutable" data being changed just because it's not really immutable, you've just fooled yourself when doing the cast.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:47:49 UTC, anonymous wrote: On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? Changing *data.data would be undefined behaviour. Don't do it. Once data is typed as immutable, it must not change anymore. By casting you're side-stepping the type system, so that you have to make sure of such things yourself. Hm. I'm not planning to change data.data, of course, but I was worried (and curious) about potential safety issues. I suppose I could convert short* to short[] > idup it > pass a reference to the C function (that expects short*). However, I want to avoid this, because there shouldn't be any additional operations (it's a (near) real time system).
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? Changing *data.data would be undefined behaviour. Don't do it. Once data is typed as immutable, it must not change anymore. By casting you're side-stepping the type system, so that you have to make sure of such things yourself.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote:
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because
tmp and data.data are still pointing to the same address? If
this is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted
to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)*
on the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a
reason for it.
I'm still curious, though, how D handles this internally,
because data.data is still mutable while the other reference to
the same address (tmp) is not. What if I change data.data while
the other thread is being executed?
Just tested it.
writeln(data.data[0]);
data.data[0] = -11;
send(play, tmp, data.len);
writeln(tmp[0]);
//
receive (
(immutable(short)* data, size_t len) {
writeln(data[0];
});
prints
0 // original value
-11 // tmp
-11 // data in the other thread
Is this behavior intended?
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)* on
the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a reason
for it.
I'm still curious, though, how D handles this internally, because
data.data is still mutable while the other reference to the same
address (tmp) is not. What if I change data.data while the other
thread is being executed?
PS In this case, it was hard to provide a complete test case,
because there are things going on in a C function and other D
modules.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Re: Reading unicode string with readf ("%s")
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko wrote:
Hi!
The following code does not correctly handle Unicode strings.
-
import std.stdio;
void main () {
string s;
readf ("%s", &s);
write (s);
}
-
Example input ("Test." in cyrillic):
-
Тест.
-
(hex: D0 A2 D0 B5 D1 81 D1 82 2E 0D 0A)
Example output:
-
ТеÑÑ.
-
(hex: C3 90 C2 A2 C3 90 C2 B5 C3 91 C2 81 C3 91 C2 82 2E 0D 0A)
Here, the input bytes are handled separately: D0 -> C3 90, A2
-> C2 A2, etc.
On the bright side, reading the file with readln works properly.
Is this an expected shortcoming of "%s"-reading a string?
No.
Could it be made to work somehow?
Yes. std.stdio.LockingTextReader is to blame:
void main()
{
import std.stdio;
auto ltr = LockingTextReader(std.stdio.stdin);
write(ltr);
}
$ echo Тест | rdmd test.d
ТеÑÑ
LockingTextReader has a dchar front. But it doesn't do any
decoding. The dchar front is really a char front.
Is it worth a bug report?
Yes.
Ivan Kazmenko.
Pointer across threads
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because tmp
and data.data are still pointing to the same address? If this is
the case, why doesn't the compiler warn me? Or is it something
else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Re: Pointer across threads
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Sorry, it should read
send(proc, tmp, data.len);
Re: isRangeOf ?
Jonathan M Davis: That loses the ability to test which type of range you're talking about. Yes, one can think about templates like "isForwardRangeOf", etc. But for such specialized cases I think using isForwardRange+is(ElementType) is acceptable and avoids adding too many templates to Phobos. isRangeOf is for the common case where any range is OK (a forward range), and you need a range of items of type T (opApply still gives an iterable but unfortunately it's not compatible with most Phobos. That's why I have not suggested a function named "isIterableOf" meant to accept opApply too). I have opened an ER: https://issues.dlang.org/show_bug.cgi?id=13682 Bye, bearophile
Re: isRangeOf ?
On Tuesday, November 04, 2014 09:40:58 bearophile via Digitalmars-d-learn wrote:
> Sometimes I have a function that needs an iterable:
>
> void foo(Range)(Range data)
> if (isForwardRange!Range && is(Unqual!(ForeachType!Range) ==
> int)) {}
>
>
> So is it a good idea to add a "isRangeOf" template to Phobos?
>
> void foo(Range)(Range data)
> if (isRangeOf!(Range, int)) {}
That loses the ability to test which type of range you're talking about. The
normal thing to do is to simply test the range type and the element type
similar to what you're doing in the first case (though normaly,
Unqual!(ElementType!Range) would be used rather than
Unqual!(ForeachType!Range)). And if what you're really trying to do is check
whether the data variable can be used with foreach, and e in
foreach(e; data)
would be an int, calling it a range isn't really correct anyway, since
opApply and container types would also qualify.
- Jonathan M Davis
Re: manually call opUnary
On Tuesday, November 04, 2014 07:19:03 Algo via Digitalmars-d-learn wrote:
> Is it possible?
> As in
> {
> int a;
> a.opUnary!"++"();
> }
> no property 'opUnary' for type 'int'
opUnary only exists when it's been declared on a user-defined type. The way
to use it generically is to use the actual operator - ++ in this case. There
might be a case where calling opUnary directly makes sense, but in general,
it really doesn't. Regardless, it doesn't exist for built-ins.
- Jonathan M Davis
Re: Reading unicode string with readf ("%s")
https://issues.dlang.org/show_bug.cgi?id=12990 this?
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On 11/4/2014 7:34 PM, Jack wrote: On Tuesday, 4 November 2014 at 08:30:34 UTC, Gary Willoughby Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. You might start by adding a call to Mix_Init after SDL_Init and before calling any other Mix_* functions. SDL_Init doesn't know anything about the SDL_mixer library. See [1] for details (and don't forget the corresponding Mix_Quit [2]). [1] https://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_9.html [2] https://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_10.html#SEC10
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 08:30:34 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 22:26:14 UTC, Jack wrote: I'll try and think about this for a while Thanks for the help sir. No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error.
isRangeOf ?
Sometimes I have a function that needs an iterable:
void foo(Range)(Range data)
if (isForwardRange!Range && is(Unqual!(ForeachType!Range) ==
int)) {}
So is it a good idea to add a "isRangeOf" template to Phobos?
void foo(Range)(Range data)
if (isRangeOf!(Range, int)) {}
Bye,
bearophile
Re: Struct template
On Monday, 3 November 2014 at 17:05:21 UTC, John Colvin wrote: static if (is(typeof(T) == int)) should be static if (is(T == int)) T is already a type. I thought this was supposed to produce an error message rather than fail silently... I'm positive this used to be an error. Did it change?
Re: Templates for structures
On Monday, 3 November 2014 at 14:53:29 UTC, Ali Çehreli wrote: It sounds possible but I don't understand it yet. Can you give an example of the input and output to the D code? Ali Thank you Ali. I realized, that my wishes look like serialization. So i decide read and learn code from existent serialization libraries.
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Monday, 3 November 2014 at 22:26:14 UTC, Jack wrote: I'll try and think about this for a while Thanks for the help sir. No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening?
