Re: Dgame revived
On Sunday, 15 March 2015 at 23:17:10 UTC, Joel wrote: On Sunday, 15 March 2015 at 22:51:17 UTC, Namespace wrote: On Sunday, 15 March 2015 at 22:30:06 UTC, Joel wrote: I've been getting these errors: I found two places that have 'package(Dgame):' - source\Dgame\Graphic\Color.d(30) and source\Dgame\Math\Rect.d(44), and if I remove them (comment them out), then only one error remains: Yeah, I've used a dmd 2.067 version. I will fix this tomorrow, so that Dgame is useable with dmd 2.066. Compiling using dmd... Error: cannot read file main.d FAIL .dub\build\main-debug-windows-x86-dmd_2066-7A96EE8F0A68A2410292AA6D54ADEF4C \ dgame-example executable Error executing command run: dmd failed with exit code 1. That error should be fixed now. I still get this error. Or am I using the wrong zip file? Keep up the good work! Thanks! Currently you should use the Master branch until I fixed the package thing.
Re: Dgame revived
I think a tutorial on how to do tile map with sprites would be awesome http://dgame-dev.de/?page=tutorialtut=tilemap
Passing variadic arguments to C
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
Re: Passing variadic arguments to C
On Sunday, 22 February 2015 at 17:20:23 UTC, Foo wrote:
On Sunday, 22 February 2015 at 17:15:06 UTC, anonymous wrote:
On Sunday, 22 February 2015 at 17:09:27 UTC, Foo wrote:
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
yes
I get the error, that I cannot pass a dynamic array to a C
function.
My fault, the reason was that Args contains strings. ;)
Re: Passing variadic arguments to C
On Sunday, 22 February 2015 at 17:15:06 UTC, anonymous wrote:
On Sunday, 22 February 2015 at 17:09:27 UTC, Foo wrote:
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
yes
I get the error, that I cannot pass a dynamic array to a C
function.
Re: const member function
On Saturday, 21 February 2015 at 06:38:18 UTC, rumbu wrote:
Often I'm using the following code pattern:
class S
{
private SomeType cache;
public SomeType SomeProp() @property
{
if (cache is null)
cache = SomeExpensiveOperation();
return cache;
}
}
Is there any way to mark SomeProp() as const? Because I want to
call somewhere const(S).SomeProp, which for the outside world
is must be const, returning just a value, even that internaly
it modifies the internal S structure.
AFAIK it is unsafe and not recommended, but this works for me:
import std.stdio;
class Foo {
void say(string s) const {
writeln(s);
}
}
class Bar {
Foo f;
const(Foo) getFoo() const {
if (!f)
cast() this.f = new Foo();
return f;
}
}
void main() {
Bar b = new Bar();
const Foo f = b.getFoo();
f.say(Hello);
}
Re: const member function
On Saturday, 21 February 2015 at 15:26:28 UTC, ketmar wrote: On Sat, 21 Feb 2015 08:27:13 +, rumbu wrote: My question was not how I do this, I know already. My question was if there is another way to safely call a non-const instance function on a const object. is there a way to been safely hit by a truck? In a tank. ;)
Re: What is the Correct way to Malloc in @nogc section?
On Saturday, 21 February 2015 at 14:39:47 UTC, anonymous wrote: On Saturday, 21 February 2015 at 13:41:41 UTC, Foo wrote: Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct? Nice. I think you fixed everything I had pointed out. Yeah, I hope so too. Sorry for my annoyed behaviour, that wasn't my week and you where the the straw to break the camel's back. ;) I hope I have the phrase translated correctly. :D
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote: On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote: This is something I've done recently. Would be glad if my code will help you: https://github.com/Dgame/m3 Especially the m3.d module could be useful for you. /* Class and Struct */ emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted. /* Array */ make: You can't assume zero-initialization. T.sizeof is not the size of an element. reserve: Not safe (you're freeing the old memory), must not be @trusted. append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`. destruct: Not safe, must not be @trusted. Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct?
Re: GC has a barbaric destroyng model, I think
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote: And since today it is @safe wherever possible. Well, you marked functions @trusted rather indiscriminately :) Such approach doesn't really improve safety, and the code could work as well being @system. It's not like @system is inherently broken or something like that. Since with @safemarked functions are checked by the compiler it is advisable to mark functions with @safe. And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. Of course I'm rather new to D, so I could be wrong. But since my other comrades aren't willing to use D, this code will rot on Github if nobody else will use it.
Re: GC has a barbaric destroyng model, I think
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote: On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote: And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. What did you check them for? :) Just first example: make and destruct, being marked as @trusted, don't prevent caller from UAF and double free vulnerabilities, and compiler can't help with that by checking the caller. Other functions marked as trusted have similar problems. If the the caller can't be automatically checked for safety and must ensure safety manually, it means the callee is @system. That seems to be a problem with trusted and safe :)
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote: On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote: This is something I've done recently. Would be glad if my code will help you: https://github.com/Dgame/m3 Especially the m3.d module could be useful for you. /* Class and Struct */ emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted. /* Array */ make: You can't assume zero-initialization. T.sizeof is not the size of an element. I'm aware of that. reserve: Not safe (you're freeing the old memory), must not be @trusted. append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`. destruct: Not safe, must not be @trusted. Ah, that is nice to know. I will fix this soon. Or would you help me out with an PR? Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote: On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote: Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone. As it is right now, I fear it may do more harm than good. Always the same in this newsgroup. You want to help as good as you can (even if it's not perfect) and all you get are subliminal messages... :) I'm regret that I tried to help, I will delete this repo as far as possible. :)
Re: This Week in D: Issue #4
On Thursday, 12 February 2015 at 10:06:43 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 11 February 2015 at 14:32:46 UTC, Adam D. Ruppe wrote: On Wednesday, 11 February 2015 at 11:21:46 UTC, Dominikus Dittes Scherkl wrote: Did I missed issue #5 ? No, I did; I was sick most of last week and decided to skip it, just going to bed instead on sunday night. Sorry, I didn't wanted to create any pressure. Of course health is more important. Gute Besserung! Always nice to see other german people here. :) Moin.
Re: What is the Correct way to Malloc in @nogc section?
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the
Correct way to do this is. In a few places online I've seen
code for custom _new and _delete functions similar to this:
[code]
T _new(T, Args...) (Args args) {
size_t objSize;
static if(is (ValType == class))
objSize = __traits(classInstanceSize, T);
else
objSize = T.sizeof;
void* tmp = core.stdc.stdlib.malloc(objSize);
if (!tmp) throw new Exception(Memory allocation failed);
void[] mem = tmp[0..objSize];
T obj = emplace!(T, Args)(mem, args);
return obj;
}
void _delete(T)(T obj) {
clear(obj);
core.stdc.stdlib.free(cast(void*)obj);
}
[/code]
The Exception obviously uses the GC, and would need to be
replaced with a printf or something; however, emplace doesn't
have a @nogc replacement that I know of. What I'd like to know,
from people much more knowledgeable about the ins and outs of
D, is what the Best or Correct way to allocate and
deallocate within @nogc sections?
PS: Tangentially related, what hashing algorithm does D use?
I've seen people suggest using typeid(object).toHash(object);
however, toHash isn't @nogc, so I need to write my own Hashing
function. For the sake of consistency and peace of mind, I'd
really like to match mine as closely to Ds internal one as
possible.
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3 And since today it is @safe wherever possible.
Re: Module for manual memory management
On Saturday, 7 February 2015 at 11:29:51 UTC, Jacob Carlborg wrote: On 2015-02-04 21:55, Walter Bright wrote: No need to reinvent this: https://github.com/D-Programming-Language/phobos/blob/master/std/file.d line 194 Just for the record, you can get a link to the exact line by clicking on the line number in the left margin and the copying the link from the address bar. The same I've said a page previously. Funny. :)
Re: Should we remove int[$] before 2.067?
Maybe someone should remove this from the Changelog? http://dlang.org/changelog.html#partial-type
Re: Module for manual memory management
On Thursday, 5 February 2015 at 07:53:34 UTC, Andrei Alexandrescu wrote: On 2/4/15 11:48 PM, Foo wrote: I would be glad if you or Walter could review the other parts as well. I'm very sure that your review will be very helpful and I'm convinced that the modules Array or Smart Pointer could be useful for phobos. Your code is a ways from being in reviewable form. It would be great if a member of the community could act as a mentor. -- Andrei Oh, I didn't thought that it is so bad. :D It works splendidly so far for us. Sorry, that I'm wasting your time. :)
Re: Module for manual memory management
For what it's worth, today I finished the current work. Now we will start working with it. If someone has critique, improvement suggestions or want to take some ideas, he is free to do so. To repeat myself: we rewrote some functionality which already existed in D, but were improvable. For example the existing emplace method is quite long, hard to understand / read and is not marked with @nogc. Since we want to avoid the GC wherever possible we had to rewrite it. I hope it's useful for someone else and that some of you guys take some ideas from it. https://github.com/Dgame/m3
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
maybe it get that
later. But what do you mean with it use more operations than
necessary? I
can't see it. But both points are helpful critique. Thanks a
lot! :)
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just use it and change the allocator bit.
It would be much easier for me, if some of you would add such a
allocator to it. :P
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we
will
start working with it. If someone has critique, improvement
suggestions
or want to take some ideas, he is free to do so.
To repeat myself: we rewrote some functionality which already
existed in
D, but were improvable. For example the existing emplace
method is quite
long, hard to understand / read and is not marked with @nogc.
Since we
want to avoid the GC wherever possible we had to rewrite it. I
hope it's
useful for someone else and that some of you guys take some
ideas from it.
https://github.com/Dgame/m3
Opened File.d at random:
@trusted
@nogc
char[] read(const string filename) nothrow {
import std.c.stdio : FILE, SEEK_END, SEEK_SET, fopen,
fclose, fseek, ftell, fread;
FILE* f = fopen(filename.ptr, READ_BINARY);
scope(exit) fclose(f);
fseek(f, 0, SEEK_END);
immutable size_t fsize = ftell(f);
fseek(f, 0, SEEK_SET);
char[] str = m3.m3.make!(char[])(fsize);
fread(str.ptr, fsize, 1, f);
return str;
}
Then stopped right there. This is nowhere near production
quality - there is no error checking whatsoever, does more
operations than necessary, won't work on special files etc.
etc. etc.
I applaud the intention but there is a lot more work to be done
on this before it's in reviewable form.
Andrei
Yes that is correct, currently there is no error checking, maybe
it get that later. But what do you mean with it use more
operations than necessary? I can't see it. But both points are
helpful critique. Thanks a lot! :)
As I said above, it's currently only for our work. But I
presented it here, so that some guys can get some inspiration or
can reuse our code. :)
Maybe, but really only maybe, I will get some work done, so that
it's is ready for phobos. But since such a review can take years,
I see no use to do that work. But if someone else has the will to
do that, reuse our code!
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
maybe it get that
later. But what do you mean with it use more operations than
necessary? I
can't see it. But both points are helpful critique. Thanks a
lot! :)
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just use it and change the allocator bit.
Yes, I've also looked at that. But I think my code is more
readable and easier to understand. But I will take a second look.
;)
BTW: You can redirect to the line by adding #194:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194
just click on the line number on the left.
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we
will
start working with it. If someone has critique, improvement
suggestions
or want to take some ideas, he is free to do so.
To repeat myself: we rewrote some functionality which already
existed in
D, but were improvable. For example the existing emplace
method is quite
long, hard to understand / read and is not marked with @nogc.
Since we
want to avoid the GC wherever possible we had to rewrite it. I
hope it's
useful for someone else and that some of you guys take some
ideas from it.
https://github.com/Dgame/m3
Opened File.d at random:
@trusted
@nogc
char[] read(const string filename) nothrow {
import std.c.stdio : FILE, SEEK_END, SEEK_SET, fopen,
fclose, fseek, ftell, fread;
FILE* f = fopen(filename.ptr, READ_BINARY);
scope(exit) fclose(f);
fseek(f, 0, SEEK_END);
immutable size_t fsize = ftell(f);
fseek(f, 0, SEEK_SET);
char[] str = m3.m3.make!(char[])(fsize);
fread(str.ptr, fsize, 1, f);
return str;
}
Then stopped right there. This is nowhere near production
quality - there is no error checking whatsoever, does more
operations than necessary, won't work on special files etc.
etc. etc.
I applaud the intention but there is a lot more work to be done
on this before it's in reviewable form.
Andrei
I would be glad if you or Walter could review the other parts as
well. I'm very sure that your review will be very helpful and I'm
convinced that the modules Array or Smart Pointer could be useful
for phobos.
Re: Want to read a whole file as utf-8
Since I'm now almost finished, I'm glad to show you my work: https://github.com/Dgame/m3 You're free to use it or to contribute to it.
Re: Improving reviewing and scrutiny
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei Alexandrescu wrote: I just stepped into a disaster zone in std.file and submitted https://issues.dlang.org/show_bug.cgi?id=14125. This reveals the merits of reviewing pull requests carefully, and the issues that can crop in when that doesn't happen. I appeal again to a broader participation to reviewing pull requests by the community, even folks who don't have commit rights yet. A good review counts a lot, and the lack thereof... well see above. Also I'd like to open discussion with the dlang brass to figure out ways on how to make sure this doesn't happen again in the future. Thanks, Andrei Did you take a deeper look after I grumbled about it? :P
Want to read a whole file as utf-8
How can I do that without any GC allocation? Nothing in std.file seems to be marked with @nogc I'm asking since it seems very complicated to do that with C++, maybe D is a better choice, then we would probably move our whole project from C++ to D.
Re: Want to read a whole file as utf-8
On Tuesday, 3 February 2015 at 19:56:37 UTC, FG wrote: On 2015-02-03 at 20:50, Tobias Pankrath wrote: Use std.utf.validate instead of decode. It will only allocate one exception if necessary. Looks to me like it uses decode internally... But Foo, do you have to use @nogc? It still looks like it's work in progress, and lack of it doesn't mean that the GC is actually involved in the function. It will probably take several months for the obvious nogc parts of the std lib to get annotated, and much longer to get rid of unnecessary use of the GC. So maybe the solution for now is to verify the source code of the function in question with ones own set of eyeballs and decide if it's good enough for use, ie. doesn't leak too much? Yes, we don't want to use a GC. We want determinsitic life times. I'm not the boss, but I support the idea. @Nordlöw Neither of them can be marked with @nogc. :/
Re: Want to read a whole file as utf-8
On Tuesday, 3 February 2015 at 19:44:49 UTC, FG wrote: On 2015-02-03 at 19:53, Foo wrote: How can I do that without any GC allocation? Nothing in std.file seems to be marked with @nogc I'm asking since it seems very complicated to do that with C++, maybe D is a better choice, then we would probably move our whole project from C++ to D. Looks like std.stdio isn't marked with @nogc all the way either. So for now the temporary solution would be to use std.c.stdio. Get the file size, malloc a buffer large enough for it[1], use std.c.stdio.read to fill it, assign it to a char[] slice and std.utf.decode to consume the text... Oh wait, decode isn't @nogc either. FFS, what now? [1] I assume the file is small, otherwise there would be an extra step involved where after nearing the end of the buffer you move the rest of the data to the front, read new data after it, and continue decoding. How would I use decoding for that? Isn't there a way to read the file as utf8 or event better, as unicode?
Re: Conway's game of life
On Sunday, 1 February 2015 at 21:00:07 UTC, gedaiu wrote: Hi, I implemented Conway's game of life in D. What do you think that I can improve to this program to take advantage of more D features? https://github.com/gedaiu/Game-Of-Life-D Thanks, Bogdan For each remove you create a new array. That is lavish. You should use a bool inside the struct Cell. If it's false, the cell is not displayed and is out of the game. My suggestion: don't use the D GC, it's crap. Try to circumvent the GC wherever possible. Therefore you should use the -vgc compiler flag and the @nogc attribute.
Re: Module for manual memory management
On Saturday, 31 January 2015 at 01:07:21 UTC, Andrei Alexandrescu wrote: On 1/30/15 3:49 PM, Foo wrote: Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounted, Scoped, emplace and so on, but I'm not a big fan of some implementations (in my opinion not much of it follows the KISS principle). Also, as far as I remember, RefCounted and Unique are somewhat outdated. As said I'm just curious and I'm aware that my code may be somewhat un-phobos like. My current stand is this: http://dpaste.dzfl.pl/f1423322b7d5 Just to make it clear: m3 = manual memory management = mmm = m3 and here is some test code: http://dpaste.dzfl.pl/026013fbe19f I repeat: I know that I reimplement some logic like emplace and that my version is shorter but maybe not quite correct/incomplete. So why come with your own self-admitted incomplete/incorrect alternatives instead of adding/improving the standard ones? If something's there that shouldn't, remove it. I don't get this I didn't get it so I'll redo it incompletely. And I'm also aware of std.allocator and so on, but that is something different IMO. Agreed. Andrei And I did not literally said 'incorrect'. I said _maybe_ incomplete. In my tests it works properly. What I meant with 'not quite correct' was that it isn't well tested _yet_. But that can be done later.
Re: Module for manual memory management
On Saturday, 31 January 2015 at 01:07:21 UTC, Andrei Alexandrescu wrote: On 1/30/15 3:49 PM, Foo wrote: Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounted, Scoped, emplace and so on, but I'm not a big fan of some implementations (in my opinion not much of it follows the KISS principle). Also, as far as I remember, RefCounted and Unique are somewhat outdated. As said I'm just curious and I'm aware that my code may be somewhat un-phobos like. My current stand is this: http://dpaste.dzfl.pl/f1423322b7d5 Just to make it clear: m3 = manual memory management = mmm = m3 and here is some test code: http://dpaste.dzfl.pl/026013fbe19f I repeat: I know that I reimplement some logic like emplace and that my version is shorter but maybe not quite correct/incomplete. So why come with your own self-admitted incomplete/incorrect alternatives instead of adding/improving the standard ones? If something's there that shouldn't, remove it. I don't get this I didn't get it so I'll redo it incompletely. Too much and too long code. ;) Sometimes it is better to see a new version from scratch to rethink old ones. ;) I'm not for removing them, I'm for rebuilding them. And a new version can bring new wind into the sails. That's why I'm presented my code here: for discussion. But that is not that important, my main target was the implementation of Unique and Shared. You can adapt them with minimal effort. But I'm quite sure that my 'make' function is not yet present in phobos. So, what do you think about discussing if and how my make, Unique and Shared could improve phobos. And I'm also aware of std.allocator and so on, but that is something different IMO. Agreed. Andrei
Re: Should we remove int[$] before 2.067?
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally)
specify the
element type.
Actually, I'm having trouble implementing staticArray like
that, perhaps there are compiler issues causing problems. Using
this:
T[len] staticArray(T, size_t len)(T[len] items)
{
return items;
}
you would need to call it: staticArray([a, b, c]). UFCS doesn't
seem to work, and I can't get the immutable or function array
example to compile either (with the extra [brackets])...
That is such a ugly call. Consider this:
@nogc
@safe
T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
return values;
}
void main() {
pragma(msg, typeof([1, 2, 3].s));
}
Something like staticArray([1, 2, 3]) is probably so ugly and way
to long so that nobody new would like it or use it. We should
consider the usability. int[$] looks nicer and is shorter. Nobody
want to type ugly and long names instead.
Let look at staticArray([1, 2, 3]) as a new user: I have to call
a function with an array(whereby it is unclear to the new user if
[1, 2, 3] is placed on the heap or not) and the result of this
call is a static array? Why? Is it worth it? Should I use
something cumbersome?
That is why I'm either for the language feature or for something
short like '[1, 2, 3].s'
And no, nobody want to write 'alias s = staticArray' every time
again. Don't come with this counter please.
Re: Should we remove int[$] before 2.067?
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
On 1/30/15 10:40 AM, Foo wrote:
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven
wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally)
specify the
element type.
Actually, I'm having trouble implementing staticArray like
that,
perhaps there are compiler issues causing problems. Using
this:
T[len] staticArray(T, size_t len)(T[len] items)
{
return items;
}
you would need to call it: staticArray([a, b, c]). UFCS
doesn't seem
to work, and I can't get the immutable or function array
example to
compile either (with the extra [brackets])...
That is such a ugly call. Consider this:
@nogc
@safe
T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
return values;
}
void main() {
pragma(msg, typeof([1, 2, 3].s));
}
Something like staticArray([1, 2, 3]) is probably so ugly and
way to
long so that nobody new would like it or use it. We should
consider the
usability. int[$] looks nicer and is shorter. Nobody want to
type ugly
and long names instead.
Let look at staticArray([1, 2, 3]) as a new user: I have to
call a
function with an array(whereby it is unclear to the new user
if [1, 2,
3] is placed on the heap or not) and the result of this call
is a static
array? Why? Is it worth it? Should I use something cumbersome?
That is why I'm either for the language feature or for
something short
like '[1, 2, 3].s'
And no, nobody want to write 'alias s = staticArray' every
time again.
Don't come with this counter please.
The interesting thing is because of the tight overloading
rules, s will only match statically-sized arrays. So it's
okay to simply expose it as std.array.s without fear it might
clash with other uses of the s symbol. Awesome. -- Andrei
Exactly. ;)
Module for manual memory management
Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounted, Scoped, emplace and so on, but I'm not a big fan of some implementations (in my opinion not much of it follows the KISS principle). Also, as far as I remember, RefCounted and Unique are somewhat outdated. As said I'm just curious and I'm aware that my code may be somewhat un-phobos like. My current stand is this: http://dpaste.dzfl.pl/f1423322b7d5 Just to make it clear: m3 = manual memory management = mmm = m3 and here is some test code: http://dpaste.dzfl.pl/026013fbe19f I repeat: I know that I reimplement some logic like emplace and that my version is shorter but maybe not quite correct/incomplete. And I'm also aware of std.allocator and so on, but that is something different IMO.
Re: Arrays, garbage collection
On Friday, 30 January 2015 at 01:08:31 UTC, bearophile wrote:
The D type inference for array literals is now more flexible:
void main() {
auto[$][$] m1 = [[1, 2], [3, 4], [5, 6]];
pragma(msg, typeof(m1)); // int[2][3]
const auto[string] aa1 = [red: 1, blue: 2];
pragma(msg, typeof(aa1)); // const(int)[string]
}
It helps avoid bugs like:
int[5] a = [1,2,4,5];
void main() {}
And it makes the usage of value arrays (fixed size arrays) more
handy. We need to minimize the work that the garbage collector
has to do. Value arrays help in this. So making value arrays
more handy and natural to use is good (regardless how the
current Phobos hates them).
- - - - - - - - -
What's missing is a handy and compiler-efficient syntax to
create value array literals. Some persons have proposed the
[]s syntax:
void main() {
// Some imports here.
foo([[1, 2]s, [3, 4]]s);
auto t1 = tuple([1, 2]s, red);
auto aa1 = [key: [1, 2]s];
auto pairs = 10.iota.map!(i = [i, i + 10]s);
}
To do those same things without the []s syntax you have to
write longer code.
@nogc
@safe
T[n] s(T = Args[0], size_t n = Args.length, Args...)(auto ref
Args args) pure nothrow {
return [args];
}
@nogc
@safe
T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
return values;
}
void main() {
pragma(msg, typeof(s(1, 2, 3)));
pragma(msg, typeof([1, 2, 3].s));
}
Compilation output:
int[3]
int[3]
You only have to type a dot between the array and the 's'.
Because of pure and nothrow and the low cost of the function call
even such a lousy thing like the DMD optimizer should be capable
of inlining such a function every time.
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote: I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option. You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote: On 1/26/2015 12:45 PM, Jonathan Marler wrote: Just because they are function attributes does not mean they were tokenized as keywords. The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be. I feel like I keep repeating myself so I'm just going to copy/paste. If the grammar supported decorating a function with a list of id tokens (not just keywords), then you could implement a variation on the c++ solution of allowing override and final after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see nogc and safe as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the '@' character on function attributes like safe and nogc but they don't have to be added as keywords. Right. That's was what I meant. Same thing could be possible for body...
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote: On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote: On 1/26/2015 12:45 PM, Jonathan Marler wrote: Just because they are function attributes does not mean they were tokenized as keywords. The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be. I feel like I keep repeating myself so I'm just going to copy/paste. If the grammar supported decorating a function with a list of id tokens (not just keywords), then you could implement a variation on the c++ solution of allowing override and final after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see nogc and safe as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the '@' character on function attributes like safe and nogc but they don't have to be added as keywords. Right. That's was what I meant. Same thing could be possible for body... Ya same thing applies to body. I'm surprised no one has given a reason why it wasn't done this way. Because you/we are community members and therefore second-class citizens. If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more. Look what happend to auto ref for non templates: community wants it but we don't get it.
Re: Fastest Way of Accessing Entries in an AA
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote: On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote: how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-) Correction: I thought it would be nice if the compiler explained to me that key in aa ? aa[key] is a sub-optimal performance-wise. You know, that you kan reuse the result of the in operator by AAs? example: auto ptr = key in aa; ptr ? *ptr : ValueType.init
Re: D idioms list
I saw recently (at last in this thread:
http://forum.dlang.org/thread/tdfydchrairigdlgt...@forum.dlang.org#post-qakiogaqvmiwlneimhgu:40forum.dlang.org)
that many users use
key in aa ? aa[key] : ValueType.init;
instead of
auto ptr = key in aa;
ptr ? *ptr : ValueType.init;
which is more economic.
Maybe you can add it to your list:
import std.stdio;
void main() {
immutable string key = foo;
immutable string[string] arr = [key : bar];
if (auto ptr = key in arr)
writeln(*ptr);
}
Re: Fastest Way of Accessing Entries in an AA
On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 09, 2015 00:20:07 Foo via
Digitalmars-d-learn wrote:
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via
Digitalmars-d-learn wrote:
how can it? compiler doesn't know what the code is supposed
to
do. if
compilers will know such things someday, we can stop writing
programs
altogether, as compilers will be able to write any program
for
us. ;-)
Correction:
I thought it would be nice if the compiler explained to me
that
key in aa ? aa[key]
is a sub-optimal performance-wise.
You know, that you kan reuse the result of the in operator by
AAs?
example:
auto ptr = key in aa;
ptr ? *ptr : ValueType.init
This idiom is quite common:
if(auto ptrToValue = key in aa)
{
}
though I'm not sure that that quite fits in with what Nordlow
seems to be
trying to do with init. aa.get probably does a better job of
that, though
looking at the implementation for get, it's basically doing
what you're
suggesting:
auto p = key in aa;
return p ? *p : defaultValue;
though that has the downside of using a lazy parameter for the
default
value, which is convenient but doesn't do great things for
performance.
- Jonathan M Davis
I just wasn't sure that he knows about it.
Re: D idioms list
On Thursday, 8 January 2015 at 20:00:11 UTC, Foo wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? Struct inheritance with alias this You are using a class ;) And the public label is redundant.
VLA in Assembler
Hi,
Could someone explain me, if and how it is possible to allocate a
variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it know. ;)
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 10:59:09 UTC, bearophile wrote:
Foo:
Hi,
Could someone explain me, if and how it is possible to
allocate a variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it know.
;)
Doing it with alloca is simpler:
void main() @nogc {
import core.stdc.stdlib: alloca, exit;
alias T = int;
enum n = 42;
auto ptr = cast(T*)alloca(T.sizeof * n);
if (ptr == null)
exit(1); // Or throw a memory error.
auto arr = ptr[0 .. n];
}
Bye,
bearophile
Yes I know, but I really want it in inline assembly. It's for
learning purpose. :)
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 12:15:23 UTC, uri wrote:
On Wednesday, 17 December 2014 at 11:39:43 UTC, Foo wrote:
On Wednesday, 17 December 2014 at 10:59:09 UTC, bearophile
wrote:
Foo:
Hi,
Could someone explain me, if and how it is possible to
allocate a variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it
know. ;)
Doing it with alloca is simpler:
void main() @nogc {
import core.stdc.stdlib: alloca, exit;
alias T = int;
enum n = 42;
auto ptr = cast(T*)alloca(T.sizeof * n);
if (ptr == null)
exit(1); // Or throw a memory error.
auto arr = ptr[0 .. n];
}
Bye,
bearophile
Yes I know, but I really want it in inline assembly. It's for
learning purpose. :)
You could look at the disassembly.
And how? I'm on Windows.
Re: VLA in Assembler
And it is using malloc... ;)
I wanted something that increases the stack pointer ESP.
e.g.
void main()
{
int[] arr;
int n = 42;
writeln(arr.length);
writeln(arr.ptr);
asm {
mov EAX, n;
mov [arr + 8], ESP;
sub [ESP], EAX;
mov [arr + 0], EAX;
}
writeln(arr.length);
//writeln(arr[0]);
}
but that does not work...
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 16:10:40 UTC, Adam D. Ruppe
wrote:
On Wednesday, 17 December 2014 at 14:11:32 UTC, Foo wrote:
asm {
mov EAX, n;
mov [arr + 8], ESP;
sub [ESP], EAX;
mov [arr + 0], EAX;
}
but that does not work...
That wouldn't work even with malloc remember, an integer
more than one byte long, so your subtract is 1/4 the size it
needs to be! Also, since the stack grows downward, you're
storing the pointer to the end of the array instead of the
beginning of it.
NOTE: I've never actually done this before, so I'm figuring it
out as I go too. This might be buggy or otherwise mistaken at
points. (Personally, I prefer to use a static array sized to
the max thing I'll probably need that I slice instead of
alloca...)
Here's some code that runs successfully (in 32 bit!):
void vla(int n) {
int[] arr;
asm {
mov EAX, [n];
// the first word in an array is the length,
store that
mov [arr], EAX;
shl EAX, 2; // number of bytes == n * int.sizeof
sub ESP, EAX; // allocate the bytes
mov [arr + size_t.sizeof], ESP; // store the beginning of it
in the arr.ptr
}
import std.stdio;
writeln(arr.length);
writeln(arr.ptr);
// initialize the data...
foreach(i, ref a; arr)
a = i;
writeln(arr); // and print it back out
}
void main() {
vla(8);
}
This looks right but isn't, we changed the stack and didn't
put it back. That's usually a no-no. If we disassemble the
function, we can take a look at the end and see something scary:
8084ec6: e8 9d 6a 00 00 call 808b968
_D3std5stdio15__T7writelnTAiZ7writelnFAiZv // our final
writeln call
8084ecb: 5e popesi // uh oh
8084ecc: 5b popebx
8084ecd: c9 leave
8084ece: c3 ret
Before the call to leave, which puts the stack back how it was
at the beginning of the function - which saves us from a random
EIP being restored upon the ret instruction - the compiler put
in a few pop instructions.
main() will have different values in esi and ebx than it
expects! Running it in the debugger shows these values changed
too:
before
(gdb) info registers
[...]
ebx0xd4f4 -11020
[...]
esi0x80916e8134813416
after
ebx0x1 1
esi0x0 0
It popped the values of our array. According to the ABI: EBX,
ESI, EDI, EBP must be preserved across function calls.
http://dlang.org/abi.html
They are pushed for a reason - the compiler assumes they remain
the same.
In this little test program, nothing went wrong because no more
code was run after vla returned. But, if we were using, say a
struct, it'd probably fault when it tried to access `this`.
It'd probably mess up other local variables too. No good!
So, we'll need to store and restore the stack pointer... can we
use the stack's push and pop instructions? Nope, we're changing
the stack! Our own pop would grab the wrong data too.
We could save it in a local variable. How do we restore it
though? scope(exit) won't work, it won't happen at the right
time and will corrupt the stack even worse.
Gotta do it ourselves - which means we can't do the alloca even
as a single mixin, since it needs code added before any return
point too!
(There might be other, better ways to do this... and indeed,
there is, as we'll see later on. I peeked at the druntime
source code and it does it differently. Continue reading...)
Here's code that we can verify in the debugger leaves
everything how it should be and doesn't crash:
void vla(int n) {
int[] arr;
void* saved_esp;
asm {
mov EAX, [n];
mov [arr], EAX;
shl EAX, 2; // number of bytes == n * int.sizeof
// NEW LINE
mov [saved_esp], ESP; // save it for later
sub ESP, EAX;
mov [arr + size_t.sizeof], ESP;
}
import std.stdio;
writeln(arr.length);
writeln(arr.ptr);
foreach(i, ref a; arr)
a = i;
writeln(arr);
// NEW LINE
asm { mov ESP, [saved_esp]; } // restore it before we return
}
Note that this still isn't quite right - the allocated size
should be aligned too. It works for the simple case of 8 ints
since that's coincidentally aligned, but if we were doing like
3 bytes, it would mess things up. Gotta be rounded up to a
multiple of 4 or 16 on some systems.
hmm, I'm looking at the alloca source and there's a touch of a
guard page on Windows too. Check out the file:
dmd2/src/druntime/src/rt/alloca.d, it is written in mostly
inline asm.
Note the comment
Re: German D Community?
On Monday, 1 December 2014 at 09:38:35 UTC, trgy wrote: On Monday, 1 December 2014 at 09:22:47 UTC, Stefan Koch wrote: On Monday, 1 December 2014 at 09:17:42 UTC, trgy wrote: Hello, is there a german D community? I cannot find a forum/wiki or something else. I hope you can help me. :) Thanks in advance. Best regards trgy There is a german community. Most of them are here :) As far as I know there is no seperate forum or wiki. Thank you for this information. Would nobody of the german community prefer to have a forum/wiki in german? Best regards trgy I would like it. :)
Re: Scope and Ref and Borrowing
Remembers me a bit of http://wiki.dlang.org/DIP36
Re: RFC: moving forward with @nogc Phobos
On Tuesday, 30 September 2014 at 13:38:43 UTC, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of let the user pick, but I would use a
global variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceManagementPolicy.gc,
rc = ResourceManagementPolicy.rc,
mrc = ResourceManagementPolicy.mrc;
auto RMP = gc;
and in my code:
RMP = rc;
string str = foo; // compiler knows - ref counted
// ...
RMP = gc;
string str2 = bar; // normal behaviour restored
Of course each method/function in Phobos should use the global
RMP.
Re: RFC: moving forward with @nogc Phobos
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of let the user pick, but I would use a
global variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceManagementPolicy.gc,
rc = ResourceManagementPolicy.rc,
mrc = ResourceManagementPolicy.mrc;
auto RMP = gc;
and in my code:
RMP = rc;
string str = foo; // compiler knows - ref counted
// ...
RMP = gc;
string str2 = bar; // normal behaviour restored
Re: RFC: moving forward with @nogc Phobos
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei
Alexandrescu wrote:
On 9/30/14, 6:38 AM, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of let the user pick, but I would use a
global
variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceManagementPolicy.gc,
rc = ResourceManagementPolicy.rc,
mrc = ResourceManagementPolicy.mrc;
auto RMP = gc;
and in my code:
RMP = rc;
string str = foo; // compiler knows - ref counted
// ...
RMP = gc;
string str2 = bar; // normal behaviour restored
This won't work because the type of string is different for
RC vs. GC. -- Andrei
But it would work for phobos functions without template bloat.
Re: is there any reason UFCS can't be used with 'new'?
On Sunday, 28 September 2014 at 19:11:23 UTC, Jay wrote:
i want to chain 'new' with method calls on the created object.
i found this on the internet:
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF);
it would look much nicer with UFCS:
window.mainWidget = Button.new().text(Hello
worldd).textColor(0xFF);
well, it's not *exactly* UFCS but you get what i mean.
mixin template New(T) if (is(T == class)) {
static T New(Args...)(Args args) {
return new T(args);
}
}
class Bar {
string txt;
this() {
txt = Foo;
}
this(string t) {
txt = t;
}
mixin New!Bar;
}
void main() {
import std.stdio;
writeln(Bar.New().txt);
writeln(Bar.New(Bar).txt);
}
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
Consider: struct MyRefCounted void opInc(); void opDec(); int x; } MyRefCounted a; a.x = 42; MyRefCounted b = a; b.x = 43; What is a.x after this? Andrei a.x == 42 a.ref_count == 1 (1 for init, +1 for copy, -1 for destruction) b.x == 43 b.ref_count == 1 (only init)
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
On Saturday, 27 September 2014 at 19:11:08 UTC, Andrei Alexandrescu wrote: On 9/27/14, 1:11 AM, Foo wrote: Consider: struct MyRefCounted void opInc(); void opDec(); int x; } MyRefCounted a; a.x = 42; MyRefCounted b = a; b.x = 43; What is a.x after this? Andrei a.x == 42 a.ref_count == 1 (1 for init, +1 for copy, -1 for destruction) b.x == 43 b.ref_count == 1 (only init) So then when does the counter get ever incremented? -- Andrei increment: by postblit call decrement: by dtor call But if you ask me, we should either use a valid library solution like: http://dpaste.dzfl.pl/b146ac2e599a (it is only a draft of 10 min work) Or we should extend UDA's, so that: @rc(int) x; is rewritten to: Rc!int x;
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 18:38:57 UTC, Ali Çehreli wrote: On 09/18/2014 04:20 AM, IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome! This is the feature that I thought would never get implemented. :) Ali No, these are rvalue references. ;)
Re: Programming a Game in D? :D
On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: Hi, not too sure if there's still someone reading this post, but i do have another question. So, I heared so much good stuff about D, it's powerfull, fast the syntax is nice, but well, why is D actually not used for common games yet? (I mean I know about some smaller projects, but nothing big) Because D has a GC, is unstable and has many many bugs (even an ape could find some).
mixin assembler does not work?
Hey guys. Can someone explain me, why this code does only works
with the inline assembler version but not with the mixin?
Thanks in advance!
Code:
import std.stdio : writeln;
import std.conv : to;
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = asm { sub ESP, ~ c ~ ; mov ~ arr.stringof ~ ,
~ c ~ ; mov ~ arr.stringof ~ + 4, ESP; };
}
void main() {
ubyte[] a;
writeln(a.length);
static if (false) {
asm {
sub ESP, 1000; // Reserve 1000 bytes
mov a, 1000;// Set a.length = 1000
mov a + 4, ESP; // Set a[0] to reserved bytes
}
} else {
mixin Vala!(1000, a);
}
writeln(a.length);
}
Re: mixin assembler does not work?
For clarification: how would that work without mixin + string?
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:44:07 UTC, sigod wrote:
On Sunday, 20 July 2014 at 14:18:58 UTC, Foo wrote:
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = asm { sub ESP, ~ c ~ ; mov ~ arr.stringof ~
,
~ c ~ ; mov ~ arr.stringof ~ + 4, ESP; };
}
...
mixin Vala!(1000, a);
I'm not sure how to do it, but I see few mistakes in your code:
1. You declaring it as a string. (Or your intend to use
`mixin()`?)
2. You trying to use `template` as a [`mixin template`][0].
[0]: http://dlang.org/template-mixin
Yeah, it now works with mixin(Vala!(1000, a)); I thought that
both are the same.
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:46:32 UTC, bearophile wrote:
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %d; // Reserve 'count' bytes
mov %s, %d; // Set a.length = 'count'
mov %s + 4, ESP; // Set a[0] to reserved bytes
}, count, arr.stringof, count, arr.stringof);
I'd like to write that more like this:
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %%(count); // Reserve 'count'
bytes
mov %%(arr.stringof), %%(count); // Set a.length =
'count'
mov %%(arr.stringof) + 4, ESP; // Set a[0] to
reserved bytes
});
See:
http://fslang.uservoice.com/forums/245727-f-language/suggestions/6002107-steal-nice-println-syntax-from-swift
Bye,
bearophile
It seems that your code doesn't work with 2.065.
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:55:00 UTC, Foo wrote:
For clarification: how would that work without mixin + string?
I tried this:
mixin template Vala2(uint count, alias arr) {
asm {
sub ESP, count;
mov arr, count;
mov arr + 4, ESP;
}
}
but I get several errors. Unfortunately it seems that asm cannot
be used in mixin templates?!
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 15:54:15 UTC, bearophile wrote:
mixin template Vala2(uint count, alias arr) {
What about disallowing mixin templatename unless you add
mixin before the template keyword?
Bye,
bearophile
I do not understand?
