Re: Strategy to link/include library
It's very useful to me ,,,thank you Jacob,
Re: Passing shared delegates
On 16.1.2013 22:53, Maxim Fomin wrote:
Yes, it happens so (shared function made it a member). Casting away
shared is UB but it can be done if your are sure.
Ok. But that leaves me with an unanswered question from one of my
previous posts.
What happens when you cast from and to shared? Is there any moving in
memory from TLS and back? Or does it just access the memory as if it
were in shared space?
I have tried to compare addresses of b and _b, but writeln refuses to
display an address of shared and assert does not help me either. But
using the inspection capabilities of VisualD I found out that they seem
to have the same address.
Consider rewriting the code and eliminating unnecessary shareds and
I am afraid that the original code has as little shareds as possible.
But I have an idea how to rewrite it to avoid needing to access _b.
please stop attaching to each line of code.
Sorry about that. It is a habit that prevents Thunderbird from
linewrapping a code. If you have Thunderbird on receiving end then it is
no problem - you can copy the quoted code without those ''. But I
understand that with other clients it might be irritating.
To workaround add another method:
void callback(B b)
{
_b.execute(callback);
}
Yes, that could help. But as I wrote before, I will rewrite it to avoid
this issue.
Thanks,
Martin
Re: UDA syntax
UDAs very design point is to never change type they are attached to. If you want to inject code in a class/struct at compile-time, template mixins are supposed tools.
Re: Passing shared delegates
On Thursday, 17 January 2013 at 08:46:22 UTC, Martin Drasar wrote:
Ok. But that leaves me with an unanswered question from one of
my
previous posts.
Casting away shared in undefined behavior. Although it may be not
written explicitly in dlang.org, once D will have a standard like
C or C++, it will be name like so.
In practice this means that behavior of program is uncertain and
may result in many consequences. In this case content of arrays
may be any of 1,2,3,4,5,6.
import std.concurrency : spawn;
import std.stdio : writeln;
shared int[] arr1;
shared int[] arr2;
static this()
{
arr1.length = arr2.length = 100;
foreach(ref e; arr1)
{
e = 1;
}
foreach(ref e; arr2)
{
e = 2;
}
}
void thread1()
{
int[] arr_1 = cast(int[])arr1;
int[] arr_2 = cast(int[])arr2;
arr_2[] = 3;
arr_1[] = 4;
}
void thread2()
{
int[] arr_1 = cast(int[])arr1;
int[] arr_2 = cast(int[])arr2;
arr_2[] = 5;
arr_1[] = 6;
}
void main()
{
spawn(thread1);
spawn(thread2);
writeln(arr1);
writeln(arr2);
}
Note, if you mark functions as @safe, the code will not compile,
because throwing shared is not allowed in D safe code.
What happens when you cast from and to shared? Is there any
moving in
memory from TLS and back? Or does it just access the memory as
if it
were in shared space?
It is implementation specific, but I guess nothing is moved, just
a variable is reinterpreted.
I have tried to compare addresses of b and _b, but writeln
refuses to
display an address of shared and assert does not help me
either. But
using the inspection capabilities of VisualD I found out that
they seem
to have the same address.
Thanks,
Martin
import core.stdc.stdio : printf;
import std.concurrency;
int a;
__gshared int b;
shared int c;
void thread()
{
printf(%p=%d\n%p=%d\n%p=%d\n, a, a, b, b, c, c);
}
void main()
{
c = a = 2;
spawn(thread);
printf(%p=%d\n%p=%d\n%p=%d\n, a, a, b, b, c, c);
}
You can compile this code and look at addresses and assembly if
you are interested in implementation details.
Re: Passing shared delegates
On 17.1.2013 12:56, Maxim Fomin wrote: Casting away shared in undefined behavior. Although it may be not written explicitly in dlang.org, once D will have a standard like C or C++, it will be name like so. In practice this means that behavior of program is uncertain and may result in many consequences. In this case content of arrays may be any of 1,2,3,4,5,6. ... snip ... Note, if you mark functions as @safe, the code will not compile, because throwing shared is not allowed in D safe code. I know about some peculiarities of shared (this thread http://forum.dlang.org/thread/k7orpj$1tt5$1...@digitalmars.com was a good eye-opener) and tend to avoid it as much as possible and solve my problems with message passing concurrency, however there are some times when I had to do some casting and just be careful. What happens when you cast from and to shared? Is there any moving in memory from TLS and back? Or does it just access the memory as if it were in shared space? It is implementation specific, but I guess nothing is moved, just a variable is reinterpreted. Ok, good. ... snip ... You can compile this code and look at addresses and assembly if you are interested in implementation details. Good ol' printf. I should have thought about it. Thanks. Martin
Re: UDA syntax
On 2013-01-17 08:20, Era Scarecrow wrote: Oh yes, do UDA's only work on types? or do they work on functions/methods/delegates too? If you have it on a function how could that be useful? You can basically attach an UDA to any declaration. I think the exception is parameters. -- /Jacob Carlborg
Re: BitArray new design - slice problems
17-Jan-2013 07:53, Era Scarecrow пишет:
Well got a few curious problems. Slicing doesn't seem it wants to work
as a separate type and can cause problems.
Let's take an example. Say our slice is..
struct BitArraySlice {
BitArray* ba;
ulong start, end;
}
Now how much does it depend on the bitarray that it's pointing to? If
it is a wrapper then we have a problem with range checks which should be
legal.
BitArray x = BitArray(100); //100 elements
auto sl = x[50 .. 100];
x.length = 50;
Well, the slice was invalidated by shrinking an array. I don't expect
the below to work.
sl[0] = true; //out of range! BitArray valid from 0-49, not 50-100
The good part is that error can be detected easily. In c++ for instance
it typically isn't.
The harder problem is what to do when the original BitArray goes out of
scope. I guess in case of storage allocated on heap it should work but
if on the stack it shouldn't (and can't).
That much is sorta easy to fix with a separate opIndex (and fixed
sizes), but it's possible to re-slice the dynamic array to make it
smaller. So even if we have opIndex allow out of ranges...
struct BitArray {
size_t[] store; //storage
ubyte start, end;
}
BitArray x = BitArray(100); //100 elements
auto sl = x[50 .. 100];
//likely does x.store[] = x.store[0 .. 2];
//due to compact 1 byte offsets to determine end of bitarray.
x.length = 50;
sl[0] = true; //ok, 0-64 valid on 32bit machines
sl[32] = true; //out of range! 82 past not within 0-63
That's why it's far better to allow slices to be invalidated depending
on the length parameter of BitArray pointed by. Compact array do weird
things in the previous version too.
So let's take the slice and give it the address of the storage
instead, other than it could point to a local variable it will work; But
now I have basically two definitions of bitarray, one that can be a
range/slice while the other that manages the memory and binary operators.
struct BitArraySlice {
//same as BitArray now, what advantage does this give?
size_t[] store;
ulong start, end;
}
Seems like making the slices a separate entity is going to cause more
problems (Not that they can't be solved but the advantages seem
smaller); Plus there's issues trying to get immutable/idup working.
Slices are ranges and thus are converted to array via std.array.array,
nothing to invent or re-implement.
Thoughts? Feedback? I'm about ready to drop this and resume my
previous version and enhance it with recent experiences.
Feel free to do it how you see it. It's just that I think the semantics
of the previous version can't be improved to a consistent state.
--
Dmitry Olshansky
Re: BitArray new design - slice problems
On Thursday, 17 January 2013 at 18:12:28 UTC, Dmitry Olshansky wrote: Well, the slice was invalidated by shrinking an array. I don't expect the below to work. It just seems like shrinking/expanding the array should still work, perhaps I'm thinking of them too much like a normal array slice. If this is acceptable behavior then okay, but the increased complexity may not be worth it. The good part is that error can be detected easily. In c++ for instance it typically isn't. The harder problem is what to do when the original BitArray goes out of scope. I guess in case of storage allocated on heap it should work but if on the stack it shouldn't (and can't). Passing back the BitArray in either form is valid, as dynamic stays valid and a full binary copy stays valid. The slices on the other hand won't be valid unless it's on the heap. sl[0] = true; //ok, 0-64 valid on 32bit machines sl[32] = true; //out of range! 82 not within 0-63 That's why it's far better to allow slices to be invalidated depending on the length parameter of BitArray pointed by. Compact array do weird things in the previous version too. Hmmm... So let's take the slice and give it the address of the storage instead, other than it could point to a local variable it will work; But now I have basically two definitions of bitarray, one that can be a range/slice while the other that manages the memory and binary operators. Seems like making the slices a separate entity is going to cause more problems (Not that they can't be solved but the advantages seem smaller); Plus there's issues trying to get immutable/idup working. Slices are ranges and thus are converted to array via std.array.array, nothing to invent or re-implement. Thoughts? Feedback? I'm about ready to drop this and resume my previous version and enhance it with recent experiences. Feel free to do it how you see it. It's just that I think the semantics of the previous version can't be improved to a consistent state. Sure they can, drop the compact part of it and leave it fully dynamic (or vise-verse). But that would make some people unhappy; On the other hand we could go hybrid where I take the new storage implementations and allow template versions based on needs, remove the compact related stuff, but then it's almost back to the separate slice design. Hmmm... Should the slices be 'use at your own risk' when you tamper with the original BitArray? How else should it be?
Re: MS ODBC encoding issue
On Mon, 14 Jan 2013 10:02:04 -, Regan Heath re...@netmail.co.nz
wrote:
I'm more than happy to upload the database file here,but I can't find
how to.May I have your mail address?Appreciated for all the help!
My email address in the from is valid: regan at netmail dot co dot nz
Ok, solved the issue I think.
1. I can connect to your database file with a connection string like..
odbc.connect(rDriver={Microsoft Access Driver (*.mdb,
*.accdb)};Dbq=PATHGOESHERE\db1.mdb;);
Just replace PATHGOESHERE with the real path to the file, using single \
characters for path separators.
2. In fetchAll, I have made the following changes:
while(true)
{
char sz_buf[256];
- wchar[] pszBuf;
SQLINTEGER buflen;
string[] rowData;
- uint uintVal;
if(SQLFetch(hStmt)==SQL_NO_DATA)
{
break;
}
for(int i=1;i=col;i++)
{
SQLColAttribute(hStmt, cast(ushort)i, SQL_DESC_NAME,
sz_buf.ptr, 256, buf_len, cast(void*)0);
SQLColAttribute(hStmt, cast(ushort)i, SQL_DESC_TYPE,
cast(void*)0, 0, cast(short*)0, colType);
SQLColAttribute(hStmt, cast(ushort)i, SQL_DESC_LENGTH, null, 0,
cast(short*)0, colLen);
- switch(colType)
- {
- case SQL_INTEGER:
- SQLGetData(hStmt, cast(ushort)i, SQL_C_ULONG, uintVal,
uintVal.sizeof, cast(int*)buflen);
- rowData ~= to!string(uintVal);
- break;
- case SQL_VARCHAR:
- pszBuf = new wchar[colLen];
- SQLGetData(hStmt, cast(ushort)i, SQL_C_WCHAR, pszBuf.ptr,
pszBuf.length, cast(int*)buflen);
- pszBuf.length = buflen;
- rowData ~= toUTF8(pszBuf);
- break;
- default:
- break;
- }
}
v~=rowData;
row++;
}
The key here is that when we ask for the VARCHAR data, we ask for it as
WCHAR (meaning UTF-16 or more likely UCS-2 a subset of UTF-16). We then
have to convert it to UTF-8 using std.utf.toUTF8()
Your original code was asking for it as SQL_C_CHAR, and the odbc layer
knows it cannot represent the Chinese characters in ASCII, so it was
returning a '?' for each of them.
Now I can see (in Visual-D debugger) the Chinese characters in the
rowData, but I can't get it to display correctly on my windows console..
can someone remind me how to do that?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: BitArray new design - slice problems
17-Jan-2013 22:34, Era Scarecrow пишет: Thoughts? Feedback? I'm about ready to drop this and resume my previous version and enhance it with recent experiences. Feel free to do it how you see it. It's just that I think the semantics of the previous version can't be improved to a consistent state. Sure they can, drop the compact part of it and leave it fully dynamic (or vise-verse). But that would make some people unhappy; On the other hand we could go hybrid where I take the new storage implementations and allow template versions based on needs, remove the compact related stuff, but then it's almost back to the separate slice design. Hmmm... Should the slices be 'use at your own risk' when you tamper with the original BitArray? How else should it be? I'm thinking that a opSlice of stack-allocated must be @system and a heap allocated can be @safe. Possibly there are better ways to handle this. -- Dmitry Olshansky
Re: UDA syntax
On Thursday, 17 January 2013 at 04:38:14 UTC, Ali Çehreli wrote: On 01/16/2013 05:59 PM, Joseph Cassman wrote: [...] /* This template is not directly related. (I expect it to be in Phobos; maybe * it's already there. (?)) */ template hasAttribute(T, AttributeInQuestion) [...] Ali hasAttribute is an interesting encapsulation of UDA's usage. Will probably make use of the idea. Thanks for the practical examples of usage. Joseph
Re: UDA syntax
On Thursday, 17 January 2013 at 07:27:35 UTC, Jacob Carlborg wrote: On 2013-01-17 02:59, Joseph Cassman wrote: I was wondering what the syntax is for user defined attributes (i.e. bug 9222) implemented in release 2.061. I was still unclear after reading the thread forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com. Here's the documentation: http://dlang.org/attribute.html#uda Ali did a pretty good explanation as well. You can see how I used it for my serialization library: https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Attribute.d https://github.com/jacob-carlborg/mambo/blob/master/mambo/serialization/Serializer.d#L1481 Couldn't find the documentation location. Thanks for the links. Joseph
Re: BitArray new design - slice problems
On Thu, Jan 17, 2013 at 11:36:33PM +0400, Dmitry Olshansky wrote: [...] I'm thinking that a opSlice of stack-allocated must be @system and a heap allocated can be @safe. [...] Related: http://d.puremagic.com/issues/show_bug.cgi?id=8838 T -- Who told you to swim in Crocodile Lake without life insurance??
Re: BitArray new design - slice problems
On Thursday, 17 January 2013 at 19:36:34 UTC, Dmitry Olshansky wrote: I'm thinking that a opSlice of stack-allocated must be @system and a heap allocated can be @safe. That's just a small part of the problem. With the new design, 90% of it can be safe; Just the actual slice buffer when you request it (with Fixed storage) would be @system, and slices (having a pointer). But @safe code can't call @system code which means that the current design (convert to slices before operations) it all has to all be @system. Guess once it's debugged the entire thing can be @trusted and only certain things can be marked @system instead.
Re: tiny std.datetime question
On Thursday, 17 January 2013 at 07:17:57 UTC, Jonathan M Davis wrote: I'd still like to break it up a bit, but I'm not going to do it unless some variant of DIP15 or DIP16 is implemented so that it can be done without breaking any code. So, it probably won't be broken up any time soon. It's not a big an issue though when the documentation is broken up. Yes, a complex module or multi-feature module could just have the docs broken up into separate sections, however those DIPs you mention look to me like they are definitely worth implementing. There's a lot of value being able to structure and organize your code better. --rt
extern (D)?
The usual way to link in D libs into D code is to include the required D module source files, but that gives away all of the source code which in some instances is not possible to do (eg legal reasons). The other way is to create a c-style API using extern (C), but that means translating some structures from D to C, and then from C back to D which is not a nice solution. As far as I know, there's no extern (D), but maybe there is something like it available. Anyone know? --rt
Re: extern (D)?
On Fri, 18 Jan 2013 02:01:52 +0100, Rob T wrote: The usual way to link in D libs into D code is to include the required D module source files, but that gives away all of the source code which in some instances is not possible to do (eg legal reasons). The other way is to create a c-style API using extern (C), but that means translating some structures from D to C, and then from C back to D which is not a nice solution. As far as I know, there's no extern (D), but maybe there is something like it available. Anyone know? --rt You can use extern(D) or simply extern; this is described here: http://dlang.org/attribute.html#linkage Justin
Re: extern (D)?
On 1/18/13, Rob T al...@ucora.com wrote: The usual way to link in D libs into D code is to include the required D module source files, but that gives away all of the source code which in some instances is not possible to do (eg legal reasons). The other way.. The other way is to use D interface files, which the compiler can automatically generate for you if you pass the -H switch. Also use the -op switch if you're generating multiple files at once, which will preserve directory paths.
Re: extern (D)?
On Friday, 18 January 2013 at 01:07:05 UTC, Justin Whear wrote: You can use extern(D) or simply extern; this is described here: http://dlang.org/attribute.html#linkage Justin So there is an extern (D), excellent! Slightly embarrassed I didn't find this for myself. --rt
Re: extern (D)?
On Friday, 18 January 2013 at 02:08:46 UTC, Andrej Mitrovic wrote: The other way is to use D interface files, which the compiler can automatically generate for you if you pass the -H switch. Also use the -op switch if you're generating multiple files at once, which will preserve directory paths. The documentation says that the interface files will only contain the parts of a module's source code that is required for linking, however I read somewhere that it pretty much does nothing but strip out the comments because it needs the full source code for a inlining, CTFE, and templates. So I'd have to manually modify or construct them manually, which means I'll lose some abilities, but that may be OK for some situations. For classes and structs, I have no idea how to leave out the implementation details. --rt
Re: extern (D)?
On 1/18/13, Rob T al...@ucora.com wrote: however I read somewhere that it pretty much does nothing but strip out the comments because it needs the full source code for a inlining, CTFE, and templates. There was a recent pull that implemented better header generation (https://github.com/D-Programming-Language/dmd/pull/1487), it will be in the 2.062 release (which might be a long time from now but it's worth knowing). It's probably doing a better job at hiding implementation details.
Re: extern (D)?
On 2013-01-18 05:37, Rob T wrote: The documentation says that the interface files will only contain the parts of a module's source code that is required for linking, however I read somewhere that it pretty much does nothing but strip out the comments because it needs the full source code for a inlining, CTFE, and templates. So I'd have to manually modify or construct them manually, which means I'll lose some abilities, but that may be OK for some situations. You cannot both have CTFE/inlining/templates and hide the source code. It's the same as in C++. For classes and structs, I have no idea how to leave out the implementation details. You can either use an interface or just not provide an implementation for the methods. Note that it's perfectly fine to have a method in D without an implementation even it's not abstract. This is to support the use case you have here and separate compilation. I guess you would need to list the fields on classes/structs, again that's just like C++. -- /Jacob Carlborg
