Undefined identifier WIN32_FILE_ATTRIBUTE_DATA
I'm not sure if this is the correct forum. But It looks like I'm one of the few people that ran into this. I've recently upgraded to 2.60 and been getting this error when compiling: Error: undefined identifier WIN32_FILE_ATTRIBUTE_DATA D:\__dev\D\dmd2\src\phobos\std\file.d 530 Now I have found the thread of Walter at http://www.digitalmars.com/d/archives/digitalmars/D/announce/D_version_of_MicroEmacs_24416.html , but it didn't help me much to solving my problem. Does anyone have an idea how I can fix this :-S Thank you
Re: precise gc?
> > I'm not sure I understand why you would hide a pointer from the GC. As already suggested by Kapps, for weak references. I need that for my new std.signals implementation. > > > Are there memory models in use > > where the inverted pointer value might also be in GC memory? > > > > Yes, that can happen in 32-bit. > Yeah, you are right if all pointer bits are actually used it is far too easy. On the other hand especially because less space is wasted for pointers on 32 bit, I can easily afford an extra variable to solve this problem (kind of). Buah, I am starting to like 64 bit architectures ;-) Thanks!
Re: precise gc?
> Yeah, you are right if all pointer bits are actually used it is far too > easy. On the other hand especially because less space is wasted for > pointers on 32 bit, I can easily afford an extra variable to solve this > problem (kind of). I guess it is a pretty safe bet to assume that the lowest 65535 addresses in memory space (mask: 0x) are not in GC memory?
Re: Pyd thread
On Sat, 2012-11-10 at 14:08 -0800, Ellery Newcomer wrote: […] > Never used ctypes. How difficult would it be to get python > objects/functions to the extension side? As long as the code compiles to a shared object/dynamic link library and presents C-linkage entry points, Python code can call the entry points through ctypes. C++ codes just provide C-linkage entries, D codes just provide C-linkage entries. The real issue is that it must be a shared object or dynamic link library. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Binary compatibility on Linux
Jacob Carlborg wrote: > What's the best way to achieve binary compatibility on Linux? For > example, if I compile an application on, say Ubuntu 12.04, it will most > likely not run on any older versions of Ubuntu but it will run on future > versions. The best way is to get your software in the official debian archive. There are infrastructure and established workflows to recompile packages for each Debian version. The backports archive contains newer versions of a package for the current stable Debian release. Is the software in question free software? It's not that hard to get software in Debian. Have a look at http://wiki.debian.org/UpstreamGuide Regards, Thomas Koch
Re: Const ref and rvalues again...
11/10/2012 11:07 PM, Jonathan M Davis пишет:
And actually, to make matters worse, I'm not sure that scope on delegates is
working correctly. I thought that it was, but this code compiles:
import std.stdio;
void delegate() global;
void foo(scope void delegate() del)
{
global = del;
}
void main()
{
{
char[5] bar = "hello";
foo((){writeln(bar);});
}
char[7] baz = "goodbye";
global();
}
It also prints out "hello", and if a closure had not been allocated,
I would
have at least half-expected it to print out "goodb", because I'd have thought
that baz would have been taking up the same memory that bar had been.
Nope. It's just that the stack is intact and contains: hello and goodbye
one after another. Without optimizations { } scope doesn't mean reuse
stack space.
Now if play with stack a bit, for me the next one prints:
-²↑
import std.stdio;
void delegate() global;
void foo(scope void delegate() del)
{
global = del;
}
void f()
{
{
char[5] bar = "hello";
foo((){writeln(bar);});
}
}
void main()
{
char[7] baz = "goodbye";
f();
global();
}
--
Dmitry Olshansky
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
You don't necessarily need a cross compiler to do the job. Set-up a raspbian chroot instead! There's some rough instructions here. http://superpiadventures.wordpress.com/2012/07/16/development-environment/ You are also able to debug programs through qemu, though there's a hurdle you have to jump through. http://tinkering-is-fun.blogspot.co.uk/2009/12/debugging-non-native-programs-with-qemu.html Regards, Iain. interesting... but a lot of these instructions assume a lot more linux expertise than I have to hand, even the ones that claim to cover every step miss things. That's one of the reasons that I made my RasPi available to all (as long as they ask for an account) ^^ A...
Re: Const ref and rvalues again...
On Sunday, November 11, 2012 13:36:05 Dmitry Olshansky wrote:
> Nope. It's just that the stack is intact and contains: hello and goodbye
> one after another. Without optimizations { } scope doesn't mean reuse
> stack space.
>
> Now if play with stack a bit, for me the next one prints:
> -²↑
>
> import std.stdio;
>
> void delegate() global;
>
> void foo(scope void delegate() del)
> {
> global = del;
> }
>
>
> void f()
> {
> {
> char[5] bar = "hello";
> foo((){writeln(bar);});
> }
> }
>
> void main()
> {
> char[7] baz = "goodbye";
> f();
>
> global();
> }
It still prints "hello", even with full optimations turned on. So, it must be
allocating a closure in spite of scope. So, it looks to me like scope is just
completely ignored and does absolutely nothing at this point, unless I'm just
completely missing something here.
- Jonathan M Davis
GDC is this a bug or a feature?
|> gdc -o lib_helloWorld.so -shared helloWorld.os /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o): relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a: could not read symbols: Bad value collect2: ld returned 1 exit status -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Binary compatibility on Linux
On 2012-11-10 22:14, eskimo wrote: I am sorry. I haven't quite said what I meant. I meant: The oldest still supported LTS of course :-) That makes more sense. -- /Jacob Carlborg
Re: Binary compatibility on Linux
On 2012-11-11 10:30, Thomas Koch wrote: The best way is to get your software in the official debian archive. There are infrastructure and established workflows to recompile packages for each Debian version. The backports archive contains newer versions of a package for the current stable Debian release. I don't want to limit myself to just the debian based package mangers. I want my tools to be available/usable on all distributions. -- /Jacob Carlborg
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
You don't necessarily need a cross compiler to do the job. Set-up a raspbian chroot instead! There's some rough instructions here. http://superpiadventures.wordpress.com/2012/07/16/development-environment/ You are also able to debug programs through qemu, though there's a hurdle you have to jump through. http://tinkering-is-fun.blogspot.co.uk/2009/12/debugging-non-native-programs-with-qemu.html Regards, Iain. The comments on the first article say that using qemu is as slow as compiling on the RasPi, and recommend using the cross-compiler instead. I followed the instructs anyway, and all seemed to go well, but they just stop without detailing how to actually compile anything, or explaining what has been done >< A...
Re: Binary compatibility on Linux
On 2012-11-10 20:10, 1100110 wrote: Oldest system to reasonably support? I would say Debian Stable. It is used on a lot of server systems and isn't *too* far behind/old. How compatible is Debian with non-debian based distributions? -- /Jacob Carlborg
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 2012-11-10 17:14, Ellery Newcomer wrote: Ubuntu 12.10/gnome classic works well enough; just turn off compiz. I tried mint and ran into trouble while compiling llvm. make gobbled memory for a while, and then the desktop restarted itself (I guess?). All my windows: gone. I manage to turn of compiz but I don't know if I made some bad choices in the process because now I only have the desktop. No left or top bar. -- /Jacob Carlborg
Re: Binary compatibility on Linux
Jacob Carlborg wrote: > On 2012-11-11 10:30, Thomas Koch wrote: > >> The best way is to get your software in the official debian archive. >> There are infrastructure and established workflows to recompile packages >> for each Debian version. >> The backports archive contains newer versions of a package for the >> current stable Debian release. > > I don't want to limit myself to just the debian based package mangers. I > want my tools to be available/usable on all distributions. If your package is in Debian then it is automatically also in Ubuntu, Mint, Xandros, Univention, Aptosid, Knoppix and a few douzend more distributions which are all derivatives of Debian: http://wiki.debian.org/Derivatives/Census http://www.debian.org/misc/children-distros Roughly the other half(?) of the linux universe is based on Fedora, e.g. CentOS, Red Hat: https://fedoraproject.org/wiki/Derived_distributions So by getting your package in the archives of Debian and Fedora, you should serve the large majority of linux users. The Debian wiki has a list of advantages why somebody would want to have his software in a distributions archive: http://wiki.debian.org/AdvantagesForUpstream Best regards, Thomas Koch
Re: Const ref and rvalues again...
On Sunday, 11 November 2012 at 10:09:17 UTC, Jonathan M Davis
wrote:
It still prints "hello", even with full optimations turned on.
So, it must be
allocating a closure in spite of scope. So, it looks to me like
scope is just
completely ignored and does absolutely nothing at this point,
unless I'm just
completely missing something here.
Try this:
---
import std.stdio;
void delegate() global;
void foo(scope void delegate() del)
{
global = del;
}
void f()
{
{
char[5] bar = "hello";
foo((){writeln(bar);});
}
}
void smashStack() {
uint[1000] dummy = 0xbadcab1e;
asm { nop; }
}
void main()
{
char[7] baz = "goodbye";
f();
smashStack();
global();
}
---
David
Re: precise gc?
On Saturday, 10 November 2012 at 22:17:10 UTC, eskimo wrote: What is the current state? Is it enough to store a pointer in a ptrdiff_t variable instead of a pointer for the GC to ignore it For a precise GC (as in the thread title) yes, but not for the current D GC. or is my current trick of simply inverting its value required? You could use it, and come up with something else which also works on x86, etc., but I'd look into storing your weak reference (or whatever) in a page with the NO_SCAN attribute set. It will cause the GC to ignore it entirely. David
Re: GDC is this a bug or a feature?
On 11 November 2012 10:39, Russel Winder wrote: > > |> gdc -o lib_helloWorld.so -shared helloWorld.os > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o): > relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used > when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a: could not read symbols: Bad > value > collect2: ld returned 1 exit status > > > -- > Russel. > = > Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net > 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder I'd say feature. If libgphobos was a shared object, I don't believe you would get this. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Const ref and rvalues again...
11/11/2012 2:08 PM, Jonathan M Davis пишет:
On Sunday, November 11, 2012 13:36:05 Dmitry Olshansky wrote:
Nope. It's just that the stack is intact and contains: hello and goodbye
one after another. Without optimizations { } scope doesn't mean reuse
stack space.
Now if play with stack a bit, for me the next one prints:
-²↑
import std.stdio;
void delegate() global;
void foo(scope void delegate() del)
{
global = del;
}
void f()
{
{
char[5] bar = "hello";
foo((){writeln(bar);});
}
}
void main()
{
char[7] baz = "goodbye";
f();
global();
}
It still prints "hello", even with full optimations turned on.
I tried with and without optimizations. I get garbage as expected.
So, it must be
allocating a closure in spite of scope. So, it looks to me like scope is just
completely ignored and does absolutely nothing at this point, unless I'm just
completely missing something here.
Something must be screwed up. I dunno what, I use near-latest DMD from
github and Win32 binaries.
For good measure try making stack variables larger if you are on 64bit.
Drop in a couple of calls to writeln before and after calling 'f' it
should scramble the stack.
--
Dmitry Olshansky
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11 November 2012 10:43, Alix Pexton wrote: > >> >> You don't necessarily need a cross compiler to do the job. Set-up a >> raspbian chroot instead! >> >> There's some rough instructions here. >> >> http://superpiadventures.wordpress.com/2012/07/16/development-environment/ >> >> >> You are also able to debug programs through qemu, though there's a >> hurdle you have to jump through. >> >> >> http://tinkering-is-fun.blogspot.co.uk/2009/12/debugging-non-native-programs-with-qemu.html >> >> >> Regards, >> Iain. >> >> > > The comments on the first article say that using qemu is as slow as > compiling on the RasPi, and recommend using the cross-compiler instead. > Your milage may vary depending on what hardware you have. Personally I find it 3-4 times quicker to build (considering it takes about 24+ hours to built gdc on a RasPi device). > I followed the instructs anyway, and all seemed to go well, but they just > stop without detailing how to actually compile anything, or explaining what > has been done >< > > A... What's been done is a chroot system has been set-up with ARM binaries, instead of i386 or x86_64. qemu-debootstrap installs an executable qemu-arm-static inside this chroot, so when you try to run any ARM binaries, qemu kicks in and acts as an emulator. To compile, simply following the same instructions as per the gdc wiki. apt-get install all build deps, retrieve source, ./configure and make. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Const ref and rvalues again...
On 10 November 2012 21:07, Jonathan M Davis wrote:
> On Saturday, November 10, 2012 13:21:42 Manu wrote:
> > I'm still not buying this. Here's a common struct I will pass by ref
> > (perhaps the most common struct in my industry):
> >
> > struct Vector { float, x,y,z,w; }
> > struct Matrix { Vector xRow, yRow, zRow, wRow; }
> >
> > Vector mul( scope const ref Matrix m, scope const Vector v)
> > {
> > Vector v;
> > // perform a matrix multiply against the vector...
> > // this work uses every single field of the inputs given, but the
> result
> > it produces has to references to the sources.
> > // everything is operated on and copied to the output struct, which is
> > returned.
> > return result;
> > }
> >
> > Why should this be a problem?
> > The majority of my work-horse structs apply to this pattern. This is
> what I
> > imagine 'scope' to be for...
> > The main advantage I expect is that I can have confidence that passing
> > rvalues (temporaries) is safe, and that external code won't take
> references
> > to memory that I may not own/control. Is that not the point?
> >
> > Surely the problem that scope should be protecting against is a pointer
> to
> > any part of the argument escaping. *Copies* of values contained in the
> > argument/s are fine.
>
> H. scope on value types is pointless, because there are no references
> to
> escape, but if you pass by ref, then it does become possible for a pointer
> to
> the argument to escape,
Precisely, to me, this seems like the ENTIRE POINT of 'in'? (I originally
presumed 'in' implied ref, but I was wrong, 'in ref' is supported however)
but I don't know that that's actually actually covered
> by scope. The description for scope in docs is that "references in the
> pa
> rameter cannot be escaped (e.g. assigned to a global variable)." And
> taking the address of a local variable (which is the only way that any
> sort of
> reference to the data could escape) is never @safe anyway.
When did '@safe'ty enter into it? Are you saying that a ref variable is
somehow a local variable? It's a local pointer to a foreign variable... and
a function can usually operate on that data however it likes.
Scope would promise that nothing other than the function I give it to will
get its grubby little hands on it.
Let's say that function wanted to call through to some other function and
pass the variable along (by ref). Obviously, the second function would also
have to have it's inputs marked scope, to promise that it never escapes
from there.
I imagine scope similarly to const, once it goes scope, the whole callstack
must maintain the scope property, otherwise the outermost function can't
trust it anymore.
This makes perfect sense for any function that is likely to receive
immediate or local variables by reference (which is extremely common).
It also seems absolutely relevant to the rvalues -> ref thing.
If you passed in a
> pointer, and scope were fully working, then you'd be protected against the
> pointer escaping, but passing by ref isn't really the same thing. I'd have
> thought that taking the address of a variable passed by ref would fall into
> pretty much the same camp as taking the address of any other local
> variable,
> which is completely unsafe to escape to the point that I'm not sure that
> there's any point in protecting against it. It's just completely stupid to
> do
> anyway and is definitely @system. Outside of taking the address of a ref
> parameter, taking the address of a local variable and escpaing it is
> _always_
> going to result in garbage, and ref parameters aren't really references in
> the
> normal sense, so I don't know.
>
What do you mean 'aren't really references in the normal sense'?
You bring up a good point, but I don't know if it's applicable. Certainly,
> without the ref there (like is the case with the Vector that you're passing
> in), scope would never do anything, because it doesn't even theoretically
> have
> anything to do. It's purely a value type that's not even being passed by
> ref.
>
Correct, scope on a purely value type passed by-value means absolutely
nothing.
scope on a pointer parameter means something; I would expect the pointer
its self, nor a pointer INTO anything under the pointer could escape.
scope on a by-value parameter that contains pointers (like
delegates/slices) has meaning, I presume scope would be transitive like
const, apply the pointer rule above.
ref is sugar for a pointer, and the above applies verbatim. If you take the
address of the ref argument, you have the pointer, and it mustn't escape,
likewise, no pointers or pointer to anything beneath it.
If my imagination of this concept completely wrong?
This sounds useful to me, I can't imagine another scenario where the
keyword a) makes sense, and b) is useful...
In general though, putting scope on struct parameters would cause a lot of
> problems, because of arrays that they might hold and whatnot. Slices
> wouldn't
> be able t
Re: Binary compatibility on Linux
On 11/11/2012 11:57 AM, Thomas Koch wrote: So by getting your package in the archives of Debian and Fedora, you should serve the large majority of linux users. Which is well and good, but doesn't address the problem that software developers face, which is "How can I make directly available binaries of my programs that will work for any Linux user?" It's useful to be able to do that regardless of whether your software is FOSS and regardless of whether or not it's in distro repositories, because your latest release will always take time to propagate to the distros and because not everyone is comfortable compiling from source.
Re: Binary compatibility on Linux
On 2012-11-10 20:10, 1100110 wrote: Oldest system to reasonably support? I would say Debian Stable. It is used on a lot of server systems and isn't *too* far behind/old. How would Debian Stable compare to, say, a five year old Ubuntu LTS that is still supported? -- /Jacob Carlborg
[OT] Re: Immutable and unique in C#
On Fri, 09 Nov 2012 14:53:27 +0100 Sönke Ludwig wrote: > Just stumbled over this, which is describing a type system extension > for C# for race-free parallelism: > > http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf > Ugh, "researchers" really need to quit releasing shit in multi-column PDF. Fucking pain in the ass to read. They need to try researching what the current decade is, what do they think this is, 1950? Don't they ever even try to read their *own* shit? Or, heck, even *other* researcher's papers? Or do they just live and die by their printer? I really don't get why they keep doing it, makes no damn sense at all. Some sort of idiotically mandated requirement? And then they wonder why people dismiss/ignore them as out-of-touch ivory tower. Geez.
Re: precise gc?
> You could use it, and come up with something else which also > works on x86, etc., but I'd look into storing your weak reference > (or whatever) in a page with the NO_SCAN attribute set. It will > cause the GC to ignore it entirely. Thanks but that's no option for me, because I need the pointers, to be ignored by the GC, to be in the same page as pointers which should not be ignored. (Actually even in the same struct so they are really neighbors.)
Re: Binary compatibility on Linux
On Sun, 11 Nov 2012 12:45:56 +0100
Joseph Rushton Wakeling wrote:
> On 11/11/2012 11:57 AM, Thomas Koch wrote:
> > So by getting your package in the archives of Debian and Fedora,
> > you should serve the large majority of linux users.
>
> Which is well and good, but doesn't address the problem that software
> developers face, which is "How can I make directly available binaries
> of my programs that will work for any Linux user?"
>
I'm not a Linux expert, but I'm fairly certain the answer is "You
can't". Linux is very good at a lot of things, but standardization is
definitely not one of them. Linux is just far too divergent ("herding
cats" comes to mind) for a widely-compatible binary to be realistic.
The best that can be done is make a dead-simple-to-use script to grab
dependencies (isolated from the rest of the system if need be) and
compile.
> It's useful to be able to do that regardless of whether your software
> is FOSS and regardless of whether or not it's in distro repositories,
> because your latest release will always take time to propagate to the
> distros and because not everyone is comfortable compiling from source.
Is instantiabilty of templated types decidable?
This code implements sort of an unary counter:
class Elem( size_t mynumber) {
Elem!( mynumber +1)* next;
}
void main(){
auto unaryCounter= new Elem!0;
}
Although only `Elem!0' has to be instantiated dmd 2.060 on
windows shouts:
Error: template instance Elem!(500u) recursive expansion
This is the reason for the subject. Because:
a) Instantiability is decidable
Why does the compiler stop with the evaluation at that randomly
choosen and apparently hard coded value of 500 recursive
expansions?
b) Instantiability is not decidable
Why does the compiler even try to instantiate more than the
indeed needed type `Elem!0'?
I miss the rationale for this behaviour.
-manfred
Re: GDC is this a bug or a feature?
On Sunday, 11 November 2012 at 10:39:41 UTC, Russel Winder wrote: |> gdc -o lib_helloWorld.so -shared helloWorld.os /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o): relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a: could not read symbols: Bad value collect2: ld returned 1 exit status I've had the same problem when trying to compile a shared library, but with dmd. It turned out that to make a shared library you can't use phobos dependencies because it isn't ready to work with shared libraries. Indeed, if you remove any phobos dependencies, the shared library is compiled successfully. Well, that's the noob explanation, I don't know the details of why phobos doesn't work. My bet is that it is shipped as a static library, and (if I'm not wrong) you can't link a static library on a shared library... Still, that is a big problem that D has.
Re: Is instantiabilty of templated types decidable?
On Sunday, 11 November 2012 at 12:33:25 UTC, Manfred Nowak wrote: a) Instantiability is decidable Why does the compiler stop with the evaluation at that randomly choosen and apparently hard coded value of 500 recursive expansions? You are right, it is just an arbitrary limit, but useful to give the user at least somewhat useful diagnostics instead of just hitting a stack overflow eventually. b) Instantiability is not decidable Why does the compiler even try to instantiate more than the indeed needed type `Elem!0'? The other types _are_ needed to be known (e.g. for TypeInfo generation, and generally because the fields are always typed internally). You might be confusing this with knowing the _size_ of Elem!(n + 1) when calculating the size of Elem!(n) due to the recent discussion, which is indeed not necessary. David
Re: Is instantiabilty of templated types decidable?
On Sunday, 11 November 2012 at 12:33:25 UTC, Manfred Nowak wrote: a) Instantiability is decidable Why does the compiler stop with the evaluation at that randomly choosen and apparently hard coded value of 500 recursive expansions? It's not decidable. Consider use of static if. It's Turing complete. I can give an example if you like. b) Instantiability is not decidable Why does the compiler even try to instantiate more than the indeed needed type `Elem!0'? I miss the rationale for this behaviour. As David says, it's needed for TypeInfo etc.
Re: Normal/Gaussian random number generation for D
On 11/06/2012 07:14 PM, jerro wrote: In general I like the API in file normal.d attached to your original post. I think the engines should have an option to do some initialization in Normal's constructor, though. We could achieve that by calling _engine.initialize in Normal's constructors, if such method exists. What's wrong with such initialization being in the constructor of the relevant NormalEngine? I think that was your original idea, and I derailed it because of my misunderstanding of what you wanted to initialize. The users would need to construct their own instance of engine to use the function that takes engine as a parameter. So it would make sense to add helper functions for creating engine instances. In general the idea is that the engine should be something hidden; where you need to use it, you just need to pass the name as a template parameter; it should be rare that you really need to manually instantiate your own engine. But we can add such a helper function if you like. What I'm frustrated about is that as-is it's not possible to just have auto nrng = Normal(mean, sigma); ... but you have instead to write, auto nrng = Normal!()(mean, sigma); despite the fact that Normal has default template parameters given. So maybe a helper function normalRNG which returns an instance of Normal would also be helpful. There's one change that I think would make the API more convenient. Normal struct and the engine don't store an instance of a RNG , so they don't need to take it as a template parameter. We could make opCall methods templates instead. That way the users would never need to explicitly specify the type of the RNG. Good call. I've uploaded a tweaked version based on your comments here: https://github.com/WebDrake/phobos/tree/normal ... so feel free to pull, further revise and add in your Ziggurat implementation :-) I haven't yet written any of the helper functions you suggest, but will do so shortly based on your response to my above remarks.
Re: Binary compatibility on Linux
On 11/11/2012 01:19 PM, Nick Sabalausky wrote:
I'm not a Linux expert, but I'm fairly certain the answer is "You
can't". Linux is very good at a lot of things, but standardization is
definitely not one of them. Linux is just far too divergent ("herding
cats" comes to mind) for a widely-compatible binary to be realistic.
The best that can be done is make a dead-simple-to-use script to grab
dependencies (isolated from the rest of the system if need be) and
compile.
I think you're most likely right -- at least, it's impossible in the general
case if not perhaps for a narrow band of widely-used distros.
It's just that I think people were answering a different question from that
which the OP asked, and I think his actual question deserves a decent answer
(even if it's a negative one).
Re: deprecate deprecated?
On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the
deprecated
attribute - it's all-or-nothing approach, poor messages, etc.
Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
Anyone want to take on the challenge?
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's
with the command line switches.
Exactly, deprecated is one of those features that *needs* to be
in the compiler, at least part of it. Because is not only about
the deprecated attribute for user symbols, there are also
deprecated constructs in the language, that only the compiler can
detect and can emit messages for.
Having deprecated as a core part of the language is not an
option, is the only way to do it right, so why don't we just fix
it in the compiler then? Adding the deprecated("message") syntax
was a huge step forward. Now we just need an option to emit
deprecations as warnings and that's it. It's already there, you
just have to merge it :)
https://github.com/D-Programming-Language/dmd/pull/1185
Re: deprecate deprecated?
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote: On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote: I know there's been some long term unhappiness about the deprecated attribute - it's all-or-nothing approach, poor messages, etc. Each change in it changes the language and the compiler. I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning BTW, I already implemented that and is available as a pull request (I just called the option -di to follow the naming of -wi). https://github.com/D-Programming-Language/dmd/pull/1185 This pull request is available since July 2011 (was pull #248 back then), and I'm trying to convince Walter to merge it since then without any success. I'm really glad this finally came up here, maybe he finally understand the importance of having an usable deprecated implementation :) BTW, I think the default should be to have deprecations as warnings and not the other way around, but since I at least have the option to make them warnings, I'm fine.
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On Sunday, 11 November 2012 at 11:22:52 UTC, Iain Buclaw wrote: Your milage may vary depending on what hardware you have. Personally I find it 3-4 times quicker to build (considering it takes about 24+ hours to built gdc on a RasPi device). 6–8 hours to build?! I sure love building LDC on my ODROID-X. ;) David
Re: Getting rid of dynamic polymorphism and classes
How would you create a vector of canvas and iterate over them?
Re: Is instantiabilty of templated types decidable?
On 11/11/12 06:49, Peter Alexander wrote: > On Sunday, 11 November 2012 at 12:33:25 UTC, Manfred Nowak wrote: >> a) Instantiability is decidable >> Why does the compiler stop with the evaluation at that randomly >> choosen and apparently hard coded value of 500 recursive >> expansions? > > It's not decidable. Consider use of static if. It's Turing complete. I > can give an example if you like. > I'd like. An example might help me better understand why it's undecidable. [snip]
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11 November 2012 13:18, David Nadlinger wrote: > On Sunday, 11 November 2012 at 11:22:52 UTC, Iain Buclaw wrote: >> >> Your milage may vary depending on what hardware you have. Personally >> I find it 3-4 times quicker to build (considering it takes about 24+ >> hours to built gdc on a RasPi device). > > > 6–8 hours to build?! I sure love building LDC on my ODROID-X. ;) > > David Ya, but how many lines of code is LDC vs GDC+GCC. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: deprecate deprecated?
On 11-11-2012 14:18, Leandro Lucarella wrote: On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote: On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote: I know there's been some long term unhappiness about the deprecated attribute - it's all-or-nothing approach, poor messages, etc. Each change in it changes the language and the compiler. I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning BTW, I already implemented that and is available as a pull request (I just called the option -di to follow the naming of -wi). https://github.com/D-Programming-Language/dmd/pull/1185 This pull request is available since July 2011 (was pull #248 back then), and I'm trying to convince Walter to merge it since then without any success. I'm really glad this finally came up here, maybe he finally understand the importance of having an usable deprecated implementation :) BTW, I think the default should be to have deprecations as warnings and not the other way around, but since I at least have the option to make them warnings, I'm fine. Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries because it can break arbitrary build systems out there. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: deprecate deprecated?
On 11-11-2012 14:09, Leandro Lucarella wrote:
On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
Anyone want to take on the challenge?
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with the
command line switches.
Exactly, deprecated is one of those features that *needs* to be
in the compiler, at least part of it. Because is not only about
the deprecated attribute for user symbols, there are also
deprecated constructs in the language, that only the compiler can
detect and can emit messages for.
Having deprecated as a core part of the language is not an
option, is the only way to do it right, so why don't we just fix
it in the compiler then? Adding the deprecated("message") syntax
was a huge step forward. Now we just need an option to emit
deprecations as warnings and that's it. It's already there, you
just have to merge it :)
https://github.com/D-Programming-Language/dmd/pull/1185
I'm against that pull request. Not because I think it isn't useful, but
because I think it doesn't fix the problem.
Usage of deprecated symbol(s) should be a warning by default and the new
option should be used to turn that into an error; not the other way around.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Is instantiabilty of templated types decidable?
On Sunday, 11 November 2012 at 13:40:45 UTC, evansl wrote:
On 11/11/12 06:49, Peter Alexander wrote:
On Sunday, 11 November 2012 at 12:33:25 UTC, Manfred Nowak
wrote:
a) Instantiability is decidable
Why does the compiler stop with the evaluation at that
randomly
choosen and apparently hard coded value of 500 recursive
expansions?
It's not decidable. Consider use of static if. It's Turing
complete. I
can give an example if you like.
I'd like. An example might help me better understand why it's
undecidable.
[snip]
Collatz sequence.
struct Collatz(int n)
{
enum next = n % 2 == 0 ? n / 2 : 3 * n + 1;
Collatz!(next)* foo;
}
It's an unsolved problem in mathematics whether or not this
instantiates an infinite number of templates.
Re: Is instantiabilty of templated types decidable?
David Nadlinger wrote:
>> a) Instantiability is decidable
> an arbitrary limit, but useful
I doubt the usefullness of any value `v' ( here `v == 500')
because the recursive definition might come to an end at value
`v +1'. Especially in the case, that the coder knows of such a
limit, the limit should be adjustable---but an option for
adjusting the limit is missing.
>> b) Instantiability is not decidable
> The other types _are_ needed to be known
It is useless to force the compiler to know anything about a
type for which the instantiability is not decided---and it is a
prerequisite, that the instantiability is not decidable.
If the coder doesn't know the instantantiability either or
simply wants the compiler to stop at some point with the
expansions, the language should give the coder an oportunity to
declare those points.
For example: an attribute named `Undecided' can be used to
express such a declaration in the example given in the OP:
class Elem( size_t mynumber) {
Undecided( Elem!( mynumber +1)*) next;
}
Where the attribute `Undecided( T)' replaces `T' until its
instantiation by a type with similar meaning as "NaN" or `null',
for example `TypeWithUndecidedExistence' or `TWUE'. Of course:
although `TWUE' has `typeinfo' etc., `TWUE' poisons every type
constructing operation by that the result is again `TWUE'
-manfred
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
What's been done is a chroot system has been set-up with ARM binaries, instead of i386 or x86_64. qemu-debootstrap installs an executable qemu-arm-static inside this chroot, so when you try to run any ARM binaries, qemu kicks in and acts as an emulator. To compile, simply following the same instructions as per the gdc wiki. apt-get install all build deps, retrieve source, ./configure and make. :-) o.O you are still assuming I have way more pre-existing linux knowledge/experience than I actually do, I really do need this stuff explaining in tiny baby steps... I followed the instructions, pretty sure I will have messed up somewhere, read some more of the comments on the original qemu instructions and someone points out that if reports to be emulating the wrong arm processor, and no one has posted to say they have had any success, never a good sign >< A...
Re: deprecate deprecated?
On Sunday, 11 November 2012 at 13:59:59 UTC, Alex Rønne Petersen wrote: Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries +1. Or even plus a whole lot more, if I had multiple votes. David
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11 November 2012 15:13, Alix Pexton wrote: > >> What's been done is a chroot system has been set-up with ARM binaries, >> instead of i386 or x86_64. qemu-debootstrap installs an executable >> qemu-arm-static inside this chroot, so when you try to run any ARM >> binaries, qemu kicks in and acts as an emulator. >> >> To compile, simply following the same instructions as per the gdc >> wiki. apt-get install all build deps, retrieve source, ./configure >> and make. :-) >> > > o.O > > you are still assuming I have way more pre-existing linux > knowledge/experience than I actually do, I really do need this stuff > explaining in tiny baby steps... > > I followed the instructions, pretty sure I will have messed up somewhere, > read some more of the comments on the original qemu instructions and someone > points out that if reports to be emulating the wrong arm processor, and no > one has posted to say they have had any success, never a good sign >< > > A... Don't think that would be the case for you. It works just fine, just make sure you are using the correct configure --target flag. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Normal/Gaussian random number generation for D
What's wrong with such initialization being in the constructor of the relevant NormalEngine? I think that was your original idea, and I derailed it because of my misunderstanding of what you wanted to initialize. The problem is that structs can't have constructors with no parameters. In general the idea is that the engine should be something hidden; where you need to use it, you just need to pass the name as a template parameter; it should be rare that you really need to manually instantiate your own engine. But we can add such a helper function if you like. I agree that those helper functions are not very important, but on the other hand I don't think adding them costs us anything. But maybe we should take care of the other stuff first. What I'm frustrated about is that as-is it's not possible to just have auto nrng = Normal(mean, sigma); ... but you have instead to write, auto nrng = Normal!()(mean, sigma); despite the fact that Normal has default template parameters given. So maybe a helper function normalRNG which returns an instance of Normal would also be helpful. Yes, I think it would be. I've uploaded a tweaked version based on your comments here: https://github.com/WebDrake/phobos/tree/normal ... so feel free to pull, further revise and add in your Ziggurat implementation :-) I'll add the Zigggurat implementation, probably tomorrow.
Re: Immutable and unique in C#
On Fri, 09 Nov 2012 07:53:27 -0600, Sönke Ludwig wrote: Just stumbled over this, which is describing a type system extension for C# for race-free parallelism: http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf Independent of this article I think D is currently missing out a lot by omitting a proper unique type (a _proper_ library solution would be a start, but I'm not sure if that can handle all details). It would make a lot of the cases work that are currently simply not practical because of loads of casts that are necessary. What's wrong with std.typecons.Unique? By the way, back when concurrency in D was actively being discussed and developed, (IIRC) Walter did try to implement unique as a proper type in D, but ran into several gotchas. In essence, while we all want unique/mobile, for unique/mobile to be non-broken it also needs at least a lent/scope and an owned type. Ownership type systems are a relatively new area of CS and as demonstrated by the paper, still an active area of research. The thorny issue of these systems is that you need to associate variables with types. For example, this.x = that.y; is only valid if x and y are both owned by the same region. This is easy to verify at runtime, but not at compile-time. Anyways, ownership types (or whatever supersedes them) were pushed back to D3 and we were left with message passing for the common user, synchronized for traditional lock-based shared memory and shared for lock-free programming. P.S. Thanks for the link to the paper.
Re: Normal/Gaussian random number generation for D
On 11/11/2012 05:30 PM, jerro wrote: The problem is that structs can't have constructors with no parameters. Aaack, I'd completely forgotten that. OK, so we can go with the initialize function as you suggested. I suggest you add it in together with Ziggurat. I agree that those helper functions are not very important, but on the other hand I don't think adding them costs us anything. But maybe we should take care of the other stuff first. Well, they should be trivial enough to write, let's get Ziggurat in and working first and then add them. I'll add the Zigggurat implementation, probably tomorrow. Excellent! Will look forward to seeing that.
Re: Is instantiabilty of templated types decidable?
On 11/11/2012 03:45 PM, Peter Alexander wrote:
On Sunday, 11 November 2012 at 13:40:45 UTC, evansl wrote:
On 11/11/12 06:49, Peter Alexander wrote:
On Sunday, 11 November 2012 at 12:33:25 UTC, Manfred Nowak wrote:
a) Instantiability is decidable
Why does the compiler stop with the evaluation at that randomly
choosen and apparently hard coded value of 500 recursive
expansions?
It's not decidable. Consider use of static if. It's Turing complete. I
can give an example if you like.
I'd like. An example might help me better understand why it's
undecidable.
[snip]
Collatz sequence.
struct Collatz(int n)
{
enum next = n % 2 == 0 ? n / 2 : 3 * n + 1;
Collatz!(next)* foo;
}
It's an unsolved problem in mathematics whether or not this instantiates
an infinite number of templates.
The possible inputs are finite, so the property is decidable.
Something needs to happen with shared, and soon.
Hi, It's starting to get outright embarrassing to talk to newcomers about D's concurrency support because the most fundamental part of it -- the shared type qualifier -- does not have well-defined semantics at all. I'm certainly not alone in being annoyed by this state of affairs: http://d.puremagic.com/issues/show_bug.cgi?id=8993 I've posted rants about the state of shared before and, from the comments on those, it appears that what most people want shared to do is at least one (and usually multiple) of * make variables global (if appropriate in the context); * make the wrapped type completely separate from the unwrapped type; * make all operations be atomic; * make all operations result in memory barriers. At a glance, this looks fine. Exactly what you would want for shared types in a concurrent setting, right? Except, not really. I'll try to explain all of the unsolved problems with shared below... First of all, the fact that shared(T) is completely separate from T (i.e. no conversions allowed, except for primitive types) is a huge usability problem. In practice, it means that 99% of the standard library is unusable with shared types. Hell, even most of the runtime doesn't work with shared types. I don't know how to best solve this particular problem; I'm just pointing it out because anyone who tries to do anything non-trivial with shared will invariably run into this. Second, the idea of making shared insert atomic operations is an absolute fallacy. It only makes sense for primitive types for the most part, and even for those, what sizes are supported depends on the target architecture. A number of ideas have come up to solve this problem: * We make shared(T) not compile for certain Ts depending on the target architecture. I personally think this is a terrible idea because most code using shared will not be portable at all. * We require any architecture D targets to support atomic operations for a certain size S at the very least. This is fine for primitives up to 64 bits in size, but doesn't clear up the situation for larger types (real, complex types, cent/ucent, ...). * We make shared not insert atomic operations at all (thus making it kind of useless for anything but documentation). * (Possibly others I have forgotten; please let me know if this is the case.) I don't think any of these are particularly attractive, to be honest. If we do make shared insert atomic operations, we would also have to consider the memory ordering of those operations. Third, we have memory barriers. I strongly suspect that this is a misnomer in most cases where people have suggested this; it's generally not useful to have a compiler insert barriers because they are used to control ordering of load/store operations which is something the programmer will want to do explicitly. In any case, the compiler can't usefully figure out where to put barriers, so it would just result in really bad performance for no apparent gain. Fourth, there is implementation complexity. If shared is meant to insert specialized instructions, it will result in effectively two code paths for most code generation in any D compiler (read: maintenance nightmare). Fifth, it is completely unclear whether casting to and from shared is legal (but with a big fat "caution" sign like casting away const) or if it's undefined behavior. Making it undefined behavior would further increase the usability problem I described above. And finally, the worst part of all of this? People writing code that uses shared today are blindly assuming it actually does the right thing. It doesn't. Their code will break on any non-x86 platform. This is an absolutely horrifying situation now that ARM, MIPS, and PowerPC are starting to become viable targets for D. Something needs to be done about shared. I don't know what, but the current situation is -- and I'm really not exaggerating here -- laughable. I think we either need to just make it perfectly clear that shared is for documentation purposes and nothing else, or, figure out an alternative system to shared, because I don't see shared actually being useful for real world work no matter what we do with it. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Immutable and unique in C#
Am 11.11.2012 18:20, schrieb Robert Jacques: > > What's wrong with std.typecons.Unique? - Does not implicitly cast to immutable - Has no way to enforce uniqueness of data referenced within the contained object - Cannot be passed between threads (i.e. in std.concurrency) and if it would be passable, it would not be safe - Does not allow temporal elevation to non-unique in pure contexts - No support for arrays and unique partitions Probably more, but basically in its current form it's mostly useless apart from documenting the intent. Some of the things can be fixed in the library type, but to make it really sound and useful, a library solution is not enough (at least not with the current means that the language offers). > By the way, back when concurrency in D was actively being discussed and > developed, (IIRC) Walter did try to implement unique as a proper type in > D, but ran into several gotchas. Do you remember which? All I could find was a thread stating that Walter did not like the idea of adding an additional transitive type modifier along const, immutable and shared because of the combinatorial number of types. Oddly, I could have sworn that I have commented on unique at that time, but can't find that either. > In essence, while we all want > unique/mobile, for unique/mobile to be non-broken it also needs at least > a lent/scope and an owned type. The system described in the paper does not need need lent/owned types. That can be attributed to the fact that their function definition disallows access of mutable global fields. So as long as only 'pure' functions operate on a given 'isolated' value, their recovery rules allow working pretty comfortable, while still statically enforcing memory isolation. Calling normal, impure methods or functions would have to break the 'isolated' property and inhibit recovery. This would be the place where the system with 'lent'/'owned' would allow more freedom, but only at the cost of a generally higher complexity. > Ownership type systems are a relatively > new area of CS and as demonstrated by the paper, still an active area of > research. The thorny issue of these systems is that you need to > associate variables with types. For example, this.x = that.y; is only > valid if x and y are both owned by the same region. This is easy to > verify at runtime, but not at compile-time. At least the following assignments can be verified statically using only local information, no need to track exact memory region ownership: unique <- unique immutable <- unique writable <- unique writable <- writable this.x = this.y inside an 'isolated' memory region would be valid as long as it happens in a pure context and no non-unique/non-immutable values are passed into the function. Anything else would inhibit recovery of 'isolated' after the implicit conversion to 'writable' that is necessary to pass the object to a function/method. > Anyways, ownership types (or > whatever supersedes them) were pushed back to D3 and we were left with > message passing for the common user, synchronized for traditional > lock-based shared memory and shared for lock-free programming. Yeah, I'm well aware of that.. unfortunately ;) This system has the potential to be backward (vs current state) and forward (vs a full ownership system) compatible, while not affecting anything of the existing language (like needing to store explicit ownership information). However, I have to admit that without actually trying it and seeing how usable it is first hand, it's difficult to tell how usable it is in practice (e.g. because D functions have to be explicitly tagged 'pure' for the recovery to work). Maybe also error messages would be difficult to understand or something else.
Re: Binary compatibility on Linux
On Sun, 2012-11-11 at 07:19 -0500, Nick Sabalausky wrote:
[…]
> I'm not a Linux expert, but I'm fairly certain the answer is "You
> can't". Linux is very good at a lot of things, but standardization is
> definitely not one of them. Linux is just far too divergent ("herding
> cats" comes to mind) for a widely-compatible binary to be realistic.
> The best that can be done is make a dead-simple-to-use script to grab
> dependencies (isolated from the rest of the system if need be) and
> compile.
[…]
There is only one Linux, well except that they keep evolving it and
changing the version number. Linux is very standardized in that there is
only one. There is no Linux divergence as there was UNIX divergence.
There are many, many, Linux-based distributions. The compilers vary, the
version of Linux varies, the libraries vary, the packaging system
varies. Binary compatibility across all of these is clearly impossible.
This is not a problem, this is the antithesis of problem, as long as you
allow the platform packagers to package or ship source and a build
specification. Hence aptitude, yum, Waf and such stuff.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: GDC is this a bug or a feature?
On Sun, 2012-11-11 at 11:17 +, Iain Buclaw wrote: […] > I'd say feature. If libgphobos was a shared object, I don't believe > you would get this. So the upshot is that we need to indent for libgphobos2.so in order for D to be useful in association with Python and ctypes. I guess the question is whether, like Go, D will eschew shared objects, or whether, like C and C++, D will embrace shared objects. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Something needs to happen with shared, and soon.
On 11/11/12, Alex Rønne Petersen wrote: > And finally, the worst part of all of this? People writing code that > uses shared today are blindly assuming it actually does the right thing. > It doesn't. I think most people probably don't even use shared due to lacking Phobos support. E.g. http://d.puremagic.com/issues/show_bug.cgi?id=7036 Not even using the write functions worked on shared types until 2.059 (e.g. printing shared arrays). 'shared' has this wonderfully attractive name to it, but apparently it doesn't have much guarantees? E.g. Walter's comment here: http://d.puremagic.com/issues/show_bug.cgi?id=8077#c1 So +1 from me just because I have no idea what shared is supposed to guarantee. I've just stubbornly used __gshared variables because std.concurrency.send() doesn't accept mutable data. send() doesn't work with shared either, so I have no clue.. :)
Re: GDC is this a bug or a feature?
On 11 November 2012 19:03, Russel Winder wrote: > On Sun, 2012-11-11 at 11:17 +, Iain Buclaw wrote: > […] >> I'd say feature. If libgphobos was a shared object, I don't believe >> you would get this. > > So the upshot is that we need to indent for libgphobos2.so in order for > D to be useful in association with Python and ctypes. > > I guess the question is whether, like Go, D will eschew shared objects, > or whether, like C and C++, D will embrace shared objects. > I'm genuinely optimistic about embracing shared objects. Though I've taken a cathedral stance and will not be releasing anything until it is ready. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Something needs to happen with shared, and soon.
Fully agree. Kind Regards Benjamin Thaut
Re: Something needs to happen with shared, and soon.
Alex Rønne Petersen: Something needs to be done about shared. I don't know what, Maybe deprecate it and introduce something else that is rather different and based on thought-out theory? Bye, bearophile
Re: Is instantiabilty of templated types decidable?
On Sun, 11 Nov 2012 19:37:45 +0100
Timon Gehr wrote:
> On 11/11/2012 03:45 PM, Peter Alexander wrote:
> >
> > Collatz sequence.
> >
> > struct Collatz(int n)
> > {
> > enum next = n % 2 == 0 ? n / 2 : 3 * n + 1;
> > Collatz!(next)* foo;
> > }
> >
> > It's an unsolved problem in mathematics whether or not this
> > instantiates an infinite number of templates.
>
> The possible inputs are finite, so the property is decidable.
Technically, yea, but I think upwards of ~4 billion template
instantiations is quite unrealistic, to the point of being effectively
undecidable.
Re: Undefined identifier WIN32_FILE_ATTRIBUTE_DATA
On Sun, 11 Nov 2012 08:03:40 -, creatio wrote: I'm not sure if this is the correct forum. But It looks like I'm one of the few people that ran into this. I've recently upgraded to 2.60 and been getting this error when compiling: Error: undefined identifier WIN32_FILE_ATTRIBUTE_DATA D:\__dev\D\dmd2\src\phobos\std\file.d 530 Now I have found the thread of Walter at http://www.digitalmars.com/d/archives/digitalmars/D/announce/D_version_of_MicroEmacs_24416.html , but it didn't help me much to solving my problem. Does anyone have an idea how I can fix this :-S Try to reduce your code down to a sample which fails and post it here. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Is instantiabilty of templated types decidable?
On Sunday, 11 November 2012 at 20:40:35 UTC, Nick Sabalausky wrote: The possible inputs are finite, so the property is decidable. Technically, yea, but I think upwards of ~4 billion template instantiations is quite unrealistic, to the point of being effectively undecidable. My thoughts exactly. Using the template system in this way looks like abuse rather than being practical. There must be alternative methods to get the same results for whatever you may be attempting. What we could do is set a practical limit of some default number. 500 appears to be the default limit right now, although in reality without an official written spec we have nothing specific to expect and rely on. I do agree with manfred that the limit is arbitrary and there may be a few valid use cases where the number should be user adjustable. --rt
Re: Something needs to happen with shared, and soon.
On Sunday, 11 November 2012 at 19:28:30 UTC, Andrej Mitrovic
wrote:
On 11/11/12, Alex Rønne Petersen wrote:
And finally, the worst part of all of this? People writing
code that
uses shared today are blindly assuming it actually does the
right thing.
It doesn't.
I think most people probably don't even use shared due to
lacking
Phobos support. E.g.
http://d.puremagic.com/issues/show_bug.cgi?id=7036
Not even using the write functions worked on shared types until
2.059
(e.g. printing shared arrays).
'shared' has this wonderfully attractive name to it, but
apparently it
doesn't have much guarantees? E.g. Walter's comment here:
http://d.puremagic.com/issues/show_bug.cgi?id=8077#c1
So +1 from me just because I have no idea what shared is
supposed to
guarantee. I've just stubbornly used __gshared variables because
std.concurrency.send() doesn't accept mutable data. send()
doesn't
work with shared either, so I have no clue.. :)
Fix support for shared(T) in std.variant, and you will have fixed
send() as well. Meanwhile, in common cases a simple wrapper
struct suffices.
##
module toy;
import std.concurrency, std.stdio;
struct SImpl {
string s;
int i;
}
alias shared( SImpl ) S;
struct Msg { S s; }
struct Quit {}
S global = S( "global", 999 );
void main () {
auto child = spawn( &task );
S s = S( "abc", 42 );
child.send( Msg( s ) );
child.send( Msg( global ) );
child.send( Quit() );
}
void task () {
bool sentinel = true;
while ( sentinel ) {
receive(
( Msg msg ) { writeln( msg.s.s, " -- ", msg.s.i ); },
( Quit msg ) { sentinel = false; }
);
}
}
##
grant@aesgard ~/Projects/D/foo/shared_test $ dmd toy && ./toy
abc -- 42
global -- 999
-- Chris Nicholson-Sauls
Re: deprecate deprecated?
On Sunday, November 11, 2012 15:01:14 Alex Rønne Petersen wrote: > I'm against that pull request. Not because I think it isn't useful, but > because I think it doesn't fix the problem. > > Usage of deprecated symbol(s) should be a warning by default and the new > option should be used to turn that into an error; not the other way around. Agreed. Otherwise, you can't deprecate something without immediately breaking code, which means that if you're trying to never immediately break people's code when making a change (which is the position that Phobos is in), then you can't use deprecated. "Scheduling" stuff for deprecation has helped, but it hasn't really fixed all that much. Making it so that deprecated emited a warning instead of an error and otherwise did not affect compilation _would_ fix it (as long as -w didn't affect it), but then a flag for making it an error is needed so that people can be sure that they've completely removed all deprecated features from their code (due to how deprecated affects conditional compilation). - Jonathan M Davis
Re: deprecate deprecated?
On Sunday, November 11, 2012 16:16:33 David Nadlinger wrote: > On Sunday, 11 November 2012 at 13:59:59 UTC, Alex Rønne Petersen > > wrote: > > Yes, definitely warnings by default. The current system makes > > the deprecated keyword useless in practice for libraries > > +1. Or even plus a whole lot more, if I had multiple votes. They're obviously not regulated, so just go for typeof(vote).max. ;) - Jonathan M Davis
Re: Const ref and rvalues again...
On Sunday, November 11, 2012 12:10:59 David Nadlinger wrote:
> On Sunday, 11 November 2012 at 10:09:17 UTC, Jonathan M Davis
>
> wrote:
> > It still prints "hello", even with full optimations turned on.
> > So, it must be
> > allocating a closure in spite of scope. So, it looks to me like
> > scope is just
> > completely ignored and does absolutely nothing at this point,
> > unless I'm just
> > completely missing something here.
>
> Try this:
>
> ---
> import std.stdio;
>
> void delegate() global;
>
> void foo(scope void delegate() del)
> {
> global = del;
> }
>
>
> void f()
> {
> {
> char[5] bar = "hello";
> foo((){writeln(bar);});
> }
> }
>
> void smashStack() {
> uint[1000] dummy = 0xbadcab1e;
> asm { nop; }
> }
>
> void main()
> {
> char[7] baz = "goodbye";
> f();
> smashStack();
> global();
> }
> ---
That did it. And if scope is removed, it works again. I clearly don't get the
low level stuff though, since it's just plain bizarre to me that the previous
example didn't do it.
- Jonathan M Davis
Re: Const ref and rvalues again...
On Sunday, November 11, 2012 15:17:03 Dmitry Olshansky wrote: > Something must be screwed up. I dunno what, I use near-latest DMD from > github and Win32 binaries. I'm on 64-bit Linux, so that may change things a bit. - Jonathan M Davis
Re: Something needs to happen with shared, and soon.
On Sunday, 11 November 2012 at 20:08:25 UTC, Benjamin Thaut wrote: Fully agree. +1
alias this to a template function
I'm just curious if this is supposed to eventually work:
struct Test {
alias get this;
T get(T)() {
return T.init;
}
}
void main() {
Test t;
int a = t;
}
Where the int a = t would be expanded to int a = t.get!int;
The TDPL book says multiple alias this is supposed to be allowed,
so you can subtype multiple things, but I'm wondering if we're
eventually going to get the template to do multiple subtypes with
one function.
Re: alias this to a template function
On Sunday, 11 November 2012 at 21:36:41 UTC, Adam D. Ruppe wrote:
I'm just curious if this is supposed to eventually work:
How can the compiler possibly figure out what T is supposed to be?
This will never work. It doesn't even work without the alias this.
void main() {
Test t;
int a = t.get(); // cannot deduce T
}
Re: Const ref and rvalues again...
On Sunday, November 11, 2012 13:30:12 Manu wrote:
> What do you mean 'aren't really references in the normal sense'?
ref is not really part of a variable's type. It's just a storage class and is
really only applicable in very specific circumstances. A function parameter is
a local variable, but ref makes it so that it just so happens to affect a
variable outside the function as well. The semantics of the function itself or
how the parameter is used aren't any different either way. So, if you were to
remove ref from the parameter, the function itself would be unaffected
semantically-speaking (it would affect the code generation some though). It's
the caller whose semantics change.
This is in direct contrast with a pointer or reference type where the fact
that it refers to something else outside the function is fully part of the
type.
Taking the address of a local variable is already something that is incredibly
unsafe and doesn't work. So, anyone doing it is being an idiot anyway. And if
it's _always_ stupid, then protecting it with scope isn't really necessary.
pure mostly stops anything like that from happening in the general case, but
doesn't prevent people from doing stupid stuff like
int* foo() pure
{
int i;
return bar(&i);
}
int* bar(int* p) pure
{
return p;
}
Regardless, my point was that the refness of the parameter isn't really part
of the type of the parameter, whereas all other issues with reference escaping
that scope would affect _are_ part of the type. So, you're talking about scope
protecting against something quite different from what it would protect from in
all other circumstances. Protecting against escaping a ref parameter and a
reference type escaping are two different (albeit not completely unrelated)
things.
Honestly, before you brought up the possibility of scope protecting against
pointers to ref parameters escaping, it had never occurred to me. I've never
seen anyone bring it up before. And as you're talking about protecting against
escaping a pointer to a local variable, which is an incredibly stupid thing to
do anyway, I'm not sure that the protection is really needed.
But I don't know what Walter's or Andrei's intentions were with regards to
whether scope would extend to the fact that the parameter is ref. I don't
think that it's necessarily the case that it wouldn't, but you're then
protecting against escaping a pointer to a local variable (albeit one which
affects a variable outside of the function) rather than against escaping a
reference type. And from everything I've seen, it's protecting against
escaping reference types which was its purpose.
Unfortunately, TDPL doesn't seem to discuss scope parameters at all (I thought
that it did, but I can't find it anywhere now if it does), meaning that the
online docs are the only official documentation on scope, and all other
information on it comes from newsgroup discussions on the matter. It's quite
possible that many of us have misunderstood aspects of what scope parameters
were intended to do.
So, assuming that if/when scope actually starts affecting more than delegates
as quite a few us think that it's supposed to do, then what you're looking for
may very well be on the table, much as I wouldn't have expected it to be. I
don't know.
Feel free to create an enhancement request for it. Even it wasn't part of the
original intention of scope parameters, Walter may think that it's worth
making it so that it is.
> That would be the point though. If you don't want that, then you don't want
> scope.
The problem is that in most cases, I really don't think that that is what the
average programmer wants, and there _are_ people who use in as a matter
course. It would be one thing if you had to explicitly use scope, then I
suspect that it wouldn't be used as a matter of course by much of anyone. For
the most part, it would then just be used when the programmer knew that that's
what they wanted. But with in, so many people seem to really like the concept
of it being the opposite of out that they use it as a matter of course without
understanding the consequences.
- Jonathan M Davis
Re: deprecate deprecated?
On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis wrote: They're obviously not regulated, so just go for typeof(vote).max. ;) I'm afraid this would backfire – assuming that votes are integral, if somebody else also supported the issue after me, then the votes would either be reset or we would have undefined behavior. ;) David
Re: alias this to a template function
On Sunday, 11 November 2012 at 21:42:45 UTC, Peter Alexander wrote: How can the compiler possibly figure out what T is supposed to be? How does it figure out which alias this right now? Looking at the dmd source, it looks like it calls implicitCastTo, which eventually calls another function to resolve the alias this. The requested type is known to the implicit cast function, so it's possible to pass that on and use it as the template argument. Since I think knowing the requested type would be necessary to resolve multiple alias this, I figure it will be changed to pass it on eventually anyway. But actually instantiating the template is another step that doesn't match the normal dot behavior, as you pointed out, so that left me wondering if they were planning to do it or not. It'd be different than the normal deduction, but it'd be potentially useful too, expanding alias this to work on more than just a pre-written list of types.
Re: alias this to a template function
On Sunday, November 11, 2012 22:36:40 Adam D. Ruppe wrote:
> I'm just curious if this is supposed to eventually work:
>
> struct Test {
> alias get this;
> T get(T)() {
> return T.init;
> }
> }
>
> void main() {
> Test t;
> int a = t;
> }
>
>
> Where the int a = t would be expanded to int a = t.get!int;
>
> The TDPL book says multiple alias this is supposed to be allowed,
> so you can subtype multiple things, but I'm wondering if we're
> eventually going to get the template to do multiple subtypes with
> one function.
You can only alias types and variables. A templated type isn't a type until
it's been fully instantiated.
- Jonathan M Davis
Re: deprecate deprecated?
On Sunday, November 11, 2012 23:06:45 David Nadlinger wrote: > On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis > > wrote: > > They're obviously not regulated, so just go for > > typeof(vote).max. ;) > > I'm afraid this would backfire – assuming that votes are > integral, if somebody else also supported the issue after me, > then the votes would either be reset or we would have undefined > behavior. ;) No. This is D. It wouldn't be undefined at all. It would just wrap around to typeof(vote).min. That should be completely defined for integral types (for that matter, it's well-defined in C land too. It's just that you have issues with the size of the type changing depending on which machine you compile on). I'm not sure what happens with non-integral types though. I _was_ pretty much assuming an integral type. But yes, that would be a problem, because you would have nullified all future votes. typeof(vote.max) / 2 it is then. ;) - Jonathan M Davis
Re: alias this to a template function
On Sunday, 11 November 2012 at 22:25:11 UTC, Jonathan M Davis
wrote:
You can only alias types and variables. A templated type isn't
a type until it's been fully instantiated.
This compiles today though:
struct Test{
alias get this;
T get(T)() { return T.init; }
}
It is just useless because there's no way to instantiate it
though the alias this (you must do .get!T).
Re: deprecate deprecated?
On Sunday, 11 November 2012 at 22:28:58 UTC, Jonathan M Davis wrote: for that matter, it's well-defined in C land too. Signed integer overflow isn't well-defined in C; only operations on unsigned types are guaranteed to wrap around. And since people might also want to downvote a proposal… Anyway, what was the topic? ;) David
Re: Binary compatibility on Linux
On Sun, 11 Nov 2012 04:45:48 -0600, Jacob Carlborg wrote: On 2012-11-10 20:10, 1100110 wrote: Oldest system to reasonably support? I would say Debian Stable. It is used on a lot of server systems and isn't *too* far behind/old. How compatible is Debian with non-debian based distributions? I've used alien a fair number of times, and its usually "just worked." Here is an FAQ: http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html That link provides a lot of info. Honestly, unless Ubuntu has done something really weird, Debian should be just as compatible with non-Debian distros as Ubuntu is. Give me a solid example of what you mean and I'll take a closer look. Ubuntu has a Debian-for-Ubuntu-Devs page. https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers That should explain something at least. How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which loses support in April? I'm not entirely sure. http://packages.ubuntu.com/hardy/ http://packages.debian.org/stable/
Re: Something needs to happen with shared, and soon.
On Sun, 11 Nov 2012 22:19:08 +0100, martin wrote: > On Sunday, 11 November 2012 at 20:08:25 UTC, Benjamin Thaut wrote: >> Fully agree. > > +1 +1. I find it so broken that I have to avoid using it in all but the most trivial situations.
Re: alias this to a template function
On Sunday, November 11, 2012 23:28:21 Adam D. Ruppe wrote:
> On Sunday, 11 November 2012 at 22:25:11 UTC, Jonathan M Davis
>
> wrote:
> > You can only alias types and variables. A templated type isn't
> > a type until it's been fully instantiated.
>
> This compiles today though:
>
> struct Test{
> alias get this;
> T get(T)() { return T.init; }
> }
>
>
> It is just useless because there's no way to instantiate it
> though the alias this (you must do .get!T).
Weird. I've never seen a situation before where an alias accepted a partially-
instantiated template. I'm _very_ surprised that that compiles.
- Jonathan M Davis
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11/11/2012 02:50 AM, Jacob Carlborg wrote: On 2012-11-10 17:14, Ellery Newcomer wrote: Ubuntu 12.10/gnome classic works well enough; just turn off compiz. I tried mint and ran into trouble while compiling llvm. make gobbled memory for a while, and then the desktop restarted itself (I guess?). All my windows: gone. I manage to turn of compiz but I don't know if I made some bad choices in the process because now I only have the desktop. No left or top bar. Ouch. Looks like what I should have said is gnome classic (no effects), and I guess compizconfig didn't actually turn anything off. Also, I'm working from a clean install, so that might account for behavior difference. It still sucks, though. Found myself wishing I had installed server instead.
Re: alias this to a template function
On 11/11/2012 10:42 PM, Peter Alexander wrote:
On Sunday, 11 November 2012 at 21:36:41 UTC, Adam D. Ruppe wrote:
I'm just curious if this is supposed to eventually work:
How can the compiler possibly figure out what T is supposed to be?
Just how it figures out the parameter types of lambdas.
For example, defer the type checking, alias this lookup and template
instantiation into the implicit conversion AST node.
This will never work.
Maybe it wont.
It doesn't even work without the alias this.
void main() {
Test t;
int a = t.get(); // cannot deduce T
}
Which only means it does not currently work.
Re: Is instantiabilty of templated types decidable?
On 11/11/2012 09:40 PM, Nick Sabalausky wrote:
On Sun, 11 Nov 2012 19:37:45 +0100
Timon Gehr wrote:
On 11/11/2012 03:45 PM, Peter Alexander wrote:
Collatz sequence.
struct Collatz(int n)
{
enum next = n % 2 == 0 ? n / 2 : 3 * n + 1;
Collatz!(next)* foo;
}
It's an unsolved problem in mathematics whether or not this
instantiates an infinite number of templates.
The possible inputs are finite, so the property is decidable.
Technically, yea, but I think upwards of ~4 billion template
instantiations is quite unrealistic, to the point of being effectively
undecidable.
Undecidability has a precise definition in theoretical computer science.
It means that there is no algorithm that implements the given predicate.
It is a lot stronger than impracticality of implementation.
I claim that the following, very simple algorithm decides whether or not
the template above terminates instantiation without errors with the
given parameter:
bool collatzTerminates(int n){ return true; }
Therefore, a conforming D compiler implementation could evaluate the
template above lazily.
Re: alias this to a template function
Jonathan M Davis wrote: > where an alias accepted a partially-instantiated template It seems to be like any non-instantiated function `template'--- only declared within a non templatized `struct'. -manfred
Re: Something needs to happen with shared, and soon.
Le 11/11/2012 23:36, Graham St Jack a écrit : On Sun, 11 Nov 2012 22:19:08 +0100, martin wrote: On Sunday, 11 November 2012 at 20:08:25 UTC, Benjamin Thaut wrote: Fully agree. +1 +1. I find it so broken that I have to avoid using it in all but the most trivial situations. That isn't a bad thing in itself.
Re: Something needs to happen with shared, and soon.
On Monday, November 12, 2012 01:17:06 deadalnix wrote: > Le 11/11/2012 23:36, Graham St Jack a écrit : > > On Sun, 11 Nov 2012 22:19:08 +0100, martin wrote: > >> On Sunday, 11 November 2012 at 20:08:25 UTC, Benjamin Thaut wrote: > >>> Fully agree. > >> > >> +1 > > > > +1. > > > > I find it so broken that I have to avoid using it in all but the most > > trivial situations. > > That isn't a bad thing in itself. I don' think that it's really intended that shared by 100% easy to use. You're _supposed_ to use it sparingly. But at this point, it borders on being utterly unusable. We have a bit of a problem with the basic idea though in that you're not supposed to be using shared much, and it's supposed to be segregated such that having the shared equivalent of const (as in it works with both shared and non-shared) would pose a big problem (it's also probably untenable with memory barriers and the like), but if you _don't_ have something like that, you either can't use shared with much of anything, or you have to cast it away all over the place, which loses all of the memory barriers or whatnot. We have conflicting requirements which aren't being managed very well. I don't know how protected shared really needs to be though. Anything involving shared should make heavy use of mutexes and synchronized and whatnot meaning that at least some of the protections that people want with shared are useless unless you're writing code which is being stupid and not using mutexes or whatnot. So, casting away shared might not actually be that big a deal so long as it's temporary to call a function (as opposed to stashing the variable away somewhere) and that call is protected by a mutex or other thread- protection mechanism. At the moment, I think that the only way to make stuff work with both shared and unshared (aside from using lots of casts) is to make use of templates, and since most of druntime and Phobos isn't tested with shared, things like Unqual probably screw with that pretty thoroughly. It's at least conceivable though that stuff like std.algorithm could work with shared just fine. I don't think that there's much question though that shared is the major chink in our armor with regards to thread-local by default. The basic idea is great, but the details still need some work. - Jonathan M Davis
Re: Immutable and unique in C#
On 11/11/2012 10:59 AM, Sönke Ludwig wrote:
However, I have to admit that without actually trying it and seeing how
usable it is first hand, it's difficult to tell how usable it is in
practice (e.g. because D functions have to be explicitly tagged 'pure'
for the recovery to work).
With purity, transitive immutability, and transitive sharing, D already is quite
a long way down the road. But we can go further, as currently new() and pure
functions are not exploited for their implicit casting ability.
For example,
struct S { int x; }
...
shared S* s = new S();
can be made to work, as can:
pure S* foo(S* s);
shared S* s = foo(new S());
I'm not convinced that adding a "unique" qualifier is strictly necessary.
Re: Something needs to happen with shared, and soon.
drop it in favour of : http://forum.dlang.org/post/k7j1ta$2kv8$1...@digitalmars.com On Sunday, 11 November 2012 at 18:46:12 UTC, Alex Rønne Petersen wrote: Hi, It's starting to get outright embarrassing to talk to newcomers about D's concurrency support because the most fundamental part of it -- the shared type qualifier -- does not have well-defined semantics at all. I'm certainly not alone in being annoyed by this state of affairs: http://d.puremagic.com/issues/show_bug.cgi?id=8993 I've posted rants about the state of shared before and, from the comments on those, it appears that what most people want shared to do is at least one (and usually multiple) of * make variables global (if appropriate in the context); * make the wrapped type completely separate from the unwrapped type; * make all operations be atomic; * make all operations result in memory barriers. At a glance, this looks fine. Exactly what you would want for shared types in a concurrent setting, right? Except, not really. I'll try to explain all of the unsolved problems with shared below... First of all, the fact that shared(T) is completely separate from T (i.e. no conversions allowed, except for primitive types) is a huge usability problem. In practice, it means that 99% of the standard library is unusable with shared types. Hell, even most of the runtime doesn't work with shared types. I don't know how to best solve this particular problem; I'm just pointing it out because anyone who tries to do anything non-trivial with shared will invariably run into this. Second, the idea of making shared insert atomic operations is an absolute fallacy. It only makes sense for primitive types for the most part, and even for those, what sizes are supported depends on the target architecture. A number of ideas have come up to solve this problem: * We make shared(T) not compile for certain Ts depending on the target architecture. I personally think this is a terrible idea because most code using shared will not be portable at all. * We require any architecture D targets to support atomic operations for a certain size S at the very least. This is fine for primitives up to 64 bits in size, but doesn't clear up the situation for larger types (real, complex types, cent/ucent, ...). * We make shared not insert atomic operations at all (thus making it kind of useless for anything but documentation). * (Possibly others I have forgotten; please let me know if this is the case.) I don't think any of these are particularly attractive, to be honest. If we do make shared insert atomic operations, we would also have to consider the memory ordering of those operations. Third, we have memory barriers. I strongly suspect that this is a misnomer in most cases where people have suggested this; it's generally not useful to have a compiler insert barriers because they are used to control ordering of load/store operations which is something the programmer will want to do explicitly. In any case, the compiler can't usefully figure out where to put barriers, so it would just result in really bad performance for no apparent gain. Fourth, there is implementation complexity. If shared is meant to insert specialized instructions, it will result in effectively two code paths for most code generation in any D compiler (read: maintenance nightmare). Fifth, it is completely unclear whether casting to and from shared is legal (but with a big fat "caution" sign like casting away const) or if it's undefined behavior. Making it undefined behavior would further increase the usability problem I described above. And finally, the worst part of all of this? People writing code that uses shared today are blindly assuming it actually does the right thing. It doesn't. Their code will break on any non-x86 platform. This is an absolutely horrifying situation now that ARM, MIPS, and PowerPC are starting to become viable targets for D. Something needs to be done about shared. I don't know what, but the current situation is -- and I'm really not exaggerating here -- laughable. I think we either need to just make it perfectly clear that shared is for documentation purposes and nothing else, or, figure out an alternative system to shared, because I don't see shared actually being useful for real world work no matter what we do with it.
Re: Something needs to happen with shared, and soon.
On 2012-11-11 18:46:10 +, Alex Rønne Petersen said: Something needs to be done about shared. I don't know what, but the current situation is -- and I'm really not exaggerating here -- laughable. I think we either need to just make it perfectly clear that shared is for documentation purposes and nothing else, or, figure out an alternative system to shared, because I don't see shared actually being useful for real world work no matter what we do with it. I feel like the concurrency aspect of D2 was rushed in the haste of having it ready for TDPL. Shared, deadlock-prone synchronized classes[1] as well as destructors running in any thread (thanks GC!) plus a couple of other irritants makes the whole concurrency scheme completely flawed if you ask me. D2 needs a near complete overhaul on the concurrency front. I'm currently working on a big code base in C++. While I do miss D when it comes to working with templates as well as for its compilation speed and a few other things, I can't say I miss D much when it comes to anything touching concurrency. [1]: http://michelf.ca/blog/2012/mutex-synchonization-in-d/ -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Something needs to happen with shared, and soon.
On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote: It's starting to get outright embarrassing to talk to newcomers about D's concurrency support because the most fundamental part of it -- the shared type qualifier -- does not have well-defined semantics at all. I think a couple things are clear: 1. Slapping shared on a type is never going to make algorithms on that type work in a concurrent context, regardless of what is done with memory barriers. Memory barriers ensure sequential consistency, they do nothing for race conditions that are sequentially consistent. Remember, single core CPUs are all sequentially consistent, and still have major concurrency problems. This also means that having templates accept shared(T) as arguments and have them magically generate correct concurrent code is a pipe dream. 2. The idea of shared adding memory barriers for access is not going to ever work. Adding barriers has to be done by someone who knows what they're doing for that particular use case, and the compiler inserting them is not going to substitute. However, and this is a big however, having shared as compiler-enforced self-documentation is immensely useful. It flags where and when data is being shared. So, your algorithm won't compile when you pass it a shared type? That is because it is NEVER GOING TO WORK with a shared type. At least you get a compile time indication of this, rather than random runtime corruption. To make a shared type work in an algorithm, you have to: 1. ensure single threaded access by aquiring a mutex 2. cast away shared 3. operate on the data 4. cast back to shared 5. release the mutex Also, all op= need to be disabled for shared types.
Re: Immutable and unique in C#
On Sunday, November 11, 2012 17:29:02 Walter Bright wrote: > I'm not convinced that adding a "unique" qualifier is strictly necessary. Where it would be particularly valuable would be passing stuff across threads with std.concurrency. We don't _need_ it for that however. It would just make it cleaner, because you wouldn't have to worry about whether anything else on the current thread had a reference to what you were passing across. So, while I think that it would be nice, I'm not convinced that it's worth adding at this point. There's a halfway decent chance that you'd just end up casting to unique to pass it across anyway (depending on how the value was constructed), which then puts us in exactly the same boat that we're in now except for the fact that we're casting to unique instead of casting to shared or immutable. - Jonathan M Davis
error help
Hi there!!, can any one help me with these errors, what do they mean and how do i resolve them OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\LOGICT~1\AppData\Local\Temp\.rdmd\rdmd-main.d-68F08AE56B791207D2A55B3DD37498A5\objs\main.obj(main) Error 42: Symbol Undefined _D4core6memory2GC6extendFPvkkZk C:\Users\LOGICT~1\AppData\Local\Temp\.rdmd\rdmd-main.d-68F08AE56B791207D2A55B3DD37498A5\objs\main.obj(main) Error 42: Symbol Undefined _D4core6memory2GC6qallocFkkZS4core6memory8BlkInfo_ C:\Users\LOGICT~1\AppData\Local\Temp\.rdmd\rdmd-main.d-68F08AE56B791207D2A55B3DD37498A5\objs\main.obj(main) Error 42: Symbol Undefined _D4core5bitop3bsrFNaNbkZi --- errorlevel 3
Re: Getting rid of dynamic polymorphism and classes
On Sunday, 11 November 2012 at 13:24:07 UTC, gnzlbg wrote:
How would you create a vector of canvas and iterate over them?
I assume you mean to ask "How'd you create a vector of shapes?".
And I assume you mean "... by using the
pointers-to-member-functions design pattern introduced in the
first post". Notice that in the video I posted, they introduce a
similar but cleaner design pattern, that uses virtual functions
to accomplish the same goal. I think it's better to use that,
given that virtual function calls aren't noticeably slower than
calling through those member function pointers.
But anyway, here's how you'd do it using the
pointers-to-member-functions idiom:
#include
#include
#include
#include
#include
#include
template
class MyShape
{
public:
void refresh()
{
_cprintf("MyShape<%d> refreshed\n", typeId);
}
};
struct Shape
{
std::function refresh;
template ::value
>::type>
Shape(S&& s)
: _s (new S(s))
{
refresh = [&]()
{ return reinterpret_cast(_s.get())->refresh(); };
}
private:
std::unique_ptr _s; // or std::shared_ptr
};
int main()
{
std::vector shapes;
shapes.emplace_back(MyShape<2>());
shapes.emplace_back(MyShape<4>());
for (auto& shape : shapes)
{
shape.refresh();
}
_getch();
return 0;
}
// Prints:
MyShape<2> refreshed
MyShape<4> refreshed
Re: Something needs to happen with shared, and soon.
The only problem beeing that you can not really have user defined shared (value) types: http://d.puremagic.com/issues/show_bug.cgi?id=8295 Kind Regards Benjamin Thaut
Re: Is instantiabilty of templated types decidable?
On Mon, 12 Nov 2012 00:46:06 +0100
Timon Gehr wrote:
> On 11/11/2012 09:40 PM, Nick Sabalausky wrote:
> > On Sun, 11 Nov 2012 19:37:45 +0100
> > Timon Gehr wrote:
> >
> >> On 11/11/2012 03:45 PM, Peter Alexander wrote:
> >>>
> >>> Collatz sequence.
> >>>
> >>> struct Collatz(int n)
> >>> {
> >>> enum next = n % 2 == 0 ? n / 2 : 3 * n + 1;
> >>> Collatz!(next)* foo;
> >>> }
> >>>
> >>> It's an unsolved problem in mathematics whether or not this
> >>> instantiates an infinite number of templates.
> >>
> >> The possible inputs are finite, so the property is decidable.
> >
> > Technically, yea, but I think upwards of ~4 billion template
> > instantiations is quite unrealistic, to the point of being
> > effectively undecidable.
> >
>
> Undecidability has a precise definition in theoretical computer
> science. It means that there is no algorithm that implements the
> given predicate. It is a lot stronger than impracticality of
> implementation.
>
I'm not disagreeing with that. But when the question is "Should the
compiler loop for days trying to instantiate millions, if not
billions of types for a design that's flawed and impractical (due to
said explosion of type instantiations)?", or something along those
lines, then the question of "undecidable versus unrealistic" becomes
irrelevent.
If there's laziness techniques that can drastically reduce the number
of instantiations the compiler actually needs to analyze/create, then
fine, but at some point it *still* has a decision to make of "Geez,
we've just created hundreds (thousands?) of recursive instantiations,
and in at least this particular case we have no fucking idea how many
more we might need, should we continue for a ridiculous amount of
time/resources, or just tell the user he's using an impractical
approach?" When you're facing that judgement call, it really doesn't
matter whether that "ridiculous amount of time/resources" is
technically finite or not.
Re: Something needs to happen with shared, and soon.
On 11/11/2012 10:05 PM, Benjamin Thaut wrote: The only problem beeing that you can not really have user defined shared (value) types: http://d.puremagic.com/issues/show_bug.cgi?id=8295 If you include an object designed to work only in a single thread (non-shared), make it shared, and then destruct it when other threads may be pointing to it ... What should happen?
Re: Getting rid of dynamic polymorphism and classes
I should point out, just so that no-one is missing the obvious
here, that you'd be using static polymorphism through the use of
template functions whenever it's possible, i.e. when you don't
need to store polymorphic types.
So, you'd do this:
template
auto func(const S& shape)
-> typename std::enable_if<
is_shape::value
::type
{
// ...
}
You would NOT do this:
void func(const Shape& shape)
{
// ...
}
The big question is then: is the code bloat introduced by the
massive use of template functions worth the speed gained through
static polymorphism (vs. dynamic). Whether it is or not, the main
gain for me is in de-coupling of types, which helps in writing
truly generic code.
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 2012-11-12 00:14, Ellery Newcomer wrote: Ouch. Looks like what I should have said is gnome classic (no effects), and I guess compizconfig didn't actually turn anything off. Also, I'm working from a clean install, so that might account for behavior difference. I start to think I have to reinstall. It still sucks, though. Found myself wishing I had installed server instead. I was using this virtual machine for testing DWT Linux as well, so I kind of need a GUI. I was hoping I could use the same machine for building Linux binaries as testing DWT. -- /Jacob Carlborg
Re: Binary compatibility on Linux
On 2012-11-11 23:30, 1100110 wrote: I've used alien a fair number of times, and its usually "just worked." Here is an FAQ: http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html That link provides a lot of info. Honestly, unless Ubuntu has done something really weird, Debian should be just as compatible with non-Debian distros as Ubuntu is. Give me a solid example of what you mean and I'll take a closer look. I'm not saying it's incompatible, I'm asking :) BTW, I actually don't know how compatible Ubuntu either. Ubuntu has a Debian-for-Ubuntu-Devs page. https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers That should explain something at least. I guess I'll to take a look at that page. How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which loses support in April? I'm not entirely sure. http://packages.ubuntu.com/hardy/ http://packages.debian.org/stable/ As I understand it Debian is a more stable distribution and Ubuntu is a faster moving target. The question is how much faster. Would Ubuntu LTS be more ahead of compared to the latest stable Debian. -- /Jacob Carlborg
Re: Getting rid of dynamic polymorphism and classes
On Monday, 12 November 2012 at 05:49:55 UTC, Tommi wrote: Notice that in the video I posted, they introduce a similar but cleaner design pattern, that uses virtual functions to accomplish the same goal. I didn't mean to say 'similar', it's rather different. It accomplishes the same goal though, but using less memory and through the use of virtual functions.
