Re: D need an ORM library!
On Tuesday, 21 August 2018 at 08:22:34 UTC, Russel Winder wrote: If there was a D version of SQLAlchemy, that would be wonderful. Feel free to s/TBA/Russel Winder/ Great! there are many people waiting for this! ^_^
Re: D need an ORM library!
On Tuesday, 21 August 2018 at 10:48:30 UTC, bauss wrote: Currently (When I get time again) working on implementing PostgreSQL and Sqlite support for Diamond. Mysql and Mssql should work out the box. https://github.com/DiamondMVC/Diamond Some examples will come later, unless you use the latest stable version of Diamond then you have examples for MySql, but the implementation changes with the next release. http://diamondmvc.org/docs/data/#database I wouldn't call it light-weight like you explain, because it does have the whole framework, but you could technically just strip out the part of compile it with the appropriate flags to exclude the parts you don't need like the webserver. Else take a look at https://github.com/buggins/hibernated and perhaps https://github.com/buggins/ddbc is enough. yeah, Diamond is great, but I think it will be more wonderful if it's database ORM can be separated to a standalone project, that's would be useful for the application that's is not WEB oriented but need an ORM.
Re: D need an ORM library!
On Monday, 20 August 2018 at 23:24:04 UTC, Matthias Klumpp wrote: On Monday, 20 August 2018 at 15:58:37 UTC, Jesse Phillips wrote: [...] There are a number of things out there, but personally don't know there state or simplicity. 2016 there was a talk: http://dconf.org/2016/talks/nowak.html But personally I preferred this one: http://dconf.org/2016/talks/smith.html https://github.com/cruisercoder/dstddb This all looks very dead. Is there any project still alive? The only effort that still seems to be actively developed as far as I can see is hunt-entity... And I agree, SQLAlchemy is pretty great! yeah, Only entity is likely a living ORM implementation in D. But, it's API is too complicated, and API is not stable from my experience. SQLAlchemy is very great, and I remember that in D wiki has mentioned this, but the status is "Proposed Project Mentors: TBA".
D need an ORM library!
hi, I thinks D need an ORM library for Sqlite/Mysql/PostgreSQL, entity currently support all the three targets, but entity's API is too complex and cumbersome for using. Is there a more light-weight and simpler implementation like ActiveAndroid ? Thanks! --- Binghoo Dang
Re: could someone test support for Asian languages in nanogui port?
On Friday, 4 May 2018 at 10:40:52 UTC, drug wrote: I port nanogui, but besides porting I'd like to improve it using great capabilities of D language provides. One of them is utf support, so I added support for Asian languages to nanogui.TextBox. But I'm not sure I've did it well and so I'd like to ask someone to test it using the following: ``` git clone --recursive https://github.com/drug007/nanogui.git cd nanogui git checkout textbox # TextBox exists in this branch only dub --config=sdl # Keyboard events provided only by SDL2 backend only ``` On the right side there will be a window with four text boxes with russian, english, japanese and chinese text respectively. It would be nice to get some feedback from users - probably I did something totally wrong. Also I'm curious does it worth efforts? hi, I'm a Chinese, and I just have done the test. I also copied some Japanese text from Dlang twitter channel and added some Chinese wide punctuation Char. And It's all seems displayed correctly. The resulting screenshot is here: https://pasteboard.co/HjRmOYg.png The only problem is that the font style simply looks strange. You can see the 'normal' text display in Win10 by default like this: https://pasteboard.co/HjRrigh.png And the font problem is probably related to SDL or GL, for all UI based on GL or SDL, they all have the same problem. Dlangui also has the same situation, that's why I just did not use Dlangui for a production project. But, Anyway, the text is displayed correctly. Great work for doing this! Dlang needs a great GUI framework.
Re: Error: non-shared method Node.~this is not callable using a shared object
On Saturday, 6 January 2018 at 11:23:13 UTC, ChangLong wrote: This code is not working. --- shared struct Stack { Node n = void ; } struct Node { ~this() {} } --- Error: non-shared method test.Node.~this is not callable using a shared object Is this a bug ? Node.~this is not called from Stack. take a look at http://ddili.org/ders/d.en/struct.html constructor and destructor for struct must be static.
Re: I want to transmit the class name and the member name in the method
On Friday, 5 January 2018 at 07:40:14 UTC, Brian wrote: I think code style like: ~~ struct User { int id; string name; string email; } class ORM { } auto db = new ORM; auto users = db.select(User).where(email.like("*@hotmail.com")).limit(10); foreach(user; users) { writeln("user: " + user.name + "\n"); } ~~ this rust code is support it: https://github.com/diesel-rs/diesel/blob/master/examples/postgres/all_about_updates/src/lib.rs there's entity library exist in D Dub, which is an ORM framework, you may read the code for reference: https://code.dlang.org/packages/entity
Re: How to pack a struct to a ubyte[] in a more "The D way" style ?
hi Davis, Thanks for your great help to me! Yeah, the library may had a design principle when it was designed, as you can see the buffer appender is not that suitable for an application-defined structured data packing. And after I turn to the bitfield, I then got another trouble: The bitfield template only allows (8, 64) bits to be packed, so in a real application, and obviously, in my application, the packet is greater than 8 bytes. So, the appender and bitfield are not practical for my situation. And now, I realized that the problem what I have done is only using bit-shift other than using direct cast operator. In C, one can directly cast a struct to memory bytes, for D, the struct can have methods, and the alignment is also more complex. So, I think that handy packing and unpacking elements in a struct to D array is just OK. And better than C, the D array is autoincremented, this feature already makes the thing more simpler to understand. So, before I can write my own template for generating the packing and unpacking code, I would just remove the bit shit. Again, Thank you very much! On Thursday, 21 December 2017 at 12:21:55 UTC, Jonathan M Davis wrote: On Monday, December 18, 2017 08:45:32 Binghoo Dang via Digitalmars-d-learn wrote: hi Davis, I read the std.bitmanip, and I tried to test the code like below: ``` import std.stdio; import std.array; import std.bitmanip; void main(string[] args) { align(1) struct c { ushort c1; uint c2; //ubyte[8] c3; } ubyte[] buffer; auto ap = appender(&buffer); uint a = 0x11223344; ushort b = 0x6677; ap.append!uint(a); ap.append!ushort(b); c cobj; cobj.c1 = 0xEEFF; cobj.c2 = 0xDEADBEAF; //cobj.c3 = [0x12, 0x34, 0x56, 0x78]; ap.append(cobj); ubyte[3] d = [0xAA, 0xBB, 0xCC]; ap.append(d); foreach(e; buffer) { writef("%02X ", e); } } ``` For compiling this code, I got error like this > onlineapp.d(22): Error: template std.bitmanip.append cannot > deduce function from >argument types > !()(RefAppender!(ubyte[]), > > c), candidates are: >/dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3623): >std.bitmanip.append(T, Endian endianness = > Endian.bigEndian, > >R)(R range, T value) >if (canSwapEndianness!T && >isOutputRange!(R, ubyte)) >onlineapp.d(25): Error: template std.bitmanip.append cannot >deduce function from >argument types >!()(RefAppender!(ubyte[]), >ubyte[3]), candidates are: > >/dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3623): >std.bitmanip.append(T, Endian endianness = > Endian.bigEndian, > >R)(R range, T value) >if (canSwapEndianness!T && >isOutputRange!(R, ubyte)) It seems that the appending is just allow using the fundamental types like uint, ushort, it does not support struct, and can't support dynamic array too. As the hardware protocol is a dynamic-length style, so I also need to support append array or another buffer directly. It seems that I can't get the point how to using the bitmanip to do the packing I need, and also I have no idea what the unpacking will look like. write, append, peek, and read all operate on integral types only. If you have an array of int or whatnot that you want to put into an array of ubyte, then just use a loop, and if you have a struct, then write or append each of the members individually. Those functions are for making it clean and easy to write integral types to an array or range of ubyte (or to read them back out again) while properly taking endianness into account, not for directly serializing objects. I really don't know what to tell you if the examples in the docs aren't enough to figure out how to use the functions, because if I were trying to show you how, I'd give very similar examples, and I don't know why the docs wouldn't be clear as they are or how they could be made clearer for you. - Jonathan M Davis
Re: How to pack a struct to a ubyte[] in a more "The D way" style ?
hi Davis, I read the std.bitmanip, and I tried to test the code like below: ``` import std.stdio; import std.array; import std.bitmanip; void main(string[] args) { align(1) struct c { ushort c1; uint c2; //ubyte[8] c3; } ubyte[] buffer; auto ap = appender(&buffer); uint a = 0x11223344; ushort b = 0x6677; ap.append!uint(a); ap.append!ushort(b); c cobj; cobj.c1 = 0xEEFF; cobj.c2 = 0xDEADBEAF; //cobj.c3 = [0x12, 0x34, 0x56, 0x78]; ap.append(cobj); ubyte[3] d = [0xAA, 0xBB, 0xCC]; ap.append(d); foreach(e; buffer) { writef("%02X ", e); } } ``` For compiling this code, I got error like this onlineapp.d(22): Error: template std.bitmanip.append cannot deduce function from >argument types !()(RefAppender!(ubyte[]), c), candidates are: /dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3623): std.bitmanip.append(T, Endian endianness = Endian.bigEndian, R)(R range, T value) >if (canSwapEndianness!T && isOutputRange!(R, ubyte)) onlineapp.d(25): Error: template std.bitmanip.append cannot deduce function from >argument types !()(RefAppender!(ubyte[]), ubyte[3]), candidates are: /dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3623): std.bitmanip.append(T, Endian endianness = Endian.bigEndian, R)(R range, T value) >if (canSwapEndianness!T && isOutputRange!(R, ubyte)) It seems that the appending is just allow using the fundamental types like uint, ushort, it does not support struct, and can't support dynamic array too. As the hardware protocol is a dynamic-length style, so I also need to support append array or another buffer directly. It seems that I can't get the point how to using the bitmanip to do the packing I need, and also I have no idea what the unpacking will look like. Thanks!
Re: Write native GUI applications for Windows
On Monday, 18 December 2017 at 07:55:25 UTC, Andrey wrote: Hello! I have a question about creating native GUI applications for Windows 7 or/and Windows 10. I know that exist DWT, DlangUI and other... But I'm interesting in native GUI. If it will be C++ then I would use WinAPI from SDK. And what about D? What should I do? Make some kind of wrapper above C WinApi? I also know that on GitHub exists such wrapper (https://github.com/AndrejMitrovic/DWinProgramming) but it is old - last commit was 4 years ago. Could you help me? You can use libuid which can be found here https://code.dlang.org/packages/libuid. It wrapped the native os gui for d, and it's cross-platform.
Re: How to pack a struct to a ubyte[] in a more "The D way" style ?
Thanks for your idea. On Monday, 18 December 2017 at 05:08:24 UTC, Jonathan M Davis wrote: ubyte[] makeCMDPacket(RCPCmd cmd, in ubyte[] data) { this.preamble = RCPPKT_PRE; this.hdr.msgtype = RCPMSG_CMD; this.hdr.cmdcode = cast (ubyte) cmd; this.hdr.len = 0x & data.length; Why are you using & instead of simply casting to ushort? Casting would be more idiomatic. Or you can use to!ushort if you want to verify the size at runtime and have a ConvException thrown if the value is too large. I'm using & because I'm using a C-Style. and the length needs to be packed into 2bytes, for casting, I don't know what will happen if data.length is greater. In C & C++, this kind of the cast will cause errors. I don't know what D will do for this. ``` It's basically a C-style code, and it works perfect, But I know that this is not a "D-way", So, any suggestions? I'd suggest that you check out std.bitmanip if you haven't. https://dlang.org/phobos/std_bitmanip.html append, peek, read, and write in particular are useful if you're putting various integral values into an array of ubyte[] or reading them from it. Glancing over what you have, I'm pretty sure that all of the bitshifts and bitwise &'s and can be removed by using append or write to write the data to the array and peek or read to read from it. Also, as far as D style goes, variables and enum values are usually given camelCase names, whereas you've named your enum values in all uppercase and your variables names in all lowercase, and you've underscores in the middle of names. But of course, you can do what you want on that. It's just that if you make any libraries public (e.g. on code.dlang.org), it's better to follow the D naming guidelines for anything in the public API: https://dlang.org/dstyle.html - Jonathan M Davis Yeah, thanks for the suggestion, I will check bit manipulation more in detail. I just heard of that, but I just did a misunderstanding that I think that is for packing and unpacking of bits.
How to pack a struct to a ubyte[] in a more "The D way" style ?
hi, I'm a dlang newbie, and I recently made a program that interacts with an RFID Reader, it's basically a Serial-Port communication model. And after 2 days, I finally got a working code like these: ``` enum RCPCmd{ RCPCMD_GET_REGION = 0x06, RCPCMD_SET_REGION = 0x07, RCPCMD_SYS_RESET = 0x08, ... RCPCMD_START_AUTOREAD2 = 0x36, RCPCMD_STOP_AUTOREAD2 = 0x37, RCPCMD_WRITE_TYPEC_TAGDATA = 0x46, RCPCMD_FAIL = 0xFF } enum { RCPMSG_CMD = 0x00, RCPMSG_RESP = 0x01, RCPMSG_NOTIFY = 0x02 } private struct RCProtocol { enum { RCPPKT_PRE = 0xBB, RCPPKT_END = 0x7E } align(1) struct RCPacketHdr { ubyte msgtype; ubyte cmdcode; ushort len; } /** * These kind of members will be need only for private var for making a cmd packet. * But access-able as a parsed result for a incomming packet. */ ubyte preamble; RCPacketHdr hdr; ubyte[] payload; //ubyte[len] of payload. ubyte end; ushort crc16; ubyte[] makeCMDPacket(RCPCmd cmd, in ubyte[] data) { this.preamble = RCPPKT_PRE; this.hdr.msgtype = RCPMSG_CMD; this.hdr.cmdcode = cast (ubyte) cmd; this.hdr.len = 0x & data.length; this.end = RCPPKT_END; this.payload = data.dup; ubyte [] pkt; pkt ~= this.hdr.msgtype; pkt ~= this.hdr.cmdcode; pkt ~= this.hdr.len >> 8; pkt ~= this.hdr.len & 0xff; pkt = this.preamble ~ pkt ~ this.payload ~ this.end; // calc crc16 for Preamble + HDR + Data + END this.crc16 = new RCPCRC16().calc(pkt); pkt ~= this.crc16 >> 8; pkt ~= this.crc16 & 0xff; return pkt; } int parseRespPacket(in ubyte[] recv) { const size_t len = recv.length; if (recv is null) return PARSE_ERR; if (len < 8) return PARSE_ERR_PKTLEN; if (recv[0] !is RCPPKT_PRE) return PARSE_ERR_PKTHEAD; this.preamble = recv[0]; this.hdr.msgtype = recv[1]; this.hdr.cmdcode = recv[2]; this.hdr.len = (recv[3] << 8) + 0xff & recv[4]; if ( this.hdr.len > (len - 8)) return PARSE_ERR_PKT; this.end = recv[5+this.hdr.len]; if (this.end != RCPPKT_END) return PARSE_ERR_PKT; this.payload = recv[5 .. (5+this.hdr.len)].dup; ubyte [] pkt; pkt ~= this.hdr.msgtype; pkt ~= this.hdr.cmdcode; pkt ~= this.hdr.len >> 8; pkt ~= this.hdr.len & 0xff; pkt = this.preamble ~ pkt ~ this.payload ~ this.end; // calc crc16 for Preamble + HDR + Data + END const ushort desired_crc = new RCPCRC16().calc(pkt); this.crc16 = (recv[6+this.hdr.len] << 8) + recv[7+this.hdr.len]; if (this.crc16 != desired_crc) { writefln("-- PARSE ERR: CRC, desired = %04X, actuall is %04X", this.crc16, desired_crc); return PARSE_ERR_CRC; } return PARSE_OK; } } ``` It's basically a C-style code, and it works perfect, But I know that this is not a "D-way", So, any suggestions? Thanks!