md5 return toHexString
Hi All, I cannot seem to understand whats wrong with this:
// main.d
import std.stdio;
import std.digest.md;
import std.file;
string md5sum(const string fname)
{
MD5 hash;
File f = File(fname, rb);
foreach( ubyte[] buf; f.byChunk(4096))
{
hash.put(buf);
}
string s = toHexString!(LetterCase.lower)(hash.finish());
writeln(s); //This is correct
return s;
}
void main()
{
string crc = md5sum(main.d);
writeln(crc); //This is garbage
}
The writeln in md5sum prints correctly, but the return s seems
to mess it up? What's going on?
Thanks for you time,
-Andy
Re: md5 return toHexString
On Friday, 24 April 2015 at 17:56:59 UTC, tcak wrote:
On Friday, 24 April 2015 at 17:50:03 UTC, AndyC wrote:
Hi All, I cannot seem to understand whats wrong with this:
// main.d
import std.stdio;
import std.digest.md;
import std.file;
string md5sum(const string fname)
{
MD5 hash;
File f = File(fname, rb);
foreach( ubyte[] buf; f.byChunk(4096))
{
hash.put(buf);
}
string s = toHexString!(LetterCase.lower)(hash.finish());
writeln(s); //This is correct
return s;
}
void main()
{
string crc = md5sum(main.d);
writeln(crc); //This is garbage
}
The writeln in md5sum prints correctly, but the return s
seems to mess it up? What's going on?
Thanks for you time,
-Andy
Just do that return s.dup(). Then it works for me. That's
probably due to the fact that s is in stack. But I am not sure
how toHexString works.
Ah, yep, that works. I'd originally written it as:
return toHexString!(LetterCase.lower)(hash.finish());
Which doesn't work, so used the temp string to test it.
Now I'm using:
return toHexString!(LetterCase.lower)(hash.finish()).dup();
Kinda weird. But works. Thank you!
-Andy
H1 2015 - memory management
The vision says We aim to make the standard library usable in its entirety without a garbage collector. Safe code should not require the presence of a garbage collector I was just playing with std.json, and this part got me to thinking. How will we parse a string into a json struct w/out allocating memory? And if I allocate memory w/out the GC, then is the caller responsible to free it? Things like string format and file read are gonna have to alloc memory, yes? How will we make std.* usable w/out the GC? -Andy
Re: H1 2015 - db access support in Phobos
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote: I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). Standard library must contain only * set of interfaces for uniform DB access * Connection - can create Statement or PreparedStatement, control transactions * Statement - can run update or query * PreparedStatement - same as Statement, but with parameters * ResultSet - DB query result row access * DataSource - can create connections, w/o parameters * Driver - interface which implements connection factory for particular DB types * Some useful classes like ConnectionPool * factory method to create connection by URL and parameter set * some method to register DB driver for factory - e.g. when called from driver's module __gshared static this() Drivers may be placed in separate packages in standard library or in some DUB packages. Look at https://github.com/buggins/ddbc Currently it contains drivers for sqlite, MySQL and PostgreSQL. If Andrey/Walter wish, I can prepare pool request based on code from ddbc. Best regards, Vadim -1 on copy Java. It seems over complicated. We need a base Database Class, then derive PostgresDatabase from that. No need for Driver class. PostgresDatabase class contains all the knowledge to connect to the actual database so what's left for Driver? If we have Database class, why do we need Connection or DataSource? They don't offer anything Database shouldn't already have. Database (and children), ResultSet and Statement are all that's needed. Statement can have a prepare() function. No need to make an entire PreparedStatement class, seems overkill. I pray we never ever have factories. I like verbs, they make sense. -Andy
Re: Time for 2.067
On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote: Time to button this up and release it. Remaining regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=192294query_format=advanced How about this one: https://issues.dlang.org/show_bug.cgi?id=7762 Not sure if its supposed to compile, but it was reported master wouldn't. -Andy
std.zip
I was looking at this bug report: https://issues.dlang.org/show_bug.cgi?id=2138 and sure enough it doesn't handle zipfiles with more than 65K files. and I checked the code and its pretty limited on what it will even read. Which got me to wondering, why reinvent the wheel? Can std.zip use libzip instead of rewriting it? -Andy
Re: 2.067 should modify writeln function, make it display correctly ANSI characters in CMD. Exe
On Sunday, 25 January 2015 at 16:09:59 UTC, FrankLike wrote: Many people want to display their string(ANSI),but always to convert string by 'toMBSz',and it can't convert to immutable char[],it's difficult to display their ANSI string in CMD.EXE. What do you think？ But .. some people switch cmd.exe to utf8, so you'll break them. http://superuser.com/questions/269818/change-default-code-page-of-windows-console-to-utf-8 not to mention all the linux people it'll break. Perhaps: import std.windows.charset; import std.conv; then: writeln(to!(string)(toMBSz(utf8)));
Re: Link errors with curl, libevent, OpenSSL
On Sunday, 25 January 2015 at 15:11:33 UTC, AndyC wrote:
On Sunday, 25 January 2015 at 05:48:26 UTC, Vladimir Panteleev
wrote:
On my Ubuntu Server, I can't link any D program which uses
libraries other than Phobos.
Example:
//
import std.net.curl;
import std.stdio;
void main()
{
writeln(get(dlang.org));
}
//
dlang@k3:~/2015-01-25$ dmd -L-lcurl test.d
/usr/local/lib/x86_64-linux-gnu/libphobos2.a(curl.o): In
function `_D3std3net4curl4HTTP19_sharedStaticCtor34FZv':
/usr/local/src/phobos/std/net/curl.d:2503: undefined reference
What weirdness has Ubuntu done that this doesn't work? I'm
running Slackware and just tried your example and it works fine.
Does Ubuntu have developer curl packages as well as regular
curl packages? Maybe libcurl-dev package?
-Andy
Yep, Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1001576
-Andy
Re: Link errors with curl, libevent, OpenSSL
On Sunday, 25 January 2015 at 05:48:26 UTC, Vladimir Panteleev
wrote:
On my Ubuntu Server, I can't link any D program which uses
libraries other than Phobos.
Example:
//
import std.net.curl;
import std.stdio;
void main()
{
writeln(get(dlang.org));
}
//
dlang@k3:~/2015-01-25$ dmd -L-lcurl test.d
/usr/local/lib/x86_64-linux-gnu/libphobos2.a(curl.o): In
function `_D3std3net4curl4HTTP19_sharedStaticCtor34FZv':
/usr/local/src/phobos/std/net/curl.d:2503: undefined reference
to `curl_version_info'
/usr/local/lib/x86_64-linux-gnu/libphobos2.a(curl.o): In
function `_D3std3net4curl4Curl19_sharedStaticCtor35FZv':
/usr/local/src/phobos/std/net/curl.d:3497: undefined reference
to `curl_global_init'
/usr/local/lib/x86_64-linux-gnu/libphobos2.a(curl.o): In
function `_D3std3net4curl4Curl19_sharedStaticDtor36FZv':
/usr/local/src/phobos/std/net/curl.d:3503: undefined reference
to `curl_global_cleanup'
[...]
collect2: error: ld returned 1 exit status
--- errorlevel 1
The library (.a and .so) is installed and DMD passes -lcurl to
gcc.
This is what DMD runs:
gcc test.o -o test -m64 -lcurl
-L/usr/local/lib/x86_64-linux-gnu -Xlinker --export-dynamic
-l:libphobos2.a -lpthread -lm -lrt
I got the above program to build by editing /etc/dmd.conf and
adding -L-l:libphobos2.a -L-lcurl to DFLAGS. However, this
doesn't help when linking with other D libraries, e.g. when
using Dub.
I believe this problem is documented here:
https://issues.dlang.org/show_bug.cgi?id=7044
https://issues.dlang.org/show_bug.cgi?id=12572
I don't see a workaround that would apply to dub, though.
Is there a fix or workaround? I think this can be fixed in Dub
to make it pass the libraries in the correct order, but I don't
normally use Dub so I'm not sure. I sort of need this to be
able to work on dlang.org - some functionality is only provided
by posix.mak, which doesn't work under Cygwin.
What weirdness has Ubuntu done that this doesn't work? I'm
running Slackware and just tried your example and it works fine.
Does Ubuntu have developer curl packages as well as regular curl
packages? Maybe libcurl-dev package?
-Andy
Re: Bugzilla
On Sunday, 25 January 2015 at 03:16:32 UTC, Daniel Murphy wrote: AndyC wrote in message news:vbenmvhfimpisqmud...@forum.dlang.org... On a side-side note, is it ok if I close the low hanging fruit? I don't know what you mean, you'll have to be more specific. I mean the really old reports, that are obviously no longer an issue (depricated units, fixed, bad report, etc) like these: https://issues.dlang.org/show_bug.cgi?id=4718 https://issues.dlang.org/show_bug.cgi?id=4310 https://issues.dlang.org/show_bug.cgi?id=2116 -Andy
Re: std.zip
On Sunday, 25 January 2015 at 18:40:54 UTC, ketmar wrote: On Sun, 25 Jan 2015 16:02:33 +, AndyC wrote: I was looking at this bug report: https://issues.dlang.org/show_bug.cgi?id=2138 and sure enough it doesn't handle zipfiles with more than 65K files. and I checked the code and its pretty limited on what it will even read. Which got me to wondering, why reinvent the wheel? Can std.zip use libzip instead of rewriting it? 'cause there is no libzip on windows by default, and there are GNU/Linux, FreeBSD and other OSes where libzip can absent. making it required dependency for dmd is not a very good move. and integrating more and more C libraries in dmd source tree is not a good idea too. yet i found std.zip handy sometimes, so i'm happy that we have it in Phobos. Its handy, yes, until you hit one of its many limitations, then what will you do? Which is less work: 1) include libzip in the install as a requirement, and write a D interface for it. 2) reimplement all of it in D? I don't honestly know. More C libraries means D is more useful faster and with less bugs. Seems like a win to me. -Andy
Re: Bugzilla
On Saturday, 24 January 2015 at 17:13:19 UTC, Daniel Murphy wrote: AndyC wrote in message news:fsmjexsfxtqveqffi...@forum.dlang.org... I think this bug report can just be closed: https://issues.dlang.org/show_bug.cgi?id=9889 The example works fine. It still fails on win32. Oops, I should not have assumed format was os independent. On a side note, I assume D1 is EOL'd and I can close bugs like this one? https://issues.dlang.org/show_bug.cgi?id=6450 On a side-side note, is it ok if I close the low hanging fruit? -Andy
Bugzilla
I think this bug report can just be closed: https://issues.dlang.org/show_bug.cgi?id=9889 The example works fine. Its also confusing because the comment says std.format.formatValue, but the code uses std.string.format. On a side note, as if I find old bug reports that can just be closed whats the best way for me to report it? If I add a comment on the bug report will it just be lost in the shuffle? -Andy
Re: Cross platform Development
On Friday, 23 January 2015 at 17:32:09 UTC, seany wrote: Hello I read this page, but I still have questions : http://forum.dlang.org/thread/fzbaxwcrbztqedqgm...@forum.dlang.org#post-mailman.1142.1332716016.4860.digitalmars-d:40puremagic.com I also read this : http://stackoverflow.com/questions/1510989/can-c-be-compiled-into-platform-independent-code-why-not However, I am wondering what are the ways to develop in a native 64 bit linux machine, and deploy similar linux machines as well as in 64 + 32 bit windowes machines. Are there ways to do so? I will need some detailed guidance. I think you need to ask a more detailed question. Do you want source compatibility or binary compatibility? Are you using GUI stuff? Cuz that's gonna add a world of hurt. Are you wanting to take a bit of source, compile it, and have that single executable run on all 32/64/linux/windows machines? If this is what you want, I'd recommend perl. One bit of code ... runs everywhere! -Andy
github question
I'm new to git and github, I read the 10 tips posted earlier, and I dont understand the last one: Avoid thrashing. The story says, Instead, remove the offending commits, and force push your modified branch. How would one do that? Is there doc's around that might explain that in a little more detail? Thanks, -Andy
Re: github question
On Friday, 23 January 2015 at 03:33:22 UTC, Daniel Murphy wrote: AndyC wrote in message news:afvimfdmrfevmcjuu...@forum.dlang.org... I'm new to git and github, I read the 10 tips posted earlier, and I dont understand the last one: Avoid thrashing. The story says, Instead, remove the offending commits, and force push your modified branch. How would one do that? Is there doc's around that might explain that in a little more detail? Usually it's done with git's interactive rebase. You can easily reorder and combine commits, so if eg part of an earlier commit was reverted the original and the revert commit can be combined. Searching for interactive rebase will get you lots of tutorials. Ah, thank you. I found this one pretty descriptive: http://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history -Andy
Re: New menus are up
I have not read this entire thread, so I don't know if you already know. std.csv doesn't seem to appear in the menus. Also core.sys.* is missing. The url does exist though: http://dlang.org/phobos/std_csv.html There may be others I don't know, I just happened to be searching for these specifically. -Andy
import conflicts
Hi all, I'm trying to write my first actual app that'll go into
production. My file starts with this set of imports:
import std.stdio, std.string, std.json, std.process, std.conv,
std.file,
core.sys.posix.syslog, tinyredis.redis;
import core.sys.posix.unistd: chdir;
import core.sys.posix.sys.stat: mkdir, umask;
import core.thread: Thread, dur;
import core.stdc.stdlib: exit;
At some point in code I have added:
if (exists(lastUpdate.7z)) {
remove(lastUpdate.7z);
}
Now I get compile errors:
autoupdate.d(183): Error: std.file.remove at
/usr/include/dmd/phobos/std/file.d(429) conflicts with
core.stdc.stdio.remove at
/usr/include/dmd/druntime/import/core/stdc/stdio.d(548)
I'm not importing core.stdc.stdio, so why is it conflicting?
Thanks for your time,
-Andy
Re: import conflicts
On Sunday, 18 January 2015 at 19:20:34 UTC, Vlad Levenfeld wrote: I get this all the time with std.array.array (I use my own array implementations, but phobos' array seems to secretly creep in everywhere). I think its got to do with that private import visibility bug (https://issues.dlang.org/show_bug.cgi?id=314 or https://issues.dlang.org/show_bug.cgi?id=13096 I think) which, by the looks of it, should be getting a fix... soon? ish? Ah, if its just a compiler bug I'm ok with that. I was worried there was something about the language I didnt understand. I got it to compile ok using: import std.file: remove, exists, rename; Thanks, -Andy
