digitalmars.D - Missing things in Phobos
- Steve Teale <steve.teale britseyeview.com> Oct 20 2011
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 20 2011
- Piotr Szturmaj <bncrbme jadamspam.pl> Oct 20 2011
- Sean Kelly <sean invisibleduck.org> Oct 20 2011
- Daniel Gibson <metalcaedes gmail.com> Oct 20 2011
- Daniel Gibson <metalcaedes gmail.com> Oct 20 2011
- Daniel Gibson <metalcaedes gmail.com> Oct 20 2011
- "Regan Heath" <regan netmail.co.nz> Oct 24 2011
I'm sure that there's quite a long list, but two things I've bumped into with using the MySQL protocol are: 1) We don't have SHA1 - I know there are people working on this. I've done a version that is as close to the reference C implementation as I could make myself keep it. This may be useful as a check for others doing more efficient implementations. If you want it, please let me know. Related issue is should we have std.digest instead of std.md5 2) We don't have an off-the-shelf Socket class for Unix Sockets Steve
Oct 20 2011
I think the solution to the second problem (along with an enormous range of other problems) would be having the =D8MQ's binding in Phobos. http://www.zeromq.org/ On Thu, Oct 20, 2011 at 1:37 PM, Steve Teale <steve.teale britseyeview.com> wrote:I'm sure that there's quite a long list, but two things I've bumped into with using the MySQL protocol are: 1) We don't have SHA1 - I know there are people working on this. I've done a version that is as close to the reference C implementation as I could make myself keep it. This may be useful as a check for others doing more efficient implementations. If you want it, please let me know. Related issue is should we have std.digest instead of std.md5 2) We don't have an off-the-shelf Socket class for Unix Sockets Steve
Oct 20 2011
Steve Teale wrote:I'm sure that there's quite a long list, but two things I've bumped into with using the MySQL protocol are: 1) We don't have SHA1 - I know there are people working on this. I've done a version that is as close to the reference C implementation as I could make myself keep it. This may be useful as a check for others doing more efficient implementations. If you want it, please let me know.
https://github.com/pszturmaj/dmisc/blob/master/sha.d It works for octet/byte hashing. It needs some polishing for handling per bit hashing.Related issue is should we have std.digest instead of std.md5
What about: std.crypto.hash.md5 std.crypto.hash.sha std.crypto.hash.whirlpool std.crypto.hash.etc? or std.crypt.* ?
Oct 20 2011
On Oct 20, 2011, at 2:37 AM, Steve Teale <steve.teale britseyeview.com> wrot= e:=20 2) We don't have an off-the-shelf Socket class for Unix Sockets
The lack of networking support is my biggest problem with Phobos right now. I= wish I had the time to do something about it.=
Oct 20 2011
Am 20.10.2011 11:37, schrieb Steve Teale:2) We don't have an off-the-shelf Socket class for Unix Sockets
It shouldn't be too hard to add AF_UNIX support to std.socket. (Derive something suitable from std.socket.Address and possibly std.socket.Socket) In fact, I have some old untested code lying around that adds such an Address type: http://pastebin.com/gMxd4AqB It's from D1 though and /may/ need minor changes to work with the current std.socket. (Also it may be buggy, as it's untested) (IPv6 support is also missing from std.socket btw)Steve
Cheers, - Daniel
Oct 20 2011
Am 20.10.2011 23:44, schrieb Daniel Gibson:Am 20.10.2011 11:37, schrieb Steve Teale:2) We don't have an off-the-shelf Socket class for Unix Sockets
It shouldn't be too hard to add AF_UNIX support to std.socket. (Derive something suitable from std.socket.Address and possibly std.socket.Socket) In fact, I have some old untested code lying around that adds such an Address type: http://pastebin.com/gMxd4AqB It's from D1 though and /may/ need minor changes to work with the current std.socket. (Also it may be buggy, as it's untested)
Ok, while having a quick look at this old code I spotted the following bugs: 1. Line 23: path[1] does not exist if path.length==1 => check length 2. After Line 29 should be a return (or else { ... } with ... being lines 31-36) Seems like I was tired or drunk or something when I wrote that ;) Fixed (still untested) version: http://pastebin.com/Vb5QqJwS(IPv6 support is also missing from std.socket btw)
Cheers, - Daniel
Oct 20 2011
Am 21.10.2011 00:12, schrieb Daniel Gibson:Am 20.10.2011 23:44, schrieb Daniel Gibson:Am 20.10.2011 11:37, schrieb Steve Teale:2) We don't have an off-the-shelf Socket class for Unix Sockets
It shouldn't be too hard to add AF_UNIX support to std.socket. (Derive something suitable from std.socket.Address and possibly std.socket.Socket) In fact, I have some old untested code lying around that adds such an Address type: http://pastebin.com/gMxd4AqB It's from D1 though and /may/ need minor changes to work with the current std.socket. (Also it may be buggy, as it's untested)
Ok, while having a quick look at this old code I spotted the following bugs: 1. Line 23: path[1] does not exist if path.length==1 => check length
Got it wrong again, this should work: if(path[0] == '\0' && (path.length==1 || path[1] == '\0')) return; Need sleep.
Oct 20 2011
On Thu, 20 Oct 2011 10:37:33 +0100, Steve Teale <steve.teale britseyeview.com> wrote:I'm sure that there's quite a long list, but two things I've bumped into with using the MySQL protocol are: 1) We don't have SHA1 - I know there are people working on this. I've done a version that is as close to the reference C implementation as I could make myself keep it. This may be useful as a check for others doing more efficient implementations. If you want it, please let me know.
I have a complete set of hashing functions (the original code which became the modules now present in Tango) I just need to tidy them up, add documentation, etc.. I don't know when I will get around to it however.Related issue is should we have std.digest instead of std.md5
Agreed. Or std.crypto.digest or similar if we want to expand into the other areas of cryptography. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 24 2011









Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> 