Re: Added --makedepend flag to rdmd
Thanks very much for this - I need it for the build tool I am working on. On 06/06/11 01:18, Andrei Alexandrescu wrote: I just added a --makedepend flag to rdmd: https://github.com/D-Programming-Language/tools/commit/451ffed8ff985465a52124f7671494ac1d3744b4 It instructs rdmd to simply print to stdout the name of the input file followed by a colon and then by the space-separated files that the input file depends on, directly or indirectly. Example: // file test1.d; import test2.d; // file test2.d; import test3.d, mylib.test4.d; With this setup, assuming test3.d and test4.d contain no further non-system imports, the command: rdmd --makedepend test1.d will print test1.d : ./test2.d ./mylib/test4.d ./test3.d This flag is intended to be useful to larger-scale build tools that need to store and track module interdependencies. In the simplest use case, directing the output of rdmd --makedepend (for each of a project's root files) to a file and then including that file in a makefile will ensure that dependencies are properly maintained. Cheers, Andrei -- Graham St Jack
Re: Discuss here the best article iPad2 contest
Am 06.06.2011 19:41, schrieb Steven Schveighoffer: > > Everyone did a great job. This was a tough one to decide. Yeah, all articles are really interesting and well written. > Nick, your article was too long for me, but I *loved* the dialog. It's pretty long, but written in style that kept me reading on. Cheers, - Daniel
Re: Removing undefined behavior of bitshifts
On Tue, 07 Jun 2011 02:20:17 +0300, Timon Gehr wrote: Currently, the behavior of a shift by more than the size in bytes of the operand is undefined. (Well, it's an 'error', but unchecked.) Also see http://d.puremagic.com/issues/show_bug.cgi?id=4887 -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Removing undefined behavior of bitshifts
On Tue, 07 Jun 2011 02:20:17 +0300, Timon Gehr wrote: I'd much prefer the behavior to be defined as 1<1<<(0x1f&x); (That's what D effectively does during runtime. It is also what the machine code supports, at least in x87). Can you think of any cases where this overflow behavior would be expected and useful? D can't (cheaply) catch runtime instance of this, but at compile-time it should definitely be an error. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Vote here for best article iPad2 contest
[5] Have Your Efficiency, and Flexibility Too by Nick Sabalausky
Re: Vote here for best article iPad2 contest
[2] Concurrency, Parallelism and D by David Simcha
Re: Vote here for best article iPad2 contest
[3] Getting more fiber in your diet by Robert Clipsham
Re: possible "solution" for ufcs
"Nick Sabalausky" wrote in message news:isjhv6$309k$1...@digitalmars.com... > > "Steven Schveighoffer" wrote in message > news:op.vwn4enw5eav7ka@localhost.localdomain... >> Someone wrote a very compelling argument for ufcs (uniform function call >> syntax) for ranges, and that is, given a slew of range functions, and a >> slew of ranges, it is nice to use a fluent programming syntax to specify >> wrappers for ranges without having to extend each range type. For >> example: >> >> take(10,stride(2,cycle([3,2,5,3]))); >> >> vs. >> >> [3,2,5,3].cycle().stride(2).take(10); >> >> And I thought damn it would be nice if ranges could implement ufcs, but >> other types that you didn't want to allow infinite extendability could >> avoid it. That gave me an idea :) >> >> > > I just hope it doesn't cause real ufcs to become an even lower priority > than it already is. > Sorry for the partial top-posting...
Re: gtkD program fails to run
"Mike Wey" wrote in message news:isjg1b$2qel$1...@digitalmars.com... > On 06/05/2011 11:37 PM, Mike James wrote: >> When I run the "hello world" program in the gtkD demos I get the >> following >> error message... >> >> The procedure entry point gdk_app_launch_context_get_type could not be >> located in the dynamic link library libgdk-win32-2.0-0.dll >> >> Does anybody know what I need to do to rectify the problem? >> >> I am using the latest gtkD download, gtk version 2.22 and D Compiler >> 2.053 >> to build it. >> >> Thanks, >> >> -=mike=- >> >> > > Are you using the gtk runtime linket from the GtkD dsource page ? > If so could you try the one from the gnome ftp: > ftp://ftp.gnome.org/Public/gnome/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32.zip > > -- > Mike Wey Thanks Mike, Yes I'm using that gtk version. The error message is mentioned on the dsource gtkD site but no solution was provided there. I'm looking round for a cross-platform GUI library - I'll guess I'll have to cross gtkD off the list :-/ -=mike=-
Removing undefined behavior of bitshifts
Currently, the behavior of a shift by more than the size in bytes of the operand is undefined. (Well, it's an 'error', but unchecked.) int x=32; x=1<
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 17:18:27 -0400, Timon Gehr wrote: Steven Schveighoffer wrote: Yes, but I also think if we can make UFCS optional, we give some power back to the author of the struct/class. He can choose not to participate in ufcs, and then he can control the API to his type. Plus, this can be a good interim step! It works right now! -Steve Just realized that actually it doesn't. It does not work across module boundaries... =/ :( Hm... this makes sense, the template is instantiated at the context level of the defining module, not the calling module. It can however work for something like std.range calling std.range or std.algorithm functions. Just not in the general sense. -Steve
Re: Discuss here the best article iPad2 contest
"Steven Schveighoffer" wrote in message news:op.vwn0r9ymeav7ka@localhost.localdomain... >I voted for David's article. It was a very close call for me between >Robert and David. Both articles were well written and covered very >similar topics, both of which I learned some new things from. > I'm still trying to narrow it down, they're all good! > Everyone did a great job. This was a tough one to decide. Nick, your > article was too long for me, Yea, understandable. When I realized how long it ended up, I figured that could work either for or against me ;) > but I *loved* the dialog. It reminded me tremendously of the very > successful (and one of my favorite) series Head First programming books > (mostly centered on Java), where they do things like interviews of > variable types. > Thanks. I haven't read any of the "Head First" series. But a long time ago I read a bunch of C/C++ books, and there was one in particular that really stuck out in my mind, that I never forgot. I don't remember the name of it, but it involved a robotic dog (pictured on the cover) and featured the "Profound Object Oriented Programming" method, ie "POOP". Probably 90% of the C/C++ books I've read I have no memory of whatsoever, but that one always stuck with me and has definitely influenced my style. Whether that's for the better or the worse, I can't really say ;) > TBH, I really expected more voter turnout. Maybe there will be a > last-minute rush. I'd been thinking the same thing, too. Although it looks like the rush may have just started...
Re: possible "solution" for ufcs
Steven Schveighoffer wrote: > On Mon, 06 Jun 2011 17:07:25 -0400, Lutger Blijdestijn > wrote: > >> Nice and clever! However, I don't think it's good as an alternative for >> ufcs >> in the language, unless that is going to be dropped because of too many >> ambiguities. > > I admit I'm not warm and fuzzy on arbitrarily extending interface. For > one, having functions in one place makes docs/members easy to look up. > i.e. I can look at one file and know all the operations for a datatype, > and I can look at a function call and know where to find it in the > documentation. I'm a firm believer that an object's author should be in > charge of the interface to his object. Hence my position on enforcing > strict @property syntax. I understand. What I find most attractive about ufcs is not really about extending interfaces, but making function composition saner to read. In some libraries such as jquery and linq it's very clean to compose operations, because they work well with chaining. Although it's not the same, something similar (and actually much better) could be achieved with ranges + ufcs. Ranges want to be composed, yet I find myself often introducing temporary variables to avoid a mess of nesting. Libraries with chaining are more pleasant, imho. I'll readily believe that the problems are significant though. Another issue may be function hijacking: when I call bar.foo() where foo is my extension, and the author of bar adds a foo method to it's type, the behavior silently changes. Your proposal does give some control over that. > However, ranges are really not in that league -- all operations on ranges > are pretty much external. Only the primitives live in the type. This is > something that is accepted and understood. The same thing with slices. > So it's natural to want to use ufcs there. To me, this would be a big improvement on the usability of ranges. Not saying ranges aren't usable, but this would make for much shorter and readable code. > BTW, we've had several people who think capacity should be in std.array, > but it is actually in core.object, this is due to the disjoint nature of > slice members -- they live everywhere. This will only get worse. > >> ufcs should imho be a decision on the caller side or the side of the >> function extending a datatype (like extension methods in C#), not the >> implementor of a datatype. It should ideally be available out of the >> box, to >> be used with any type. > > I am OK with ucfs being available everywhere, but the ambiguities are > difficult to work around. Especially for properties. > > My preference is that UFCS be supported only for builtin language types > (slices, fixed-size arrays, primitives) because there is no other option > for extension, and we should work on allowing author-sponsored > extendability in custom types. Type wrapping in general needs a lot more > support from the compiler and IFTI. > > The author can even explicitly only allow extendability of certain > function names, with the ability to use template constraints on > opDispatch. I just think it's an area we *already* need to work on, and > given this solution, it naturally allows better ufcs as you can wrap > functions better. > > -Steve
Re: possible "solution" for ufcs
--
---
Not sent from an iPhone.
"Steven Schveighoffer" wrote in message
news:op.vwn4enw5eav7ka@localhost.localdomain...
> Someone wrote a very compelling argument for ufcs (uniform function call
> syntax) for ranges, and that is, given a slew of range functions, and a
> slew of ranges, it is nice to use a fluent programming syntax to specify
> wrappers for ranges without having to extend each range type. For
> example:
>
> take(10,stride(2,cycle([3,2,5,3])));
>
> vs.
>
> [3,2,5,3].cycle().stride(2).take(10);
>
> And I thought damn it would be nice if ranges could implement ufcs, but
> other types that you didn't want to allow infinite extendability could
> avoid it. That gave me an idea :)
>
>
> import std.stdio;
>
> struct ufcs
> {
> auto opDispatch(string name, T...)(T args) // appropriate if compiles
> constraint here
> {
> mixin("return ." ~ name ~ "(this, args);");
> }
> }
>
> int foo(ufcs x, int y)
> {
> writefln("it works! %d", y);
> return y+1;
> }
>
> void main()
> {
> ufcs u;
> auto x = u.foo(1);
> assert(x == 2);
> }
>
> And it does indeed work (2.053)...
>
> So we can have ufcs without any changes to the compiler, and we also make
> it a *choice* for people who don't want to allow infinite extendability,
> and don't want to deal with possible compiler ambiguities.
>
> The opDispatch could even be a mixin itself (I think).
>
> What do you think?
>
I just hope it doesn't cause real ufcs to become an even lower priority than
it already is.
Re: Vote here for best article iPad2 contest
[5] Have Your Efficiency, and Flexibility Too by Nick Sabalausky -- Robert http://octarineparrot.com/
Re: TempAlloc review starts now
dsimcha wrote: > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article >> alignedMalloc: >> I seriously question having such a feature. According to my C++ book >> malloc returns a pointer "suitably aligned for any type". According to >> Microsoft, malloc is 16-byte aligned (of course, D doesn't use >> microsoft's >> runtime, DMC doesn't seem to identify alignment in malloc docs). GNU >> appears to guarantee 8-byte alignment on 32-bit systems, 16 on 64-bit >> systems (making this function mostly useless on 64-bit dmd). >> There are also some posix functions that align a malloc to a requested >> size (see memalign). > > I definitely need it in the implementation of TempAlloc, so it's gonna be > there but it can be made private if there's a consensus that it's not > needed in the public API. > >> At the very least, the function should identify what the alignment is if >> you *don't* use it. I'd like to see a good use case for this feature in >> an example, otherwise, I think it should be killed. > > The alignment if you don't use it depends on the C malloc function for > your > platform. A use case might be if you need 16-byte aligned arrays to use > SSE instructions, but that's hard to demonstrate in a short example. Maybe it would be more broadly useful if the alignment could be specified, turning it into a portable version of posix_memalign? http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_memalign.html It's not my domain and use cases may be niche, but it does fit the systems language aspect of D.
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 17:07:25 -0400, Lutger Blijdestijn wrote: Nice and clever! However, I don't think it's good as an alternative for ufcs in the language, unless that is going to be dropped because of too many ambiguities. I admit I'm not warm and fuzzy on arbitrarily extending interface. For one, having functions in one place makes docs/members easy to look up. i.e. I can look at one file and know all the operations for a datatype, and I can look at a function call and know where to find it in the documentation. I'm a firm believer that an object's author should be in charge of the interface to his object. Hence my position on enforcing strict @property syntax. However, ranges are really not in that league -- all operations on ranges are pretty much external. Only the primitives live in the type. This is something that is accepted and understood. The same thing with slices. So it's natural to want to use ufcs there. BTW, we've had several people who think capacity should be in std.array, but it is actually in core.object, this is due to the disjoint nature of slice members -- they live everywhere. This will only get worse. ufcs should imho be a decision on the caller side or the side of the function extending a datatype (like extension methods in C#), not the implementor of a datatype. It should ideally be available out of the box, to be used with any type. I am OK with ucfs being available everywhere, but the ambiguities are difficult to work around. Especially for properties. My preference is that UFCS be supported only for builtin language types (slices, fixed-size arrays, primitives) because there is no other option for extension, and we should work on allowing author-sponsored extendability in custom types. Type wrapping in general needs a lot more support from the compiler and IFTI. The author can even explicitly only allow extendability of certain function names, with the ability to use template constraints on opDispatch. I just think it's an area we *already* need to work on, and given this solution, it naturally allows better ufcs as you can wrap functions better. -Steve
Re: gtkD program fails to run
On 06/05/2011 11:37 PM, Mike James wrote: When I run the "hello world" program in the gtkD demos I get the following error message... The procedure entry point gdk_app_launch_context_get_type could not be located in the dynamic link library libgdk-win32-2.0-0.dll Does anybody know what I need to do to rectify the problem? I am using the latest gtkD download, gtk version 2.22 and D Compiler 2.053 to build it. Thanks, -=mike=- Are you using the gtk runtime linket from the GtkD dsource page ? If so could you try the one from the gnome ftp: ftp://ftp.gnome.org/Public/gnome/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32.zip -- Mike Wey
Re: possible "solution" for ufcs
Steven Schveighoffer wrote: > Yes, but I also think if we can make UFCS optional, we give some power > back to the author of the struct/class. He can choose not to participate > in ufcs, and then he can control the API to his type. > > Plus, this can be a good interim step! It works right now! > > -Steve Just realized that actually it doesn't. It does not work across module boundaries... =/ Timon
Re: possible "solution" for ufcs
Steven Schveighoffer wrote:
> Someone wrote a very compelling argument for ufcs (uniform function call
> syntax) for ranges, and that is, given a slew of range functions, and a
> slew of ranges, it is nice to use a fluent programming syntax to specify
> wrappers for ranges without having to extend each range type. For
> example:
>
> take(10,stride(2,cycle([3,2,5,3])));
>
> vs.
>
> [3,2,5,3].cycle().stride(2).take(10);
>
> And I thought damn it would be nice if ranges could implement ufcs, but
> other types that you didn't want to allow infinite extendability could
> avoid it. That gave me an idea :)
>
>
> import std.stdio;
>
> struct ufcs
> {
> auto opDispatch(string name, T...)(T args) // appropriate if compiles
> constraint here
> {
> mixin("return ." ~ name ~ "(this, args);");
> }
> }
>
> int foo(ufcs x, int y)
> {
> writefln("it works! %d", y);
> return y+1;
> }
>
> void main()
> {
> ufcs u;
> auto x = u.foo(1);
> assert(x == 2);
> }
>
> And it does indeed work (2.053)...
>
> So we can have ufcs without any changes to the compiler, and we also make
> it a *choice* for people who don't want to allow infinite extendability,
> and don't want to deal with possible compiler ambiguities.
>
> The opDispatch could even be a mixin itself (I think).
>
> What do you think?
>
> -Steve
Nice and clever! However, I don't think it's good as an alternative for ufcs
in the language, unless that is going to be dropped because of too many
ambiguities.
ufcs should imho be a decision on the caller side or the side of the
function extending a datatype (like extension methods in C#), not the
implementor of a datatype. It should ideally be available out of the box, to
be used with any type.
Re: possible "solution" for ufcs
Am 06.06.2011 21:38, schrieb Monkol:
On Mon, 06 Jun 2011 22:00:13 +0300, Steven Schveighoffer
wrote:
Someone wrote a very compelling argument for ufcs (uniform function
call syntax) for ranges, and that is, given a slew of range functions,
and a slew of ranges, it is nice to use a fluent programming syntax to
specify wrappers for ranges without having to extend each range type.
For example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs,
but other types that you didn't want to allow infinite extendability
could avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if compiles
constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
what this code must to do?
opDispatch is special template member a class or struct can have. When
using the dot-operator to acces members and these aren't there,
opDispatch!"memmbername" is tried.
Now when ou try to use uniform function call syntax (UFC) on a struct,
the function-as-method you want to use is not in the struct but in the
module-scope. The compiler therefore can't find any memeber and tries
opDispatch which itself tries to resolve to a module-scope function
using the leading dot. Through ct-string-operations and mixin the name
of the function gets injected into the code.
I hope I could help you.
Mafi
Re: TempAlloc review starts now
On 06/06/2011 20:10, dsimcha wrote: Seems there's a strong consensus that the "newVoid" name sucks. I agree in hindsight. Will change. If you made it a bit more generic, it could become uninitialized!(). // int a = void; auto a = uninitialized!int; // double[] a = newVoid!double(100); auto a = uninitialized!(double[])(100); // double[][] a = newVoid!(double[])(100, 100); auto a = uninitialized!(double[][])(100, 100); -- Robert http://octarineparrot.com/
Re: Vote here for best article iPad2 contest
[2] Concurrency, Parallelism and D by Dave Simcha -- Mike Wey
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 15:32:38 -0400, Michel Fortin
wrote:
On 2011-06-06 15:00:13 -0400, "Steven Schveighoffer"
said:
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler
ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
Clever. But how does it work for properties? Pure/safe/nothrow
functions? Ref and out parameters? Note that properties specifically are
already problem for the compiler-implemented array-member syntax.
I think properties can be done, but we can't do it by marking the function
@property (which would mean something different to the compiler).
Something like this might work:
struct ufcs
{
@property auto opDispatch(string s)() // TODO: appropriate constraint
{
mixin("return ."prop_" ~ s ~ "(this);");
}
@property auto opDispatch(string s, T)(T arg) // TODO: appropriate
constraint
{
mixin("return ."prop_" ~ s ~ "(this, arg);");
}
}
It's very sketchy, you need to appropriately name your global functions,
because naming them with @property doesn't really work. Custom
annotations could work well here.
As far as pure/safe/nothrow, I think templates need general work in this
area anyways. IFTI in particular is woefully inadequate for wrapping
functions.
I've proposed an enhancement to assist in this in some cases, perhaps it
can be tweaked to allow all sorts of "forwarding" behavior. Essentially,
I think you should be able to use another function to guide IFTI in
deciding what parameter types to use.
http://d.puremagic.com/issues/show_bug.cgi?id=4998
Bottom line: there's a lot of work to do to make UFCS work right. And
it'll require some language-level changes anyway if we want it to work
right.
Yes, but I also think if we can make UFCS optional, we give some power
back to the author of the struct/class. He can choose not to participate
in ufcs, and then he can control the API to his type.
Plus, this can be a good interim step! It works right now!
-Steve
Re: TempAlloc review starts now
Am 06.06.2011 21:40, schrieb Steven Schveighoffer: > On Mon, 06 Jun 2011 15:10:49 -0400, dsimcha wrote: >> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article >>> TempAlloc.malloc: >>> I don't like void * as a return value. Would it not be more appropriate >>> to use at least void[]? I'd suggest actually for malloc to take a >>> template parameter of the type to return, defaulting to void. i.e.: >>> T[] malloc(T = void)(size_t size); >> >> Here I'm going to have to strongly disagree. I want to keep >> TempAlloc.malloc >> consistent with GC.malloc and core.stdc.stdlib.malloc. > > I can understand that point of view. I just would like to avoid using > pointers where it's not necessary. And I especially like this: > > auto buf = TempAlloc.malloc!uint(1024); > > better than this: > > auto buf = (cast(uint *)TempAlloc.malloc(1024 * uint.sizeof))[0..1024]; > > I would actually argue that GC.malloc might be better off returning > void[]. You can always get the pointer with .ptr. > I agree. Why does GC.malloc return void* anyway? In D1 std.gc.malloc returns void[], so GC.mallocs behaviour seems like a step backwards to me. Cheers, - Daniel
Re: possible "solution" for ufcs
2011/6/6 KennyTM~ :
> Maybe better
>
> auto ref opDispatch(string name, T...)(auto ref T args) {
> mixin("return ." ~ name ~ "(this, args);");
> }
>
> so that ref-returns and ref-parameters can be handled as well. Doesn't work
> for 'lazy' though. It also cannot preserve 'pure'-ity, 'nothrow'-ness and
> '@safe'-ty of the original function.
>
>
As far as I understand, auto ref is supposed to mean "always ref, and
accept r-values". So we would need to allow tuples to contain ref
types and construct it from the target function.
Torarin
Re: possible "solution" for ufcs
KennyTM~ wrote:
>
> Maybe better
>
> auto ref opDispatch(string name, T...)(auto ref T args) {
> mixin("return ." ~ name ~ "(this, args);");
> }
>
> so that ref-returns and ref-parameters can be handled as well. Doesn't
> work for 'lazy' though. It also cannot preserve 'pure'-ity,
> 'nothrow'-ness and '@safe'-ty of the original function.
Yes, but this is an unresolved problem of the language in general. We can have
the
template mixin just mixin all 8 versions with different template constraints
until
that gets fixed (thats what will be done anyways, at least purity is reflected
in
the mangled name AFAIK). The most important feature needed to make it work
correctly, "auto ref" is already there.
Timon
Re: TempAlloc review starts now
On Mon, 06 Jun 2011 15:10:49 -0400, dsimcha wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article alignedMalloc: I seriously question having such a feature. According to my C++ book malloc returns a pointer "suitably aligned for any type". According to Microsoft, malloc is 16-byte aligned (of course, D doesn't use microsoft's runtime, DMC doesn't seem to identify alignment in malloc docs). GNU appears to guarantee 8-byte alignment on 32-bit systems, 16 on 64-bit systems (making this function mostly useless on 64-bit dmd). There are also some posix functions that align a malloc to a requested size (see memalign). I definitely need it in the implementation of TempAlloc, so it's gonna be there but it can be made private if there's a consensus that it's not needed in the public API. What about in the cases where malloc aligns to 16 bits (i.e. on 32-bit windows or 64-bit linux)? Does this not seem like a waste of 16 bytes? At the very least, the function should identify what the alignment is if you *don't* use it. I'd like to see a good use case for this feature in an example, otherwise, I think it should be killed. The alignment if you don't use it depends on the C malloc function for your platform. Which should be minimum 8 byte aligned (required by doubles). In my C++ book it says "suitably aligned for any type". I would say this is likely a requirement for any C compiler. Essentially, I would say that malloc on 32-bit systems must be at least 8-byte aligned, but could already be 16-byte aligned. A use case might be if you need 16-byte aligned arrays to use SSE instructions, but that's hard to demonstrate in a short example. It doesn't have to be complete, just something showing the allocation and the usage which requires 16-byte alignment. That being said, wrapping malloc might have some nice other features too. I like the auto-adding of the range to the GC. tempdup: 1. If this uses ElemType!(R)[] as the return type, duping a char[] will give you a dchar[]. I don't think this is very desirable. This seems right to me. tempdup() is supposed to be basically a TempAlloc version of array(). IMHO it should **ALWAYS** return a random-access range. Returning a narrow string creates an obscure special case where it doesn't. I expected it to be a TempAlloc version of .dup. IMO, it should return an array, which char[] is. Note that an array *is* random access, despite what std.range is telling you :) counter case: assert(is(typeof(str) == char[])); str = str.tempdup; // ensure allocation on the tempstack. Also, note that newStack!char(50) works and seems inconsistent with your choice for tempdup. 2. What happens for something like immutable(uint *)[]? Does it become uint *[]? Because that would be bad... No. It becomes an immutable(uint*)[]. ElementType!(immutable(uint*)[]) == immutable(uint*). I am looking at Unqual, which according to D's documentation, removes all qualifiers. But testing shows that this isn't the case. The documentation seems very sketchy on that trait, but it appears to be the most unqualified (!) implicitly converting type. So I guess my gripe is more with std.traits' documentation than your module. TempAlloc.malloc: I don't like void * as a return value. Would it not be more appropriate to use at least void[]? I'd suggest actually for malloc to take a template parameter of the type to return, defaulting to void. i.e.: T[] malloc(T = void)(size_t size); Here I'm going to have to strongly disagree. I want to keep TempAlloc.malloc consistent with GC.malloc and core.stdc.stdlib.malloc. I can understand that point of view. I just would like to avoid using pointers where it's not necessary. And I especially like this: auto buf = TempAlloc.malloc!uint(1024); better than this: auto buf = (cast(uint *)TempAlloc.malloc(1024 * uint.sizeof))[0..1024]; I would actually argue that GC.malloc might be better off returning void[]. You can always get the pointer with .ptr. I'll also point out that as a function that is not constrained by compiler requirements, we have more flexibility, such as using templates. I noticed that newStack does exactly what I'm saying, but then I question having two different functions that essentially do the same thing. Is there a reason other than consistency with GC.malloc? Perhaps TempAlloc.malloc should be private? That would solve the problem. I just thought of something else, there's newStack, but no freeStack. It seems odd to use newStack to allocate and then TempAlloc.free to deallocate. -Steve
Re: possible "solution" for ufcs
On Jun 7, 11 03:23, so wrote:
I think something is missing here.
It doesn't convert fun(int, ufcs) to ufcs.fun(int) as in the examples.
It converts fun(ufcs, int) to ufcs.fun(int).
We need is a solution to this:
fun(T)(arg1, ... ufcs!T, ... argN)
auto ref opDispatch(string name, T...)(auto ref T args) {
mixin("alias ." ~ name ~ " f;");
alias ParameterTypeTuple!f Params;
enum i = staticIndexOf!(Unqual!(typeof(this)),
staticMap!(Unqual, Params));
static assert(i >= 0);
return f(args[0 .. i], this, args[i .. $]);
}
(Doesn't work with overload set though.)
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 22:00:13 +0300, Steven Schveighoffer
wrote:
Someone wrote a very compelling argument for ufcs (uniform function call
syntax) for ranges, and that is, given a slew of range functions, and a
slew of ranges, it is nice to use a fluent programming syntax to specify
wrappers for ranges without having to extend each range type. For
example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs, but
other types that you didn't want to allow infinite extendability could
avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if
compiles constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
what this code must to do?
Re: TempAlloc review starts now
On 2011-06-06 14:47:25 -0400, "Steven Schveighoffer" said: Particularly, this looks odd: newVoid!double What the hell does that mean? :) I suggest a name like newUninit or newRaw or something that means more "uninitailized" than "no type". recycled!double Allocate from recycled memory (as opposed to new unspoiled memory). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 22:00:13 +0300, Steven Schveighoffer
wrote:
Someone wrote a very compelling argument for ufcs (uniform function call
syntax) for ranges, and that is, given a slew of range functions, and a
slew of ranges, it is nice to use a fluent programming syntax to specify
wrappers for ranges without having to extend each range type. For
example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs, but
other types that you didn't want to allow infinite extendability could
avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if
compiles constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
what this code must to do?
Re: possible "solution" for ufcs
On 2011-06-06 15:00:13 -0400, "Steven Schveighoffer" said: And it does indeed work (2.053)... So we can have ufcs without any changes to the compiler, and we also make it a *choice* for people who don't want to allow infinite extendability, and don't want to deal with possible compiler ambiguities. The opDispatch could even be a mixin itself (I think). What do you think? Clever. But how does it work for properties? Pure/safe/nothrow functions? Ref and out parameters? Note that properties specifically are already problem for the compiler-implemented array-member syntax. Bottom line: there's a lot of work to do to make UFCS work right. And it'll require some language-level changes anyway if we want it to work right. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: possible "solution" for ufcs
Steven Schveighoffer wrote:
> Someone wrote a very compelling argument for ufcs (uniform function call
> syntax) for ranges, and that is, given a slew of range functions, and a
> slew of ranges, it is nice to use a fluent programming syntax to specify
> wrappers for ranges without having to extend each range type. For example:
>
> take(10,stride(2,cycle([3,2,5,3])));
>
> vs.
>
> [3,2,5,3].cycle().stride(2).take(10);
>
> And I thought damn it would be nice if ranges could implement ufcs, but
> other types that you didn't want to allow infinite extendability could
> avoid it. That gave me an idea :)
>
>
> import std.stdio;
>
> struct ufcs
> {
> auto opDispatch(string name, T...)(T args) // appropriate if compiles
> constraint here
> {
> mixin("return ." ~ name ~ "(this, args);");
> }
> }
>
> int foo(ufcs x, int y)
> {
> writefln("it works! %d", y);
> return y+1;
> }
>
> void main()
> {
> ufcs u;
> auto x = u.foo(1);
> assert(x == 2);
> }
>
> And it does indeed work (2.053)...
>
> So we can have ufcs without any changes to the compiler, and we also make
> it a *choice* for people who don't want to allow infinite extendability,
> and don't want to deal with possible compiler ambiguities.
>
> The opDispatch could even be a mixin itself (I think).
>
> What do you think?
>
> -Steve
Great! =) This resolves everything around UFCS!
Why has nobody come up with this before? You should definitely file an
enhancement
request for phobos.
We just add something like this somewhere:
mixin template implementUFCS() {
auto opDispatch(string name, T...)(T args) if(is(typeof({mixin("return ." ~
name ~ "(this, args);");}))){
mixin("return ." ~ name ~ "(this, args);");
}
}
Each range type will do
mixin implementUFCS;
And we'll have optional UFCS!!!
A little drawback: Types using implementUFCS will have very bad error reporting
if
somebody types a member name wrong:
struct foo{mixin implementUFCS;}
int main(){foo x;x.bar();}
Error: template instance opDispatch!("bar") does not match template declaration
opDispatch(string name,T...) if (is(typeof(delegate ()
{
mixin("return ." ~ name ~ "(this, args);");
}
)))
I think here a change to the compiler would be appropriate at some point so that
we can get:
Error: no property 'bar' for type 'foo'
If opDispatch does not match.
But this is definitely the way to go for UFCS!
Timon
Re: possible "solution" for ufcs
On Jun 7, 11 03:00, Steven Schveighoffer wrote:
Someone wrote a very compelling argument for ufcs (uniform function call
syntax) for ranges, and that is, given a slew of range functions, and a
slew of ranges, it is nice to use a fluent programming syntax to specify
wrappers for ranges without having to extend each range type. For example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs, but
other types that you didn't want to allow infinite extendability could
avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if compiles
constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
Maybe better
auto ref opDispatch(string name, T...)(auto ref T args) {
mixin("return ." ~ name ~ "(this, args);");
}
so that ref-returns and ref-parameters can be handled as well. Doesn't
work for 'lazy' though. It also cannot preserve 'pure'-ity,
'nothrow'-ness and '@safe'-ty of the original function.
Re: possible "solution" for ufcs
I think something is missing here. It doesn't convert fun(int, ufcs) to ufcs.fun(int) as in the examples. It converts fun(ufcs, int) to ufcs.fun(int). We need is a solution to this: fun(T)(arg1, ... ufcs!T, ... argN)
Re: possible "solution" for ufcs
On Jun 7, 11 03:22, Monkol wrote:
On Mon, 06 Jun 2011 22:00:13 +0300, Steven Schveighoffer
wrote:
Someone wrote a very compelling argument for ufcs (uniform function
call syntax) for ranges, and that is, given a slew of range functions,
and a slew of ranges, it is nice to use a fluent programming syntax to
specify wrappers for ranges without having to extend each range type.
For example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs,
but other types that you didn't want to allow infinite extendability
could avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if compiles
constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
may be you lost symbol "!" when call template opDispatch!(string name,
T...)(T args)
No Steven is correct. You don't need the '!' before the template parameters.
Re: possible "solution" for ufcs
On Mon, 06 Jun 2011 22:00:13 +0300, Steven Schveighoffer
wrote:
Someone wrote a very compelling argument for ufcs (uniform function call
syntax) for ranges, and that is, given a slew of range functions, and a
slew of ranges, it is nice to use a fluent programming syntax to specify
wrappers for ranges without having to extend each range type. For
example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs, but
other types that you didn't want to allow infinite extendability could
avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if
compiles constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also
make it a *choice* for people who don't want to allow infinite
extendability, and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
may be you lost symbol "!" when call template opDispatch!(string name,
T...)(T args)
Re: TempAlloc review starts now
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Sun, 05 Jun 2011 18:25:07 -0400, Lars T. Kyllingstad > wrote: > > All right, folks, it's time to get the review queue started again. First > > up is David Simcha's TempAlloc, which, if accepted, is to be included in > > the core.memory module in druntime. > newVoid: I don't really like the name of this -- void is a type. It > suggests you are allocating a new void array. I'm not sure we should > adopt the hacky syntax that D uses to say "don't initialize" as a symbol > name. > Particularly, this looks odd: > newVoid!double > What the hell does that mean? :) > I suggest a name like newUninit or newRaw or something that means more > "uninitailized" than "no type". Seems there's a strong consensus that the "newVoid" name sucks. I agree in hindsight. Will change. > alignedMalloc: > I seriously question having such a feature. According to my C++ book > malloc returns a pointer "suitably aligned for any type". According to > Microsoft, malloc is 16-byte aligned (of course, D doesn't use microsoft's > runtime, DMC doesn't seem to identify alignment in malloc docs). GNU > appears to guarantee 8-byte alignment on 32-bit systems, 16 on 64-bit > systems (making this function mostly useless on 64-bit dmd). > There are also some posix functions that align a malloc to a requested > size (see memalign). I definitely need it in the implementation of TempAlloc, so it's gonna be there but it can be made private if there's a consensus that it's not needed in the public API. > At the very least, the function should identify what the alignment is if > you *don't* use it. I'd like to see a good use case for this feature in > an example, otherwise, I think it should be killed. The alignment if you don't use it depends on the C malloc function for your platform. A use case might be if you need 16-byte aligned arrays to use SSE instructions, but that's hard to demonstrate in a short example. > That being said, wrapping malloc might have some nice other features too. > I like the auto-adding of the range to the GC. > tempdup: > 1. If this uses ElemType!(R)[] as the return type, duping a char[] will > give you a dchar[]. I don't think this is very desirable. This seems right to me. tempdup() is supposed to be basically a TempAlloc version of array(). IMHO it should **ALWAYS** return a random-access range. Returning a narrow string creates an obscure special case where it doesn't. > 2. What happens for something like immutable(uint *)[]? Does it become > uint *[]? Because that would be bad... No. It becomes an immutable(uint*)[]. ElementType!(immutable(uint*)[]) == immutable(uint*). > TempAlloc.malloc: > I don't like void * as a return value. Would it not be more appropriate > to use at least void[]? I'd suggest actually for malloc to take a > template parameter of the type to return, defaulting to void. i.e.: > T[] malloc(T = void)(size_t size); Here I'm going to have to strongly disagree. I want to keep TempAlloc.malloc consistent with GC.malloc and core.stdc.stdlib.malloc. Thanks for your review and the points you've raised.
Re: TempAlloc review starts now
On 6/6/11, Steven Schveighoffer wrote: > 1. If this uses ElemType!(R)[] as the return type, duping a char[] will > give you a dchar[]. I don't think this is very desirable. It think auto return could be used here and then inside the body: static if (isSomeChar!(ElementType!R)) (ElementEncodingType!R)[] result; return result; Something like that.
possible "solution" for ufcs
Someone wrote a very compelling argument for ufcs (uniform function call
syntax) for ranges, and that is, given a slew of range functions, and a
slew of ranges, it is nice to use a fluent programming syntax to specify
wrappers for ranges without having to extend each range type. For example:
take(10,stride(2,cycle([3,2,5,3])));
vs.
[3,2,5,3].cycle().stride(2).take(10);
And I thought damn it would be nice if ranges could implement ufcs, but
other types that you didn't want to allow infinite extendability could
avoid it. That gave me an idea :)
import std.stdio;
struct ufcs
{
auto opDispatch(string name, T...)(T args) // appropriate if compiles
constraint here
{
mixin("return ." ~ name ~ "(this, args);");
}
}
int foo(ufcs x, int y)
{
writefln("it works! %d", y);
return y+1;
}
void main()
{
ufcs u;
auto x = u.foo(1);
assert(x == 2);
}
And it does indeed work (2.053)...
So we can have ufcs without any changes to the compiler, and we also make
it a *choice* for people who don't want to allow infinite extendability,
and don't want to deal with possible compiler ambiguities.
The opDispatch could even be a mixin itself (I think).
What do you think?
-Steve
Re: TempAlloc review starts now
On Sun, 05 Jun 2011 18:25:07 -0400, Lars T. Kyllingstad wrote: All right, folks, it's time to get the review queue started again. First up is David Simcha's TempAlloc, which, if accepted, is to be included in the core.memory module in druntime. newVoid: I don't really like the name of this -- void is a type. It suggests you are allocating a new void array. I'm not sure we should adopt the hacky syntax that D uses to say "don't initialize" as a symbol name. Particularly, this looks odd: newVoid!double What the hell does that mean? :) I suggest a name like newUninit or newRaw or something that means more "uninitailized" than "no type". alignedMalloc: I seriously question having such a feature. According to my C++ book malloc returns a pointer "suitably aligned for any type". According to Microsoft, malloc is 16-byte aligned (of course, D doesn't use microsoft's runtime, DMC doesn't seem to identify alignment in malloc docs). GNU appears to guarantee 8-byte alignment on 32-bit systems, 16 on 64-bit systems (making this function mostly useless on 64-bit dmd). There are also some posix functions that align a malloc to a requested size (see memalign). At the very least, the function should identify what the alignment is if you *don't* use it. I'd like to see a good use case for this feature in an example, otherwise, I think it should be killed. That being said, wrapping malloc might have some nice other features too. I like the auto-adding of the range to the GC. tempdup: 1. If this uses ElemType!(R)[] as the return type, duping a char[] will give you a dchar[]. I don't think this is very desirable. 2. What happens for something like immutable(uint *)[]? Does it become uint *[]? Because that would be bad... TempAlloc.malloc: I don't like void * as a return value. Would it not be more appropriate to use at least void[]? I'd suggest actually for malloc to take a template parameter of the type to return, defaulting to void. i.e.: T[] malloc(T = void)(size_t size); auto x = TempAlloc.malloc(50); // allocate a void[] of size 50 auto x = TempAlloc.malloc!int(50); // allocate an int[] of size 50 ints. Same should go to alignedMalloc if that feature stays. -Steve
Re: std.range: Order of arguments unluckily chosen?
I think it is about readability of nested statements: take(10,stride(2,cycle([3,2,5,3]))); vs. [3,2,5,3].cycle().stride(2).take(10); The first one is: "Take 10 of every 2nd element of cyclic [3,2,5,3,...]. The second one is: "Start with [3,2,5,3]. Then cycle that. Then only look at every 2nd element of that. Finally, take 10 elements out of the resulting range." Thanks, this alone makes me realize the need for UFCS. Until now i was thinking it is just about taste, look, that some people like the OO way. The second version writes the actions in the order they are performed, while the functional way is more like what you'd get if you had to describe the entire process in a single sentence. It also reduces nesting of parentheses. I am fine with both. But I dislike take(stride(cycle([3,2,5,3]),2),10); I agree.
Re: [Submission] D Slices
Andrei Alexandrescu писал(а) в своём письме Wed, 01 Jun 2011 00:57:14 +0700: As I mentioned, the issues involved are of increasing subtlety. As you wrote, C programmers iterate upward like this: ... Maybe add this to http://www.digitalmars.com/d/2.0/rationale.html (and btw, I don't see "rationale" on d-p-l.org) Say, if I would see on some forum "open-right proved to be inferior in almost all areas, hence D's choice sucks", I don't think there a lot of programmers out there, who will instantly come up with what Andrei wrote -- Alexander
Re: TempAlloc review starts now
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Mon, 06 Jun 2011 08:51:27 -0400, dsimcha wrote: > > On 6/6/2011 7:24 AM, Timon Gehr wrote: > >> simendsjo wrote: > >>> I have very limited experience with D and haven't taken the time to > >>> understood the code, but here are > >>> some easy nitpicks :) > >>> > >>> imports: Should stuff in core really depend on phobos? Isn't much of > >>> the > >>> reason for core to allow > >>> different "standard" libraries like tango? > >>> [snip.] > >> > >> Actually the code doesn't depend on phobos. You can change the set of > >> imports to: > >> > >> import core.memory, core.exception, core.stdc.string; > >> static import core.stdc.stdlib; > >> > >> It will still compile. Good point though. That needs to be changed. > >> > >> > >> Timon > > > > Wow. I have no idea how these dependencies on Phobos slipped past me. > > Probably because I'm so used to thinking of std.range, std.algorithm, > > etc. as fundamental parts of the language. They absolutely, 110% must > > be gotten rid of if this is to go into druntime. This may necessitate > > breaking this proposal up into two: TempAlloc itself in druntime and > > the higher level convenience functions (tempdup, stackCat, etc.) in > > std.array. > Without actually even looking at it (yet), I don't see why this goes into > druntime in the first place. From my experience with druntime, things > should go in there only if the compiler or runtime needs them to work. Is > there a proposed usage for TempAlloc in druntime or for the compiler? > -Steve You may be right. Someone (I think it was Andrei or Sean) suggested core.memory. I would be fine with moving it to Phobos instead.
Re: TempAlloc review starts now
On Mon, 06 Jun 2011 08:51:27 -0400, dsimcha wrote: On 6/6/2011 7:24 AM, Timon Gehr wrote: simendsjo wrote: I have very limited experience with D and haven't taken the time to understood the code, but here are some easy nitpicks :) imports: Should stuff in core really depend on phobos? Isn't much of the reason for core to allow different "standard" libraries like tango? [snip.] Actually the code doesn't depend on phobos. You can change the set of imports to: import core.memory, core.exception, core.stdc.string; static import core.stdc.stdlib; It will still compile. Good point though. That needs to be changed. Timon Wow. I have no idea how these dependencies on Phobos slipped past me. Probably because I'm so used to thinking of std.range, std.algorithm, etc. as fundamental parts of the language. They absolutely, 110% must be gotten rid of if this is to go into druntime. This may necessitate breaking this proposal up into two: TempAlloc itself in druntime and the higher level convenience functions (tempdup, stackCat, etc.) in std.array. Without actually even looking at it (yet), I don't see why this goes into druntime in the first place. From my experience with druntime, things should go in there only if the compiler or runtime needs them to work. Is there a proposed usage for TempAlloc in druntime or for the compiler? -Steve
Re: Discuss here the best article iPad2 contest
I voted for David's article. It was a very close call for me between Robert and David. Both articles were well written and covered very similar topics, both of which I learned some new things from. Everyone did a great job. This was a tough one to decide. Nick, your article was too long for me, but I *loved* the dialog. It reminded me tremendously of the very successful (and one of my favorite) series Head First programming books (mostly centered on Java), where they do things like interviews of variable types. TBH, I really expected more voter turnout. Maybe there will be a last-minute rush. Good luck to everyone! -Steve
Re: Vote here for best article iPad2 contest
[2] Concurrency, Parallelism and D by Dave Simcha
Re: TempAlloc review starts now
> So maybe names like TempAlloc.stackMalloc/TempAlloc.stackFree are better. I > am not sure. Or pushMalloc/popFree :-) Or pushMem, popMem, etc. Bye, bearophile
Re: TempAlloc review starts now
Lars T. Kyllingstad: > Here follows a description of TempAlloc's purpose and functionality. > Links to the code and documentation are at the bottom. I like the contents I am seeing in core.tempalloc. A segmented stack-style allocator is quite useful. In some other situations I have needed a hyerarchical allocator, that allows to allocate from the C/D heap and deallocate whole subtrees at once. Some comments: 1) Regarding the alignedMalloc/alignedFree names: maybe alignedCMalloc/alignedCFree names are better, because they remind both the programmer and the person that reads the code the memory comes from the C heap (I have similar named functions in dlibs1). 2) TempAlloc.slack name: maybe TempAlloc.segmentSlack is better, because it reminds its meaning better. 3) "The memory returned by this function is not scanned for pointers by the garbage collector unless GC.addRange is called." I suggest to add a little in-place example that shows how to do this. 4) Regarding alignedMalloc(size_t size, bool shouldAddRange = false): I suggest to add a compile-time template argument to specify the alignment, that defaults to 16, something like: alignedMalloc(size_t ALIGN=16)(size_t size, bool shouldAddRange = false) This is more future-proof, if future CPUs will need just 8 bytes alignments, of even 32 bytes alignments. 5) Regarding newVoid(): I'd like it to allow to allocate 2D arrays too. 5b) And maybe I'd like to use newVoid() to create a 2D matrix and initialize it all to a fixed value given at runtime, to replace code like: auto M = new int[][](n,m); foreach (row; M) row[] = 10; 6) As an extra function to add to this bunch of functions, I suggest to add a templated function to allocate a 2D matrix carved out of a single zone of memory (from the C or GC heap, or even the stack...). This is not fully safe, but it's handy, because it reduces a little the memory needed to allocate the whole matrix, and the memory of the rows is contigous or almost contigous. The advantage of this function is that the resulting matrix is seen as a standard array of dynamic arrays, usable in many other functions. This needs a corresponding free function. 7) Regarding newStack(): I don't like this name, it doesn' return a stack! I don't know a good name, but I suggest a name that reminds the programmer that this function returns an array. 8) Regarding TempAlloc.malloc/TempAlloc.free: I am not sure, but I'd like those functions to remind the programmer and the person that reads the code that those two functions work on a stack, so they are push-pop pairs. So maybe names like TempAlloc.stackMalloc/TempAlloc.stackFree are better. I am not sure. Bye, bearophile
Re: Vote here for best article iPad2 contest
[2] Concurrency, Parallelism and D by Dave Simcha -- Simen
Re: Vote here for best article iPad2 contest
[3] Getting more fiber in your diet by Robert Clipsham -- Dmitry Olshansky
Re: std.range: Order of arguments unluckily chosen?
so wrote: > Nice idea to make sense out of the UFCS, but i fail to realize the > actually need for UFCS to begin with. > To me, the need to convert "take(3, range)" to "range.take(3)" is > non-existent (and this wouldn't be the only reason i could come up with), > probably i am missing something. And because everyone likes this, it must > be something big :) I think it is about readability of nested statements: take(10,stride(2,cycle([3,2,5,3]))); vs. [3,2,5,3].cycle().stride(2).take(10); The first one is: "Take 10 of every 2nd element of cyclic [3,2,5,3,...]. The second one is: "Start with [3,2,5,3]. Then cycle that. Then only look at every 2nd element of that. Finally, take 10 elements out of the resulting range." The second version writes the actions in the order they are performed, while the functional way is more like what you'd get if you had to describe the entire process in a single sentence. It also reduces nesting of parentheses. I am fine with both. But I dislike take(stride(cycle([3,2,5,3]),2),10); Timon
Re: TempAlloc review starts now
Am 06.06.2011 18:34, schrieb dsimcha: > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article >> On 6/5/11 5:25 PM, Lars T. Kyllingstad wrote: >>> Code: >>> >>> https://github.com/dsimcha/TempAlloc/blob/master/tempalloc.d >>> >>> Docs: >>> >>> http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html >> I'll get back with a real review, but before I forget, there is one >> thing that I also noticed in the proposal: TempAlloc is good to have but >> the marketing folks should be dialed down a bit. In the documentation >> TempAlloc lists two advantages compared to stack allocation and three >> advantages compared to heap allocation. There's no disadvantage, >> drawback, caveat, etc. listed at all. If we went by the documentation it >> would appear that TempAlloc is the be-all-end-all memory allocator to >> replace all others. >> Documentation must clarify when use of TempAlloc is favored and when >> other allocation methods should be chosen instead. >> Thanks, >> Andrei > > Yeah, I'm really not sure how much marketing these proposals are supposed to > have. > One criticism of my std.parallelism proposal, IIRC, was too little marketing. But probably because it didn't show the advantages - and not because it showed to many disadvantages ;)
Re: TempAlloc review starts now
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 6/5/11 5:25 PM, Lars T. Kyllingstad wrote: > > Code: > > > > https://github.com/dsimcha/TempAlloc/blob/master/tempalloc.d > > > > Docs: > > > > http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html > I'll get back with a real review, but before I forget, there is one > thing that I also noticed in the proposal: TempAlloc is good to have but > the marketing folks should be dialed down a bit. In the documentation > TempAlloc lists two advantages compared to stack allocation and three > advantages compared to heap allocation. There's no disadvantage, > drawback, caveat, etc. listed at all. If we went by the documentation it > would appear that TempAlloc is the be-all-end-all memory allocator to > replace all others. > Documentation must clarify when use of TempAlloc is favored and when > other allocation methods should be chosen instead. > Thanks, > Andrei Yeah, I'm really not sure how much marketing these proposals are supposed to have. One criticism of my std.parallelism proposal, IIRC, was too little marketing.
Re: std.range: Order of arguments unluckily chosen?
On Jun 5, 11 06:55, Andrei Alexandrescu wrote:
Well this hurts. With the same in mind as you, I initially defined take
to take the number first. But OO people wanted to write array.take(3),
so I changed the order. Don't forget that UFCS is still on the table.
Impossible to please everybody!
I don't know what to do to improve the situation.
Andrei
You could provide an overload?
Take!R take(R)(size_t n, R input) if (!is(Unqual!R : size_t)) {
return take(input, n);
}
Like PHP's implode() ;).
Re: TempAlloc review starts now
On Jun 6, 11 20:59, dsimcha wrote: On 6/6/2011 4:54 AM, KennyTM~ wrote: Can't access the doc, it's 404. It should work, though it doesn't for me either. The server's being weird right now. If it doesn't work by tonight, I'll move the docs somewhere else. OK it's back.
Re: std.range: Order of arguments unluckily chosen?
On Sun, 05 Jun 2011 02:25:46 +0300, Michel Fortin
wrote:
On 2011-06-04 18:55:54 -0400, Andrei Alexandrescu
said:
On 06/04/2011 03:11 PM, Timon Gehr wrote:
I think the order should be swapped. It is also the way functional
language
libraries handle it. It works better with currying too.
Any comments/arguments on why the current order is the right order?
Well this hurts. With the same in mind as you, I initially defined
take to take the number first. But OO people wanted to write
array.take(3), so I changed the order. Don't forget that UFCS is still
on the table.
Impossible to please everybody!
I don't know what to do to improve the situation.
Perhaps like this:
auto take(R)(uint count, R this) { ... }
Note that the second parameters's name is "this", which would mean that
the second argument is the one that disappear using the member syntax.
It can then be called this way:
take(3, range);
or this way:
range.take(3);
Having to specify explicitly whether a function is meant for
member-syntax this way would also fix a couple of issues regarding UFCS:
UFCS properties would be able to work correctly, and name clashes would
happen less often when using the member syntax.
Nice idea to make sense out of the UFCS, but i fail to realize the
actually need for UFCS to begin with.
To me, the need to convert "take(3, range)" to "range.take(3)" is
non-existent (and this wouldn't be the only reason i could come up with),
probably i am missing something. And because everyone likes this, it must
be something big :)
Re: Port a benchmark to D?
On 2011-06-06 06:37, Steven Schveighoffer wrote: > On Fri, 03 Jun 2011 17:30:54 -0400, Timon Gehr wrote: > > Jonathan M Davis wrote: > >> On 2011-06-03 14:08, Timon Gehr wrote: > >> > Andrei Alexandrescu wrote: > >> > > I noticed that the C++ code uses std::list without there being any > >> > >> need > >> > >> > > for a linked list structure. See for example the data structure > >> > >> used in > >> > >> > > FindSet. It's a list, but it's just appended too and then used for > >> > >> one > >> > >> > > iteration. > >> > > > >> > > Andrei > >> > > >> > Yes, but the list in FindSet is unnecessary anyways. If I start > >> > >> changing > >> > >> > the original implementation, the first thing I will do is to remove > >> > >> that. > >> > >> > First however, I will port the code as closely as possible. Is there > >> > >> any > >> > >> > associative version of RedBlackTree (I realize it could be made > >> > >> associative > >> > >> > quite easily), or should I just use built-in hash maps? > >> > >> You give RedBlackTree a different predicate if you want to treat it as > >> a map. > >> It defaults to "a < b" with allowDuplicates as false, which makes it a > >> multiset. > > This makes it a set, not a multiset. allowDuplicates set to true would > make it a multiset. Bleh. You're right. I guess that I wasn't thinking straight (or was thinking too quickly) on that one. :( - Jonathan M Davis
Re: TempAlloc review starts now
On 2011-06-06 05:58, dsimcha wrote: > On 6/6/2011 4:56 AM, simendsjo wrote: > > 686: missing () (same as above) > > Argh. Can we **__PLEASE__** go with loose semantics for @property? As far as I know, strict enforcement is still where we're going (and honestly, I really hope that it stays that way). But we already debated that quite a bit recently on the Phobos list, so you know essentially where that stands. - Jonathan M Davis
Re: TempAlloc review starts now
On 6/5/11 5:25 PM, Lars T. Kyllingstad wrote: Code: https://github.com/dsimcha/TempAlloc/blob/master/tempalloc.d Docs: http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html I'll get back with a real review, but before I forget, there is one thing that I also noticed in the proposal: TempAlloc is good to have but the marketing folks should be dialed down a bit. In the documentation TempAlloc lists two advantages compared to stack allocation and three advantages compared to heap allocation. There's no disadvantage, drawback, caveat, etc. listed at all. If we went by the documentation it would appear that TempAlloc is the be-all-end-all memory allocator to replace all others. Documentation must clarify when use of TempAlloc is favored and when other allocation methods should be chosen instead. Thanks, Andrei
Re: Syntax changing
On Mon, 06 Jun 2011 00:11:47 +0300, Monkol wrote:
On Fri, 03 Jun 2011 00:36:42 +0300, Jonathan M Davis
wrote:
On 2011-06-02 13:56, Nick Sabalausky wrote:
"Monkol" wrote in message
news:op.vwgs7ypjcqe...@pc-2010.dnepr.net.ua...
>i think it is necessary to change template syntax and do as C++ style
>template A <>, and not A !(), A <>. many people come from C++ and it
will
>be easy to adapt.
I came from C++, and I found it easy to adapt. Plus, like it says in
the
link Steve gave, there are technical downsides to using <>.
LOL. I use C++ in my job, but I use templates in D so much more than I
do in
C++ that I now end up using !() instead of <> unless I catch myself. I
actually ultimately much prefer !() - especially since you can reduce
it to
just ! when there's only one template argument and it doesn't have any
periods
in it.
Though honestly, if a programmer can't get used to a slightly different
syntax, then they're screwed anyway. Every language has its quirks and
differences. Syntax is a very small part of all of that. Really, the
syntax is
the _easy_ part. It's the semantics where the real problems start as
far as
adapting to a new language goes.
- Jonathan M Davis
the statement to is more easy readable then
to!float("123e2") for example
No it is not, but if you were talking about templates arguments rather
than single argument, you'd have your case.
fun!(T1, T2, ... TN)(A1, A2, ... AN);
vs
fun(A1, A2, ... AN);
Re: changelog 2.53
On Mon, 06 Jun 2011 00:13:45 +0300, Monkol wrote: is it true that typedef statement was deleted in 2.53 release? If it says it was, yes.
Re: std.range: Order of arguments unluckily chosen?
Well this hurts. With the same in mind as you, I initially defined take to take the number first. But OO people wanted to write array.take(3), so I changed the order. Don't forget that UFCS is still on the table. Impossible to please everybody! I don't know what to do to improve the situation. This is the reason of quite many of the discussions here boils down to, we (not being a contributor, maybe i should say "you") shouldn't cater for particular groups be it either Functional or OO. If they don't feel something right, they should also consider the other side of the table, and come up with compelling arguments. Reading recent posts, i really started to think the word "subjectivity" is just a horse-waste to divert our attention. Given none of our backgrounds match one another, none of our experiences match with one another, none of our open/close mindedness match with one another. I like OO more than most of the people here, but it is simply a freaking paradigm. If some people just want everything OO way, knowing none of its drawbacks... Forgive my language, fuck them. We have many languages out there just doing that, and yet the only reason we are here is that we know they suck.
Re: Proposal: ClassInfo hasFinalizer field
On Sun, 05 Jun 2011 01:22:30 -0400, Robert Jacques wrote: On Sun, 05 Jun 2011 00:28:58 -0400, dsimcha wrote: On 6/4/2011 11:45 PM, Walter Bright wrote: One issue is that if someone derives from a class and adds a finalizer. One issue I did forget, though, is that these "empty" finalizers do deallocate the object's monitor. (For those not familiar with these details, D classes contain a hidden monitor field that is null initially. When you do synchronized(someClass), the monitor is lazily initialized.) I guess we could get around this by setting the finalize bit in the monitor initialization code rather than upfront, for classes that don't do any other finalization. This would almost always be more efficient than the status quo since very few classes use monitors. They shouldn't. Monitors can be shared across objects. The destruction actually calls object._d_monitordelete, which uses reference counting to ensure sanity. -Steve
Re: Proposal: ClassInfo hasFinalizer field
On Sun, 05 Jun 2011 00:28:58 -0400, dsimcha wrote: On 6/4/2011 11:45 PM, Walter Bright wrote: One issue is that if someone derives from a class and adds a finalizer. One issue I did forget, though, is that these "empty" finalizers do deallocate the object's monitor. (For those not familiar with these details, D classes contain a hidden monitor field that is null initially. When you do synchronized(someClass), the monitor is lazily initialized.) I guess we could get around this by setting the finalize bit in the monitor initialization code rather than upfront, for classes that don't do any other finalization. This would almost always be more efficient than the status quo since very few classes use monitors. What about this idea: Store the bit saying whether the class instance has any finalizers in the monitor field. That is, you still set the hasFinalizer bit in the GC block, but you check the monitor area. For example, if the monitor's lsb is set to 1 (not possible for a pointer), then the optimal case of no monitor, no finalizer is registered as true. What is the big slowdown in rt_finalize? The loop moving up the dtors? Or is it simply calling rt_finalize at all? -Steve
Re: Two other kinds of static
On Sat, 04 Jun 2011 09:36:28 -0400, bearophile
wrote:
Time ago I have half-seriously suggested a "static static", to solve a
small problem I've has in my code. foo is a function template, so even
if bar is static, every instantiation of foo gets a different bar:
auto foo(T)(int x) {
static bar = ...;
...
}
A "static static" means there is only one bar shared for all instances
of foo, this is something I have desired a bit to do:
auto foo(T)(int x) {
static static bar = ...;
...
}
Just put it outside foo:
private static bar = ...;
auto foo(T)(int x) {
...
}
Now I have found a bit of need for another kind of static :-) In C/C++
there isn't this need because they don't have nest functions as D (GCC
supports nest functions, but they are not used much). An example:
int foo() {
int bar() {
static(foo) int[10] spam;
//...
}
// ...
}
That means something like:
int foo() {
int[10] spam;
// spam not visible here
int bar() {
// use spam here only
}
// spam not visible here
}
"spam" is static regarding the bar() function, but it's not static (so
it's automatic) for foo() function. This is sometimes useful because I
know how bar will be called (inside foo), but I don't know how foo()
itself will be called and used, and generally foo() may be a recursive
function. So this is wrong code, I can't set spam as a truly static
variable:
int foo() {
static int[10] spam;
int bar() {
}
}
I understand you want to limit the accessible namespace, but saying "it
can't be done" is not true. It can be done, with proper control over the
code. That is, as long as you follow your own rules, outsiders can't
break into it. I'd recommend naming the variables in a way that
"suggests" the namespace they should be in:
int foo() {
static int[10] bar_spam; // only used inside bar
int bar() {
}
}
-Steve
Re: Port a benchmark to D?
On Fri, 03 Jun 2011 17:30:54 -0400, Timon Gehr wrote: Jonathan M Davis wrote: On 2011-06-03 14:08, Timon Gehr wrote: > Andrei Alexandrescu wrote: > > I noticed that the C++ code uses std::list without there being any need > > for a linked list structure. See for example the data structure used in > > FindSet. It's a list, but it's just appended too and then used for one > > iteration. > > > > Andrei > > Yes, but the list in FindSet is unnecessary anyways. If I start changing > the original implementation, the first thing I will do is to remove that. > > First however, I will port the code as closely as possible. Is there any > associative version of RedBlackTree (I realize it could be made associative > quite easily), or should I just use built-in hash maps? You give RedBlackTree a different predicate if you want to treat it as a map. It defaults to "a < b" with allowDuplicates as false, which makes it a multiset. This makes it a set, not a multiset. allowDuplicates set to true would make it a multiset. Yes, thats what I had in mind, but I thought it is strange that there is no boilerplate map in std.container. I think the goal is to eventually have these higher-level types based on the implementation types, but I'm uncertain how they will look or where they will go. Almost certainly, there will be a template based on a set-like template for defining a map (e.g. map!(RedBlackTree, int, int) ). If you want a cookie-cutter map type that uses the exact same implementation as RedBlackTree, with a custom allocator that helps with performance for long-lasting containers, dcollections provides such a type (TreeMap). If you do end up using it, I recommend the latest trunk, I've made some critical bug fixes (I need to release soon...). -Steve
Re: How about "auto" parameters?
On Sat, 04 Jun 2011 02:05:14 -0400, Matthew Ong wrote: Alternatively, D might want to use *some kind of voting tool online* on yahoo (group, missing) to help vote for syntax that programmer really wants. A simple solution to the long like JCP process in Java. We have this, bugzilla allows voting, you can vote once per bug/proposal (and you have 10 votes total you can distribute): http://d.puremagic.com/issues/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced&votes=1&order=votes%2Cbug_id&query_based_on= That is all the open bugs that have at least one vote, sorted by votes. We also have a wiki where DIPs (D improvement proposals) can be created to flesh out ideas in a more formal fashion. However, this system has no voting or really feedback, so I'd recommend using bugzilla or the newsgroups first. -Steve
Re: TempAlloc review starts now
On 6/6/2011 4:54 AM, KennyTM~ wrote: Can't access the doc, it's 404. It should work, though it doesn't for me either. The server's being weird right now. If it doesn't work by tonight, I'll move the docs somewhere else.
Re: TempAlloc review starts now
On 6/6/2011 4:56 AM, simendsjo wrote:
I have very limited experience with D and haven't taken the time to understood
the code, but here are
some easy nitpicks :)
imports: Should stuff in core really depend on phobos? Isn't much of the reason
for core to allow
different "standard" libraries like tango?
177: should 16 be alignBytes?
Yes. Good catch.
199/299: unnecessary initializers
I prefer to have this explicit in cases where I will actually use the
zero value.
246: Move inUse.destroy() up to clearing of inUse?
Good idea.
291: Move assumption comment to assertion. Something like this:
Good idea. This can be implemented even more easily for powers of two:
import core.bitop;
bool isPowerOfTwo(size_t num) {
return bsr(num) == bsf(num);
}
383/408/418/428: getState called without () (deprecated behavior, right..?)
Unfortunately, yes.
686: missing () (same as above)
Argh. Can we **__PLEASE__** go with loose semantics for @property?
Re: TempAlloc review starts now
On 6/6/2011 7:24 AM, Timon Gehr wrote: simendsjo wrote: I have very limited experience with D and haven't taken the time to understood the code, but here are some easy nitpicks :) imports: Should stuff in core really depend on phobos? Isn't much of the reason for core to allow different "standard" libraries like tango? [snip.] Actually the code doesn't depend on phobos. You can change the set of imports to: import core.memory, core.exception, core.stdc.string; static import core.stdc.stdlib; It will still compile. Good point though. That needs to be changed. Timon Wow. I have no idea how these dependencies on Phobos slipped past me. Probably because I'm so used to thinking of std.range, std.algorithm, etc. as fundamental parts of the language. They absolutely, 110% must be gotten rid of if this is to go into druntime. This may necessitate breaking this proposal up into two: TempAlloc itself in druntime and the higher level convenience functions (tempdup, stackCat, etc.) in std.array.
Re: TempAlloc review starts now
simendsjo:
> bool isPowerOf(int pow, int num) {
...
> static assert(isPowerOf(2, alignBytes), "getAligned requires alignBytes to be
> a power of 2")
I suggest to add something related to this to std.math instead:
bool isPow2(long x) {
return (x < 1L) ? false : !(x & (x-1L));
}
A similar template is OK too.
Bye,
bearophile
Re: std.log version 2
On 2011-06-06 04:17, Jacob Carlborg wrote:
> On 2011-06-06 01:38, Jonathan M Davis wrote:
> > On 2011-06-05 10:24, Jose Armando Garcia wrote:
> >> The problem is that std.log is using the UTC() (indirectly) in shared
> >> static this() for the module. At that point the static ctr for UTC
> >> didn't get to execute. I first changed std.datetime to instantiate UTC
> >> in a shared static ctr for UTC but that still didn't work (I assume
> >> that is a bug in dmd). So I had to move the instantiation to a share
> >> static ctr for the module.
> >>
> >> In my branch the follow code doesn't assert. Note that I was selfish
> >> and only fixed UTC but std.datetime has this problem in all the
> >> singletons.
> >>
> >> import std.datetime;
> >>
> >> shared static this()
> >> {
> >>
> >> assert(UTC() !is null); // this is with my fix.
> >> assert(LocalTime() is null); // I didn't fix LocalTime!
> >>
> >> }
> >>
> >> Having said that what is D's idiom/recommended way of constructing
> >> singletons? Maybe phobos should create shared/global singleton with
> >> the following idiom:
> >>
> >> shared(T) singleton(T)() if(is(T == class))
> >> {
> >>
> >> shared static T one;
> >> if(one is null) cas(&one, null, new shared(T));
> >>
> >> return one;
> >>
> >> }
> >
> > Phobos has no idiom or policies for dealing with singletons. In, fact I
> > think that std.datetime is probably the only module that even has any at
> > this point (most Phobos modules have functions primarily rather than
> > types which may or may not be singletons).
> >
> > In this particular case, because the singletons are immutable, changing
> > them to shared makes a lot of sense, but in the general case, it
> > probably wouldn't (at which point it would be a singleton per thread
> > rather than globally). So, I'll take a look at making the approriate
> > changes in std.datetime for all of its singletons.
> >
> > But if you could, I'd really appreciate it if you could create a small
> > test case (which has nothing to do with std.datetime), which shows the
> > bug with regards to the shared module constructor, since that needs to
> > be fixed. Having to move the variable into the module's scope like that
> > is ugly and shouldn't be necessary at all. I guess that std.datetime
> > will be stuck for the moment, but the bug does need to be properly
> > reported and fixed.
> >
> > - Jonathan M Davis
>
> I'm pretty sure someone added a singleton template to Phobos. I can't
> find it though, maybe it's been removed, or it was never added in the
> first place. At least there was talk about a design pattern module, or
> similar, on this newsgroup with a singleton implementation.
Yeah. I think that a template of some variety for singletons was discussed in
the newsgroup at some point, but I'm not aware of anything of the sort ever
getting into Phobos, and I don't remember any of the details at this point.
- Jonathan M Davis
Re: TempAlloc review starts now
simendsjo wrote: > I have very limited experience with D and haven't taken the time to > understood the code, but here are > some easy nitpicks :) > > imports: Should stuff in core really depend on phobos? Isn't much of the > reason for core to allow > different "standard" libraries like tango? > [snip.] Actually the code doesn't depend on phobos. You can change the set of imports to: import core.memory, core.exception, core.stdc.string; static import core.stdc.stdlib; It will still compile. Good point though. That needs to be changed. Timon
Re: std.log version 2
On 2011-06-06 01:38, Jonathan M Davis wrote:
On 2011-06-05 10:24, Jose Armando Garcia wrote:
The problem is that std.log is using the UTC() (indirectly) in shared
static this() for the module. At that point the static ctr for UTC
didn't get to execute. I first changed std.datetime to instantiate UTC
in a shared static ctr for UTC but that still didn't work (I assume
that is a bug in dmd). So I had to move the instantiation to a share
static ctr for the module.
In my branch the follow code doesn't assert. Note that I was selfish
and only fixed UTC but std.datetime has this problem in all the
singletons.
import std.datetime;
shared static this()
{
assert(UTC() !is null); // this is with my fix.
assert(LocalTime() is null); // I didn't fix LocalTime!
}
Having said that what is D's idiom/recommended way of constructing
singletons? Maybe phobos should create shared/global singleton with
the following idiom:
shared(T) singleton(T)() if(is(T == class))
{
shared static T one;
if(one is null) cas(&one, null, new shared(T));
return one;
}
Phobos has no idiom or policies for dealing with singletons. In, fact I think
that std.datetime is probably the only module that even has any at this point
(most Phobos modules have functions primarily rather than types which may or
may not be singletons).
In this particular case, because the singletons are immutable, changing them
to shared makes a lot of sense, but in the general case, it probably wouldn't
(at which point it would be a singleton per thread rather than globally). So,
I'll take a look at making the approriate changes in std.datetime for all of
its singletons.
But if you could, I'd really appreciate it if you could create a small test
case (which has nothing to do with std.datetime), which shows the bug with
regards to the shared module constructor, since that needs to be fixed. Having
to move the variable into the module's scope like that is ugly and shouldn't
be necessary at all. I guess that std.datetime will be stuck for the moment,
but the bug does need to be properly reported and fixed.
- Jonathan M Davis
I'm pretty sure someone added a singleton template to Phobos. I can't
find it though, maybe it's been removed, or it was never added in the
first place. At least there was talk about a design pattern module, or
similar, on this newsgroup with a singleton implementation.
--
/Jacob Carlborg
Re: TempAlloc review starts now
On Jun 6, 11 06:25, Lars T. Kyllingstad wrote: All right, folks, it's time to get the review queue started again. First up is David Simcha's TempAlloc, which, if accepted, is to be included in the core.memory module in druntime. If there are no objections, I suggest we use 3 weeks (until 27 June) for the review, followed by one week for voting. Please post reviews in this thread. Here follows a description of TempAlloc's purpose and functionality. Links to the code and documentation are at the bottom. -Lars David Simcha wrote: TempAlloc is a thread-local segmented stack memory allocator (defined/detailed in the docs) for efficiently allocating temporary buffers, matrices, etc. It has the following advantages compared to allocation on the call stack: 1. Pointers to memory allocated on the TempAlloc stack are still valid when the function they were allocated from returns. Functions can be written to create and return data structures on the TempAlloc stack. 2. Since it is a segmented stack, large allocations can be performed with no danger of stack overflow errors. It has the following advantages compared to heap allocation: 1. Both allocation and deallocation are extremely fast. Most allocations consist of verifying enough space is available, incrementing a pointer and a performing a few cheap bookkeeping operations. Most deallocations consist decrementing a pointer and performing a few cheap bookkeeping operations. 2. The segmented stack is thread-local, so synchronization is only needed when a segment needs to be allocated or freed. 3. Fragmentation is not an issue when allocating memory on the TempAlloc stack, though it can be an issue when trying to allocate a new segment. It'd be nice to get this in the next release b/c SciD, which is being worked on extensively for GSoC, uses it and Don said he wanted to use it in BigInt. Code: https://github.com/dsimcha/TempAlloc/blob/master/tempalloc.d Docs: http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html Can't access the doc, it's 404.
Re: TempAlloc review starts now
I have very limited experience with D and haven't taken the time to understood
the code, but here are
some easy nitpicks :)
imports: Should stuff in core really depend on phobos? Isn't much of the reason
for core to allow
different "standard" libraries like tango?
177: should 16 be alignBytes?
199/299: unnecessary initializers
246: Move inUse.destroy() up to clearing of inUse?
291: Move assumption comment to assertion. Something like this:
bool isPowerOf(int pow, int num) {
if(num <= 0 || pow <= 0)
return false;
else if(pow == 1)
return true;
else if(pow == num)
return true;
else {
double n = cast(double)num / cast(double)pow;
if(n%1 != 0)
return false;
else if(n == pow)
return true;
else
return isPowerOf(pow, cast(int)n);
}
}
unittest {
static assert(isPowerOf(1, 0) == false); // num==0
static assert(isPowerOf(1, 5) == true); // pow==1
static assert(isPowerOf(3, 3) == true); // pow==num
static assert(isPowerOf(2, 2) == true);
static assert(isPowerOf(2, 3) == false);
static assert(isPowerOf(2, 4) == true);
static assert(isPowerOf(2, 1024) == true);
static assert(isPowerOf(2, 1023) == false);
}
and in getAligned:
static assert(isPowerOf(2, alignBytes), "getAligned requires alignBytes to be a
power of 2")
383/408/418/428: getState called without () (deprecated behavior, right..?)
686: missing () (same as above)
Re: Making D newsgroup readonly (not digitalmars.D)
"Robert Clipsham" wrote in message news:isglqi$2j26$3...@digitalmars.com... Hi all, People continue to post to D rather than digitalmars.D or digitalmars.D.learn when looking for support/general D related chatter - shouldn't that newsgroup be marked as readonly by now? -- Robert http://octarineparrot.com/ Also why not make digitalmars.D.dwt => digitalmars.D.GUI -=mike=-
