Re: buffer to struct type conversion...TArrayStream?
If you don't want to run into alignment issues, you shouldn't cast the buffer directly: http://dpaste.dzfl.pl/b522f911871a
Text UI for D?
Does D have a recommended package for this - like (n)curses for C?
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 10:02:27 UTC, Dennis Ritchie wrote:
For example,
lazy int sum(int a = 3, int b = 5) {
return a + b;
}
That is, if the function is not invoked, it should not be
calculated at compile time.
I don't understand what you mean. You mean a function that isn't
compiled if it isn't used anywhere? Template functions that are
only compiled if instantiated, so you could write
int sum()(int a, int b) { return a+b; }
/\
empty braces for a 0-arg template. Can be called just like a
normal function, the only time it would be necessary to
explicitly write sum!() would be if you wanted to take it's
address: sum!()
Re: Should this work: export extern(C) auto ...
On 2015-03-19 13:22:44 +, Benjamin Thaut said: Generally don't expect to many things to work with DLLs at the moment. Hi, well, I think what's available is good enough to get most things done. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy. I prefer dead-old-style plain simple C functions in DLLs with a super simple interface based on basic types. Works bests, is stable, can be maintained and is easy to use. So, no fancy stuff needed in my case :-) -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Text UI for D?
On Friday, 20 March 2015 at 10:29:45 UTC, DLearner wrote: Does D have a recommended package for this - like (n)curses for C? You could just use nurses: https://github.com/D-Programming-Deimos/ncurses
Re: Text UI for D?
On Friday, 20 March 2015 at 10:29:45 UTC, DLearner wrote: Does D have a recommended package for this - like (n)curses for C? http://stackoverflow.com/questions/29061809/tui-text-user-interface-for-d
Re: Lazy functions, lazy arrays
For example,
lazy int sum(int a = 3, int b = 5) {
return a + b;
}
That is, if the function is not invoked, it should not be
calculated at compile time.
Re: final methods by default
On Fri, 20 Mar 2015 22:11:51 + weaselcat via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote: Why aren't methods of class final by default? history use final class, it should devirtualize all methods. see: https://github.com/D-Programming-Language/dmd/pull/4427 Yes, but you can not extend final class. Ok you can still use UFCS but it is not elegand solution.
Re: final methods by default
On Fri, 20 Mar 2015 16:27:04 -0700
Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Friday, March 20, 2015 23:53:14 Daniel Kozak via Digitalmars-d-learn wrote:
On Fri, 20 Mar 2015 22:11:51 +
weaselcat via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote:
Why aren't methods of class final by default?
history
use final class, it should devirtualize all methods.
see: https://github.com/D-Programming-Language/dmd/pull/4427
Yes, but you can not extend final class. Ok you can still use UFCS but it
is not elegand solution.
Then you can just do
class Foo
{
final:
// methods...
}
or
class Foo
{
final
{
// methods...
}
}
And even if you couldn't do that, you could always mark each function with
final individually.
Yes I know that and use it. Not often because I use struct and templates so I
need to marks methods as final occasionally ;-)
Re: final methods by default
On Friday, 20 March 2015 at 23:47:37 UTC, Daniel Kozak wrote:
On Fri, 20 Mar 2015 16:27:04 -0700
Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
On Friday, March 20, 2015 23:53:14 Daniel Kozak via
Digitalmars-d-learn wrote:
On Fri, 20 Mar 2015 22:11:51 +
weaselcat via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote:
Why aren't methods of class final by default?
history
use final class, it should devirtualize all methods.
see:
https://github.com/D-Programming-Language/dmd/pull/4427
Yes, but you can not extend final class. Ok you can still
use UFCS but it
is not elegand solution.
Then you can just do
class Foo
{
final:
// methods...
}
yes only if I want all methods be virtual and without any other
members:
class C {
final:
string field;
}
does not work.
or
class Foo
{
final
{
// methods...
}
}
Not usefull, I rarely have more than a few final function
following one by one.
And even if you couldn't do that, you could always mark each
function with
final individually.
Definitely the best way (in my cases).
Re: final methods by default
On Friday, March 20, 2015 23:53:14 Daniel Kozak via Digitalmars-d-learn wrote:
On Fri, 20 Mar 2015 22:11:51 +
weaselcat via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote:
Why aren't methods of class final by default?
history
use final class, it should devirtualize all methods.
see: https://github.com/D-Programming-Language/dmd/pull/4427
Yes, but you can not extend final class. Ok you can still use UFCS but it
is not elegand solution.
Then you can just do
class Foo
{
final:
// methods...
}
or
class Foo
{
final
{
// methods...
}
}
And even if you couldn't do that, you could always mark each function with
final individually.
Yes. final should probably be the default, but unfortunately, that's not the
choice that was made early on, and it was decided later that the change
wasn't worth the breakage. But it can be worked around easily enough.
- Jonathan M Davis
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 12:15:22 UTC, Dennis Ritchie wrote: On Friday, 20 March 2015 at 10:38:17 UTC, John Colvin wrote: I don't understand what you mean. You mean a function that isn't compiled if it isn't used anywhere? Yes. That's exactly what I mean. Use case?
Re: final methods by default
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote: Why aren't methods of class final by default? Because of a design choice to maximise usage flexibility that is questionable but not likely to change.
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 14:20:16 UTC, John Colvin wrote:
On Friday, 20 March 2015 at 13:35:10 UTC, Dennis Ritchie wrote:
Use case?
No. I need to be able to make an array factorials is not
evaluated, if I don't.
import std.stdio;
enum N = 15;
static int[] factorials = memoizeFactorials(N); // lazy array?
:)
int[] memoizeFactorials(int n)
{
if (!__ctfe) {
// Make sure that this function is never called at run
time
assert(false);
}
int[] result = new int[n];
result[0] = 1;
foreach (i; 1 .. n) {
result[i] = result[i - 1] * i;
}
return result;
}
void main()
{
writeln(factorials[10]);
}
Why? To make a smaller executable? For faster compilation?
This can work
auto factorials()() @property
{
//if we're here, factorials are used somewhere
//generate them at compile-time.
enum int[N] resultsE = memoizeFactorials(N);
//put them in thread-local array on first access
static resultsS = resultsE;
return resultsS[];
}
void main()
{
writeln(factorials[10]);
}
or much easier and simpler, but different:
auto factorials()(int n)
{
//generate them at compile-time.
enum int[N] results = memoizeFactorials(N);
return results[n];
}
void main()
{
writeln(factorials(10));
}
However, none of this is a good idea at all. There are only 13
factorials (0 through 12) that fit in an int, so it's such a
small array that you might as well write
enum int[N] factorials = memoizeFactorials(N);
and be done.
I made a mistake about the static variable and thread-local
storage.
immutable(int)[] factorials()() @property
{
static immutable int[N] results = memoizeFactorials(N);
return results[];
}
is the correct way to do it if you have to.
Still, it's totally not worth doing for such a short array.
final methods by default
Why aren't methods of class final by default?
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 10:38:17 UTC, John Colvin wrote: I don't understand what you mean. You mean a function that isn't compiled if it isn't used anywhere? Yes. That's exactly what I mean.
Re: Text UI for D?
On Friday, 20 March 2015 at 10:29:45 UTC, DLearner wrote: Does D have a recommended package for this - like (n)curses for C? I cannot recommend it because i've just found the package, it like Pascal turbo vision but in D. https://github.com/bbodi/dvision A few years ago someine else started a similar project but i can't found the link, it's too old.
Re: Lazy functions, lazy arrays
Use case?
No. I need to be able to make an array factorials is not
evaluated, if I don't.
import std.stdio;
enum N = 15;
static int[] factorials = memoizeFactorials(N); // lazy array? :)
int[] memoizeFactorials(int n)
{
if (!__ctfe) {
// Make sure that this function is never called at run
time
assert(false);
}
int[] result = new int[n];
result[0] = 1;
foreach (i; 1 .. n) {
result[i] = result[i - 1] * i;
}
return result;
}
void main()
{
writeln(factorials[10]);
}
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 12:52:16 UTC, Tobias Pankrath wrote: Use case? I do this with local imports so a module works without dependencies unless you use the specific functions that need the additional module.
Re: Lazy functions, lazy arrays
Now I am totally confused. lazy and eager evaluation are unrelated to compile time and run time.
Re: Text UI for D?
On Fri, Mar 20, 2015 at 10:29:44AM +, DLearner via Digitalmars-d-learn wrote: Does D have a recommended package for this - like (n)curses for C? Try Adam Ruppe's excellent terminal.d -- I use it for my own TUI programs, and it's pretty good. https://github.com/adamdruppe/arsd/blob/master/terminal.d T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: How to replace the keyword nan to check the contract assert?
On 03/20/2015 09:24 PM, Dennis Ritchie wrote: Hi,
How do I replace double.init?
import std.stdio : writeln;
import std.algorithm : uninitializedFill;
void main() {
double[] arr = new double[6];
uninitializedFill(arr[0 .. $ - 2], 3.25);
writeln(arr);
assert(arr == [3.25, 3.25, 3.25, 3.25, double.init, double.init]);
/* not work */
}
nan cannot be used in comparisons. It is neither greater than nor less
than any value. You cannot even compare it against itself. nan==nan
would always be false.
The solution is to call std.math.isNaN. In this case, you have to split
the assert into two. You can achieve the same thing in may ways but the
following works:
assert(arr[0 .. $ - 2] == [3.25, 3.25, 3.25, 3.25]);
import std.algorithm;
import std.math;
assert(arr[$ - 2 .. $].all!isNaN);
Ali
Re: How to replace the keyword nan to check the contract assert?
On Saturday, 21 March 2015 at 04:53:20 UTC, Ali Çehreli wrote: nan cannot be used in comparisons. It is neither greater than nor less than any value. You cannot even compare it against itself. nan==nan would always be false. The solution is to call std.math.isNaN. In this case, you have to split the assert into two. You can achieve the same thing in may ways but the following works: assert(arr[0 .. $ - 2] == [3.25, 3.25, 3.25, 3.25]); import std.algorithm; import std.math; assert(arr[$ - 2 .. $].all!isNaN); Thanks.
How to replace the keyword nan to check the contract assert?
Hi,
How do I replace double.init?
import std.stdio : writeln;
import std.algorithm : uninitializedFill;
void main() {
double[] arr = new double[6];
uninitializedFill(arr[0 .. $ - 2], 3.25);
writeln(arr);
assert(arr == [3.25, 3.25, 3.25, 3.25, double.init,
double.init]); /* not work */
}
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 13:35:10 UTC, Dennis Ritchie wrote:
Use case?
No. I need to be able to make an array factorials is not
evaluated, if I don't.
import std.stdio;
enum N = 15;
static int[] factorials = memoizeFactorials(N); // lazy array?
:)
int[] memoizeFactorials(int n)
{
if (!__ctfe) {
// Make sure that this function is never called at run
time
assert(false);
}
int[] result = new int[n];
result[0] = 1;
foreach (i; 1 .. n) {
result[i] = result[i - 1] * i;
}
return result;
}
void main()
{
writeln(factorials[10]);
}
Why? To make a smaller executable? For faster compilation?
This can work
auto factorials()() @property
{
//if we're here, factorials are used somewhere
//generate them at compile-time.
enum int[N] resultsE = memoizeFactorials(N);
//put them in thread-local array on first access
static resultsS = resultsE;
return resultsS[];
}
void main()
{
writeln(factorials[10]);
}
or much easier and simpler, but different:
auto factorials()(int n)
{
//generate them at compile-time.
enum int[N] results = memoizeFactorials(N);
return results[n];
}
void main()
{
writeln(factorials(10));
}
However, none of this is a good idea at all. There are only 13
factorials (0 through 12) that fit in an int, so it's such a
small array that you might as well write
enum int[N] factorials = memoizeFactorials(N);
and be done.
Re: refactoring issues
On Friday, 20 March 2015 at 18:05:07 UTC, Ivan Kazmenko wrote: Thanks. I was able to reproduce the workflow you showed in the gif to the part where an error pop-up (e.g. no property iota for type int) is followed by suggesting the appropriate fix. Do I need another tool for that? Colorout does not seem to suggest fixes. OK, here it is: https://github.com/CyberShadow/AutoFix It has some hardcoded paths though.
Re: refactoring issues
On Friday, 20 March 2015 at 18:36:19 UTC, Vladimir Panteleev wrote: On Friday, 20 March 2015 at 18:05:07 UTC, Ivan Kazmenko wrote: Thanks. I was able to reproduce the workflow you showed in the gif to the part where an error pop-up (e.g. no property iota for type int) is followed by suggesting the appropriate fix. Do I need another tool for that? Colorout does not seem to suggest fixes. OK, here it is: https://github.com/CyberShadow/AutoFix It has some hardcoded paths though. It's used like this: C:\Path\To\colorout\colorout ^ --json C:\Temp\colorout.json ^ --trigger id=C:\Path\To\AutoFix\autofix.exe ^ C:\Path\To\colorout\d.col ^ dmd, rdmd etc...
Re: Text UI for D?
On Fri, 20 Mar 2015 10:29:44 +, DLearner wrote: Does D have a recommended package for this - like (n)curses for C? most of the time you don't really need a full-blown UI, but something to control the terminal and draw frames. ;-) Adam's module does that. signature.asc Description: PGP signature
OPTLINK Error 45 Too Much DEBUG Data for Old CodeView format
Hello, after some coding i needed to update some external libraries like DerelictSDL2. As we all know, one update isn't enough, so i updated my whole d-environment at the end of the day (current dmd version, VisualD). After getting rid of some linking errors (symbols undefined) i have only one error left: Optlink: Error 45: Too Much DEBUG Data for Old CodeView format i googled, but really can't figure out what this error is about.
Re: refactoring issues
On Thursday, 19 March 2015 at 16:06:31 UTC, Vladimir Panteleev wrote: On Thursday, 19 March 2015 at 14:32:53 UTC, Ivan Kazmenko wrote: Hey, I also happen to use Far Manager and its internal editor, at least for simple projects. Is that dcheck triggering a Far plugin? I have a bit of experience with Far recording macros, but didn't try to write a plugin. It's all a bit of a mess... A FAR Lua macro[1] runs dcheck, which is just a batch file that runs DMD piped through colorout[2], which in turn parses the compiler output and records the results to a temporary file, that's read by a second program that parses and caches the .json files generated as part of my D build process and then generates editing instructions read back by the Lua macro. [1]http://dump.thecybershadow.net/5c0afb5c0f4306b1368dd8528c838133/F9.lua [2]http://blog.thecybershadow.net/2013/07/27/colorize-your-compilers-output/ Thanks. I was able to reproduce the workflow you showed in the gif to the part where an error pop-up (e.g. no property iota for type int) is followed by suggesting the appropriate fix. Do I need another tool for that? Colorout does not seem to suggest fixes. Also, what about this? 2. When the compiler could not find a suitable overload of a function, if there are template and non-template overloads, it lists only non-template overloads. Since no one replied by rationalizing that it works as intended, perhaps I should file an issue about it? Ivan Kazmenko.
Re: Lazy functions, lazy arrays
On Friday, 20 March 2015 at 14:27:06 UTC, John Colvin wrote:
I made a mistake about the static variable and thread-local
storage.
immutable(int)[] factorials()() @property
{
static immutable int[N] results = memoizeFactorials(N);
return results[];
}
is the correct way to do it if you have to.
Still, it's totally not worth doing for such a short array.
Thank you, but I can not figure out how I do this:
import std.stdio;
enum N = 12;
immutable(int)[] factorials()() @property
{
static immutable int[N] results = memoizeFactorials(N);
return results[];
}
int[] memoizeFactorials(int n)
{
if (!__ctfe)
// Make sure that this function is never called at run
time
assert(false);
int[] result = new int[n];
result[0] = 1;
foreach (i; 1 .. n)
result[i] = result[i - 1] * i;
return result;
}
void main()
{
bool flag;
if (flag) {
factorials();
writeln(factorials[10]); // 3628800
}
else
writeln(factorials[10]); // range violation(35)
}
Re: OPTLINK Error 45 Too Much DEBUG Data for Old CodeView format
You can refer to http://forum.dlang.org/post/jhbgaacoguxaubxgp...@forum.dlang.org Do you use dub? I resolved my problems (on Win) abandoning dub and using makefile. On Friday, 20 March 2015 at 17:35:19 UTC, Koi wrote: Hello, after some coding i needed to update some external libraries like DerelictSDL2. As we all know, one update isn't enough, so i updated my whole d-environment at the end of the day (current dmd version, VisualD). After getting rid of some linking errors (symbols undefined) i have only one error left: Optlink: Error 45: Too Much DEBUG Data for Old CodeView format i googled, but really can't figure out what this error is about.
Re: Temple templates with vibe.d support and first D experiences
Still does not compile, thanks for the idea though. I think it's
better to avoid Temple, compilation of Diet templates seems to be
better anyway. E.g. temple seems to accept % var.nonexistingname
% while diet gives a compile error for #{nonexistingname}.
Meanwhile I figured out an easy way to use existing HTML files
with Diet, you can avoid reformatting your files to this exotic
format. Just mark each line to be predefined content, simply
prefixing them with the '|' character like this:
doctype html
| html
| head title testing vibe /title /head
| body
| h1 My vibe example /h1
| Hello #{username}!
| p #{content} /p
| /body
| /html
This can be easily automated by a few-liner script or whatever
you prefer.
On Wednesday, 18 March 2015 at 16:27:41 UTC, John Colvin wrote:
It might not solve your problem but i strongly recommend using
2.066.1 instead. There are serious problems with 2.066.0 that
were fixed in 2.066.1
Re: final methods by default
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote: Why aren't methods of class final by default? See: http://forum.dlang.org/thread/lfqoan$5qq$1...@digitalmars.com
Re: final methods by default
On Friday, 20 March 2015 at 14:25:22 UTC, ref2401 wrote: Why aren't methods of class final by default? history use final class, it should devirtualize all methods. see: https://github.com/D-Programming-Language/dmd/pull/4427
