Re: Problems with dmd Switches in Makefiles
On Sunday, 18 May 2014 at 16:15:53 UTC, Marc Schütz wrote: For the compiler version, I've submitted a PR: https://github.com/D-Programming-Language/dmd/pull/3558 Ok, the outcome is that a dedicated option is not seen as necessary. DMD already prints its version as the first line if you call it without arguments. If you need only the version, you can use: dmd | head -n1
Convert a hex string into a ubyte[] or OutBuffer
Hi, I'm trying to do something very basic with large numbers: Let's say I have a hex representation of a large number: String hexnum = "16D81B16E091F31BEF"; I'd like to convert it into a ubyte[] in order to Base64 encode it (or, indeed ASCII85 or Base32). eg, [16, D8, 1B, 16, E0, 91, F3, 1B, EF] Is there an idiomatic/simple way to do that? For example, node's Buffer class supports the following API: var buffer = new Buffer(hexnum, "hex"); It also supports "base64" and "utf8". This seems like a very nice way to get string representations of binary data into a buffer :) Is there a D equivalent? I was looking at how the uuid module does it, I can use that as a roadmap, I just wanted to check if there was a shorter way already present in the libs. Many thanks, -Darren
Re: Convert a hex string into a ubyte[] or OutBuffer
Darren:
Let's say I have a hex representation of a large number:
String hexnum = "16D81B16E091F31BEF";
I'd like to convert it into a ubyte[]
A simple way is to use hex strings and then cast it to
immutable(ubyte)[]:
void main() {
immutable hexNum =
cast(immutable(ubyte)[])x"16D81B16E091F31BEF";
}
The immutable at the cast point is needed because string literals
are immutable in D. If you need a mutable ubyte[] you need a dup.
Also vote here:
https://issues.dlang.org/show_bug.cgi?id=5909
Bye,
bearophile
Re: Convert a hex string into a ubyte[] or OutBuffer
On Monday, 19 May 2014 at 11:36:43 UTC, Darren wrote: String hexnum = "16D81B16E091F31BEF"; string (lowercase) I'd like to convert it into a ubyte[] in order to Base64 encode it (or, indeed ASCII85 or Base32). eg, [16, D8, 1B, 16, E0, 91, F3, 1B, EF] Is there an idiomatic/simple way to do that? import std.conv: parse; import std.array: array; import std.range: chunks; import std.algorithm: map; ubyte[] bytes = hexnum /* "16D8..." */ .chunks(2) /* "16", "D8", ... */ .map!(twoDigits => twoDigits.parse!ubyte(16)) /* 0x16, 0xD8, ... */ .array();
Re: Is it possible to assumeSafeAppend malloced memory?
On Monday, 19 May 2014 at 06:08:18 UTC, Ali Çehreli wrote:
We know that most of the time memory is allocated more than the
requested amount. Is there a way to take advantage of that
extra trailing space? (And potentially the pages that come
after that.)
import core.memory;
void main()
{
const count = 1;
// I think there is extra capacity beyond the 'count'
elements
int* ptr = cast(int*)GC.malloc(count * int.sizeof);
int[] arr = ptr[0 .. count];
assert(arr.capacity == 0);
arr.assumeSafeAppend;
assert(arr.capacity == 0);// still 0. :(
}
This issue puts std.array.array to a disadvantage compared to
proper slices because array() involves the following call
chain, the last of which does call GC.malloc:
trustedAllocateArray
uninitializedArray
arrayAllocImpl
As a result, iota(10).array.assumeSafeAppend ends up having 0
capacity. :(
Ali
Recently, a new function in druntime was added: "_d_newarrayU".
This void allocates a new array *with* appendable information. We
can hope it will be given a more formal and public interface, and
it would then be useable by array and/or Appender, to produce
slices that have appendable data.
Re: Is it possible to assumeSafeAppend malloced memory?
On Mon, 19 May 2014 09:44:44 -0400, monarch_dodra
wrote:
On Monday, 19 May 2014 at 06:08:18 UTC, Ali Çehreli wrote:
We know that most of the time memory is allocated more than the
requested amount. Is there a way to take advantage of that extra
trailing space? (And potentially the pages that come after that.)
import core.memory;
void main()
{
const count = 1;
// I think there is extra capacity beyond the 'count' elements
int* ptr = cast(int*)GC.malloc(count * int.sizeof);
int[] arr = ptr[0 .. count];
assert(arr.capacity == 0);
arr.assumeSafeAppend;
assert(arr.capacity == 0);// still 0. :(
}
This is because a block must contain 'used' information in order for
capacity and assumeSafeAppend to work. This is enabled not only by adding
the flag APPENDABLE to the allocation (or you can set the attribute
later), but you must ALSO properly set up the 'used' field. This is best
left to druntime. The mechanism to store the used size may change in the
future.
Is there a reason you wouldn't want to do int[] arr = new int[count]? It's
technically the same call.
This issue puts std.array.array to a disadvantage compared to proper
slices because array() involves the following call chain, the last of
which does call GC.malloc:
trustedAllocateArray
uninitializedArray
arrayAllocImpl
This is a bug. arrayAllocImpl should alloc using the proper functions and
flags.
auto arr = array(1, 2, 3);
assert(arr.capacity != 0); // should pass
Recently, a new function in druntime was added: "_d_newarrayU".
This void allocates a new array *with* appendable information. We can
hope it will be given a more formal and public interface, and it would
then be useable by array and/or Appender, to produce slices that have
appendable data.
Cool, I didn't know this!
-Steve
DerelictAL Symbol undefined
Code: http://pastebin.com/pQjH3jRs Error code is this: Error 42: Symbol Undefined _D3std7windows8syserror14sysErrorStringFNekZAya --- errorlevel 1 I'm currently using Xamarin Studio and the compiler spewed this error out. I searched around and it said that it had to do with my phobos installation... Though my previous project(that used curl and a sql driver) worked without a problem whatsoever. Anyone can point me to the right direction?
Re: DerelictAL Symbol undefined
On 5/19/2014 10:59 PM, Jack wrote: Code: http://pastebin.com/pQjH3jRs Error code is this: Error 42: Symbol Undefined _D3std7windows8syserror14sysErrorStringFNekZAya --- errorlevel 1 I'm currently using Xamarin Studio and the compiler spewed this error out. I searched around and it said that it had to do with my phobos installation... Though my previous project(that used curl and a sql driver) worked without a problem whatsoever. Anyone can point me to the right direction? These sort of errors often occur when you are linking with libraries that are compiled with a different version of DMD (though, usually, they involve the Object class or ModuleInfo). There are a number of possible causes. Maybe someone more familiar with MonoD has seen a similar issue. I haven't, so I can really do is guess. However, there are several things you can check on your end in the meantime. Some possibilities off the top of my head... I understand that MonoD can use dub to manage the project. Is that what you are doing here? If not, did you build the Derelict libraries from the command line? Do you have multiple versions of DMD installed? Did you recently replace an older version with a newer one? Are you able to compile the file from the command line (assuming you have dub installed, set up a simple dub.json and try it out)?
Write double to text file, then read it back later without losing precision
I would like to write a double to a text file as hexadecimal and then read it back in without losing information. Could someone tell me whether this is possible? It would happen in the same program, would I have to worry about different architectures? Thanks very much Andrew
Re: Write double to text file, then read it back later without losing precision
Andrew Brown:
I would like to write a double to a text file as hexadecimal
and then read it back in without losing information.
Is this good enough for you?
void main() {
import std.stdio, std.math;
auto fout = File("ouput.txt", "w");
fout.writef("%a", PI);
fout.close;
auto fin = File("ouput.txt");
real r;
fin.readf("%f", &r);
fin.close;
assert(PI == r);
}
Bye,
bearophile
Re: Write double to text file, then read it back later without losing precision
I'm sure it will be, thank you very much.
On Monday, 19 May 2014 at 15:57:53 UTC, bearophile wrote:
Andrew Brown:
I would like to write a double to a text file as hexadecimal
and then read it back in without losing information.
Is this good enough for you?
void main() {
import std.stdio, std.math;
auto fout = File("ouput.txt", "w");
fout.writef("%a", PI);
fout.close;
auto fin = File("ouput.txt");
real r;
fin.readf("%f", &r);
fin.close;
assert(PI == r);
}
Bye,
bearophile
Re: Is it possible to assumeSafeAppend malloced memory?
On 05/19/2014 06:55 AM, Steven Schveighoffer wrote: > On Mon, 19 May 2014 09:44:44 -0400, monarch_dodra >> Recently, a new function in druntime was added: "_d_newarrayU". > Cool, I didn't know this! Thank you both! This information may be mentioned during a lightning talk at DConf. ;) Ali
Re: Convert a hex string into a ubyte[] or OutBuffer
On Monday, 19 May 2014 at 12:28:14 UTC, anonymous wrote: On Monday, 19 May 2014 at 11:36:43 UTC, Darren wrote: Is there an idiomatic/simple way to do that? import std.conv: parse; import std.array: array; import std.range: chunks; import std.algorithm: map; ubyte[] bytes = hexnum /* "16D8..." */ .chunks(2) /* "16", "D8", ... */ .map!(twoDigits => twoDigits.parse!ubyte(16)) /* 0x16, 0xD8, ... */ .array(); Nice, thanks! I've added a slightly edited version as the answer to this question on stackoverflow: http://stackoverflow.com/a/23741556/47481
Re: Modify char in string
On Sunday, 18 May 2014 at 19:09:52 UTC, Chris Cain wrote:
On Sunday, 18 May 2014 at 18:55:59 UTC, Tim wrote:
Hi everyone,
is there any chance to modify a char in a string like:
As you've seen, you cannot modify immutables (string is an
immutable(char)[]). If you actually do want the string to be
modifiable, you should define it as char[] instead.
Then your example will work:
void main()
{
char[] sMyText = "Replace the last char_";
sMyText[$ - 1] = '.';
}
If you actually want it to be immutable, you can still do it,
but you can't modify in-place, you must create a new string
that looks like what you want:
void main()
{
string sMyText = "Replace the last char_";
sMyText = sMyText[0 .. $-1] ~ ".";
// you would do
//sMyText[0 .. 5] ~ "." ~ sMyText[6..$];
// to "replace" something in the 5th position
}
Note that the second method allocates and uses the GC more
(which is perfectly fine, but not something you want to do in a
tight loop). For most circumstances, the second method is good.
Thanks - I already tried:
void main()
{
char[] sMyText = "Replace the last char_";
sMyText[$ - 1] = '.';
}
but I always getting "Error: cannot implicitly convert expression
("Replace the last char_") of type string to char[]". I know, I
can use cast(char[]) but I don't like casts for such simple
things...
Re: Modify char in string
On 05/19/2014 10:07 AM, Tim wrote:
> I already tried:
>
> void main()
> {
> char[] sMyText = "Replace the last char_";
> sMyText[$ - 1] = '.';
> }
>
> but I always getting "Error: cannot implicitly convert expression
> ("Replace the last char_") of type string to char[]".
That's a good thing because that string literal is immutable. If that
code compiled you would get undefined behavior.
> I know, I can use cast(char[])
Unfortunately, not in this case. That undefined behavior would manifest
itself as a "Segmentation fault" on many systems. :)
> but I don't like casts for such simple things...
What you want to do makes sense only if you have a mutable ASCII string.
Such strings are generated at run time so the problem is usually a non
issue:
import std.stdio;
void main()
{
foreach (line; stdin.byLine) {
char[] s = line.dup;// (or .idup if you want immutable)
s[$-1] = '.';
writefln("Input : %s", line);
writefln("Output: %s", s);
}
}
Ali
Re: Is it possible to assumeSafeAppend malloced memory?
On Monday, 19 May 2014 at 13:55:00 UTC, Steven Schveighoffer wrote: On Monday, 19 May 2014 at 06:08:18 UTC, Ali Çehreli wrote: This issue puts std.array.array to a disadvantage compared to proper slices because array() involves the following call chain, the last of which does call GC.malloc: trustedAllocateArray uninitializedArray arrayAllocImpl This is a bug. arrayAllocImpl should alloc using the proper functions and flags. Well, Yes and no. The issue is that there is no interface available to achieve this, that wouldn't completely destroy what `array` is going for anyways. So it's more of a design issue than a bug proper. https://issues.dlang.org/show_bug.cgi?id=12444 https://github.com/D-Programming-Language/phobos/pull/2044 The only way I'd know (currently) to make it work, is with reserve+assumeSafeAppend. But the issue with that approach is that it's not pure (because of the whole purity with global GC side effects deal).
Re: Is it possible to assumeSafeAppend malloced memory?
On Monday, 19 May 2014 at 13:44:45 UTC, monarch_dodra wrote: Recently, a new function in druntime was added: "_d_newarrayU". This void allocates a new array *with* appendable information. We can hope it will be given a more formal and public interface, and it would then be useable by array and/or Appender, to produce slices that have appendable data. Huh, will it also make possible to call `realloc` if capacity is exceeded? If it still resorts to GC in this case, utility of such addition sounds questionable.
Re: Is it possible to assumeSafeAppend malloced memory?
On Mon, 19 May 2014 14:46:59 -0400, monarch_dodra wrote: On Monday, 19 May 2014 at 13:55:00 UTC, Steven Schveighoffer wrote: On Monday, 19 May 2014 at 06:08:18 UTC, Ali Çehreli wrote: This issue puts std.array.array to a disadvantage compared to proper slices because array() involves the following call chain, the last of which does call GC.malloc: trustedAllocateArray uninitializedArray arrayAllocImpl This is a bug. arrayAllocImpl should alloc using the proper functions and flags. Well, Yes and no. The issue is that there is no interface available to achieve this, that wouldn't completely destroy what `array` is going for anyways. So it's more of a design issue than a bug proper. Yes, I understand. When allocating an array, you need to initialize the array properly, and the standard library should not have the implementation details of the array management leaked into it. I think you can replace the GC.malloc call with the new one you mentioned, no? It's still a bug. The expectation of array(x, y, z) is that it's the same as [x, y, z]. That is not true currently. -Steve
Can't call isDir on linux on const object
The same code works on windows DMD 1.65. But on linux:
delold.d(54): Error: mutable method std.file.DirEntry.isDir is
not callable using
a const object
[code]
bool printFile(in DirEntry dirEntry, in Duration age, Options
options)
{
immutable string type = dirEntry.isDir ? "directory" :
dirEntry.isFile ? "file" : "unknown";
if (!options.beQuiet)
writefln("%s %s, %s is %s days old", type, dirEntry.name,
dirEntry.timeLastModified, age.total!"days");
return true;
}
[/code]
Re: Can't call isDir on linux on const object
On Monday, 19 May 2014 at 20:11:45 UTC, Spacen wrote: The same code works on windows DMD 1.65. But on linux: It's because of caching. isDir on Linux calls a function with this comment: /++ This is to support lazy evaluation, because doing stat's is expensive and not always needed. Try both stat and lstat for isFile and isDir to detect broken symlinks. +/ void _ensureStatOrLStatDone() Simple solution is to just take a plain DirEntry instead of "in DirEntry" so it isn't const.
Re: Is it possible to assumeSafeAppend malloced memory?
On Monday, 19 May 2014 at 18:51:31 UTC, Dicebot wrote: If it still resorts to GC in this case, utility of such addition sounds questionable. It's not really an "addition" as much as it is a "necessary building block to make higher order GC functions work": For example, "dup" was recently made a druntime library implemented function, and as such, required that function to allocate, before building data onto it. Huh, will it also make possible to call `realloc` if capacity is exceeded? AFAIK, using the "GC.realloc" (or "GC.extent") function on it directly would not work. This may or may not be an issue with how "GC.realloc" is designed. The reason for this is because this functions are actually "extremelly" low level, and simply request GC memory, without knowing or caring about the APPENDABLE data. So while the calls could succeed, the result would not be useable. Currently, you could just use "reserve" or simply allocate again, to achieve almost the desired result. reserve+assumeSafeAppend would basically be a "void-extend" (as opposed to "size", which would be an "initialized extend"). At the end of the day though, it can all be done, but it's really about what you want to expose in "object.d".
Re: Can't call isDir on linux on const object
On Monday, 19 May 2014 at 20:18:40 UTC, Adam D. Ruppe wrote: On Monday, 19 May 2014 at 20:11:45 UTC, Spacen wrote: The same code works on windows DMD 1.65. But on linux: It's because of caching. isDir on Linux calls a function with this comment: /++ This is to support lazy evaluation, because doing stat's is expensive and not always needed. Try both stat and lstat for isFile and isDir to detect broken symlinks. +/ void _ensureStatOrLStatDone() Simple solution is to just take a plain DirEntry instead of "in DirEntry" so it isn't const. Thanks Adam. Nice and portable then.
Re: Video playback
On Sunday, 18 May 2014 at 07:10:29 UTC, Dmitry wrote: Hi everyone! I want to play video in my D-application (maybe WebM or Theora). However didn't find any library for operation with video in D. I am a beginner in D, experience of transfer of libraries with C/C++, certainly isn't present. Maybe somebody will prompt something? P.S. My application uses SFML (DSFML). the gtkd project also has gstreamer ported and have an example where a video is played back in the examples directory. I haven't tried it myself but it's worth checking out.
Re: Video playback
On Sunday, 18 May 2014 at 07:10:29 UTC, Dmitry wrote: Hi everyone! I want to play video in my D-application (maybe WebM or Theora). However didn't find any library for operation with video in D. I am a beginner in D, experience of transfer of libraries with C/C++, certainly isn't present. Maybe somebody will prompt something? P.S. My application uses SFML (DSFML). If you can ensure the host machine will have ffmpeg installed, you can do it like AE does: https://github.com/CyberShadow/ae/blob/master/utils/graphics/ffmpeg.d
Re: Is it possible to assumeSafeAppend malloced memory?
On Monday, 19 May 2014 at 21:01:52 UTC, monarch_dodra wrote: Huh, will it also make possible to call `realloc` if capacity is exceeded? AFAIK, using the "GC.realloc" (or "GC.extent") function on it directly would not work. This may or may not be an issue with how "GC.realloc" is designed. The reason for this is because this functions are actually "extremelly" low level, and simply request GC memory, without knowing or caring about the APPENDABLE data. So while the calls could succeed, the result would not be useable. Currently, you could just use "reserve" or simply allocate again, to achieve almost the desired result. reserve+assumeSafeAppend would basically be a "void-extend" (as opposed to "size", which would be an "initialized extend"). At the end of the day though, it can all be done, but it's really about what you want to expose in "object.d". I was actually thinking about plain C realloc as I didn't notice original example refers to GC malloc (oops!) Thus got an impression it can be actually possible to emulate appending to arbitrary allocated blocks. My bad, never mind :)
Re: DerelictAL Symbol undefined
On Monday, 19 May 2014 at 15:15:37 UTC, Mike Parker wrote: Do you have multiple versions of DMD installed? Did you recently replace an >older version with a newer one? I think this is the main issue. I'll try to reinstall dmd2 again.
Error compiling test code
I just installed dmd on Mint Linux distro using the Ubuntu dep package. Ran a simple test program test.d and recieved this error. test.d(1): Error: module stdio is in file 'stdio.d' which cannot be read import path[0] = /usr/include/dmd/phobos import path[1] = /usr/include/dmd/druntime/import Checked dmd.conf in the /etc folder and it is there. Checked include files in /usr/include/dmd and thery are there. Checked Lib location in dmd.conf and it appears to be there. Any hints on what is wrong will be appreciated.
Re: Error compiling test code
On 20/05/2014 3:17 p.m., Larry Hemsley wrote: I just installed dmd on Mint Linux distro using the Ubuntu dep package. Ran a simple test program test.d and recieved this error. test.d(1): Error: module stdio is in file 'stdio.d' which cannot be read import path[0] = /usr/include/dmd/phobos import path[1] = /usr/include/dmd/druntime/import Checked dmd.conf in the /etc folder and it is there. Checked include files in /usr/include/dmd and thery are there. Checked Lib location in dmd.conf and it appears to be there. Any hints on what is wrong will be appreciated. Did you use: import std.stdio; or import stdio; Because it should be std.stdio
Re: DerelictAL Symbol undefined
On Tuesday, 20 May 2014 at 00:43:03 UTC, Jack wrote: On Monday, 19 May 2014 at 15:15:37 UTC, Mike Parker wrote: Do you have multiple versions of DMD installed? Did you recently replace an >older version with a newer one? I think this is the main issue. I'll try to reinstall dmd2 again. The main problem was the Derelict Libraries not being compatible with the latest compiler. So I just re downloaded it from the main site.
Re: Objects(from classes) at Compile time? no gc
On Saturday, 17 May 2014 at 13:21:29 UTC, Marc Schütz wrote: On Friday, 16 May 2014 at 22:48:08 UTC, Taylor Hillegeist wrote: Although, I don't know if it will allocate it during runtime as well. It will not. -Steve Does this work in GDC? Can't test in GDC, but it does work in LDC, and I see no reason why it shouldn't, because this functionality is implemented in the frontend, which DMD, GDC and LDC share. I've been trying to get a baremetal GDC working for the ARM cortex-M, I guess it isn't quite ready yet. I'm looking forward to DConf 2014 to seeing, "Tiny, Ubiquitous Machines Powered by D" by Michael V. Franklin. To see how his work on the cortex-M is going. I mostly work on safety critical applications DO-170C,(Nothing with D) but this language looks like it might have a great deal of potential in this area. Not that C isn't good, but there are things that make the code look cleaner. I was looking at the Interactive D compiler and how it associated the assembly code with the lines of D code, I guess you can do that through the link file(-S in gcc). But D has code coverage information, unit test that you don't have to remove from the production code. there is a great deal of good stuff there. more and more tools for various operation seem to pop up every day. good stuff.
