Re: Copying with immutable arrays
On 10/28/2012 02:37 AM, Tobias Pankrath wrote:
> the struct
> SwA from above does neither correspond to SA nor to SB, it's imo more
> like SC:
>
> struct SC {
> immutable(int)* i;
> }
Just to confirm, the above indeed works:
struct SC {
immutable(int)* i;
}
void main()
{
immutable(SC)[] arr1;
SC[] arr2 = arr1.dup;// compiles
}
> Now a copy would do no harm, everything that was immutable in the source
> and is still accessable from the copy is immutable, too. Any reason
> (despite of implemenational issues) that this is not how it works?
Getting back to the original code, the issue boils down to whether we
can copy imutable(string[]) to string[]:
import std.stdio;
struct SwA {
string[] strings;
}
void main()
{
immutable(SwA)[] arr1;
writeln(typeid(arr1[0].strings));
}
The program prints the following:
immutable(immutable(immutable(char)[])[])
Translating the innermost definition as string:
immutable(immutable(string)[])
Let's remove the struct and look at a variable the same type as the member:
immutable(string[]) imm = [ "a", "b" ];
writeln(typeid(imm));
The typeid is the same:
immutable(immutable(immutable(char)[])[])
So we can concentrate on 'imm' for this exercise. This is the same
compilation error:
immutable(string[]) imm = [ "aaa", "bbb" ];
string[] mut = imm; // <-- compilation ERROR
If that compiled, then both 'imm' and 'mut' would be providing access to
the same set of strings. But the problem is, 'mut' could replace those
strings (note that it could not modify the characters of those strings,
but it could replace the whole string):
mut[0] = "hello";
That would effect 'imm' as well. ('imm' is the equivalent of SwA.strings
from your original code.)
Ali
Re: Compiling shared example.
On 10/28/2012 02:46 AM, Peter Sommerfeld wrote:
> But I wonder why I
> have do declare the variables shared if the data are declared
> to be shared. Is that a shortcoming of the current compiler ?
I had to look this one up. According to the spec, a shared struct does
not mean that the variables of that struct are automatically shared. It
means that the members of the struct are shared:
http://dlang.org/struct.html#ConstStruct
Here is a test:
import std.stdio;
shared struct S
{
int i;
int[] a;
}
void main()
{
auto s = S();
writeln(typeid(s));
writeln(typeid(s.i));
writeln(typeid(s.a));
}
According to the output, the members are shared, not the struct:
deneme.S
shared(int)
shared(shared(int)[])
> BTW: Thanks for your book! It is of great help for beginners
> like me!
>
> Peter
Thank you very much. It is really great to hear. :)
Ali
--
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: crash suggestions
On 10/28/2012 11:38 AM, Dan wrote:
> I'm having a crash I've been unable to figure out. I have a small pretty
> print function that so far has handled most of my needs. However while
> debugging I threw something at it that caused a crash, so I know it must
> have an issue.
> The portion calling out to pp is
> ---
> double getRate(double taxableGrossIncome) const {
> auto sortedRange = assumeSorted(_table[]);
> auto needle = KeyValuePair(taxableGrossIncome, 0);
> auto found = sortedRange.lowerBound(needle);
> if(!found.empty) {
> writeln(pp(found)); // fine
> writeln(pp(found), taxableGrossIncome); // fine
> writeln(taxableGrossIncome, pp(found)); // crash
> return found[$-1][1];
> }
> return 0;
> }
> ---
[...]
> The single file with main causing the crash is at:
> http://pastebin.com/M67PamQM
First, in order to build the code with dmd 2.060, I had to make
opEquals() and getRate() non-const.
I was able to reproduce the problem in my 64-bit environment.
The workaround is to compile with -m32. It worked for me.
There are some 64-bit compilation bugs. Please create a bug report if
you don't think this has already been reported:
http://d.puremagic.com/issues/
Ali
Reading results from dmd -profile
I am trying to read the text file (trace.log) created by running the dmd profiler on some code, so that I can use demangle to make the output a bit more readable. I can read it in as a char[], but the whenever I try any string ops I get an exception because there are invalid UTF-8 sequences in the text. So two questions: why does the output contain invalid UTF-8 sequences, and what would be a good way to handle the invalid sequences, since I guess I need them for proper demangling? Cheers
Re: What is the proper way to handle pointers in variable arguments list?
On 10/28/12 5:16 PM, Simen Kjaeraas wrote:
On 2012-08-28 22:10, Tyro[17] wrote:
On 10/28/12 4:44 PM, Dmitry Olshansky wrote:
On 29-Oct-12 00:36, Tyro[17] wrote:
The following fails because the compiler assumes I am trying to
dereference non-pointer variables. Can this be done?
void main()
{
int i;
int* pi;
double d;
double* pd;
char c;
char* pc;
scan(i, pi, d, pd, c, pc);
}
void scan(A...)(ref A data)
{
import std.traits;
foreach (element; data) {
if(isPointer!(typeof(element)) &&
isIntegral!(typeof(*element))) {
*element = 10;
}
}
}
Thanks
Well, first things first:
if ---> static if
Changing it to static allows compilation, however I get the following
runtime error:
"Segmentation fault: 11"
This happens whether I try to read from *element or modify it.
I assume you've actually initialized the pointers to something?
Given the above code, all the pointers point to null, and a segfault
would be a reasonable reaction.
Wow, so obvious yet so obviously overlooked... *banging my head on the
monitor*
Thanks
Re: What is the proper way to handle pointers in variable arguments list?
On 2012-08-28 22:10, Tyro[17] wrote:
On 10/28/12 4:44 PM, Dmitry Olshansky wrote:
On 29-Oct-12 00:36, Tyro[17] wrote:
The following fails because the compiler assumes I am trying to
dereference non-pointer variables. Can this be done?
void main()
{
int i;
int* pi;
double d;
double* pd;
char c;
char* pc;
scan(i, pi, d, pd, c, pc);
}
void scan(A...)(ref A data)
{
import std.traits;
foreach (element; data) {
if(isPointer!(typeof(element)) &&
isIntegral!(typeof(*element))) {
*element = 10;
}
}
}
Thanks
Well, first things first:
if ---> static if
Changing it to static allows compilation, however I get the following
runtime error:
"Segmentation fault: 11"
This happens whether I try to read from *element or modify it.
I assume you've actually initialized the pointers to something?
Given the above code, all the pointers point to null, and a segfault
would be a reasonable reaction.
--
Simen
Re: What is the proper way to handle pointers in variable arguments list?
On 10/28/12 4:44 PM, Dmitry Olshansky wrote:
On 29-Oct-12 00:36, Tyro[17] wrote:
The following fails because the compiler assumes I am trying to
dereference non-pointer variables. Can this be done?
void main()
{
int i;
int* pi;
double d;
double* pd;
char c;
char* pc;
scan(i, pi, d, pd, c, pc);
}
void scan(A...)(ref A data)
{
import std.traits;
foreach (element; data) {
if(isPointer!(typeof(element)) &&
isIntegral!(typeof(*element))) {
*element = 10;
}
}
}
Thanks
Well, first things first:
if ---> static if
Changing it to static allows compilation, however I get the following
runtime error:
"Segmentation fault: 11"
This happens whether I try to read from *element or modify it.
Re: What is the proper way to handle pointers in variable arguments list?
On 29-Oct-12 00:36, Tyro[17] wrote:
The following fails because the compiler assumes I am trying to
dereference non-pointer variables. Can this be done?
void main()
{
int i;
int* pi;
double d;
double* pd;
char c;
char* pc;
scan(i, pi, d, pd, c, pc);
}
void scan(A...)(ref A data)
{
import std.traits;
foreach (element; data) {
if(isPointer!(typeof(element)) && isIntegral!(typeof(*element))) {
*element = 10;
}
}
}
Thanks
Well, first things first:
if ---> static if
--
Dmitry Olshansky
What is the proper way to handle pointers in variable arguments list?
The following fails because the compiler assumes I am trying to
dereference non-pointer variables. Can this be done?
void main()
{
int i;
int* pi;
double d;
double* pd;
char c;
char* pc;
scan(i, pi, d, pd, c, pc);
}
void scan(A...)(ref A data)
{
import std.traits;
foreach (element; data) {
if(isPointer!(typeof(element)) && isIntegral!(typeof(*element))) {
*element = 10;
}
}
}
Thanks
crash suggestions
I'm having a crash I've been unable to figure out. I have a small
pretty print function that so far has handled most of my needs.
However while debugging I threw something at it that caused a
crash, so I know it must have an issue.
The portion calling out to pp is
---
double getRate(double taxableGrossIncome) const {
auto sortedRange = assumeSorted(_table[]);
auto needle = KeyValuePair(taxableGrossIncome, 0);
auto found = sortedRange.lowerBound(needle);
if(!found.empty) {
writeln(pp(found)); // fine
writeln(pp(found), taxableGrossIncome); // fine
writeln(taxableGrossIncome, pp(found)); // crash
return found[$-1][1];
}
return 0;
}
---
I can call writeln(pp(found)) or writeln(pp(found),
taxableGrossIncome), but if I try writeln(taxableGrossIncome,
pp(found)) I get a seg fault in snprintf inside of
format.formatValue. It is strange to me that it is the order of
args that causes the crash.
- I don't use new/delete anywhere. I do have one branch of code
which checks against a pointer to print and derefences it if not
null.
- In gdb before the snfrpintf call, the value to be printed is
available, so my guess is somehow the local buff variable on the
stack is corrupt?
- I ran through valgrind when I commented out the offending line
and did not see anything unreasonable.
- pp creates an appender and passes it through to pprint with
what to print and that is where formatting occurs. Maybe my
creating a appender on the stack, appending to it, and then
returning the contents with '.data' is not allowed/safe and for
all my other uses I'm lucky?
- Between the 7th frame and 8th is where something goes wrong.
The weird thing is that gdb lists the print function as having a
this paramenter in addition to the two I specified. Not sure how
that is happening?
So, I'm looking for advice on anything obviously wrong, any
tricks of the trade that might help me track it down, what
standard rules am I violating, etc.
The single file with main causing the crash is at:
http://pastebin.com/M67PamQM
Also the call stack is below. Any suggestions appreciated.
Thanks
Dan
Program received signal SIGSEGV, Segmentation fault.
0x7764990a in snprintf () from
/lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0 0x7764990a in snprintf () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00433533 in
std.format.__T11formatValueTS3std5array17__T8AppenderTAyaZ8AppenderTxdTaZ.formatValue()
(f=, obj=5, w=...) at
/usr/include/dmd/phobos/std/format.d:1478
#2 0x00433132 in std.conv.__T5toStrTAyaTxdZ.toStr()
(src=5) at /usr/include/dmd/phobos/std/conv.d:99
#3 0x004330e8 in std.conv.__T6toImplTAyaTxdZ.toImpl()
(value=5) at /usr/include/dmd/phobos/std/conv.d:824
#4 0x004330cc in std.conv.__T2toTAyaZ.__T2toTxdZ.to()
(_param_0=5) at /usr/include/dmd/phobos/std/conv.d:268
#5 0x0043305c in
std.conv.__T8textImplTAyaTxdTAyaZ.textImpl() (_param_1=...,
_param_0=5) at /usr/include/dmd/phobos/std/conv.d:3060
#6 0x0043301b in std.conv.__T4textTxdTAyaZ.text()
(_param_1=..., _param_0=5) at
/usr/include/dmd/phobos/std/conv.d:3042
#7 0x00432fe1 in
e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print()
(this=0x0, t=0x7fffd8b0, appender=...) at /tmp/e.d:69
#8 0x00432ecd in
e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print()
(this=0x0, t=0x7fffd8b0, appender=...) at /tmp/e.d:31
#9 0x0042d93e in
e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print()
(t=0x7fffd970, appender=...) at /tmp/e.d:31
#10 0x0042d39d in
e.__T2ppTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeVAyaa1_20Z.pp()
(item=0x7fffd970) at /tmp/e.d:93
#11 0x0042c482 in e.TaxTable.getRate()
(this=0x7fffd9e0, taxableGrossIncome=50001) at /tmp/e.d:116
#12 0x0042c88e in D main () at /tmp/e.d:131
#13 0x0043a1f4 in rt.dmain2.main() ()
#14 0x7fffdbe0 in ?? ()
#15 0x7fffdac0 in ?? ()
#16 0x00439b6e in rt.dmain2.main() ()
#17 0x0001 in ?? ()
#18 0x0016 in ?? ()
#19 0x0066a020 in ?? ()
#20 0x7fffdbe0 in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
(gdb)
Re: scope(failure): get exception
On Sunday, October 28, 2012 13:08:50 Jacob Carlborg wrote:
> What about allowing catch-statements without a try-statement, something
> like this:
>
> void foo ()
> {
> // some code ...
>
> catch (Exception e)
> {
>
> }
> }
>
> This would be the same as the whole function would be wrapped in a
> try-statement. It's a quite handy feature that's available in Ruby.
So, you save one set of braces? I don't see how that really buys you much.
- Jonathan M Davis
Re: scope(failure): get exception
On 2012-10-26 23:56, Jonathan M Davis wrote:
Yes. It lowers to a try-catch block, but that's effectively an implementation
detail. As it stands, technically speaking, a compiler could probably
implement it without any lowering whatsoever (I don't think that the spec says
anything about how it's implemented). But even if the compiler has to use
lowering, the main problem with your suggestion is that in complicates how
scope statements work, since then it's only going to be run if the exception
type being caught matches what was being thrown, whereas right now
scope(failure) statements run on all exceptions regardless. And scope
statements aren't really meant for exception handling. Rather, they're
intended for providing a clean means of making code exception-safe. So, I
suspect that what you suggest would be rejected, but I don't know. You can
certainly create an enhancement request for it if you want to:
What about allowing catch-statements without a try-statement, something
like this:
void foo ()
{
// some code ...
catch (Exception e)
{
}
}
This would be the same as the whole function would be wrapped in a
try-statement. It's a quite handy feature that's available in Ruby.
--
/Jacob Carlborg
Re: Compiling shared example.
Am 28.10.2012, 08:06 Uhr, schrieb Ali Çehreli :
On 10/26/2012 02:22 PM, Peter Sommerfeld wrote:
To learn about shared attribute I've copied nearly verbatim an
example from Andreis book. The code:
import core.atomic;
struct Data{
int value;
}
shared struct SharedStack(T) {
private shared struct Node{
T data;
Node* next;
this(T value){data = value;};
}
private Node* root;
// push
void push(T value){
auto n = new Node(value);
shared(Node)* oldRoot;
do {
oldRoot = root;
n.next = oldRoot;
} while(!cas(&root,oldRoot,n)); // line 30
}
// ...
}
SharedStack!(Data) q;
void main(string[] args){
Data m;
q.push(m); // line 40
}
I got the following error (dmd 2.060 win):
(40) Error function main.SharedStack!(Data).SharedStack.push(Data value)
shared is not callable using argument types (Data)
(30) template core.atomic.cas does not match any function template
declaration
What is wrong here ?
Peter
The following two changes are the workaround at least for compilation:
auto n = cast(shared)new Node(value);
// ...
shared SharedStack!(Data) q;
Ali
Thanks Ali, that keeps me going for now. But I wonder why I
have do declare the variables shared if the data are declared
to be shared. Is that a shortcoming of the current compiler ?
Anyway, I can continue ...
BTW: Thanks for your book! It is of great help for beginners
like me!
Peter
Re: Copying with immutable arrays
Thank you for your detailed answer!
What I don't understand is the reason why you need the .dup in
the first place.
Take a look at these two structs that now contain an int* and an
int instead of string[].
struct SA {
int i;
}
struct SB {
int* i;
}
If you try to .dup an array of SA it will work and if you .dup an
array of SB it will fail. I understand why it works this way,
because in case of SB you would get an mutable reference of type
int* out of immutable(int*), which would brake the type system.
However the struct SwA from above does neither correspond to SA
nor to SB, it's imo more like SC:
struct SC {
immutable(int)* i;
}
Now a copy would do no harm, everything that was immutable in the
source and is still accessable from the copy is immutable, too.
Any reason (despite of implemenational issues) that this is not
how it works?
Re: portable windowing und graphics libraries
On Sunday, 28 October 2012 at 08:42:35 UTC, hr wrote: hi, did anybody by chance port the libraries from: http://www.tecgraf.puc-rio.br/iup/ already to d? thanks There is a C interface, so it should be usable directly from D. Just link and call. Is there something to port?
portable windowing und graphics libraries
hi, did anybody by chance port the libraries from: http://www.tecgraf.puc-rio.br/iup/ already to d? thanks
Re: Compiling shared example.
On 10/26/2012 02:22 PM, Peter Sommerfeld wrote:
To learn about shared attribute I've copied nearly verbatim an
example from Andreis book. The code:
import core.atomic;
struct Data{
int value;
}
shared struct SharedStack(T) {
private shared struct Node{
T data;
Node* next;
this(T value){data = value;};
}
private Node* root;
// push
void push(T value){
auto n = new Node(value);
shared(Node)* oldRoot;
do {
oldRoot = root;
n.next = oldRoot;
} while(!cas(&root,oldRoot,n)); // line 30
}
// ...
}
SharedStack!(Data) q;
void main(string[] args){
Data m;
q.push(m); // line 40
}
I got the following error (dmd 2.060 win):
(40) Error function main.SharedStack!(Data).SharedStack.push(Data value)
shared is not callable using argument types (Data)
(30) template core.atomic.cas does not match any function template
declaration
What is wrong here ?
Peter
The following two changes are the workaround at least for compilation:
auto n = cast(shared)new Node(value);
// ...
shared SharedStack!(Data) q;
Ali
