Re: SDC-32bit
I want output C or maybe even Cool ... What's benefits this would give?
Re: SDC-32bit
On Saturday, 18 October 2014 at 09:29:10 UTC, Suliman wrote: What's benefits this would give? apart from the hack-factor a backend that generates _nice_ C-code is a really usefil thing to have. For example if you want to program microcontrollers in D.
Re: dfl2 is comming
There were 15 forks of DFL on github (some of them working fine with 2.066), you made a 16nth, with another name. ;) What's the point? Btw, your version (just like most others) contains bugs causing the app to crash on exit. The issue is with destructors (in Timer and Tooltip, for example) that try to access some global/static variables, and when the app closes GC does its final cycle and calls destructors, and at this time many of those objects are already dead. It went silent in older versions of D, but since 2.065 was pretty visible. My fix is here: https://github.com/thedeemon/dfl/commit/290d6456f6d13447311845929fd929acb6938a5d (sadly, combined with additional changes I made when trying to find the bugs) Sorry,D2.066 is no 'dm' folder,its libs all moved in dmd2\windows\lib,and most new users like to use the 'dub' or Visual studio .net . A few minutes ago,I test to compile the dfl which was cloned from 'https://github.com/Rayerd/dfl',but found some errors,not get the *.objs,and must modify the bat file. Now,it's a important thing, let more new users to like the dfl in their ways:'dub' or Visual studio.net. I think its very easy to use it for you. Thank you very much.
Re: CUDA bindings
On 10/18/2014 05:49 AM, ponce wrote: I think we need some place (could be just a NG thread?) to express users needs for library/bindings. Else we don't really know what is missing. A wiki page might be better, so that it can be modified in place and always be up to date with requests and results. -- Paul O'Neil Github / IRC: todayman
Re: Program logic bugs vs input/environmental errors
On Saturday, 18 October 2014 at 05:22:54 UTC, Walter Bright wrote:
2. If (1) cannot be done, then write the unittests like:
{
openfile();
scope (exit) closefile();
scope (failure) assert(0);
... use enforce() instead of assert() ...
}
3. In a script that compiles/runs the unittests, have the
script delete any extraneous generated files.
This is bad, it means:
- I risk having my filesystem ruined by running unit-tests
through the compiler.
- The test environment changes between runs.
Built in unit tests should have no side effects.
Something along these lines would be a better setup:
1. Load a filesystem from a read-only file to a virtual driver.
2. Run a special initializer for unit tests to set up the
in-memory test environment.
3. Create N forks (N=number of cores):
4. Fork the filesystem/program before running a single unit test.
5. Mount the virtual filesystem (from 1)
6. Run the unit test
7. Collect result from child process and print result.
8. goto 4
But just banning writing to resources would be more suitable. D
unit tests are only suitable for testing simple library code
anyway.
Re: Postblit bug
Am Fri, 17 Oct 2014 17:25:46 +
schrieb monarch_dodra monarchdo...@gmail.com:
But maybe this answers your question?
import std.stdio;
struct S
{
int* p;
this(this)
{
++*p;
}
}
void main()
{
immutable i = 0;
auto s1 = immutable(S)(i);
auto s2 = s1;
assert(*i == 0);
}
Consider that when passing a variable you can always remove
top level const-ness because a copy is made. This holds for
returns, parameters, assignments, ...
Post-blit is no different. The issue as I see it, is that D
doesn't have strong support for this notion of head-mutable or
else it would work with this type during post-blit:
struct S
{
immutable(int)* p;
this(this)
{
++*p;
}
}
--
Marco
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 05:54:01 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 04:35:07 UTC, Walter Bright wrote: Larger mantissa can help a little bit, but only a little bit. https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
In D (and C++) you would get:
if (x ((x+1)0x)){…}
perfect. nice and straightforward way to do overflow checks.
Besides, the code uses x + 1, so the code is already in undefined
state. It's just as wrong as the horrible code with UB we wère
trying to avoid in the first place.
So much for convincing me that it's a good idea...
Re: Postblit bug
On Saturday, 18 October 2014 at 06:43:28 UTC, Marco Leise wrote:
Am Fri, 17 Oct 2014 17:25:46 +
schrieb monarch_dodra monarchdo...@gmail.com:
But maybe this answers your question?
import std.stdio;
struct S
{
int* p;
this(this)
{
++*p;
}
}
void main()
{
immutable i = 0;
auto s1 = immutable(S)(i);
auto s2 = s1;
assert(*i == 0);
}
Consider that when passing a variable you can always remove
top level const-ness because a copy is made. This holds for
returns, parameters, assignments, ...
Post-blit is no different. The issue as I see it, is that D
doesn't have strong support for this notion of head-mutable or
D has it for primitives, such as pointers, slices...
else it would work with this type during post-blit:
struct S
{
immutable(int)* p;
this(this)
{
++*p;
}
}
Unsure how that's relevant? This code looks wrong to me no matter
how you look at it?
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 08:21:47 UTC, eles wrote: On Saturday, 18 October 2014 at 05:54:01 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 04:35:07 UTC, Walter Bright wrote: Larger mantissa can help a little bit, but only a little bit. https://en.wikipedia.org/wiki/Kahan_summation_algorithm As that article also points out (IIRC), you can got pretty good results by divide-and-conquer without any extra work.
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 08:58:22 UTC, John Colvin wrote: As that article also points out (IIRC), you can got pretty good results by divide-and-conquer without any extra work. http://code.activestate.com/recipes/393090/ It is built into Python: import math a = [1e99,1.0,-1e99] print sum(a) 0.0 print math.fsum(a) 1.0
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 09:30:20 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 08:58:22 UTC, John Colvin wrote: As that article also points out (IIRC), you can got pretty good results by divide-and-conquer without any extra work. http://code.activestate.com/recipes/393090/ It is built into Python: Or more accurately: there is a C version built into Python called math.fsum() that is fairly accurate (except last bit of mantissa). I believe the link above provide slower versions that are accurate.
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 08:21:47 UTC, eles wrote: On Saturday, 18 October 2014 at 05:54:01 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 04:35:07 UTC, Walter Bright wrote: Larger mantissa can help a little bit, but only a little bit. https://en.wikipedia.org/wiki/Kahan_summation_algorithm Kahan helps a little bit: a = [math.pi*(n**9) for n in range(0,101)] +[-math.pi*(n**9) for n in range(100,0,-1)] print sum(a), kahan(a), fsum(a) -1389.4713685 239.156561184 0.0 but not a lot: a = [1e16,math.pi,-1e16] print sum(a), kahan(a), fsum(a) 4.0 4.0 3.14159265359 a = [1e17,math.pi,-1e17] print sum(a), kahan(a), fsum(a) 0.0 0.0 3.14159265359
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 10:44:59 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 18 October 2014 at 08:21:47 UTC, eles wrote:
On Saturday, 18 October 2014 at 05:54:01 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 18 October 2014 at 04:35:07 UTC, Walter Bright
wrote:
Larger mantissa can help a little bit, but only a little bit.
https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Kahan helps a little bit:
a = [math.pi*(n**9) for n in range(0,101)]
+[-math.pi*(n**9) for n in range(100,0,-1)]
print sum(a), kahan(a), fsum(a)
-1389.4713685 239.156561184 0.0
but not a lot:
a = [1e16,math.pi,-1e16]
print sum(a), kahan(a), fsum(a)
4.0 4.0 3.14159265359
a = [1e17,math.pi,-1e17]
print sum(a), kahan(a), fsum(a)
0.0 0.0 3.14159265359
auto kahanSum(R)(R input)
{
double sum = 0.0;
double c = 0.0;
foreach(double el; input)
{
double y = el - c;
double t = sum + y;
c = (t - sum) - y;
sum = t;
}
return sum;
}
import std.math;
import std.range;
import std.algorithm;
import std.stdio;
double pi = PI;
void main()
{
auto a = chain(
iota(101L).map!((x) = pi * x^^9),
iota(101L).map!((x) = -pi * x^^9)
);
writeln(kahanSum(a));
writeln(a.sum);
}
$ rdmd kahantest.d
0
-980
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 11:43:32 UTC, John Colvin wrote: iota(101L).map!((x) = pi * x^^9), iota(101L).map!((x) = -pi * x^^9) Shouldn't the last expression be -pi * (100-x)^^9 ?
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 11:56:15 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 11:43:32 UTC, John Colvin wrote: iota(101L).map!((x) = pi * x^^9), iota(101L).map!((x) = -pi * x^^9) Shouldn't the last expression be -pi * (100-x)^^9 ? Yeah, my mistake. auto a = chain( iota(1, 101L).map!((x) = pi * x^^9), iota(100L, 0L, -1L).map!((x) = -pi * x^^9) ).array; writeln(a.kahanSum);// 111.157 writeln(a.sum); // -1272 writeln(a.sort().kahanSum); // 0 writeln(a.sort().sum); // 760
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 12:16:24 UTC, John Colvin wrote: writeln(a.kahanSum);// 111.157 writeln(a.sum); // -1272 writeln(a.sort().kahanSum); // 0 Yes, but it is misleading, my test case was bad. Try to add a 1.0 element to the array. a.append(1.0) a = sorted(a) print sum(a), kahan(a), accurate(a) -1024.0 0.0 1.0
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 12:22:38 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 12:16:24 UTC, John Colvin wrote: writeln(a.kahanSum);// 111.157 writeln(a.sum); // -1272 writeln(a.sort().kahanSum); // 0 Yes, but it is misleading, my test case was bad. Try to add a 1.0 element to the array. Note: the sort should be over abs(x) to have an effect, but then we would need a different dataset since +N and -N will cancel out too easily.
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 10:44:59 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 08:21:47 UTC, eles wrote: On Saturday, 18 October 2014 at 05:54:01 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 04:35:07 UTC, Walter Bright wrote: Larger mantissa can help a little bit, but only a little bit. https://en.wikipedia.org/wiki/Kahan_summation_algorithm Kahan helps a little bit: a = [math.pi*(n**9) for n in range(0,101)] +[-math.pi*(n**9) for n in range(100,0,-1)] This might simply be a case biased in favor of pairwise summation, as numbers ar symmetric.
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 12:48:00 UTC, eles wrote: This might simply be a case biased in favor of pairwise summation, as numbers ar symmetric. I haven't used pairwise summation though. The best solution is to partition based on exponent and use accurate integer arithmetics. The first function on the link I posted above is accurate in the partitions, but inaccurate of the summation of the partitions… :-/ But yes, you can create a lot worse datasets. Kahan only recover a few of the lost bits due to rounding.
How C++ Builder and Delphi make use of ARC
Hi, I was looking for some C++ Builder language extensions and found this information about ARC in Embarcadero compilers. Maybe it is relevant for the usual memory management discussions. http://docwiki.embarcadero.com/RADStudio/XE6/en/Automatic_Reference_Counting_in_Delphi_Mobile_Compilers http://docwiki.embarcadero.com/RADStudio/XE6/en/Automatic_Reference_Counting_in_C%2B%2B -- Paulo
Re: Postblit bug
Am Sat, 18 Oct 2014 08:28:40 +
schrieb monarch_dodra monarchdo...@gmail.com:
Consider that when passing a variable you can always remove
top level const-ness because a copy is made. This holds for
returns, parameters, assignments, ...
Post-blit is no different. The issue as I see it, is that D
doesn't have strong support for this notion of head-mutable or
D has it for primitives, such as pointers, slices...
else it would work with this type during post-blit:
struct S
{
immutable(int)* p;
this(this)
{
++*p;
}
}
Unsure how that's relevant? This code looks wrong to me no matter
how you look at it?
This is the only relevant point to discuss. The act of
blitting is a shallow copy. Hence while the copy is created
there is no risk in modifying its bits. Hence the proposal to
make make it mutable.
But then you added deepness in form of a pointer to the
structure that a shallow copy doesn't cover.
So I concluded that the issue with making postblit mutable is
that it removes immutable transitively through pointers,
while for a shallow copy it must be shallow, too. That's just a
basic observation. The imaginary struct I showed is the result
of that. It only removes the top level immutable from the
struct and would error out as you try modify the dereferenced
immutable(int) while reassignment would work.
--
Marco
DMD and GtkD compilation speed and installation size (2.066.0 vs. 2.066.1)
While trying to find a bug I had to reinstall DMD and GtkD so I thought I'd collect some statistics. Installation time for both DMD and GtkD built with it: 2.066.0: 443,45s user 72,33s system 160% cpu 5:21,55 total 2.066.1: 390,66s user 45,50s system 147% cpu 4:55,81 total Wow, nice improvement! Installed file size for the complete package including source files with 2.066.0: * dev-lang/dmd-2.066.0 Total files : 635 Total size : 119.79 MiB * dev-libs/GtkD-2.4.0 Total files : 918 Total size : 383.45 MiB and 2.066.1: * dev-lang/dmd-2.066.1 Total files : 638 Total size : 105.93 MiB * dev-libs/GtkD-2.4.0 Total files : 918 Total size : 168.36 MiB On a closer look the shared objects stayed the same, but the 12 .a archives for GtkD have each lost between 7 and 27 MiB! -- Marco
Re: Program logic bugs vs input/environmental errors
On 2014-10-18 06:36, Walter Bright wrote: This particular subthread is about unittests. That doesn't make the problem go away. -- /Jacob Carlborg
Re: C++ Ranges proposal for the Standard Library
On 10/18/14, 4:43 AM, John Colvin wrote:
auto kahanSum(R)(R input)
{
double sum = 0.0;
double c = 0.0;
foreach(double el; input)
{
double y = el - c;
double t = sum + y;
c = (t - sum) - y;
sum = t;
}
return sum;
}
No need to implement it. http://dlang.org/phobos/std_algorithm.html#.sum
Andrei
Re: Program logic bugs vs input/environmental errors
On 2014-10-18 07:09, Walter Bright wrote: Which means they'll be program bugs, not environmental errors. Yes, but just because I made a mistake in using a function (hitting an assert) doesn't mean I want to have undefined behavior. -- /Jacob Carlborg
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 15:17:09 UTC, Andrei Alexandrescu wrote: No need to implement it. http://dlang.org/phobos/std_algorithm.html#.sum It isn't accurate. Python's fsum is around 100 lines of c-code and AFAIK based on this algorithm: http://www.cs.berkeley.edu/~jrs/papers/robustr.pdf more: https://hg.python.org/cpython/file/7c183c782401/Modules/mathmodule.c#l1063 http://www-pequan.lip6.fr/~graillat/papers/rr2005-03.pdf But I think an integer version is faster on a large dataset.
Re: Program logic bugs vs input/environmental errors
On Saturday, 18 October 2014 at 05:10:20 UTC, Walter Bright wrote: I understand that some have to work with poorly written libraries that incorrectly use assert. If that's the only issue with those libraries, you're probably lucky :-) Short term, I suggest editing the code of those libraries, and pressuring the authors of them. Longer term, we need to establish a culture of using assert/enforce correctly. So you consider the library interface to be user input? What about calls that are used internally but also exposed as part of the library interface?
Re: C++ Ranges proposal for the Standard Library
Demmel and Hida use different algorithms based on then input size: http://www.cs.berkeley.edu/~demmel/AccurateSummation.pdf Another overview of summation algorithms: http://www.sigsam.org/bulletin/articles/147/sumnums.pdf
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 09:17:52 UTC, ZombineDev wrote: I saw [this][0] proposal for adding ranges to C++'s standard library. The [paper][1] looks at D style ranges, but concludes: Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis. What do you guys think? Since assembly code can be used to implement Java but java cannot be used to implement assembly code, we conclude that assembly code forms a more powerful and foundational basis. I probably could have chosen that example better, but I hope it gets my point across. It's always possible to reduce a library interface to something that's even more stripped-down, which is by definition more powerful and foundational. But if the user never wants to work at that low level of abstraction then you're just imposing an unnecessary burden upon them. A well-designed library provides power and flexibility in a form that encourages a good coding style and which inherently reduces the chance of mistakes. Getting this right is really, really hard to do. I think D gets it more right than C++ though, across the board. Regarding iterators vs. ranges, there are still places where ranges struggle to meet the facility of iterators. But I don't think this is a flaw in the concept so much that it's still fairly new and people are still working out the details. Given the standardization process for C++, they're probably right to remain with iterators for now and wait for all the kinks to be worked out of range design. Maybe get ranges into Boost (if they aren't there already) and see how it goes. But dismissing ranges out of hand for not being sufficiently powerful and foundational is just silly.
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 15:39:36 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 October 2014 at 15:17:09 UTC, Andrei Alexandrescu wrote: No need to implement it. http://dlang.org/phobos/std_algorithm.html#.sum It isn't accurate. Did you look at the doc. It's specially designed to be accurate...
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 16:46:31 UTC, monarch_dodra wrote: Did you look at the doc. It's specially designed to be accurate... Change the docs?
Re: C++ Ranges proposal for the Standard Library
On 10/18/2014 8:17 AM, Andrei Alexandrescu wrote:
On 10/18/14, 4:43 AM, John Colvin wrote:
auto kahanSum(R)(R input)
{
double sum = 0.0;
double c = 0.0;
foreach(double el; input)
{
double y = el - c;
double t = sum + y;
c = (t - sum) - y;
sum = t;
}
return sum;
}
No need to implement it. http://dlang.org/phobos/std_algorithm.html#.sum
Wow, I hadn't noticed that before. Sweet!
Re: C++ Ranges proposal for the Standard Library
On 10/18/2014 9:16 AM, Sean Kelly wrote: But dismissing ranges out of hand for not being sufficiently powerful and foundational is just silly. I agree. It's like foreach in D. It's less powerful and foundational than a for loop (in fact, the compiler internally rewrites foreach into for), but that takes nothing away from how darned useful (and far less bug prone) foreach is. Also, the glue layer rewrites for loops into goto loops, as gotos are more powerful and foundational :-)
Re: C++ Ranges proposal for the Standard Library
On Saturday, 18 October 2014 at 17:31:18 UTC, Walter Bright wrote: I agree. It's like foreach in D. It's less powerful and foundational than a for loop (in fact, the compiler internally rewrites foreach into for), but that takes nothing away from how darned useful (and far less bug prone) foreach is. Actually, there are quite a few bugs related to modifying values and/or indexes in a foreach loop. In particular, foreach allows ref iteration over ranges that don't give ref access...
Re: C++ Ranges proposal for the Standard Library
All that said, after a quick scan I really like the range proposal for C++. In particular, the idea of positions is a nice one, as it addresses an awkward issue with D ranges.
Re: C++ Ranges proposal for the Standard Library
Zhu and Hayes (2010) «Algorithm 908: Online Exact Summation of Floating-Point Streams» is compatible with ranges and looks interesting: http://s3.amazonaws.com/researchcompendia_prod/articles/990d22f230c4b4eb7796f0ed45b209eb-2013-12-23-01-53-27/a37-zhu.pdf
Re: Program logic bugs vs input/environmental errors
On 10/18/2014 8:21 AM, Jacob Carlborg wrote: On 2014-10-18 07:09, Walter Bright wrote: Which means they'll be program bugs, not environmental errors. Yes, but just because I made a mistake in using a function (hitting an assert) doesn't mean I want to have undefined behavior. As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point. Now, if it is a known unknown state, and you want to recover, the solution is straightforward - use enforce(). enforce() offers the guarantees you're asking for. Using assert() when you mean enforce() is like pulling the fire alarm but not wanting the fire dept. to show up.
Re: Program logic bugs vs input/environmental errors
On 10/18/2014 9:01 AM, Sean Kelly wrote:
So you consider the library interface to be user input?
The library designer has to make that decision, not the language.
What about calls that are used internally but also exposed as part of the
library interface?
The library designer has to make a decision about who's job it is to validate
the parameters to an interface, and thereby deciding what are
input/environmental errors and what are programming bugs.
Avoiding making this decision means the API is underspecified, and we all know
how poorly that works.
Consider:
/**
* foo() does magical things.
* Parameters:
* x a value that must be greater than 0 and less than 8
* y a positive integer
* Throws:
* Exception if y is negative
* Returns:
* magic value
*/
int foo(int x, int y)
in { assert(x 0 x 8); }
body {
enforce(y = 0, silly rabbit, y should be positive);
... return ...;
}
Re: C++ Ranges proposal for the Standard Library
On 10/18/2014 10:37 AM, monarch_dodra wrote: On Saturday, 18 October 2014 at 17:31:18 UTC, Walter Bright wrote: I agree. It's like foreach in D. It's less powerful and foundational than a for loop (in fact, the compiler internally rewrites foreach into for), but that takes nothing away from how darned useful (and far less bug prone) foreach is. Actually, there are quite a few bugs related to modifying values and/or indexes in a foreach loop. In particular, foreach allows ref iteration over ranges that don't give ref access... All bugs should be reported to bugzilla. I still argue that foreach is far less bug prone than for loops.
Re: On Phobos GC hunt
On 10/08/2014 10:01 PM, Andrei Alexandrescu wrote:
That's a bummer. Can we get the compiler to remove the if (__ctfe)
code after semantic checking?
Andrei
It seems that __ctfe is treated as constant in the backend.
At least there is no asm code generated for these examples (even without
-O).
void main()
{
import std.stdio;
if (__ctfe)
writeln(foo);
}
int main() { return __ctfe ? 1 : 0; }
Re: On Phobos GC hunt
On 10/08/2014 11:40 PM, Timon Gehr wrote: This is probably a regression somewhere after 2.060, because with 2.060 I get Error: variable __ctfe cannot be read at compile time Error: expression __ctfe is not constant or does not evaluate to a bool as I'd expect. Marked the bugzilla case as regression. https://issues.dlang.org/show_bug.cgi?id=13601
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote: On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? No Do you think it makes your code better or worse? Better. More clear Is this just a pointless style change? No
Re: RFC: std.json sucessor
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig wrote: Once its done you can compare its performance against other languages with this benchmark: https://github.com/kostya/benchmarks/tree/master/json Wow, the C++Rapid parser is really impressive. I threw together a test with my own parser for comparison, and Rapid still beat it. It's the first parser I've encountered that's faster. Ruby 0.4995479721139979 0.49977992077421846 0.49981146157805545 7.53s, 2330.9Mb Python 0.499547972114 0.499779920774 0.499811461578 12.01s, 1355.1Mb C++ Rapid 0.499548 0.49978 0.499811 1.75s, 1009.0Mb JEP (mine) 0.49954797 0.49977992 0.49981146 2.38s, 203.4Mb
Re: On Phobos GC hunt
On Tuesday, 14 October 2014 at 13:29:33 UTC, Dmitry Olshansky wrote: Also it's universal as in any github-hosted D project, for example here is an output for druntime: http://wiki.dlang.org/Stuff_in_Druntime_That_Generates_Garbage Still todo: - a few bugs to fix in artifact labeling One artefact labelling bug I noticed was GC.removeRange and GC.removeRoot were placed in the Artefact column where it should have been GC.rangeIter and GC.rootIter.
Re: template constraint diagnostics
On 2014-10-15 17:29:33 +, Trass3r said: http://youtu.be/qwXq5MqY2ZA?t=33m57s I wish we had diagnostics like that in D. I have answered your call: https://github.com/D-Programming-Language/phobos/pull/2627 Please comment. -S.
Re: GCC Undefined Behavior Sanitizer
On Saturday, 18 October 2014 at 08:22:25 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
In D (and C++) you would get:
if (x ((x+1)0x)){…}
perfect. nice and straightforward way to do overflow checks.
It wasn't an overflow check as ketmar suggested… It was a check
that should stay true, always for this instantiation. So the
wrong code is bypassed on overflow, possibly missing a
termination. The code would have been correct with an
optimization that set it to true or with a higher resolution
register.
Besides, the code uses x + 1, so the code is already in
undefined state. It's just as wrong as the horrible code with
UB we wère trying to avoid in the first place.
So much for convincing me that it's a good idea...
Not sure if you are saying that modulo-arithmetic as a default is
a bad or good idea?
In D and (C++ for uint) it is modulo-arithmetic so it is defined
as a circular type with at discontinuity which makes reasoning
about integers harder.
Re: GCC Undefined Behavior Sanitizer
On 10/17/2014 2:46 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: It isn't even obvious that a byte should be 8 bits, Oh come on! http://dlang.org/type.html
Re: GCC Undefined Behavior Sanitizer
On 10/16/2014 2:00 PM, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ On the other hand, D is one step ahead of C with many of those (they are part of the language, not an add-on tool). Anyhow, for the remainder, https://issues.dlang.org/show_bug.cgi?id=13636
Re: RFC: std.json sucessor
On Saturday, 18 October 2014 at 19:53:23 UTC, Sean Kelly wrote: On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig wrote: Once its done you can compare its performance against other languages with this benchmark: https://github.com/kostya/benchmarks/tree/master/json Wow, the C++Rapid parser is really impressive. I threw together a test with my own parser for comparison, and Rapid still beat it. It's the first parser I've encountered that's faster. C++ Rapid 0.499548 0.49978 0.499811 1.75s, 1009.0Mb JEP (mine) 0.49954797 0.49977992 0.49981146 2.38s, 203.4Mb I just commented out the sscanf() call that was parsing the float and re-ran the test to see what the difference would be. Here's the new timing: JEP (mine) 0. 0. 0. 1.23s, 203.1Mb So nearly half of the total execution time was spent simply parsing floats. For this reason, I'm starting to think that this isn't the best benchmark of JSON parser performance. The other issue with my parser is that it's written in C, and so all of the user-defined bits are called via a bank of function pointers. If it were converted to C++ or D where this could be done via templates it would be much faster. Just as a test I nulled out the function pointers I'd set to see what the cost of indirection was, and here's the result: JEP (mine) nan nan nan 0.57s, 109.4Mb The memory difference is interesting, and I can't entirely explain it other than to say that it's probably an artifact of my mapping in the file as virtual memory rather than reading it into an allocated buffer. Either way, roughly 0.60s can be attributed to indirect function calls and the bit of logic on the other side, which seems like a good candidate for optimization.
Re: GCC Undefined Behavior Sanitizer
On Saturday, 18 October 2014 at 23:45:37 UTC, Walter Bright wrote: On 10/17/2014 2:46 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: It isn't even obvious that a byte should be 8 bits, Oh come on! Hey, that was a historically motivated reflection on the smallest addressable unit. Not obvious that it should be 8 bit. :9
Re: template constraint diagnostics
On 2014-10-18 21:52:30 +, Shammah Chancellor said:
On 2014-10-15 17:29:33 +, Trass3r said:
http://youtu.be/qwXq5MqY2ZA?t=33m57s
I wish we had diagnostics like that in D.
I have answered your call:
https://github.com/D-Programming-Language/phobos/pull/2627
Please comment.
-S.
I don't know if anyone looked at this yet, but I've updated it quite a
bit since the original post. Please take a look again and comment.
It also generates some useful DDoc now.
Docs:
bool isConcept(T, C, bool diagnostics = false, string errorPrefix = )();
Returns true if T supports the concept C. Note, templated member
functions are not supported currently.
Concepts should be defined as in the following example:
class CInputRange(E) : Concept
{
abstract void popFront();
@property abstract E front();
bool empty;
//Optional Axioms function. This will be checked if it compiles, and
that it returns true if it does.
static bool Axioms(T)()
{
return true;
}
}
class CInfinite() : Concept
{
static bool Axioms(T)() {
enum empty = T.empty;
return !empty;
}
}
class CInfiniteInputRange(E) : CInputRange!E
{
mixin CInfinite;
}
---
template conceptDiagnostic(R, string F, int L, C...)
Prints error messages for why template instantiation failed.
Examples:
---
bool DoStuff(R)(R infRange) if ( isConcept!(R, CInfiniteInputRange!string))
{
return true;
}
bool DoStuff(R)(R infRange) if ( isConcept!(R, COutputRange!string))
{
return true;
}
//Example of using conceptDiagnostic
bool DoStuff(R, string F = __FILE__, size_t L = __LINE__ )(R infRange)
{
mixin conceptDiagnostic!(R, F, L, COutputRange!string,
CInfiniteInputRange!string);
return false;
}
---
class Concept;
Base class for Concepts. All Concepts should derive from this, or
another concept.
Re: template constraint diagnostics
I have something like this for mixin interfaces that require that
the host struct support certain semantics. There's a Traits
struct (concept-ish) that takes a set of strings for trait
identifiers and their definitions (which is some code that
compiles if and only if the trait is satisfied).
The Traits struct has a member mixin template, require, which
can be used by the interface that instantiated the Traits. When
one of the mixed-in requirements is failed, the compiler
generates an error message like this:
source/evx/meta/traits/generator.d-mixin-49(50): Error: static
assert MyStruct must support {size_t x = buffer.length;} to
enable TransferOps.
Not as nice as a compiler-aided concept solution but I have been
pretty happy with it so far. It doesn't take me long to forget
what some interface requirements are, and this way the compiler
can explicitly guide me.
Re: cmdcon-ng official thread
On Tue, 14 Oct 2014 01:48:12 +0300 ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: some news for those who still interested: * made const and static fields work * made static methods work * made @ConXXX attributes on methods and fields work * added telnet sample (sorry, GNU/Linux only, i have no other OSes) no AAs yet, sorry. and no, i will *not* add scripting language. no conditions, no assignments, no variable expanding. it's not a scripting system, and i never intend it to be one. yet if you *really* want to grow a monster, you can use ConObjects for this, albeit not without modifying the sources. p.s. telnet sample using Fibers and very simple and idiotic sheduler. yes, it supports multiple simultaneous connections (at least in theory). it shouldn't be very hard to port that sample to another OS too. be aware that cong does no locking, so if you want to use it in multithreaded environment, you have to register free functions to work with objects. yet cong using atomicLoad and atomicStore for arithmetic variables, so it provides at least some sort of thread-safety. ;-) signature.asc Description: PGP signature
Re: BareBones VersionCondition identifier for druntime
On 10/17/2014 12:04 PM, Kevin Lamonte wrote: What do y'all think? Would you be comfortable with saying to people implementing new runtimes, please version your differences from druntime in this particular way ? It's a good idea, but having a bunch of versions quickly devolves to an unmaintainable mess, in my experience. For one issue, when one adds a new piece of code, which versions apply in what ways? Once the number of versions exceeds a certain level, I've never seen it done right. A better solution is to have modules that plug in or not. The gc is designed this way. Also, dmd's source code is also (largely) done this way. Stuff that would normally be #ifdef'd is instead abstracted away to an interface. My experience with such techniques is they work well, are relatively problem free, and are much easier on the eyes.
Re: Beginner ?. Why does D suggest to learn java
On Saturday, 18 October 2014 at 02:00:42 UTC, RBfromME wrote: but i don't find the basics any easier to learn than D's. The biggest issue i personal find in getting deeper into a language is the docs and examples. The python examples, beyond the basics usually get write into OO so you find your self trying to figure out OO while trying to sift through the examples. Makes it a little harder to get going and figure out the available libraries while trying to figure OO at the same time. If you find D more fun, then use D, but OO is little more than representing aspects of real physical objects in the computer: If you want to write a program about cars you could group properties such as weight, top-speed and build-year and call that Vehicle, then add number of wheels and motorsize and call it Car or some other properties and call it Boat. Add a function print() to display all the info to each class Vehicle, Car and Boat. Then you can create a list of vehicles that store different properties for different types of vehicles while being able to treat all cars and boats the same when printing them. That's basically it. Nothing magic. The most important aspect of learning how to program is what universities tend to call datastructures and algorithms. The basics is probably just 2-4 weeks. If you already know Python a little bit you could try to use educational resources for Python and translate it into D, e.g.: http://interactivepython.org/courselib/static/pythonds/index.html The nice thing about Python that it is very close to what is called pseudo code, basically a shorthand used when sketching a program. Summing it up, I personally think the hardest part in learning to use a specific language is the docs and and examples because they all throw you write into OO and you spend more time trying to figure out OO instead of how to use the standard lib or third party lib to get a basic task done. You don't need to learn more OO than I wrote above, and perhaps not even that. What you need to learn to be productive in any imperative language is: 1. What an aggregate (of values) is, they are often called record, struct or class and how to create them. 2. Arrays and the provided operations on them (can be in language or libraries) 3. How to create links between aggregates (called references or pointers) Then pick up an online course or book on data structures and algorithms. Introductory books and courses teach roughly the same stuff, so pick anyone you like. Understanding libraries and their documentation becomes much easier when you know the basic terminology about data structures and algorithms. One of the most entertaining and useful courses in computer science.
Re: Beginner ?. Why does D suggest to learn java
On Friday, 17 October 2014 at 08:44:00 UTC, Paulo Pinto wrote: On Friday, 17 October 2014 at 01:05:37 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 00:52:14 + MachineCode via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I don't understand. If at least it were C but java? why not D itself? C is *awful* as beginner's language. never ever let people start with C if you don't hate 'em. as for D... current version of D can be used, but with some precautions. we now have excellent book by Ali. (it's great, really! i believe that it must be featured on the front dlang.org page!) but java has alot more books and tutorials. not that D is bad for beginners, it's just has a smaller userbase. and all that things with classes are reference types and structs are not, empty array is not empty array but is empty array and so on D may be confusing a little. it's good to have some CS background to understood that things. just my cent and cent. Better, go with FreePascal http://www.freepascal.org/ and discover all that those features that many C advocates spread as being close to the machine and other C only features, aren't exclusive of it. Alongside support for real modules, OO and genericity. Then with a head clean of bad C influences, jump into D. -- Paulo Don't tell him that - he may discover Freepascal/Lazarus is the holy grail of GUI programming and may never try D... ;-) -=mike=-
gdc: Compile error with normalize from std.uni
I'm using gdc on Ubuntu 14.04. Is this ubuntu packaging issue?
bash:~/tmp$ cat test2.d
import std.uni, std.stdio;
void main() {
writeln(normalize(Hello));
}
bash:~/tmp$ gdc test2.d
/usr/include/d/4.8/std/uni.d:6301: error: undefined identifier
tuple
/usr/include/d/4.8/std/uni.d:6262: error: template instance
std.uni.seekStable!(cast(NormalizationForm)0, char) error
instantiating
/usr/include/d/4.8/std/uni.d:6087: note: instantiated from here:
splitNormalized!(cast(NormalizationForm)0, char)
test2.d:4: note: instantiated from here:
normalize!(cast(NormalizationForm)0, char)
/usr/include/d/4.8/std/uni.d:6271: error: undefined identifier
tuple
/usr/include/d/4.8/std/uni.d:6087: error: template instance
std.uni.splitNormalized!(cast(NormalizationForm)0, char) error
instantiating
test2.d:4: note: instantiated from here:
normalize!(cast(NormalizationForm)0, char)
test2.d:4: error: template instance
std.uni.normalize!(cast(NormalizationForm)0, char) error
instantiating
bash:~/tmp$ gdc --version
gdc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Re: Returning multiple arrays from function - struct or byref the only option?
Thanks for the thoughts Meta and Ali.
Laeeth.
On Wednesday, 15 October 2014 at 17:56:06 UTC, Ali Çehreli wrote:
On 10/15/2014 09:48 AM, Laeeth Isharc wrote:
struct RetStruct
{
double[] a;
double[] b;
}
RetStruct myfunction(double x)
That's my preference. Tuples would work as well but they have
two minor issues for me:
- Unlike a struct, the members are anonymous. (Yes, tuples
members can have names as well but not when returning or
creating conveniently by 'return tuple(a, b)'.)
- Unlike Python, there is no automatic tuple expansion so one
has to refer to the members as result[0] and result[1], which
is less readable than struct members. (Yes, there is some
support for tuple expansion e.g. in foreach but it has some
issues with the automatic foreach loop counter.)
Summary: I return by struct. :)
Ali
Re: gdc: Compile error with normalize from std.uni
On Sat, 18 Oct 2014 10:01:51 + slycelote via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I'm using gdc on Ubuntu 14.04. Is this ubuntu packaging issue? yes. current gdc works fine. signature.asc Description: PGP signature
Re: Returning multiple arrays from function - struct or byref the only option?
On Wednesday, 15 October 2014 at 17:56:06 UTC, Ali Çehreli wrote:
- Unlike a struct, the members are anonymous. (Yes, tuples
members can have names as well but not when returning or
creating conveniently by 'return tuple(a, b)'.)
This works, but I agree it is a bit obscure (you may want to add
it to your book if it's not already there):
import std.typecons;
Tuple!(int[], left, int[], right) foo(int n, int m)
{
return typeof(return)(new int[](n), new int[](m));
}
void main()
{
auto res = foo(2, 3);
assert(res.left.length == 2);
assert(res.right.length == 3);
}
The problem is that D does not allow implicit conversions when
returning results from a function. Tuple!(int[], int[]) is
implicitly castable to Tuple!(int[], left, int[], right), but
you cannot return the result of tuple(new int[](n), new int[](m))
from foo(), as they are technically still different types, which
would require an implicit conversion. This is (IMO) a problem;
it's extremely annoying when trying to use std.typecons.Algebraic.
Re: Recommended GUI library?
On 2014-10-17 18:34, K.K. wrote: I'm looking for suggestions for a GUI library, to create a somewhat light GUI that can also be created without too much fuss, and support for Windows Linux. Have a look at DWT [1]. It's basically the only D GUI framework that doesn't have any dependencies except for system libraries. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Re: String created from buffer has wrong length and strip() result is incorrect
On Saturday, 18 October 2014 at 00:53:57 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 18 Oct 2014 00:32:09 + Lucas Burson via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Wow, your changes made it much simpler. Thank you for the suggestions and expertise ketmar :)
Re: String created from buffer has wrong length and strip() result is incorrect
On Sat, 18 Oct 2014 16:56:09 + Lucas Burson via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Wow, your changes made it much simpler. Thank you for the suggestions and expertise ketmar :) you're welcome. signature.asc Description: PGP signature
Re: Recommended GUI library?
Thanks for the extra suggestions! I'll check them out.
[OT] the uses of computing
On Saturday, 18 October 2014 at 00:06:10 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 23:31:45 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You do realize that most people are clueless about how to fix those also, right? most people are stupid. No disagreement there, but even the smart ones can only learn so much. Would you require that how to fix all that mechanical stuff be taught in schools too? but it is! or at least it was. it's all simple physics, you know. not a rocket science. Many people do not learn simple physics in school, and even if they did, wouldn't necessarily be able to figure out how to fix a specific mechanical system like a washing machine from the general physical principles. Kids would never leave school if they had to learn all the stuff everybody says they should be forced to learn. ;) nobody should be *forced* to learn: it's pointless. yet kids are very curious, and they can be taught *alot* of things if they think that they are just playing. make it interesting, and you'll be amazed how much kids can learn almost without problems. Yeah, we agree if you truly mean making most of what they learn optional, not just fun but still required. Most of the stuff we force on kids today, like multiplication tables, how to divide numbers by hand, or memorizing historical dates, is utterly useless. Yet, civilization is made up of people like you, who would all miss those mechanical systems far more than computers. it's a huge difference between i miss my washing machine and all our communication and data processing systems are foobared. Yet, I bet you they'll want that washing machine working far more than the internet. They should use tools like Automator instead, no programming needed: http://en.wikipedia.org/wiki/Automator_(software) i wasn't talking about sorting out file mess. i was talking about tabular data processing, for example, with some logics and calculations that can't be done automatically without programming. Isn't that what people use Excel macros for? There are specialized tools for the job, that are more limited than full programming languages but easier to use for the average person. Tablets are optimized for basic usage what is basic usage? i really don't know what tablets are for. what i can do with it? watching movie? listening music? reading book? yes, tablets can do this... badly. what else? All of the above, anything you'd use a portable computer for that doesn't require much typing and would benefit from a larger screen than your smartphone. I wouldn't say they do it all badly: it's the most portable TV you could ever have, if you use it to watch video. And you're not limited to the junk on the idiot box, you can download any video from the web and watch on the go. Most websites benefit from a larger screen also. i can listen music with my N900, and it fits in my pocket. movies? on tablet screen? no, thanks. books? electronic books are better. I've watched parts of movies on my 4.7 smartphone screen, which happens to have the best display I've ever used. Tablets are even better for video. I don't read books anymore, but with their high-res displays up to 200-300 ppi these days, reading text is very nice on tablets too. tablets are like XML: bad for everything. Now that's just low, you can't compare anything to the utter junk that is XML. :) Most people just need a basic appliance that isn't going to catch viruses or require registry hacks. give 'em wooden board with painting. it's great! It's a little better than that. ;) It is completely different, because there are tools like Automator to help you automate your workflow without needing to write anything. oh, please. i can do batch renaming with wildcards, and for any task that is more complex than that there *is* a need to write logic. scripts. graphic programming is a dead end. people drop icons in favor of alphabet 'cause alphabet is just better. Actually, the progression went the other way, people dropped text UIs for graphical UIs. :) I'm not saying _you_ need to leave the terminal, but for most people GUI tools like Automator are enough. If you need to communicate something on paper- well, nobody uses paper these days i wish that the goverment of my country knows about that. and banking. somehow they still insist to have everything written on paper. Well, the government is the most backwards part of any country. For most people, that is a better route, particularly if they don't need to modify the script as they go and just need it written once. so instead of spending ten minutes to write the script they'll spend a day searching for someone to hire and pay him money. great. thanks to such people we have don't put your pet into microwave-like instructions. and that instructions are pointless 'cause such people never reads any instructions
Re: Any dub tips and tricks
There is a mistake in the dil package.json excludedSourceFiles should be an array of strings, not just a string. But I don't get those errors on my OSX.
Re: [OT] the uses of computing
On Sat, 18 Oct 2014 19:42:50 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: most people are stupid. No disagreement there, but even the smart ones can only learn so much. that's why we should teach kids alot of things while their minds are clear and ready to absorb alot of knowledge. and, of course, we must teach them how to *use* that knowledge. Many people do not learn simple physics in school, and even if they did, wouldn't necessarily be able to figure out how to fix a specific mechanical system like a washing machine from the general physical principles. yes, figuring this out without manuals will be hard. but learning physics (proper learning of *anything* for that matter) will give 'em understanding of base principles (mechanics, electricity, etc) and the ability to extract information from books. it's enough for simple fixes that doesn't require to produce hi-tech parts. Yeah, we agree if you truly mean making most of what they learn optional, not just fun but still required. Most of the stuff we force on kids today, like multiplication tables, how to divide numbers by hand, or memorizing historical dates, is utterly useless. ah, i hated that so-called history lessons where i was forced to remebmer that in year i don't care about somebody who i don't care about did something i equally don't care about. ;-) yes, i'm sure that we should teach kids how to do things, not just making 'em remember that 4*8 is 32. tell 'em what multiplication is and then play games with them, games which involves using of multiplication. this way kids will learn how to use multiplication. no need to remember any tables. or let 'em build a simple robot and program it to do some funny things. it's exciting and they will learn many things about mechanics, electricity, programming... let 'em play a role of factory manager, for example, and they will develop a good understanding of how economics works. and so on. Yet, civilization is made up of people like you, who would all miss those mechanical systems far more than computers. it's a huge difference between i miss my washing machine and all our communication and data processing systems are foobared. Yet, I bet you they'll want that washing machine working far more than the internet. most people can't see a whole picture. it's bad. we must teach kids to understand how different things are interconnected too. Isn't that what people use Excel macros for? aren't writing excel macros a programming? There are specialized tools for the job, that are more limited than full programming languages but easier to use for the average person. i never meant that all people should learn full programming languages. they have to know how to write algorithms, but not necessary what pointer is or what is the difference between manual memory management and garbage collecting. yet if i'll show 'em simple recursive fibonacci function, they must be able to understand it. hey, it's lambda calculus, and lambda calculus is so simple, that even 7-year kid can understand it! i checked that, kids are really able to understand it. ;-) All of the above, anything you'd use a portable computer for that doesn't require much typing and would benefit from a larger screen than your smartphone. instagram and social networks. ;-) two of the most useless things on the planet. And you're not limited to the junk on the idiot box, you can download any video from the web and watch on the go. and can't easily mark and categorize that until someone wrote web-service for it. 'cause for doing it locally i need... ah, to write some scripts. and i have no keyboard (no, that on-screen crap may be good for tweeting, but it's generally unusable). i.e. tablets *are* idiot boxes, just with fancy pictures from over the world. I don't read books anymore even technical ones? ;-) but with their high-res displays up to 200-300 ppi these days, reading text is very nice on tablets too. i prefer to use some specialised device to reading text. it's smaller, it was made especially for reading texts and it can last alot longer without recharging. i mean that tablets can do all that things, but specialised devices are just better. and if i know that i'll have to spend some time waithing for something, i'll take my player and ebook with me. or subnotebook -- hey, it has real keyboard! tablets are like XML: bad for everything. Now that's just low, you can't compare anything to the utter junk that is XML. :) ah, you are right. tablets sometimes can be useful. ;-) Actually, the progression went the other way, people dropped text UIs for graphical UIs. :) that's 'cause they never used good UIs and we have no truly component environments. Oberon system was great even with it's TUI, and it was really exciting with it's gadgets UI. i'm still missing my Oberon system. by the way, if D will develop good runtime reflection (which is
Re: [OT] the uses of computing
On Saturday, 18 October 2014 at 20:50:42 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 18 Oct 2014 19:42:50 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: most people are stupid. No disagreement there, but even the smart ones can only learn so much. that's why we should teach kids alot of things while their minds are clear and ready to absorb alot of knowledge. and, of course, we must teach them how to *use* that knowledge. So much of what's taught today is so worthless that I'm skeptical of anyone claiming kids should be taught a lot, as if you know what that is. And given our long history of barely being able to teach any knowledge, with almost no success in getting people to use it for something original, that seems like a dead end too. Better to just let people take their own path and find what works best for them. Many people do not learn simple physics in school, and even if they did, wouldn't necessarily be able to figure out how to fix a specific mechanical system like a washing machine from the general physical principles. yes, figuring this out without manuals will be hard. but learning physics (proper learning of *anything* for that matter) will give 'em understanding of base principles (mechanics, electricity, etc) and the ability to extract information from books. it's enough for simple fixes that doesn't require to produce hi-tech parts. I disagree, as there is a large gap of knowledge between the base principles and the complex systems we build on top. How many people would be able to diagnose and force reallocation of bad sectors in their hard disk if hit with that problem, given the basics of how hard disks work? I actually ran into this recently and found little info about it, meaning not many people do it. Yeah, we agree if you truly mean making most of what they learn optional, not just fun but still required. Most of the stuff we force on kids today, like multiplication tables, how to divide numbers by hand, or memorizing historical dates, is utterly useless. ah, i hated that so-called history lessons where i was forced to remebmer that in year i don't care about somebody who i don't care about did something i equally don't care about. ;-) yes, i'm sure that we should teach kids how to do things, not just making 'em remember that 4*8 is 32. tell 'em what multiplication is and then play games with them, games which involves using of multiplication. this way kids will learn how to use multiplication. no need to remember any tables. or let 'em build a simple robot and program it to do some funny things. it's exciting and they will learn many things about mechanics, electricity, programming... let 'em play a role of factory manager, for example, and they will develop a good understanding of how economics works. and so on. We agree that practical application is a better way to motivate learning than absorbing theory from a book first, at least for most students. But some kids are just not going to enjoy those multiplication games or robot building and I'd say it's better for them to choose something else to pursue, rather than forcing them to pick up multiplication when it's a completely useless skill, now that everybody carries around a calculator with them in their phone these days. Yet, civilization is made up of people like you, who would all miss those mechanical systems far more than computers. it's a huge difference between i miss my washing machine and all our communication and data processing systems are foobared. Yet, I bet you they'll want that washing machine working far more than the internet. most people can't see a whole picture. it's bad. we must teach kids to understand how different things are interconnected too. At this point, _I_ can't see your whole picture. :) I made a simple point, that building and fixing washing machines or software is something most people don't want to do. Saying they should learn those things anyway doesn't make sense. Isn't that what people use Excel macros for? aren't writing excel macros a programming? My understanding is that you can write simple mathematical formulas, which is as far as most probably go, even though it may also allow iteration and other programming constructs. My point, that I made below, is that people who need some of the power of programming without the training can use cruder tools like these most of the time. There are specialized tools for the job, that are more limited than full programming languages but easier to use for the average person. i never meant that all people should learn full programming languages. they have to know how to write algorithms, but not necessary what pointer is or what is the difference between manual memory management and garbage collecting. yet if i'll show 'em simple recursive fibonacci function, they must be able to understand it. hey, it's
Assignment to enumerated string, is content copied or array information?
enum Values: string{
NONE = ,
Value1 = Apple,
Value2 = Peach,
Value3 = Lemon
}
Values lastHeldValue = Value3;
Is the lastHeldValue just pointer + length information, and it
points to Lemon; or is Lemon copied to another place in
memory?
I am doing comparison as if( lastHeldValue == Value3 ) and am
not
sure what comparison operation it is doing in the background.
DDoc module description?
Although perhaps unnecessary, I added DDoc documentation to my module for a short description of the body. This showed up in the place I wanted it to be in when I built the html documentation, so I was pretty happy. (below the module name and before any module members) I then went to override the DDOC macro to set it up with the correct formatting with the rest of the site I'll be putting the documentation on. The single line documentation I had written for the module apparently does not reside in BODY, and with the new formatting, it just casts it to the bottom of the page. It now resides below the footer. Is there anything I can do to correct this? If not then I'll just say screw it and not bother, but I thought it looked pretty nice. Especially for modules that have more than one class in them.
Re: Assignment to enumerated string, is content copied or array information?
On Saturday, 18 October 2014 at 23:51:53 UTC, tcak wrote:
enum Values: string{
NONE = ,
Value1 = Apple,
Value2 = Peach,
Value3 = Lemon
}
Values lastHeldValue = Value3;
Is the lastHeldValue just pointer + length information, and
it
points to Lemon; or is Lemon copied to another place in
memory?
I am doing comparison as if( lastHeldValue == Value3 ) and am
not
sure what comparison operation it is doing in the background.
The value will be copied and pasted where you use a Values.
However, strings are cached in D, so the following problem will
print true for both checks.
import std.stdio;
void main()
{
enum s = test;
auto v1 = s;
auto v2 = s;
//Check that both point to the same string in memory
writeln(v1 is v2);
//Check that both have the same value
writeln(v1 == v2);
}
Because enum values are copied and pasted, it is usually a bad
idea to make an enum that contains arrays or classes, as
everywhere you use the enum values allocates a new array/object.
With strings it's okay, as they're cached.
How to convert from ubyte[] to and from float?
What is the best way to convert from a part of a ubyte[] to a float? I've tried converting the ubyte[] into a uint, but neither casting the uint to a float nor to!float work. I suppose I could use a trick record union, but that seems inelegant. If I use pointers, the alignment may (unpredictably) not be proper (whatever that means these days).
Re: [OT] the uses of computing
On Sat, 18 Oct 2014 23:38:35 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: don't you think that we are going in circles now? not that i'm tired of this conversation, but i see that we get each other's POVs, and have no more arguments to convince each other. ;-) i respect your opinions but just don't agree with them. ;-) besides, it's increasingly hard for me to answer, 'cause my English writing skill is awful. i can understand you but can't clearly express myself. I don't read books anymore even technical ones? ;-) I think the only technical book I've read in the last decade is Andrei's TDPL, which I bought in print and got about halfway through. I've probably read bits and pieces of maybe five other non-technical books here and there in the same timespan, which were all given to me as gifts. I've never read an ebook, yet I read extensively online. Books are an outdated form, now that we have blogs. i believe that blog posts and textbooks compliments each other. i prefer textbook for learning new language, for example, and read blogs to learn some interesting/funny/hidden features. I don't know much about Oberon, but that gadgets UI sounds like it's still a GUI. sure, it's GUI, but with some consolish pieces dropped in. you can connect components and you can write some textual commands/scripts to modify component behavior. best from both worlds! ;-) I actually agree with you that some sort of component system like that is likely the future, even if it's only ultimately used to make developers' lives easier and largely unconfigured by users themselves it's simple enough for users to modify. changing layouts by dragging components, embedding components into components and so on. this things are mostly visual and easy. people love to customize their working environment if it's easy enough. ;-) though I haven't looked much into the complex historical reasons why it hasn't happened yet. 'cause so-called software industry is not ready to die yet. ;-) with proper component system there will be no much sense in selling applications. and selling components is much harder: how many people will buy e-mail data source component? it's not even visual! and selling e-mail reader is worthless, 'cause people will deconstruct it to basic parts and build their own application, and will not buy shiny new version with improved interface. they will not even buy the full package if they only need one part of it, like faster e-mail data source component. so the only way to keep software bussines (as we know it) running is turning component system back to non-component one. take, for example, COM technology (which is badly done, but still usable component system). how much software uses COM to decouple application in reusable parts? even microsoft realised that this will be disaster and turned COM to advancing scripting interface instead of truly component system. have you ever seen BlackBox Component Builder? it's written in Component Pascal, but the basic principles are language-independent. i'm dreaming about BCB with D as base language... No, never heard of it, sounds interesting. try it, it's fun and free! ;-) you'll see component programming system in action. it's not component OS, but it's great programming environment nevertheless. D is almost capable of powering such system. if only i had more free time and motivation... creating something BCB-like can be that killer app D needs. signature.asc Description: PGP signature
Re: How to convert from ubyte[] to and from float?
On 10/18/2014 06:06 PM, Charles Hixson via Digitalmars-d-learn wrote:
What is the best way to convert from a part of a ubyte[] to a float?
I've tried converting the ubyte[] into a uint, but neither casting the
uint to a float nor to!float work.
I suppose I could use a trick record union, but that seems inelegant.
If I use pointers, the alignment may (unpredictably) not be proper
(whatever that means these days).
This is what I understood:
import std.exception;
ubyte[float.sizeof] toBytes(float f)
{
ubyte* beg = cast(ubyte*)f;
return beg[0..f.sizeof];
}
float toFloat(const(ubyte)[] bytes)
{
enforce(bytes.length = float.sizeof);
return *cast(float*)bytes.ptr;
}
void main()
{
float f = 1.5;
auto bytes = toBytes(f);
float f2 = toFloat(bytes);
assert(f2 == f);
}
There are no alignment issues because f and ubyte[float.sizeof] are not
related. If you meant that ubyte[] should be a reference to an existing
float, then toBytes must take by 'ref float' and then it can return a
ubyte[]. However, it would be the responsibility of the caller to ensure
that the float would live long enough.
If that happened, then there would be no alignment issues because we
would have started with a float anyway and the ubyte[] would be
referring to that float in memory.
Ali
