Re: Merging one Array with Another
On Friday, 1 May 2015 at 22:47:17 UTC, Ali Çehreli wrote: It is about the uniqueness of consecutive elements. It says unique consecutive elements. Ali Ah. Then I guess that if input is SortedRange then SortedRange should be returned. Thanks.
Re: Reducing source code: weak+alias values in array
On Saturday, 2 May 2015 at 03:21:38 UTC, Jens Bauer wrote: For some reason, my build time has increased dramatically... Building with 1 vector takes 0.6 seconds. Building with 2 vector takes 0.7 seconds. Building with 4 vector takes 0.9 seconds. Building with 8 vector takes 1.1 seconds. Building with 16 vectors takes 1.7 seconds. Building with 32 vectors takes 3.4 seconds. Building with 64 vectors takes 12.4 seconds. Building with 112 vectors takes 55.5 seconds. Building with 113 vectors takes 56.7 seconds. Here's the source code for the file I'm building: http://pastebin.com/pCh9e7hQ
Re: DIP77 - Fix unsafe RC pass by 'ref'
Am Sat, 11 Apr 2015 20:42:52 + schrieb deadalnix deadal...@gmail.com: On Saturday, 11 April 2015 at 18:20:51 UTC, Marco Leise wrote: Am Fri, 10 Apr 2015 14:04:39 + schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com: On Friday, 10 April 2015 at 10:28:03 UTC, Walter Bright wrote: That's what ref counting is about. That would require pervasive ref-counting. You make is sound like there was an alternative to ref counting for resources. Is there? Ownership, GC. That doesn't convince me yet. GC is just incorrect to use here. D's GC like any other that is non-deterministic will hold on to many external resources for longer than is feasible. (Unique) ownership on the other hand isn't really what we are looking at here, right? I mean, the DIP talks about what happens when you are dealing with multiple references to the same item. That leaves us with RC, which I think is a good choice. -- Marco
[Issue 9614] Uninitialized holes in function stack frames confuses GC
https://issues.dlang.org/show_bug.cgi?id=9614
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #1 from ag0ae...@gmail.com ---
A complete test case:
import std.stdio;
size_t from_f, from_g;
void main ()
{
put();
f();
writefln(%#x, from_f); /* prints 0x */
writefln(%#x, from_g); /* prints 0x */
}
void put()
{
/* Put 0x where there will be a gap between f's stack frame and g's
stack frame. */
size_t[2] a;
a[0] = 0x;
}
void f()
{
size_t a;
from_f = *(a - 1); /* This reads put's 0x. This isn't so bad as we're
reading from beyond the live stack. */
g();
}
void g()
{
size_t a;
from_g = *(a + 3); /* Reads put's 0x again. This is bad, because we're
reading from the middle of the live stack. If the value were a GC
pointer, it would keep its allocation alive. */
}
Tested with dmd 2.067.1 on linux.
Problem doesn't show with -m32.
ldc doesn't seem to have the issue.
--
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Hardware|x86 |All OS|Windows |All --- Comment #21 from Walter Bright bugzi...@digitalmars.com --- The most practical solution is to simply disallow referencing variables from a dynamic closure that end sooner than the closing } of the function. This leaves it up to the user to decide how to handle it, such as passing the variable explicitly as an argument, declaring the variable at function scope, or copying the variable to another declared at function scope. --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 --- Comment #22 from Ketmar Dark ket...@ketmar.no-ip.org --- i.e. forbid closures at all. i wonder how should i pass additional parameter to std.alporithm.map predicate though. --
Re: Reducing source code: weak+alias values in array
On 04/27/15 19:49, Jens Bauer via Digitalmars-d-learn wrote:
I was wondering if there's a way to reduce my bulky startup
files a bit.
On Wednesday, 29 April 2015 at 13:58:14 UTC, Artur Skawina wrote:
mixin(VectorFuncs!(q{
PTR stack = {`_stack`};
EXC Reset_Handler = {`defaultResetHandler`};
EXC NMI_Handler;
EXC HardFault_Handler;
PAD pad01;
PAD pad02;
//...
}));
For some reason, my build time has increased dramatically...
Building with 1 vector takes 0.6 seconds.
Building with 2 vector takes 0.7 seconds.
Building with 4 vector takes 0.9 seconds.
Building with 8 vector takes 1.1 seconds.
Building with 16 vectors takes 1.7 seconds.
Building with 32 vectors takes 3.4 seconds.
Building with 64 vectors takes 12.4 seconds.
Building with 112 vectors takes 55.5 seconds.
Building with 113 vectors takes 56.7 seconds.
... Two foreach loops shouldn't take that long, right ?
The generated code appears to be correct, though.
Re: Merging one Array with Another
On 05/01/2015 06:39 PM, Per =?UTF-8?B?Tm9yZGzDtnci?=
per.nord...@gmail.com wrote: On Friday, 1 May 2015 at 22:47:17 UTC,
Ali Çehreli wrote:
It is about the uniqueness of consecutive elements. It says unique
consecutive elements.
Ali
Ah.
Then I guess that if input is SortedRange then SortedRange should be
returned.
Interesting idea. I have defined a simple algorithm below to see how it
could work (my skipped() function instead of uniq()).
import std.stdio;
import std.range;
import std.algorithm;
import std.exception;
struct Skipper(R)
{
R range;
this(R range)
{
enforce(range.length % 2 == 0,
This example requires even number of elements);
this.range = range;
}
@property bool empty() { return range.empty; }
@property auto front() { return range.front; }
void popFront()
{
range.popFront();
range.popFront();
}
}
auto skipped(R)(R range)
{
import std.traits;
static if (isInstanceOf!(SortedRange, R)) {
// Nice! Let's add an .assumeSorted at the end
return Skipper!R(range).assumeSorted;
} else {
return Skipper!R(range);
}
}
void use(R)(R range)
{
pragma(msg, R);
writeln(range);
writeln();
}
void main()
{
auto a = [ 1, 2, 3, 4, 5, 6 ];
use(a.skipped);
use(a.assumeSorted.skipped);
}
Prints at compile time:
Skipper!(int[])
SortedRange!(Skipper!(SortedRange!(int[], a b)), a b)
Prints at run time:
[1, 3, 5]
[1, 3, 5]
One issue is that many standard algorithms could benefit from this as
well. Should it be only for SortedRange? What about user defined
types... What if I wanted MyCoolRange to be appended automatically as
.myCoolRange. Could there we standard mechanism to support any range type?
Maybe the answer is a helper mixin that defines a template
specialization for SortedRange!(R2, Func) instead of my 'static if'
solution. (I was too impatient to get that syntax right. :) )
Ali
Re: Merging one Array with Another
fix: completeSort(x.assumeSorted, y); x = x.chain(y).uniq.array; or (was fixed) y = y.sort().uniq.array; completeSort(x.assumeSorted, y); x ~= y;
Re: Closure capture loop variables
On Friday, 1 May 2015 at 21:46:15 UTC, deadalnix wrote: No it does not. In JS, var declare a variable at function level, so that is why you see the behavior you see. Yes, I know, I said that a short while down in that post.
Re: Closure capture loop variables
On Fri, 01 May 2015 18:08:07 +, Adam D. Ruppe wrote: Javascript does D's current behavior, so I thought it was correct too, if js doing something, big chances are that it's wrong. Brendan failed his Scheme classes, especially those where he was taught about closures. signature.asc Description: PGP signature
Re: apache spark - not disk or network bound but CPU bound
On Friday, 1 May 2015 at 11:15:01 UTC, Laeeth Isharc wrote: http://radar.oreilly.com/2015/04/investigating-sparks-performance.html paper: http://www.eecs.berkeley.edu/~keo/publications/nsdi15-final147.pdf
Re: How to reuse functions
ERRATA CORRIGE: in place of x_s replace with x_n. Sorry
Re: How to reuse functions
On Friday, 1 May 2015 at 11:03:19 UTC, anonymous wrote:
If x_n is a constant (enum), you can use that to create a
function instead of a delegate:
void main() {
enum real x_n = 1;
real x_m = -1;
real function(real) s_n = z = F1(z, x_n);
auto J = jac(s_n, x_m);
}
If x_n is not constant, then the only way I see to make this
work, is to use a module variable:
real x_n;
void main() {
x_n = 1;
real x_m = -1;
real function(real) s_n = z = F1(z, x_n);
auto J = jac(s_n, x_m);
}
On Friday, 1 May 2015 at 06:48:46 UTC, John Colvin wrote:
A combination of std.functional.reverseArgs and
std.functional.partial might help. It's unfortunately we don't
have a version that can set an arbitrary argument, only the
first one; It would be an easy improvement to make.
Thank you both. I understood what you have shown to me.
About the chain 'reverseArg'+'partial' I reached to use it
partially, only the partial part; so it worked with exception of
reverseArg. I made several attempt to make it working but without
succes.
About the scope/declaration suggestion they worked, fine. I've
also made a change declaring x_s as static and worked as well
(without change of scope and without use of enum).
Unfortunatly I tried to exted the code by introducing array of
functions F1-[F1, F2, ...] and I saw such solution cannot apply.
That why because of built functions passed (as example) to lambda
function they do not store information. And I went back to
delegates that store the necessary data to create the correct
function. I've seen some method to pass from delegates to
function, but onestly I found a to complex approach and much more
a workaround that a good programming.
Going back to my study of D I will find the right way of thinking
to approch such problems (I imagine now the trick could be using
templates... I will see).
Thanks again. I've learned many things by looking at you solution.
What wrong?
Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based on DMD v2.066.1 and LLVM 3.5.0. $ ./z TUQLUE 42 11 Compiled by DMD v2.067.1 the program crashes: $ ./aa TUQLUE Segmentation fault What I'm doing wrong?
Re: D needs emplacement new
On Monday, 27 April 2015 at 13:12:51 UTC, anonymous wrote:
void main()
{
import std.stdio;
import core.memory: GC;
auto pointerInDisguise = new size_t;
*pointerInDisguise = cast(size_t) cast(void*) new Object;
/* Not sure why stomping is necessary, but without this,
the first
try below fails. */
Probably issue 9614 - Uninitialized holes in function stack
frames confuses GC - https://issues.dlang.org/show_bug.cgi?id=9614
static void stomp() {ubyte[1024] x;}
stomp();
GC.collect();
writeln(cast(size_t) cast(void*) new Object ==
*pointerInDisguise);
/* prints true = memory is reused */
GC.collect();
writeln(cast(size_t) cast(void*) new Object ==
*pointerInDisguise);
/* prints true = memory is reused */
}
Re: Calling functions using mixins
On Friday, 1 May 2015 at 21:50:51 UTC, anonymous wrote: What's that supposed to do? Excuse me, what is not said. I thought that my wish will be obvious. On Friday, 1 May 2015 at 21:59:31 UTC, Ali Çehreli wrote: On 05/01/2015 02:41 PM, Dennis Ritchie wrote: immutable string[] s = [ foo, bar ]; writeln(mixin(`format(%(%s, %), s)`));; If you are trying to call those functions, remove the double quotes by %-(, and use %| to specify what is a delimiter. To call, each needs a semicolon: mixin(format(%-(%s();%| %), s)); If you wanted to print the results of calling those functions, then, yes, use a comma. Also, I think you need to put writeln inside as well: mixin(format(writeln(%-(%s(), %));, s)); Ali Thanks. Yes, I wanted to print the results of calling these functions.
Re: Merging one Array with Another
On Friday, 1 May 2015 at 19:30:08 UTC, Ilya Yaroshenko wrote: Probably you need something like that: x = x.chain(y).sort.uniq.array; You're right: import std.stdio, std.algorithm, std.range; auto x = [11, 3, 2, 4, 5, 1]; auto y = [0, 3, 10, 2, 4, 5, 1]; writeln(x.chain(y).uniq); writeln(x.chain(y).sort.uniq); outputs [11, 3, 2, 4, 5, 1, 0, 3, 10, 2, 4, 5, 1] [0, 1, 2, 3, 4, 5, 10, 11] so why doesn't http://dlang.org/phobos/std_algorithm_iteration.html#.uniq say anything about need for sortness!? I expected D to be strict here and SortedRange as input to uniq.
Re: Reducing source code: weak+alias values in array
On Friday, 1 May 2015 at 21:36:29 UTC, Artur Skawina wrote:
On 05/01/15 22:29, Jens Bauer via Digitalmars-d-learn wrote:
On Wednesday, 29 April 2015 at 13:58:14 UTC, Artur Skawina
wrote:
Use `@weakalias!blah` instead:
enum weakalias(string A) = gcc.attribute.attribute(alias,
A);
@weakalias!defaultResetHandler extern (C) void
Reset_Handler();
Here's my resulting code-snippet:
enum weak = gcc.attribute.attribute(weak);
alias Tuple(A...) = A;
alias weakalias(string A) = Tuple!(weak,
gcc.attribute.attribute(alias, A));
...
foreach (I, M; A.init.tupleof)
{
static if (is(typeof(M)==A.EXC))
code ~= `@weakalias!`~M.n~` extern (C) void ` ~
__traits(identifier, A.tupleof[I]) ~ ();\n;
}
... because the 'alias' attribute does not automcatically include
the 'weak' attribute.
It seems to work, but did I write the code correctly ?
... Is it possible to generate a static array without
specifying a fixed array size ?
No, but you can just do:
code ~= \n@isr_vector VectorFunc[ ~
A.tupleof.length.stringof ~ ] g_pfnVectors = [\n;
That works great. Thank you for your valuable help. :)
Apart from the above two mentioned problems, the code builds
and produces the expected results. I even started to
understand some parts of it, and I find it pretty awesome. ;)
(Ab)using the compiler for the DSL parsing gets really awesome
{snip}
I remember the Atari 130XE (and thus the Atari 600XL/800XL) were
able to auto-generate basic-code, saving a lot of typing. Though
different, this really reminds me of those days. :)
I've never touched a C++ template, but I've been using #define in
C.
Though #define is a neat feature, it does not beat this, and as
I've never had enough reason to use C++ templates, I expect
they're not as powerful as D's ability to generate code at
compile-time.
Re: Closure capture loop variables
On Saturday, 2 May 2015 at 00:55:19 UTC, Adam D. Ruppe wrote: On Friday, 1 May 2015 at 21:46:15 UTC, deadalnix wrote: No it does not. In JS, var declare a variable at function level, so that is why you see the behavior you see. Yes, I know, I said that a short while down in that post. Saw that later :) The important point is that we are in violent agreement here.
Re: ARM Cortex-M Microcontroller startup files
On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote: * Is dynamic memory allocation a requirement of D, or a library feature? We should agree whether we are making only yet another C compiler or do we want the D compiler. The ability to use object oriented features was the reason I started with D. I think we do npot need full gc but I want to create objects at least at start. they will live trough the program so I have no need to delete then. I think it is possible to have the memory and object management things as set of files that may optionally compiled in or left out. There must be better and smaller malloc programs than the one I use now. I'm totally with you on this. I don't want a better C or a worse D. I hope that programming in D on these microcontrollers looks very much like the idomatic D in other domains. I want dyanamic memory allocation to be available for sure, but I don't want it to be a prerequisite like the garbage collector currently is. IMO it should be opt in. Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default). That looks small and tight, but should be written in D :-) Mike
Re: Building DMD on SmartOS
On Friday, 1 May 2015 at 20:58:57 UTC, Jens Bauer wrote: Would it work to first build GDC or LDC ? (I can build GDC on my PowerMac without having a D compiler already) If you can build either of those on a SmartOS host, why bother with dmd? I don't know if it would work, but I don't believe it's been tested, so probably not.
Re: Merging one Array with Another
On 05/01/2015 03:41 PM, Per =?UTF-8?B?Tm9yZGzDtnci?= per.nord...@gmail.com wrote: so why doesn't http://dlang.org/phobos/std_algorithm_iteration.html#.uniq say anything about need for sortness!? It is about the uniqueness of consecutive elements. It says unique consecutive elements. Ali
Re: Ada to D - an array for storing values of each of the six bits which are sufficient
Maybe someone will show a primitive packed array. I really can not imagine how to do it on D.
Re: Building DMD on SmartOS
The last version in c++ should build.
On May 1, 2015, at 3:58 PM, Jens Bauer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote:
I would like to use D on SmartOS.
SmartOS looks pretty interesting. [see docker.com] :)
{snip}
Unfortunately I get this error;
{snip}
On Thursday, 30 April 2015 at 17:54:00 UTC, Joakim wrote:
dmd git HEAD requires a host D compiler to build dmd
{snip}
Would it work to first build GDC or LDC ?
(I can build GDC on my PowerMac without having a D compiler already)
Re: ARM Cortex-M Microcontroller startup files
On Friday, 1 May 2015 at 07:15:58 UTC, Timo Sintonen wrote: I repeat here that there are several output devices in a board at the same time like serial port and lcd display. Printf can not be bound to one device at compile time. It is not hard to take the formatter out of printf and make it a separate interface that can be connected to different outputs. this way we do not need the libc dummies. I think this is more the D and object oriented way. A hook sounds too much C for me. You can use std.format to get printf-style formatting and then pass the string to where you want. Even better would be a CTFE formatter. There was discussion about this last year. Anybody knows the state? There are quite a few people who want a CTFE formatter, I believe, but that also has the issue of causing a lot of code bloat. Remember also that you *can* use std.format.format at compile time: enum str = This is a %s.format(test);
Re: ARM Cortex-M Microcontroller startup files
On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote: On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote: IMO it should be opt in. Agree. :) The problem I've seen with most C-solutions, is that once someone uses printf, the binary suddenly grows out of proportions. (It may be because the programmer included a line for debugging only, and that causes the otherwise 1K program to be huge and almost not fit the MCU). Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default). That looks small and tight, but should be written in D :-) It looks small and quite quick, but I think it would choke if allocating 256 blocks of 1 byte each and then freeing the first 255 of them. But I absolutely like the simplicity. I wrote a (much larger) MiniMalloc (also C), which can take any number of blocks and any size. The block address is guaranteed to be on a 4-byte boundary. Allocating a block of size 0 will always return the same address; this can never be freed. The good part is that you can use it with fairly small microcontrollers up to the entire 32-bit address range and no maximum number of blocks/maximum block size, so you can easily allocate a couple of buffers for your 24-bit TFT display. The drawback: If you make a 'buffer-overflow', eg write past your block's memory, you will corrupt the header of the next block, because I placed the header in front of each block. Thus my malloc/calloc/realloc/free is very old-fashioned, but it does join neighbouring blocks when they're released. I've stress-tested it for more than 24 hours, and even though it was fairly fragmented, there were no signs of other problems. It's been tested with 0xdeadbeef fills, 0x fills and unfilled. Is it possible to write the malloc so it's garbage collector-friendly ? -Eg. would certain algorithms be better than others; would a few 'accessor' or 'query' functions be helpful; would it be useful for the garbage collector to be able to store a couple of flags ?
Re: Interrogative: What's a good blog title?
The Crusade against Progress Scott Meyers' delight
Re: [Hackathon] ARM Cortex-M LCD Demo
On Fri, 01 May 2015 15:30:21 +, Mike wrote: I know, random rectangles on a screen is not all that remarkable, they ARE remarkable! signature.asc Description: PGP signature
Re: Quick Start with D: few examples and set of links.
Thank you for the patch for windows line endings!
On Friday, 1 May 2015 at 14:01:38 UTC, Anonymous wrote:
This is great, thank you.
I couldn't get the example in the introduction to work without
adding .map!(chomp) to the pipeline:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(chomp)
.map!(to!double)
.tee!((x){mean += x;})
.array;
Without that, I got an error converting to a double (my file
had '\r' after each number)
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote:
http://d.readthedocs.org
I hope this examples will be useful for students.
Ilya
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 14:01:38 UTC, Anonymous wrote:
This is great, thank you.
I couldn't get the example in the introduction to work without
adding .map!(chomp) to the pipeline:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(chomp)
.map!(to!double)
.tee!((x){mean += x;})
.array;
Without that, I got an error converting to a double (my file
had '\r' after each number)
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote:
http://d.readthedocs.org
I hope this examples will be useful for students.
Ilya
`parse` should works with whitespace after number:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(line = parse!double(line))
.tee!((x){mean += x;})
.array;
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Nice tutorial! Thanks! By the way, can i try to translation for korean? :)
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 15:11:37 UTC, xky wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Nice tutorial! Thanks! By the way, can i try to translation for korean? :) Iit would be great! See also: 1. Localisation with RST: http://docs.readthedocs.org/en/latest/localization.html 2. GitHub page: https://github.com/9il/thenextafterc/tree/master
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 15:25:28 UTC, Ali Çehreli wrote: On 05/01/2015 02:49 AM, Ilya Yaroshenko wrote: On Friday, 1 May 2015 at 08:45:35 UTC, Namespace wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Hellow Wolrd! Is this intended? Thanks! Fixed. Now it's time to fix the other typo there: Wolrd - World :) Ali OMG! This article is my work for english exams Thank you)
Re: if(arr) now a warning
On Fri, 01 May 2015 02:55:00 -0700, Walter Bright wrote: Imagine you find some cool D library, download it, and find it doesn't compile. How many of you are going to fix it? Or are you just going to chuck it to /dev/null? How many users have we lost because of this? zero. if that library is SO old, it is unmaintained anyway, so there will be no not only new features, but no bugfixes too. anyone wanting to use such library in new code is insane. This really blows. And things like that isnan = isNaN really has GOT TO STOP. sed -r 's/\bisnan\b/isNaN/' We need to be working on things that MATTER. language consistency IS matter. i wouldn't even try to explain newcomer what `if (arr)` really means, why it means that, and why in the name of hell he should care about `arr.ptr`, while in all other places it doesn't matter. and i can tell you how many users you lost due to THIS: at least ten. ten real users vs ??? imaginary users. What happens with every Reddit post about D? No matter the topic, it always becomes about D not being usable without the GC. why should anyone care about what is going on on reddit? ah, i know. it's 'cause Random Reddit Poster, who never wrote something bigger than hello, world in D is first-class citizen, and people who using D every day to write all kind of programs are second-class citizens. Why am I the only one working on that? maybe 'cause other people who can devote their time to this doesn't see random reddit mumbling as a serious motivation? I'm willing to break existing code for a large benefit. Not a small one. having consistent language is a large benefit. but it's not immediate one. signature.asc Description: PGP signature
Re: Quick Start with D: few examples and set of links.
Pipeline should be optimised (I am not sure about `tee`) by LDC,
GDC and probably DMD so all examples are generaly equal.
On Friday, 1 May 2015 at 15:15:14 UTC, Anonymous wrote:
Yes, that works. I also tried what John Colvin suggested
(.byLine(KeepTerminator.no, std.ascii.newline) and that works
too. Is it true that both of those are better than adding chomp
because it would be one less time through the pipeline?
Learned several new things today! Thanks again!
On Friday, 1 May 2015 at 15:03:33 UTC, Ilya Yaroshenko wrote:
On Friday, 1 May 2015 at 14:01:38 UTC, Anonymous wrote:
This is great, thank you.
I couldn't get the example in the introduction to work
without adding .map!(chomp) to the pipeline:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(chomp)
.map!(to!double)
.tee!((x){mean += x;})
.array;
Without that, I got an error converting to a double (my file
had '\r' after each number)
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote:
http://d.readthedocs.org
I hope this examples will be useful for students.
Ilya
`parse` should works with whitespace after number:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(line = parse!double(line))
.tee!((x){mean += x;})
.array;
Re: Quick Start with D: few examples and set of links.
Yes, that works. I also tried what John Colvin suggested
(.byLine(KeepTerminator.no, std.ascii.newline) and that works
too. Is it true that both of those are better than adding chomp
because it would be one less time through the pipeline?
Learned several new things today! Thanks again!
On Friday, 1 May 2015 at 15:03:33 UTC, Ilya Yaroshenko wrote:
On Friday, 1 May 2015 at 14:01:38 UTC, Anonymous wrote:
This is great, thank you.
I couldn't get the example in the introduction to work without
adding .map!(chomp) to the pipeline:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(chomp)
.map!(to!double)
.tee!((x){mean += x;})
.array;
Without that, I got an error converting to a double (my file
had '\r' after each number)
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote:
http://d.readthedocs.org
I hope this examples will be useful for students.
Ilya
`parse` should works with whitespace after number:
auto sample = File(10numbers.txt)
.byLine
.takeExactly(10)
.map!(line = parse!double(line))
.tee!((x){mean += x;})
.array;
[Hackathon] ARM Cortex-M LCD Demo
A simple demonstration using D to bare-metal program and ARM Cortex-M microcontroller. Full description with pictures and even a video can be found here: https://github.com/JinShil/stm32f42_discovery_demo/blob/master/README.md I know, random rectangles on a screen is not all that remarkable, but there's quite a bit of work that needs to be done before one can write their first pixel. * Minimal D runtime * Memory-mapped IO features * Clock and flash memory configuration * Software initialization (data and bss segments) * SPI driver to configure the external LCD controller * Internal parallel LCD controller configuration * Hardware random number generator EVERYTHING is in D. I've had this project on the back burner for a while, and the Hackathon gave me the excuse I needed to get it done. I didn't put a lot of effort into the code because I just wanted to get something working to prove some ideas I had, and show that D has some potential in this domain. I hope you find it interesting. Ask me anything. Mike
Re: Quick Start with D: few examples and set of links.
On 05/01/2015 02:49 AM, Ilya Yaroshenko wrote: On Friday, 1 May 2015 at 08:45:35 UTC, Namespace wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Hellow Wolrd! Is this intended? Thanks! Fixed. Now it's time to fix the other typo there: Wolrd - World :) Ali
Re: if(arr) now a warning
On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote: On Friday, 1 May 2015 at 02:16:01 UTC, deadalnix wrote: On Friday, 1 May 2015 at 01:12:08 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mhto1k$2dk0$1...@digitalmars.com... Nothing negates that. It's a judgment call. Please let's stop here. Thanks. -- Andrei Please stop trying to undo this improvement. Just fix your code and move on. Thanks. There is probably a better way to introduce the change, that would facilitate the transition but I agree with the feeling. std.alocator is probably one of the only piece of code where this behavior is justified. I guess my earlier post got buried? http://forum.dlang.org/post/ajrysqkjmlqjlmkip...@forum.dlang.org Nothing in there tells us how much of these are actually justified and how much are bugs.
Re: if(arr) now a warning
On Friday, 1 May 2015 at 06:02:15 UTC, deadalnix wrote: On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote: I guess my earlier post got buried? http://forum.dlang.org/post/ajrysqkjmlqjlmkip...@forum.dlang.org Nothing in there tells us how much of these are actually justified and how much are bugs. And that's your argument? Consider: 1. I make very heavy use of array-to-bool conversions in my code; 2. To the best of my memory, I've NEVER had a bug due to incorrect array-to-bool conversions. Honestly, pragmatically speaking, I think it would be easier for me to start maintaining my forked compiler than to fix all those warnings, plus the rather long tail of all the other D projects I've written over the years that I'm going to have to maintain sooner or later.
Re: if(arr) now a warning
On 4/30/15 6:12 PM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mhto1k$2dk0$1...@digitalmars.com... Nothing negates that. It's a judgment call. Please let's stop here. Thanks. -- Andrei Please stop trying to undo this improvement. Just fix your code and move on. Thanks. After we have discussed this matter extensively Walter and I decided to move forward and undo this language change. It's a judgment call. The advantages and disadvantages of this have been discussed extensively. We are accountable for decisions like this, and we must make the decisions we believe are right. That said, making a decision when there are strong feelings and opinions on both sides is always difficult. We would really like to find consensus, but failing that, request your indulgence. Please review: https://github.com/D-Programming-Language/dmd/pull/4623 Thanks, Andrei
Re: if(arr) now a warning
On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote: On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote: This one is quite straightforward. Dfix could probably handle it. I'd have to rewrite dfix on top of SDC to get this working. dfix can only work at the lexical and AST level at the moment. As soon as you need information like Is this a dynamic array? you need a compiler. I could try using DCD's suhmantick analisyss[1] code to try to get this to work, but it wouldn't work correctly in a lot of cases. [1] it's really dumb, but works well enough for an auto-complete engine How about parsing DMD's output (with -vcolumns)?
Re: if(arr) now a warning
On Friday, 1 May 2015 at 07:15:07 UTC, Vladimir Panteleev wrote: On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote: On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote: This one is quite straightforward. Dfix could probably handle it. I'd have to rewrite dfix on top of SDC to get this working. dfix can only work at the lexical and AST level at the moment. As soon as you need information like Is this a dynamic array? you need a compiler. I could try using DCD's suhmantick analisyss[1] code to try to get this to work, but it wouldn't work correctly in a lot of cases. [1] it's really dumb, but works well enough for an auto-complete engine How about parsing DMD's output (with -vcolumns)? Erm, never mind. I forgot this is all assuming the compiler change is going away.
Re: ARM Cortex-M Microcontroller startup files
On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote: On 04/30/2015 08:43 AM, Timo Sintonen wrote: Printf is a little tricky. It is actually a file operation to stdout and that is actually a syscall to kernel. No, you usually have to implement some hook for outputting yourself, e.g. putc or write, printf solely takes care of the formatting. I repeat here that there are several output devices in a board at the same time like serial port and lcd display. Printf can not be bound to one device at compile time. It is not hard to take the formatter out of printf and make it a separate interface that can be connected to different outputs. this way we do not need the libc dummies. I think this is more the D and object oriented way. A hook sounds too much C for me. Even better would be a CTFE formatter. There was discussion about this last year. Anybody knows the state?
Re: dub -vgc
On 2015-05-01 00:52:57 +, Laeeth Isharc said: Does dflags work ? http://code.dlang.org/package-format Hi, yes. Overlooked this one as d(ebug)flags. Thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: How to reuse functions
On Friday, 1 May 2015 at 03:34:53 UTC, Luigi wrote:
Hi everybody.
I am tring to use a function where its parameter is another
function, and at the same time are both already made - they
cannot be modified - and the second one has to be conditioned
before to be passed as argument.
Let's say I have these function and I cannot modify:
-jac(+d) that works on function and return real
real jac(real function(real) fun, real x) {return d(fun, x);}
real d(real function(real) fun, real x) {return fun(x);}
-F1 that works on two reals and return real
real F1(real a, real b) {return a + b;}
So I need a way to condition F1 fixing b and then pass it to
jac as argument.
To do that I've created a delegate 'simp' conditionig F1:
real delegate(real) simp(real function(real, real) f, real x) {
real _simp(real z) {
return f(z, x);
}
return _simp;
}
(here 'simp' fixes b at x).
My main is:
void main() {
real x_n = 1;
real x_m = -1;
real delegate(real) s_n = simp(F1, x_n);
//auto J = jac(s_n, x_m); //Error: function app.jac (real
function(real) fun, real x) is not callable using argument
types (real delegate(real), real)
}
the code fails because jac expect as argument a function but I
found only a delegate to obtain a simplified function without
any touch at already made functions jac, d and F1.
There is a clean way to make it possible? I mean: without to
touch (neither rewrite) jac, d and F1, obtain simplied F1 to
pass to jac.
Thaks in advance to anyone could help me.
Luigi
A combination of std.functional.reverseArgs and
std.functional.partial might help. It's unfortunately we don't
have a version that can set an arbitrary argument, only the first
one; It would be an easy improvement to make.
Re: ARM Cortex-M Microcontroller startup files
On Thursday, 30 April 2015 at 11:30:33 UTC, Mike wrote: Starting from zero appeals to my way of thinking. I've made several attempts at this both on the PC and for microcontrollers, so please allow me to offer my thoughts on the idea: While this may seem simple to achieve, I think it will raise a few questions that will need answering. * Can ModuleInfo be leveraged, without introducing overhead, to call module constructors and static constructors? They might be useful for hardware initialization. I think we should omit moduleinfo totally and so we can not have module constructors. I think pointers to static constructors are available in a certain section that I have not in my link script. Adding this section should make them available. * Is dynamic memory allocation a requirement of D, or a library feature? We should agree whether we are making only yet another C compiler or do we want the D compiler. The ability to use object oriented features was the reason I started with D. I think we do npot need full gc but I want to create objects at least at start. they will live trough the program so I have no need to delete then. I think it is possible to have the memory and object management things as set of files that may optionally compiled in or left out. There must be better and smaller malloc programs than the one I use now. * Does D need the C runtime, or can it init on its own? We should not depend on any libc. If we need anything from libc we must require/provide a multilib libc set that has been compiled with the correct compiler flags. * Should the C standard library bindings be part of the runtime, or exist as an external Deimos library? Either way they can still be used by the runtime, I'm just suggesting that they should be encapsulated. The bindings do not take space in the library but what are we doing with bindings if we do not have libc? I think it would be better to have a separate libc port project that contains the library and bindings. * What will be done about TypeInfo for now? It's causing me some serious code-bloat problems. See http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org I hope the compiler devs can tell us if it is possible to remove typeinfo totally and what language features we will lose then. * Is data and bss initialization part of the runtime, or delegated to toolchain, silicon, and BSP vendors? In C the data initialization is made before main. The copying is target independent but may depend on build environment, like what symbols the linker script provides. There is no general rule if any hardware specific init is needed at this point, before or after. One thing that has not been mentioned yet is that D is using TLS by default. Tdata and tbss can be combined to global data and bss. However, it is not hard to make śeparate sections for them and be prepared to multithreaded system.
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de --- My current idea is to abuse the Code Definition Window to show assembly instead. The assembly would be a file produced by compiling and dumping the file after saving it (or maybe after some new command invoked by a hotkey). The caret location inside the dump file would update according to a line number change in the editor. Short of source, at very least, there needs to be symbol names at the header of blocks of code. There are, but I'd like to avoid having to figure the actual mangled D symbol from the source (though feasable). Using debug line numbers seems better for navigating larger functions. Do the GNU tools make this easier? The objdump tools that come with GDC or LDC don't produce really helpful results (and don't work on OMF and MS-COFF). When compiling to assembly, GDC adds location information which could be used, LDC does not (I might be missing some command-line switch, though). DMD can't build to asm anyway, so dumping an object file will be necessary anyway. Maybe I can rip some code from cv2pdb, it can read line number information from executables with CV4 and DWARF debug information. I'll have to add CV8 support for Win64 though. --
[your code here] Rounding real numbers
A process for rounding numbers. This incarnation can be run like
round 1.23 3.4 4
or by reading lines from stdin. It could be simplified as an example by
getting rid of the argument-processing form. It shows off templated
function composition using std.functional.pipe, ct-regexes, and component
programming.
I wrote this after realizing that there wasn't a convenient UNIX utility
for doing this and use it regularly.
-
import std.algorithm,
std.conv,
std.functional,
std.math,
std.regex,
std.stdio;
// Transforms input into a real number, rounds it, then to a string
alias round = pipe!(to!real, lround, to!string);
// Matches numbers that look like they need rounding
static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`;
void main(string[] args)
{
// If arguments, process those and exit, otherwise wait around
// for input on stdin
if (args.length 1)
args[1..$].map!round.joiner( ).writeln;
else
// Replace anything that looks like a real number with the
// rounded equivalent.
stdin.byLine(KeepTerminator.yes)
.map!(l = l.replaceAll!(c = c.hit.round)(reFloatingPoint))
.copy(stdout.lockingTextWriter());
}
-
Re: [Hackathon] ARM Cortex-M LCD Demo
On Friday, 1 May 2015 at 15:37:09 UTC, ketmar wrote: On Fri, 01 May 2015 15:30:21 +, Mike wrote: I know, random rectangles on a screen is not all that remarkable, they ARE remarkable! I agree. This is fantastic work! I am so excited to see this.
Re: Destruction in D
On Friday, 1 May 2015 at 02:35:52 UTC, Idan Arye wrote: On Thursday, 30 April 2015 at 23:27:49 UTC, bitwise wrote: Well, the third thing was just my reasoning for asking in the first place. I need to be able to acquire/release shared resources reliably, like an OpenGL texture, for example. If you want to release resources, you are going to have to call some functions that do that for you, so you can't escape that special stack frame(what's so special about it?) - though the compiler might inline it. When you use a GC the compiler don't need to invoke the destructor in the end of the scope because the object is destroyed in the background, but that also means you can't rely on it to release your resources, so languages like Java and C# use try-with-resources and using statements(corresponding) to call something at the end of the scope and end up using that stack frame anyways. I'm not sure I understand you 100%, but my plan was to have an asset management system give out ref counted textures/etc. Whenever the last one went out of scope, the asset would be destroyed. This only works if the destructor is called on the graphics thread due to limitations of graphics APIs. In a single threaded C++ app, this is fine, destructors are called at end of scope. I was confused though, because like C#, D has both reference and value types. But, while in C#, value types still do not have destructors(grrr...) D structs do have destructors, which apparently run when the struct goes out of scope. However, the D port of my code will most likely use multithreaded rendering, which removes the guarantee that the assets will go out of scope on the graphics thread, so this idea is a no-go anyways.
Re: Merging one Array with Another
fix: completeSort(x.assumeSorted, y); x = x.chain(y).uniq.array; or completeSort(x.assumeSorted, y.uniq.array); x ~= y; On Friday, 1 May 2015 at 19:34:20 UTC, Ilya Yaroshenko wrote: If x is already sorted x = x.completeSort(y).uniq.array; On Friday, 1 May 2015 at 19:30:08 UTC, Ilya Yaroshenko wrote: Both variants are wrong because uniq needs sorted ranges. Probably you need something like that: x = x.chain(y).sort.uniq.array; On Friday, 1 May 2015 at 19:08:51 UTC, Per Nordlöw wrote: What's the fastest Phobos-way of doing either x ~= y; // append x = x.uniq; // remove duplicates or x = (x ~ y).uniq; // append and remove duplicates in one go provided that T[] x, y; ?
Re: Reducing source code: weak+alias values in array
On Wednesday, 29 April 2015 at 13:58:14 UTC, Artur Skawina wrote:
On 04/27/15 19:49, Jens Bauer via Digitalmars-d-learn wrote:
I was wondering if there's a way to reduce my bulky startup
files a bit.
{snip}
Just create a helper module, which the startup files can all
use to generate the data from a dsl. Eg
{snip}
I've experimented a little with the code, but ran into two minor
problems.
code ~= `@weakalias(`~M.n~`) extern (C) void ` ~
__traits(identifier, A.tupleof[I]) ~ ();\n;
The above part gives me some problems; I do not know how to
create the @weakalias.
I can make a @exc (which defaults to defaultExceptionVector) and
@rst (which defaults to defaultResetHandler), but I have not yet
succeeded in making a universal @weakalias.
alias Tuple(A...) = A;
alias rst = Tuple!(weak, gcc.attribute.attribute(alias,
defaultResetHandler));
alias exc = Tuple!(weak, gcc.attribute.attribute(alias,
defaultExceptionHandler));
... I tried messing with changing the above code, but no luck so
far:
code ~= `@weak @gcc.attribute.attribute(alias, `~M.n~`)
extern (C) void ` ~ __traits(identifier, A.tupleof[I]) ~ ();\n;
If I modify the above to ...
foreach (I, M; A.init.tupleof)
{
static if (is(typeof(M)==A.RST))
code ~= `@rst extern (C) void ` ~ __traits(identifier,
A.tupleof[I]) ~ ();\n;
static if (is(typeof(M)==A.EXC))
code ~= `@exc extern (C) void ` ~ __traits(identifier,
A.tupleof[I]) ~ ();\n;
}
... then it will build and produce the expected results. That
requires replacing the EXC for the ResetHandler by RST, I like
the original code much better, though. :)
I also had some trouble with the exception vectors not being
generated, and it turned out that my array was dynamic instead of
static.
For now, I've just made the array a constant size (100 elements);
eg. changed ...
code ~= \n@isr_vector VectorFunc[] g_pfnVectors = [\n;
... to ...
code ~= \n@isr_vector VectorFunc[100] g_pfnVectors = [\n;
... Is it possible to generate a static array without specifying
a fixed array size ?
Apart from the above two mentioned problems, the code builds and
produces the expected results. I even started to understand some
parts of it, and I find it pretty awesome. ;)
stdx.data.json - enhancement suggestions
On Wednesday, 29 April 2015 at 18:48:22 UTC, Laeeth Isharc wrote: Hi. What's the best way to pass the contents of a file to the stream parser without reading the whole thing into memory first? I get an error if using byLine because the kind of range this function returns is not what the stream parser is expecting. There is an optional filename argument to parseJSONStream, but I am not sure what this is for, since it still requires the first argument for the input if the filename is passed. Thanks. Laeeth. some more suggestions for enhancements here: https://github.com/s-ludwig/std_data_json/issues/12 a big advantage of languages like python is that there are end-to-end examples of using the language+libraries to accomplish real work. (they don't need to be more than a screenful of code, but for the newcomer having it all set out makes a big difference). since I believe a significant reason for people to switch to D will be a realisation that actually CPU time isn't free, it makes sense to be accommodating to people who previously used scripting types of languages for these jobs. Laeeth.
Re: stdx.data.json - enhancement suggestions
This line can be removed: .map!(ch = ch.idup) On Friday, 1 May 2015 at 20:02:46 UTC, Ilya Yaroshenko wrote: Current std.stdio is deprecated. This ad-hoc should works. auto json = File(fileName) .byChunk(1024 * 1024) //1 MB. Data cluster equals 1024 * 4 .map!(ch = ch.idup) .joiner .map!(b = cast(char)b) .parseJSON;
Re: stdx.data.json - enhancement suggestions
Current std.stdio is deprecated. This ad-hoc should works. auto json = File(fileName) .byChunk(1024 * 1024) //1 MB. Data cluster equals 1024 * 4 .map!(ch = ch.idup) .joiner .map!(b = cast(char)b) .parseJSON; On Friday, 1 May 2015 at 14:19:26 UTC, Laeeth Isharc wrote: On Wednesday, 29 April 2015 at 18:48:22 UTC, Laeeth Isharc wrote: Hi. What's the best way to pass the contents of a file to the stream parser without reading the whole thing into memory first? I get an error if using byLine because the kind of range this function returns is not what the stream parser is expecting. There is an optional filename argument to parseJSONStream, but I am not sure what this is for, since it still requires the first argument for the input if the filename is passed. Thanks. Laeeth. some more suggestions for enhancements here: https://github.com/s-ludwig/std_data_json/issues/12 a big advantage of languages like python is that there are end-to-end examples of using the language+libraries to accomplish real work. (they don't need to be more than a screenful of code, but for the newcomer having it all set out makes a big difference). since I believe a significant reason for people to switch to D will be a realisation that actually CPU time isn't free, it makes sense to be accommodating to people who previously used scripting types of languages for these jobs. Laeeth.
Re: Merging one Array with Another
Both variants are wrong because uniq needs sorted ranges. Probably you need something like that: x = x.chain(y).sort.uniq.array; On Friday, 1 May 2015 at 19:08:51 UTC, Per Nordlöw wrote: What's the fastest Phobos-way of doing either x ~= y; // append x = x.uniq; // remove duplicates or x = (x ~ y).uniq; // append and remove duplicates in one go provided that T[] x, y; ?
Re: Merging one Array with Another
If x is already sorted x = x.completeSort(y).uniq.array; On Friday, 1 May 2015 at 19:30:08 UTC, Ilya Yaroshenko wrote: Both variants are wrong because uniq needs sorted ranges. Probably you need something like that: x = x.chain(y).sort.uniq.array; On Friday, 1 May 2015 at 19:08:51 UTC, Per Nordlöw wrote: What's the fastest Phobos-way of doing either x ~= y; // append x = x.uniq; // remove duplicates or x = (x ~ y).uniq; // append and remove duplicates in one go provided that T[] x, y; ?
Re: if(arr) now a warning
On 5/1/2015 12:06 PM, deadalnix wrote: On Friday, 1 May 2015 at 18:45:54 UTC, Walter Bright wrote: On 5/1/2015 11:09 AM, deadalnix wrote: neither you nor walter provide a good sum up of your discussion. My last post here: https://github.com/D-Programming-Language/dmd/pull/2885 So, the plan is to make this a warning ? If so that sound like the right way forward. You must be looking at something else. What I said, and I quote: --- I'll try to summarize: 1.this should have been better specified to begin with 2.there are incorrect usages of if (arr) in the wild 3.there are correct usages of if (arr) in the wild The case if (arr) ...arr[0]... will produce a runtime error, so I am not terribly concerned that is a disastrous problem. What does greatly concern me is this change will break a LOT of long standing, correct D code. This is a long standing complaint about D, and has driven away a lot of users. There are also the users driven way because they download existing D code, and that code doesn't compile. They don't really care why it doesn't compile, just that it doesn't compile, and they don't look any further. Is if(arr) a problem big enough to merit taking this rather large risk? I'm skeptical. I suspect this kind of change and check would be appropriate for a D linter, and not be part of the core language. --
Re: if(arr) now a warning
On Friday, 1 May 2015 at 18:45:54 UTC, Walter Bright wrote: On 5/1/2015 11:09 AM, deadalnix wrote: neither you nor walter provide a good sum up of your discussion. My last post here: https://github.com/D-Programming-Language/dmd/pull/2885 So, the plan is to make this a warning ? If so that sound like the right way forward.
Merging one Array with Another
What's the fastest Phobos-way of doing either x ~= y; // append x = x.uniq; // remove duplicates or x = (x ~ y).uniq; // append and remove duplicates in one go provided that T[] x, y; ?
Re: if(arr) now a warning
On Friday, 1 May 2015 at 07:06:53 UTC, Andrei Alexandrescu wrote: On 4/30/15 6:12 PM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mhto1k$2dk0$1...@digitalmars.com... Nothing negates that. It's a judgment call. Please let's stop here. Thanks. -- Andrei Please stop trying to undo this improvement. Just fix your code and move on. Thanks. After we have discussed this matter extensively Walter and I decided to move forward and undo this language change. It's a judgment call. The advantages and disadvantages of this have been discussed extensively. We are accountable for decisions like this, and we must make the decisions we believe are right. That said, making a decision when there are strong feelings and opinions on both sides is always difficult. We would really like to find consensus, but failing that, request your indulgence. Please review: https://github.com/D-Programming-Language/dmd/pull/4623 Thanks, Andrei You say you want to find a consensus, but neither you nor walter provide a good sum up of your discussion. That makes it hard to express any good rebuttal or even be understanding of you position. People here have presented situations where they faced bugs due to the current behavior, and even Walter got it wrong in the doc in the past (which makes any point saying that the current behavior is desirable moot). Right now, the main reason expressed on your side is the breakage in std.allocator, which is known to be fairly different than your usual D code. It lets most people here with the feeling that breaking our code is no big deal (I have breakage in SDC with pretty much every release, usually for the better, sometime completely for nothing like when struct construction were not lvalues anymore) but breaking yours is. It has been presented in this thread how the current behavior lead to confusion (including, as already mentioned, from Walter himself) and how unit tests is likely to NOT catch it, because it create this kind of situation where things mostly works, but really do not. The only person here that has presented convincing evidence against the change is Vladimir, and that's be really interesting to dig into his report to know if all the reported uses are correct or if the change discovered some bug in his code. Possible less painful transition path also have been proposed, but none has been discussed. I sure have made the mistake myself several time and have to make people fix their PR because of incorrect use of slice to bool conversion on a regular basis, so I'd expect that this damn thing to be a positive change. It seems that the majority of people agree. Granted, it is not because most people think something that it makes it right, but that certainly is a good justification to at least provide detailed explanation of why the majority is wrong if it is the case.
Re: Closure capture loop variables
On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote:
Yes, they are.
I thought this until just a couple weeks ago when I was shown to
be pretty conclusively wrong. See the discussion here:
https://issues.dlang.org/show_bug.cgi?id=2043
When a new scope is introduced, a new variable is created. It
might happen to share memory as an optimization in the
implementation, but it is conceptually a whole new variable.
foreach(i; 0..10) {
int a; // new variable declared, it is set to 0 right now
assert(a == 0); // always passes
a = 5; // this isn't kept on the next iteration through
}
When you capture a variable from an inner scope, the optimization
of sharing memory with the same variable on a previous iteration
is no longer valid because the old variable now continues to
exist.
The correct behavior is analogous to:
{
auto a = new Object();
}
{
auto a = new Object();
}
There, the GC might collect the first a and reuse the memory for
the second a, but they are still different a's.
When you do a closure, you're doing:
Object capturedVariable, otherCapturedVariable;
{
auto a = new Object();
capturedVariable = a;
}
{
auto a = new Object();
otherCapturedVariable = a;
}
Note that this is exactly what happens now if you call the
function twice, but a scoped variable inside a loop is the same
idea.
If the GC collected the first a and reused its memory for the
second a, that'd be a bug - there's another reference to it in
capturedVariable, so the memory is not safe to reuse.
Javascript does D's current behavior, so I thought it was correct
too, but C# doesn't it that way. And thinking about it,
Javascript doesn't really do it that way either because it's
`var`s are hoisted up to function scope anyway - there's no such
thing as a variable whose lifetime is only inside a loop there.
(Note: the new `let` keyword in javascript is supposed to do
scoping... but has the same closure behavior as `var` in firefox.
However, looking at the docs, this seems to be a bug (perhaps in
my test, or perhaps in my oldish version of firefox. Take a look:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
Prior to the introduction of the let keyword in ECMAScript 6, a
common problem with closures occurred when they were created
inside a loop.
The let keyword, which adds lexical scoping rather than hoisted
to function scoping, is said to change this situation. D's
variables all work like `let` in JS. Therefore, we should do what
it does too, which is what C# also does.)
D closures capture variables by reference.
If this is the standard, D's implementation is still wrong. It
isn't capturing the inner variable by reference, it is capturing
the reused memory by reference. It is analogous to the GC
collecting and reusing memory that is still referenced in an
outer scope - a clear bug.
The D standard says The stack variables referenced by a nested
function are still valid even after the function exits (this is
different from D 1.0). , so arguably you could say it is doing
the right thing and capturing the stack, something I agreed with
again until just ten days ago.
See my change of mind here too in the edit:
http://stackoverflow.com/questions/29759419/closures-in-loops-capturing-by-reference/29760081#29760081
There, I say it is expected because a longstanding bug is
expected to work around but that doesn't make it *right*.
Re: Destruction in D
On Friday, 1 May 2015 at 17:45:02 UTC, bitwise wrote: On Friday, 1 May 2015 at 02:35:52 UTC, Idan Arye wrote: On Thursday, 30 April 2015 at 23:27:49 UTC, bitwise wrote: Well, the third thing was just my reasoning for asking in the first place. I need to be able to acquire/release shared resources reliably, like an OpenGL texture, for example. If you want to release resources, you are going to have to call some functions that do that for you, so you can't escape that special stack frame(what's so special about it?) - though the compiler might inline it. When you use a GC the compiler don't need to invoke the destructor in the end of the scope because the object is destroyed in the background, but that also means you can't rely on it to release your resources, so languages like Java and C# use try-with-resources and using statements(corresponding) to call something at the end of the scope and end up using that stack frame anyways. I'm not sure I understand you 100%, but my plan was to have an asset management system give out ref counted textures/etc. Whenever the last one went out of scope, the asset would be destroyed. This only works if the destructor is called on the graphics thread due to limitations of graphics APIs. In a single threaded C++ app, this is fine, destructors are called at end of scope. I was confused though, because like C#, D has both reference and value types. But, while in C#, value types still do not have destructors(grrr...) D structs do have destructors, which apparently run when the struct goes out of scope. However, the D port of my code will most likely use multithreaded rendering, which removes the guarantee that the assets will go out of scope on the graphics thread, so this idea is a no-go anyways. Structs allow you to implement ref-counting smart pointers like you can do in C++. There is an implementation in the standard library: http://dlang.org/phobos/std_typecons.html#.RefCounted But for something as structured and as heavy as gaming resources, I would go for a more manual approach like a repository-style architecture, where you manually tell the repository to load/release the the resources.
Re: if(arr) now a warning
On 5/1/2015 11:09 AM, deadalnix wrote: neither you nor walter provide a good sum up of your discussion. My last post here: https://github.com/D-Programming-Language/dmd/pull/2885
Re: Closure capture loop variables
On 5/1/2015 11:08 AM, Adam D. Ruppe wrote: There, I say it is expected because a longstanding bug is expected to work around but that doesn't make it *right*. I did agree in the bug report on that that it was a bug.
Re: if(arr) now a warning
On Friday, 1 May 2015 at 09:54:43 UTC, Walter Bright wrote: I've had the mispleasure several times of reaching back to update some older D code of mine, that works fine, and finding not only will it not compile, I have to re-architect parts of it. The situation was so bad I wound up creating: https://github.com/DigitalMars/undeaD and if *I* find this annoying, irritating, disheartening, etc., I can only imagine how others feel about it. Why is that a valid argument AGAINST the change, while the exact same argument was not valid the other way around. You were confused writing the doc in the first place, and if *You* find it confusing, you should be able to imagine how others feel about it. I'm sorry, but it is just backward rationalization. Imagine you find some cool D library, download it, and find it doesn't compile. How many of you are going to fix it? Or are you just going to chuck it to /dev/null? How many users have we lost because of this? This really blows. And things like that isnan = isNaN really has GOT TO STOP. Just today I found it broke some older piece of code I had that's perfectly correct. This breaks code without fixing anything. So, because of some stupid change have been made in the past, that mean that all change should be avoided ? That is once again bogus logic. We need to be working on things that MATTER. What happens with every Reddit post about D? No matter the topic, it always becomes about D not being usable without the GC. This change expose bugs. It does matter. isnan vs isNaN does not. It does not matter. This is not about isNan or about the GC, so there is no point in bringing these subjects into the conversation unless the goal is to make everything confusing and OT. A big piece of the fix for that is going through Phobos and fixing code that returns gc allocated arrays with algorithms that return ranges. True, but OT. Why am I the only one working on that? I don't remember anyone having a problem with isnan. Red herring. This is not about isnan, never was, never will be. You are the one trying to bring that up.
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 15:53:12 UTC, Ilya Yaroshenko wrote: Pipeline should be optimised (I am not sure about `tee`) by LDC, GDC and probably DMD so all examples are generaly equal. Yeah I wouldn't expect a big difference here. Even if things aren't well optimised, the various branches should be very predictable.
Re: Closure capture loop variables
On 4/30/2015 5:55 AM, Vladimir Panteleev wrote: I think Freddy's programs are working as designed. Yes, they are. D closures capture variables by reference. No, we're not changing that.
Re: Implicit conversion error
On Thursday, 30 April 2015 at 22:24:15 UTC, bearophile wrote: Paul: When compiled on a 64 bit machine, this line int r = uniform(0, mobs.length); .length returns a size_t, and 0 is an int. uniform() probably decides to unify those types to a size_t. A size_t is 32 bit on 32 bit machines and 64 bits on 64 bit machines. But D int is always a 32 bit signed integer. D allows implicit assignment of a 32 bit size_t to int but not a 64 bit size_t to an int. I agree that it's a bit of a mess. Bye, bearophile Thank you for the explanation, it makes perfect sense despite being a bit of a surprise. (I should have worked this out for myself but I haven't figured out how to use the documentation properly yet!). Paul
Re: if(arr) now a warning
On Fri, 01 May 2015 00:12:53 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 30 April 2015 at 23:12:18 UTC, Daniel Kozak wrote:
OK so, please revert this one:
https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae
WAT ?
and this one:
http://forum.dlang.org/thread/ibupwrwsgjvrjwabh...@forum.dlang.org
I'm not sure I get the details of that one, would you mind to sum
up the crux of the issue ?
struct S {
immutable A = 5;
int x;
}
int main() {
S s;
assert(s.sizeof == s.x.sizeof);
assert(s.sizeof == s.x.sizeof + s.A.sizeof);
return 0;
}
before 2.067:
core.exception.AssertError@test.d(12): Assertion failure
after 2.067:
core.exception.AssertError@test.d(11): Assertion failure
I do not want to change any of the issue above, I just do not understand why
some breaking changes are OK, and some other are not so ok.
Re: if(arr) now a warning
On Friday, May 01, 2015 08:51:10 Paolo Invernizzi via Digitalmars-d wrote: On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote: snip I just do not understand why some breaking changes are OK, and some other are not so ok. +1 but, again, I'm hopeless that W+A will understand the break-my-code spirit... Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). In light of that, I'm actually kind of surprised that he's agreed to some of the code breakage that we've done (e.g. making implicit falthrough in switch statements illegal). But to be fair, it's often hard to know when it's worth making a breaking change even if you're willing to make them in order to catch and prevent bugs or to clean-up a language featuer or whatever. And pretty much every time you make such a change, some folks will be very happy about, whereas others will be very _un_happy about it. So, to some extent, you just can't win. And when that's the case, it's frequently easier to just leave things as they are and avoid making breaking changes even if it might be better if they were made. - Jonathan M Davis
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Showing how easy interacting with python can be is a very good idea, and doing so by dealing with scientific data is an even better one!
Re: if(arr) now a warning
On 1 May 2015 at 12:03, Iain Buclaw ibuc...@gdcproject.org wrote: On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote: Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). It's not really as simple as that, and I think I understand W A's position here. It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D. I was in the break my code camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions. I would love a cleaner D language, if only it could be enforced just onto NEW code. pragma(old_code); Actually, one could even take inspiration from Perl's 'use VERSION' as a way tell the compiler to use the semantics/warnings of a previous release. But then it comes down to a feeling of some competing element between cleaner D language vs. cleaner D implementation. Iain.
Re: Factory pattern in D
On Friday, 1 May 2015 at 10:12:36 UTC, Chris wrote:
On Friday, 1 May 2015 at 10:04:46 UTC, Namespace wrote:
How about this:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
T factory(T)() {
return T();
}
void main()
{
auto a = factory!(A);
}
That's what I was looking for, I just couldn't get it right.
Thanks.
Rikki:
I wanted to avoid classes and interfaces.
This might be a bit more useful:
---
struct A {
int x = 42;
}
struct B {
int x = 7;
}
auto factory(string type = )() {
static if (type == A)
return A();
else static if (type == B)
return B();
else
return A(); // default
}
void main()
{
auto a = factory!A;
auto b = factory!B;
auto x = factory;
}
---
Re: ARM Cortex-M Microcontroller startup files
Am Fri, 01 May 2015 06:57:07 +
schrieb Timo Sintonen t.sinto...@luukku.com:
I think we should omit moduleinfo totally and so we can not have
module constructors. I think pointers to static constructors are
available in a certain section that I have not in my link script.
Adding this section should make them available.
C-like constructors. I've got some old code which allows attaching a
@attribute(cctor) to a extern(C) function to make it a C-constructor.
That code could be revived quickly if it's useful.
Outputting normal D module ctors as C-ctors is possible but 'hacky':
First, the calling convention doesn't match. In order to be compatible
C-constructors should stay extern(C). Now extern(D/C) are actually the
same for all GDC supported architectures, but still. There's also the
issue that it's a semantic change as you can no longer rely on cycle
detection.
TLDR: I'd prefer using @cctor extern(C) void foo() {} instead of normal
d module ctors.
Bonus points: You can have more than one @cctor per module.
Re: ARM Cortex-M Microcontroller startup files
On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
Most asserts on microcontrollers I've seen are just implemented
as while(1){}
-But one could probably also trigger the debugger (BKPT),
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then
version(ASSERT_BKPT) could be used to add a breakpoint before
that while(1){}. Thus --version=ASSERT_BKPT could be specified
on the command-line.
Would it be possible to 'extend' an existing assert; eg. the
user might want to be notified via the U(S)ART ?
In a desktop computer it is easy to return to the system. A
flying aeroplane can not stop its engines and wait the pilot to
reboot...
We do have the 'weak' attribute now. Just make a weak default
handler that stops. Then the application designer can override it
with whatever the application needs.
Re: ARM Cortex-M Microcontroller startup files
On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote: On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote: On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote: Thus I would expect the hook to be somewhere in vfprintf ? As Timo said, eventually, what printf needs is the `write` syscall. The C library needs to be ported to the hardware in question. That requires implementing all the syscalls the the C library needs: `write` for printf, `sbrk` for malloc, etc... (http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c) Sometimes the toolchain vendors provide this, sometimes the programmer has to do it. Uhm, in that case, why not supply a weakref dummy, eg. functions that can be overridden. Thus stat, open, fstat, lseek, read, write, isatty, close, link and unlink just do nothing at all. If the MCU has a file-system, then it can implement those as strong refs. Same about gettimeofday, getpid, execve, fork, kill - Often there's only a single thread and no possibility for loading and executing a named program. -So it should be fairly easy to change newlib 'requirements' to 'optional'. :) I feel like trying this out, perhaps when the new light comes. ;) Please do not make yet another c compiler. Make a D compiler. File system support can be an option that can be selected. A file in D is an object. Try to think object oriented way.
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Thanks. That's very good and exactly what we need for people to lose their fear of touching D.
Re: if(arr) now a warning
On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote: snip I just do not understand why some breaking changes are OK, and some other are not so ok. +1 but, again, I'm hopeless that W+A will understand the break-my-code spirit... /P
Re: if(arr) now a warning
On Friday, May 01, 2015 10:40:46 Daniel Kozak via Digitalmars-d wrote: I do not want to change any of the issue above, I just do not understand why some breaking changes are OK, and some other are not so ok. Well, fixing bugs often results in breaking changes. Sometimes, it's determined that something causes enough bugs that we make it illegal (e.g. implicit fallthrough in switch statements), and that would be a breaking change (though in principle, it finds and prevents enough bugs to be worth it). Sometimes, we're forced to make changes in the language to enable something we want or need to do or to make an existing feature work correctly, and that can result in breaking changes. Sometimes, we decide that a previous design decision was enough of a mistake to be worth changing even though it breaks code. There are a number of reasons for it. Ultimately, the question is whether the changes are worth the problems that the breakage causes (which often depends on how much code is likely to break and how critical it is that the change be made; e.g. fixing a bug is pretty much always going to be worth the breakage, whereas making a design change often wouldn't be). And whether the change is made tends to depend on who's involved in the decision. Some devs are more willing to make breaking changes than others, and it's not always clear whether something is really a bug or just an unfortunate result of other design decisions. Walter tends to reject most breaking changes, but he might consider something to be a bug that needs to be fixed whereas someone else thinks that it's legitimate behavior. And Walter doesn't review every pull request, so sometimes, breaking changes are made without his knowledge or consent. We make _far_ fewer breaking changes than we used to, and the bar has been raised considerably, but we do upon occasion make breaking changes when we think that it's worth it, and that's always going to be on a case-by-case basis. So, it's very hard to give a definitive answer as to what is and isn't an acceptable breaking change. It really depends on the change in question. In general, I think that most breaking changes occur due to regressions that aren't caught, in which case, they're bugs, not purposeful changes. And while we're doing better at catching and preventing regressions, we definitely don't get them all. We really need more folks trying out the betas with their projects and reporting any issues that they find in order to get anywhere near catching them all (and we'll probably never catch 100% of them, particularly if a regression affects only rare cases). So, frequently, code breakage is completely accidental. - Jonathan M Davis
Re: ARM Cortex-M Microcontroller startup files
On Friday, 1 May 2015 at 07:30:03 UTC, Timo Sintonen wrote:
On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
Most asserts on microcontrollers I've seen are just
implemented as while(1){}
-But one could probably also trigger the debugger (BKPT),
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then
version(ASSERT_BKPT) could be used to add a breakpoint before
that while(1){}. Thus --version=ASSERT_BKPT could be specified
on the command-line.
Would it be possible to 'extend' an existing assert; eg. the
user might want to be notified via the U(S)ART ?
In a desktop computer it is easy to return to the system. A
flying aeroplane can not stop its engines and wait the pilot to
reboot...
The 'assert' is intended for debugging, right ?
If not enabling --version=ASSERT_LOOP, --version=ASSERT_BKPT,
--version=ASSERT_RESET or any other version, then assert should
simply default to an empty funciton.
Personally, I never ever used assert myself. I always handle the
situation by making sure my data were in range; if they aren't, I
correct them.
We do have the 'weak' attribute now. Just make a weak default
handler that stops. Then the application designer can override
it with whatever the application needs.
Yes, of course. Why didn't I think of this ? :)
Re: if(arr) now a warning
On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote: Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). It's not really as simple as that, and I think I understand W A's position here. It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D. I was in the break my code camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions. I would love a cleaner D language, if only it could be enforced just onto NEW code.
Re: if(arr) now a warning
On 5/1/2015 2:28 AM, Vladimir Panteleev wrote: I was in the break my code camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions. I've had the mispleasure several times of reaching back to update some older D code of mine, that works fine, and finding not only will it not compile, I have to re-architect parts of it. The situation was so bad I wound up creating: https://github.com/DigitalMars/undeaD and if *I* find this annoying, irritating, disheartening, etc., I can only imagine how others feel about it. Sometimes the older code is complex, underdocumented, and I don't remember how it worked or how it needs to be re-architected. But it does work, it just doesn't compile anymore. Imagine you find some cool D library, download it, and find it doesn't compile. How many of you are going to fix it? Or are you just going to chuck it to /dev/null? How many users have we lost because of this? This really blows. And things like that isnan = isNaN really has GOT TO STOP. Just today I found it broke some older piece of code I had that's perfectly correct. We need to be working on things that MATTER. What happens with every Reddit post about D? No matter the topic, it always becomes about D not being usable without the GC. A big piece of the fix for that is going through Phobos and fixing code that returns gc allocated arrays with algorithms that return ranges. Why am I the only one working on that? I don't remember anyone having a problem with isnan. I'm willing to break existing code for a large benefit. Not a small one. And certainly not when the benefit is zero, like the isnan renaming. And I'm willing to break code that relied on bugs in the compiler.
Re: ARM Cortex-M Microcontroller startup files
On Friday, 1 May 2015 at 09:49:51 UTC, Jens Bauer wrote: A hacky open could return a pointer to an object, because the returned value is a 32-bit integer, which is the same size as a pointer and: ... would introduce a lot of dangling pointer errors instead of 'error: file not open'...
Re: if(arr) now a warning
On Friday, 1 May 2015 at 09:28:58 UTC, Vladimir Panteleev wrote: On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote: Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). It's not really as simple as that, and I think I understand W A's position here. It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D. I was in the break my code camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions. I would love a cleaner D language, if only it could be enforced just onto NEW code. Most of commercial code _is_ maintained, fix it for a change like this one is _trivial_. This apply to _every programming language_ : we are doing it right now, today, to upgrade a commercial library that we sell to a different visual studio edition. Hunting for bugs is wasted time. Explaining the pitfalls of the language is wasted time. Explaining the inconsistency of the language is wasted time. Reling on convenctions instead of being forced by a tool is wasted time. This comes from my experience, as the CTO of a company with a big D codebase: reddit turned out to be some sort of pestilence for D, IMHO... /P
Re: Factory pattern in D
On 1/05/2015 10:01 p.m., Chris wrote:
What would be the D equivalent of the factory pattern? This obviously
doesn't work:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
auto factory(string type) {
if (type == A)
return A();
else if (type == B)
return B();
else
return A(); // default
}
void main()
{
auto a = factory(A);
}
Error: mismatched function return type inference of B and A
(dmd 2.067.1)
Interfaces/classes not structs.
Quick Start with D: few examples and set of links.
http://d.readthedocs.org I hope this examples will be useful for students. Ilya
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #4 from Manu turkey...@gmail.com --- (In reply to Rainer Schuetze from comment #3) My current idea is to abuse the Code Definition Window to show assembly instead. The assembly would be a file produced by compiling and dumping the file after saving it (or maybe after some new command invoked by a hotkey). The caret location inside the dump file would update according to a line number change in the editor. This sounds like an awesome start! Short of source, at very least, there needs to be symbol names at the header of blocks of code. There are, but I'd like to avoid having to figure the actual mangled D symbol from the source (though feasable). Using debug line numbers seems better for navigating larger functions. Seems very reasonable, probably better. If the caret is able to follow the cursor in the editor window, then we'll have a really useful tool I think. Do the GNU tools make this easier? The objdump tools that come with GDC or LDC don't produce really helpful results (and don't work on OMF and MS-COFF). When compiling to assembly, GDC adds location information which could be used, LDC does not (I might be missing some command-line switch, though). DMD can't build to asm anyway, so dumping an object file will be necessary anyway. So... as I see it, with the DMD compiler landscape as it is, the most important compiler in this case is LDC. If you're doing performance work for Windows, I think it's fairly safe to say you're using LDC, since it's the only compiler that can link against other VS code, and produces high-performance output. While DMD output would ofcourse be useful, I'm not sure there's as much value analysing DMD output because it's a pretty average codegen anyway. I doubt many people would optimise for DMD? The real money is on analysing the output from LDC, since for optimised builds, I think that's the compiler that will typically be used for Windows codegen, no? Maybe I can rip some code from cv2pdb, it can read line number information from executables with CV4 and DWARF debug information. I'll have to add CV8 support for Win64 though. That sounds like a lot of work. I kinda hoped this would be a relatively simple feature with tools already available, the trouble being to integrate it into the VS UI/menu. But yeah, I think you can clearly see the problem space, and it sounds like you have some personal interest in this too, so I'll leave it to your good judgement from here. I'm super excited you're interested in this idea! :) Thanks again! --
Re: ARM Cortex-M Microcontroller startup files
On Friday, 1 May 2015 at 07:44:49 UTC, Timo Sintonen wrote:
On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
Thus I would expect the hook to be somewhere in vfprintf ?
Sometimes the toolchain vendors provide this, sometimes the
programmer has to do it.
Uhm, in that case, why not supply a weakref dummy, eg.
functions that can be overridden.
{snip}
-So it should be fairly easy to change newlib 'requirements'
to 'optional'. :)
I feel like trying this out, perhaps when the new light comes.
;)
Please do not make yet another c compiler. Make a D compiler.
File system support can be an option that can be selected. A
file in D is an object. Try to think object oriented way.
That would do nicely, but I was merely thinking about crippling
the library so it does 'nothing'.
If we were simply to supply 'fopen' instead of 'open', returning
an object would be fairly straightforward.
A hacky open could return a pointer to an object, because the
returned value is a 32-bit integer, which is the same size as a
pointer and:
If successful, open() returns a non-negative integer, termed
a file
descriptor. It returns -1 on failure, and sets errno to
indicate the error.
-That means though, that the RAM *must* be in the area 0x
... 0x7fff in order to satisfy the non-negative integer
statement.
But it's of course not pretty, and it would not be portable to
a 64-bit system, if open does not return a 64-bit integer on
those systems.
We could also keep returning a 'file number', then have a
function, which found the FILE* (which is an object) for this
'file number'. This would most likely limit the number of files
one can keep open simultaneously. The limit could be changed
during startup.
The problem with these two implementations is that I don't use
files in microcontrollers, so there will be cases where it's
insufficient. But being able to open more than 1000 files
simultaneously does not make much sense on a microcontroller,
which has 64K RAM or less.
If anyone has a better suggestion, I'm ears all over the place..
I mean I'm all ears. ;)
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:45:35 UTC, Namespace wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Hellow Wolrd! Is this intended? Thanks! Fixed.
Re: Factory pattern in D
On Friday, 1 May 2015 at 10:04:46 UTC, Namespace wrote:
How about this:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
T factory(T)() {
return T();
}
void main()
{
auto a = factory!(A);
}
That's what I was looking for, I just couldn't get it right.
Thanks.
Rikki:
I wanted to avoid classes and interfaces.
[Issue 3743] Forward reference problem with static if statements
https://issues.dlang.org/show_bug.cgi?id=3743 --- Comment #2 from Joakim db...@joakim.fea.st --- I think I ran into this issue when I tried to import core.sys.posix.sys.types.off_t in core.stdc.stdio, for use in the fpos_t definition on linux. Commenting out the static if block around off_t fixed the issue, so it's definitely related to static if somehow. --
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Hellow Wolrd! Is this intended?
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 09:14:19 UTC, cym13 wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Showing how easy interacting with python can be is a very good idea, and doing so by dealing with scientific data is an even better one! +1
Re: Factory pattern in D
How about this:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
T factory(T)() {
return T();
}
void main()
{
auto a = factory!(A);
}
Factory pattern in D
What would be the D equivalent of the factory pattern? This
obviously doesn't work:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
auto factory(string type) {
if (type == A)
return A();
else if (type == B)
return B();
else
return A(); // default
}
void main()
{
auto a = factory(A);
}
Error: mismatched function return type inference of B and A
(dmd 2.067.1)
Re: if(arr) now a warning
On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote: Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). It's not really as simple as that, and I think I understand W A's position here. It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D. I was in the break my code camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions. I would love a cleaner D language, if only it could be enforced just onto NEW code. pragma(old_code);
Re: Factory pattern in D
On Friday, 1 May 2015 at 10:04:46 UTC, Namespace wrote:
How about this:
struct A {
int x = 42;
}
struct B {
int x = 7;
}
T factory(T)() {
return T();
}
void main()
{
auto a = factory!(A);
}
Of course, you can restrict the type to A or B, or both:
T factory(T)() if (is(T == A) || is(T == B)) {
return T();
}
