Re: #pragma comment (lib, ...)
On 2012-10-12 07:46, Paulo Pinto wrote: This already exists, it is called NuGet. Again, it's not cross-platform. How well does it work with D, at all? -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-11 21:45, H. S. Teoh wrote: Yeah, it was one of the things that convinced me to *not* use Redhat. I saw a similar thing back in the Bad Old Days of Win98, Win2k, and their ilk, where installing a driver would sometimes prompt you something to the effect of "this driver needs to install a file that already exists; overwrite the file, delete it, or skip it?" None of those options should be anything the *user* has to decide, IMO. It essentially amounted to "flip a coin and pray the OS won't crash, and if you're *really* lucky the driver might actually work". Things like that convinced me *not* to use Windows. (I don't know if Windows still does that, as I don't use it anyore; but for everyone else's sake I would certainly hope it doesn't!) Haha. Of course, IIRC Redhat has since fixed this broken design, but the horrible memory of it stuck. Debian, OTOH, has a depends-on-package policy, which results in a much saner system where a package can specify a dependency on other packages (with an entire package as a unit), optionally with a version constraint, and thus be ensured that it will get the correct versions of all related files. That was one of the things that convinced me to use Debian. :) That's how it should work. The smallest unit should be a package. -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-12 01:03, Kapps wrote: In an ideal world, your VS plugin would support Packages in the Add References dialog. Just like you could, in theory, add a project as a reference, you would add a package. Then, upon build, the plugin would call the package manager and get the libraries / imports required for it, appending the options to the compilre for your own build. This is something that wouldn't be particularly difficult to make a plugin for given an existing package manager. Mono-Develop would perform in the same way I'd imagine. Exactly, that's how I'm thinking. -- /Jacob Carlborg
Re: Any interest in libgit bindings?
On 2012-10-11 21:38, Andrej Mitrovic wrote:
I guess it depends on what you get from clang. The XML I'm working on
has this sort of output:
I'm pretty sure I get the full path of every header. That is
"/usr/home/foo/libgit2/includes/git2/submodule.h", or something similar.
This is translated into:
git2\submodule.d
mingw\include\inttypes.d
mingw\lib\gcc\mingw32\_4\_6\_1\include\stddef.d
The last one could use improvement (_4\_6\_1\ should be _4_6_1). I
call remDrive, chomp(".h"), chomp(".tcc"), translate slashes to dot,
and I make sure module names aren't keywords and it's done.
Yeah, that looks a bit ugly.
As for macros, I don't have access to those. If a symbol is
initialized with a macro then I get the post-processed value of the
macro, but I don't have the definition of the macro itself.
I haven't tackled macros yet. There are no API for this in libclang yet
so I would have to create that first.
On the other hand, libclang do have an API for doxygen documentation
which recently got added. If think that is awesome and it will be in the
next release of Clang, which they recently announced the release
schedule for.
--
/Jacob Carlborg
Re: List of reserved words
On 2012-10-11 21:28, Jonathan M Davis wrote: A lot of it is there already: http://dlang.org/phobos/object.html I wouldn't count that list. I'm thinking more something that explicitly says: "These are reserved symbols by the language or the runtime". Creating your own function named "assumeSafeAppend" actually works fine. On the other hand, naming a module "object" is known to cause Bad Things to happen. So there are some differences. -- /Jacob Carlborg
Re: Tips for debugging EXC_BAD_ACCESS
On 2012-10-11 20:19, Michel Fortin wrote: Most likely, the object objc_msgSend is called on has been deallocated, which would mean that windowSendEvent is called with a deallocated NSWindow object as its first argument. How can I detect that? Can I use the object somehow and try to get the crash inside my own code instead of in system function? I don't know how DWT works, but I'd say there's something amiss with how DWT is retaining its NSWindow. Ok, I'll have a look at this. If I understand it correctly, it works something like this: * DWT creates a couple of subclasses * DWT creates a native window * Sets up an event loop * Fetches the next native event * Translate it into a DWT event * Calls any handlers * Pass the native event to the super class Since you're on OS X, I'd suggest you try using Instruments to track the reference counters of all Objective-C objects within your program until it crashes, then search back the history for all retain/release/autorelease calls made to the address the EXEC_BAD_ACCESS happens on. I tried using Instruments but I'm barely know what I'm doing. I tried with the "leaks" profile but I could really find anything/didn't really know how to use it. It also crashes so fast that Instruments barely has a chance of collection any data. -- /Jacob Carlborg
Re: What is the case against a struct post-blit default constructor?
On Thursday, 11 October 2012 at 22:05:34 UTC, Jonathan M Davis wrote: On Friday, October 12, 2012 01:20:44 Dmitry Olshansky wrote: > > This sounds more like a limitation of invariants, rather > than a problem > with .init. You make (imo) a valid point. > > Would it be complicated for opAssign to first check > memcmp(this, > T.init), and only do entry invariant check if the comparison > fails? > > Potentially ditto on exit. With your rule T.init is a valid state. AFAICT in Jonathan's example it isn't. Yeah. All that's required is that you outright skip the call to the invariant before calling opAssign. It _does_ mean special casing opAssign, but I don't see that as a problem. I don't understand why it matters whether the object is valid before it's assigned to. Presumably, you're completely replacing its state, and regardless of what you actually do in the function, it would still need to be valid afterwards. So, it seems perfectly fine to me to just skip calling the variant before calling opAssign, but Walter was against it. His comment on the bug ( http://d.puremagic.com/issues/show_bug.cgi?id=5058 ) indicated that he thought that init should always be in a valid state, but since NaN and null are invalid states, I see no reason that a struct's init value can't be an invalid state. It can be copied and passed around just fine. It just wouldn't pass its invariant if you tried to call a function on it before assigning it a valid value. - Jonathan M Davis Yes, as answered, opAssign may do things to this, such as dealocate a payload, reduce a ref counter, or who knows what. As a matter of fact, there was a bug in emplace about that I recently fixed. My rational for skipping the test *ONLY* if "this == .init" is that .init is supposed to mean not yet fully initialized. This would make code such as: T t = t.init; //Not yet ready for use. //Attempt to use will assert the invariant ... t = T(5); //Initialize it later. Don't check invariant on entry ... //Use t and check invariants every time. ... t = t.init; //De-initialization, Don't check invariant on exit. //Future attempt for use will assert the invariant I'd also do the same for destructor entry: The language already states that .init SHOULD be a valid destructible state.
Re: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 23:03:45 UTC, Kapps wrote: On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote: Okay, so I'll stop being a dick for a minute, I'm actually curious to know how you imagine it working with a tool like VisualStudio. It sounds like you're not just talking about a tool to fetch libs and dependencies, but also perform the build? And the dependencies are detailed in the build script? An inflexible build system like Visual Studio doesn't really handle that very well. In an ideal world, your VS plugin would support Packages in the Add References dialog. Just like you could, in theory, add a project as a reference, you would add a package. Then, upon build, the plugin would call the package manager and get the libraries / imports required for it, appending the options to the compilre for your own build. This is something that wouldn't be particularly difficult to make a plugin for given an existing package manager. Mono-Develop would perform in the same way I'd imagine. This already exists, it is called NuGet. Besides, Visual Studio projects are actually MSBuild scripts, for me that is quite flexible. -- Paulo
Re: Proposal: __traits(code, ...) and/or .codeof
On Tuesday, 9 October 2012 at 19:29:34 UTC, F i L wrote: On Tuesday, 9 October 2012 at 13:28:55 UTC, luka8088 wrote: Is this at least similar to what you had in mind ? [ ..code.. ] Yes, I realized, a bit after I originally posted that, that my suggestion was already possible if BankType & Logger where mixin-templates instead of struct/classes. Thanks for the code example though. I still think an built-in .codeof/.astof would be nice, but what D really needs to achieve this in a syntactically pleasing and powerful way, is 'macro' templates (like Nimrod has) which work on the AST directly. I doubt this is a major concern ATM however. My point of making this example was to show that nothing is missing in D itself. You just need to be more creative. If you want to write in a manner more similar to your original example (by that I mean without mixin templates) you can use classes, class methods can be turned to delegates with their context pointer changed before execution, and then you would get the same effect. Also having such syntax could be very confusing because someone could introduce some syntax which is very similar to D but behaves differently and it is embedded in a way that looks just like a D code. Also the idea is to have "// generic code" part in some library and not visible to the *user* so the rest of the code would be syntactically pleasing. If you check current phobos code, you will see that there are some examples of using mixins this way. Please also check the comments on https://github.com/D-Programming-Language/dmd/pull/953 (if you haven't done that already).
Re: What is the case against a struct post-blit default constructor?
On 2012-05-12 00:10, Jonathan M Davis wrote: On Friday, October 12, 2012 01:20:44 Dmitry Olshansky wrote: > > This sounds more like a limitation of invariants, rather than a problem > with .init. You make (imo) a valid point. > > Would it be complicated for opAssign to first check memcmp(this, > T.init), and only do entry invariant check if the comparison fails? > > Potentially ditto on exit. With your rule T.init is a valid state. AFAICT in Jonathan's example it isn't. Yeah. All that's required is that you outright skip the call to the invariant before calling opAssign. It _does_ mean special casing opAssign, but I don't see that as a problem. I don't understand why it matters whether the object is valid before it's assigned to. Presumably, you're completely replacing its state, and regardless of what you actually do in the function, it would still need to be valid afterwards. So, it seems perfectly fine to me to just skip calling the variant before calling opAssign, but Walter was against it. His comment on the bug ( http://d.puremagic.com/issues/show_bug.cgi?id=5058 ) indicated that he thought that init should always be in a valid state, but since NaN and null are invalid states, I see no reason that a struct's init value can't be an invalid state. It can be copied and passed around just fine. It just wouldn't pass its invariant if you tried to call a function on it before assigning it a valid value. The opAssign can presumably be more complex, and e.g. require deallocation of non-GC memory, releasing handles and whatnot. Anyways, is there a reason you cannot use @disable this() for SysTime? That way, you have rather explicitly marked .init as invalid. -- Simen
Re: Struct polymorphism?
On Tuesday, 9 October 2012 at 03:41:42 UTC, Era Scarecrow wrote: Now I guess a question out there for you all. Who would be interested in an implementation and how would you use it? Does it seem like a good idea? How many levels would you want to use? One? Several levels allowing class-like inheritance? Nothing yet it seems. Hmmm... Well I've thrown together a working version (in the last 4 days?) that needs more testing and documentation; But is a proof of concept, probably good enough for my other project. Incorporates a minimal encryption library for testing and demonstration. This makes heavy use of mixins. Thoughts and feedback are welcome. https://github.com/rtcvb32/Side-Projects
Re: GC statistics
On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei Alexandrescu wrote: This is mostly for GC experts out there - what statistics are needed and useful, yet not too expensive to collect? https://github.com/D-Programming-Language/druntime/pull/236 Andrei I'd like to see mark, sweep and page-freeing time be counted separately so that if overall GC performance is slow, the user can identify where the bottleneck is. For example, mark time will be slow if there's a lot of total memory to be scanned. Sweep time will be slow if there are a lot of blocks allocated, even if they're all small. I'm not sure if this is feasible, though, because it assumes that the GC implementation is mark-sweep. I guess we could name the subcategories something more generic like mark and process marks.
Re: DIP20: Volatile read/write intrinsics
On 10/11/2012 10:18 PM, Alex Rønne Petersen wrote: Oops. It should be clearer now. It is!
Re: DIP20: Volatile read/write intrinsics
On 12-10-2012 04:05, Chad J wrote: On 10/11/2012 10:35 AM, Alex Rønne Petersen wrote: On 11-10-2012 14:42, Chad J wrote: On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote: I suppose a simple D_Volatile version identifier will do, like we have D_SIMD for core.simd.__simd. Cool. OK, updated. I do have a critique for your description: Compilers that support these intrinsics must define the D_Volatile version identifier. Compilers that do not may support them, but programmers should not rely on it. I read this as meaning: Compilers that support volatile intrinsics must define D_Volatile. Compilers can support volatile intrinsics without defining D_Volatile. And I see a contradiction ;) Oops. It should be clearer now. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: DIP20: Volatile read/write intrinsics
On 10/11/2012 10:35 AM, Alex Rønne Petersen wrote: On 11-10-2012 14:42, Chad J wrote: On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote: I suppose a simple D_Volatile version identifier will do, like we have D_SIMD for core.simd.__simd. Cool. OK, updated. I do have a critique for your description: Compilers that support these intrinsics must define the D_Volatile version identifier. Compilers that do not may support them, but programmers should not rely on it. I read this as meaning: Compilers that support volatile intrinsics must define D_Volatile. Compilers can support volatile intrinsics without defining D_Volatile. And I see a contradiction ;)
Re: What is the case against a struct post-blit default constructor?
First of all thank you for the detailed responses.
I wrote a response yesterday but somehow the website seems to
have swallowed it.
On Thursday, 11 October 2012 at 12:43:31 UTC, Andrei Alexandrescu
wrote:
We could (after all, C++ does it). There are a few
disadvantages to doing so, however.
1. Defining static data is more difficult. Currently, all
static data is statically-initialized. With default
constructors, we'd need to define the pre-construction state of
such objects anyway, and then change the compiler to call
constructors prior to main(). I find the current design simpler
and easier to use.
This is a good reason. I like the idea of "no code gets run
before main" Running code before main only lead to problems in
C++. However those problems were always merely inconvenient,
never big issues. I think it's not good to allow people to run
code before main, but I think it's a bigger problem to have no
default constructors.
2. Creating a temporary object cannot be anymore assumed to be
a O(1), no-resources-allocated deal. Instead, generic code must
conservatively assume that objects are always arbitrarily
expensive to create. That makes some generic functions more
difficult to implement.
I think that is OK. The generic algorithm should assume that your
object is cheap to create. In C++ all algorithms assume this and
there are few issues. Sure, every now and then you pass an
expensive-to-create object to an algorithm which creates
instances, but that bug is very easy to debug.
3. Two-phase object destruction (releasing state and then
deallocating memory), which is useful, is made more difficult
by default constructors. Essentially the .init
"pre-default-constructor" state intervenes in all such cases
and makes it more difficult for language users to define and
understand object states.
I'm not sure that I understand this. My two ways of interpreting
this are:
A) You mean that the compiler currently assumes that it doesn't
have to call the destructor for objects that are at init. But
after introducing a default constructor it would always have to
call the destructor. I think that's OK. That's an optimization
that's unlikely to give you much gain for types that need a
destructor.
B) You mean that if we introduce a default constructor, there
would still be situations where an object is at init and it's
destructor gets called. For example if people throw exceptions.
And users might be confused by this when their destructor gets
run and their object is at init, instead of the state that they
expect. I think this is OK. It is the same situation that we
currently have with static opCall(). Yes, with the static
opCall() hack people kinda expect that their object isn't always
initialized, so their destructors probably react better to the
state being at init, but I think if the documentation states
clearly "there are situations where the destructor will be called
on an object whose default constructor was not called" then
people can handle that situation just fine.
4. Same as above applies to an object post a move operation.
What state is the object left after move? C++'s approach to
this, forced by the existence of default constructors and other
historical artifacts, has a conservative approach that I
consider inferior to D's: the state of moved-from object is
decided by the library, there's often unnecessary copying, and
is essentially unspecified except that "it's valid" so the
moved-from object can continue to be used. This is in effect a
back-door introduction of a "no-resources-allocated" state for
objects, which is what default constructors so hard tried to
avoid in the first place.
For moving you'd just have to define a state that the source
object is in after moving. Since it's a destructive move I would
expect the object to be at init after moving, as if the
destructor had been called. If that is well defined, then I think
users will be fine with it. This is actually the situation that
we currently have, and users seem to be fine with it. This can be
achieved with a tiny change to the current implementation of
std.algorithm.move: Make it memcpy from init instead of a
statically allocated value.
I'd also like it if we could write all structs so that init is a
valid state of the struct, as Walter suggests. However this is
going to make certain things impossible in the language. Simple
things like having shared data between multiple instances of a
struct. Or counting how often objects of a certain type was
allocated. Or iterating over all instances of a type.
In fact there are parts of the standard library that don't work
because they'd need a default constructor. One of the linked
posts mentions this example from std.typecons:
import std.typecons;
{
RefCounted!(int, RefCountedAutoInitialize.yes) a;
assert(a == 0); // works
RefCounted!(int, RefCountedAutoInitialize.no) b = a;
a
delegate opCall?
>From what I understand from TDPL, given a struct or object obj, writing
obj(x,y,z) will be translated to obj.opCall(x,y,z), correct? So why is
it that this doesn't work:
struct S {
RetVal delegate(Args args) opCall;
}
void main() {
auto s = S((Args args) => doSomething(args));
Args my_args;
RetVal r = s(my_args); // this is line 7
}
I get this error: test.d(7): Error: struct S does not overload ()
An easy workaround is to rename the delegate "impl", then implement
opCall as a wrapper:
RetVal opCall(Args args) { return impl.args; }
But this seems unnecessarily verbose to me.
T
--
What's a "hot crossed bun"? An angry rabbit.
Re: dlibgit sample - concurrency issues
On 10/12/12, Andrej Mitrovic wrote:
> There is a minimal git client sample
> ported from C (it has just a few commands implemented).
Ok guys I could use some help here. Take a look at these (ported from
C which used pthreads and didn't really care about thread safety):
https://github.com/AndrejMitrovic/dlibgit/blob/master/samples/network/clone.d#L43
https://github.com/AndrejMitrovic/dlibgit/blob/master/samples/network/common.d#L26
Here's the original C sample:
https://github.com/libgit2/libgit2/blob/development/examples/network/clone.c
(uses pthread_create)
The situation is:
- Main thread prepares some struct data type
- This is the type:
https://github.com/AndrejMitrovic/dlibgit/blob/master/samples/network/common.d#L14
- Main thread spawns a worker thread that has to write to the struct
data type (the type has indirections due to string fields).
- Worker thread reads from and writes to this data type.
- Main thread spins and reads from the data type until a bool flag is
set, after which it knows the work thread is done and the main thread
can break out of the loop.
I can't put the struct variable in TLS and use spawn() to pass a
pointer to it ("Aliases to mutable thread-local data not allowed."),
so I've had to use a __gshared global instead and let the spawned
function access it implicitly.
I could type the struct variable as shared() but I'd have to cast away
the shared qualifier when calling git_clone, which is a C function
(https://github.com/AndrejMitrovic/dlibgit/blob/master/samples/network/clone.d#L17).
Question is: Isn't there a better way to model this, without using
globals or casts? I'd love to see a good thread-safe example on how to
implement this.
Re: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote: Okay, so I'll stop being a dick for a minute, I'm actually curious to know how you imagine it working with a tool like VisualStudio. It sounds like you're not just talking about a tool to fetch libs and dependencies, but also perform the build? And the dependencies are detailed in the build script? An inflexible build system like Visual Studio doesn't really handle that very well. In an ideal world, your VS plugin would support Packages in the Add References dialog. Just like you could, in theory, add a project as a reference, you would add a package. Then, upon build, the plugin would call the package manager and get the libraries / imports required for it, appending the options to the compilre for your own build. This is something that wouldn't be particularly difficult to make a plugin for given an existing package manager. Mono-Develop would perform in the same way I'd imagine.
Re: #pragma comment (lib, ...)
On 11 October 2012 18:49, David Nadlinger wrote: > On Thursday, 11 October 2012 at 16:01:09 UTC, Iain Buclaw wrote: >> >> On 11 October 2012 16:29, David Nadlinger wrote: >>> >>> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote: Does LDC only build one executable? >>> >>> […] >> >> >> Not what the LDC compiler does, the actual /usr/bin/ldc executable >> itself. Is it in one pieces, or in pieces? eg: GDC is in two >> pieces, gdc and cc1d. > > > Ah, now I see what you mean. Yes, LDC consists of only one executable. > > David So the object that interprets pragma(lib) is able to communicate with the object that handles what flags to pass to the linker. :-) This is not possible with gdc, as the driver that handles the calling of ld (gdc) does not / cannot communicate with the compiler component (cc1d). Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: What is the case against a struct post-blit default constructor?
On Friday, October 12, 2012 01:20:44 Dmitry Olshansky wrote: > > > > This sounds more like a limitation of invariants, rather than a problem > > with .init. You make (imo) a valid point. > > > > Would it be complicated for opAssign to first check memcmp(this, > > T.init), and only do entry invariant check if the comparison fails? > > > > Potentially ditto on exit. > > With your rule T.init is a valid state. AFAICT in Jonathan's example it > isn't. Yeah. All that's required is that you outright skip the call to the invariant before calling opAssign. It _does_ mean special casing opAssign, but I don't see that as a problem. I don't understand why it matters whether the object is valid before it's assigned to. Presumably, you're completely replacing its state, and regardless of what you actually do in the function, it would still need to be valid afterwards. So, it seems perfectly fine to me to just skip calling the variant before calling opAssign, but Walter was against it. His comment on the bug ( http://d.puremagic.com/issues/show_bug.cgi?id=5058 ) indicated that he thought that init should always be in a valid state, but since NaN and null are invalid states, I see no reason that a struct's init value can't be an invalid state. It can be copied and passed around just fine. It just wouldn't pass its invariant if you tried to call a function on it before assigning it a valid value. - Jonathan M Davis
Re: What is the case against a struct post-blit default constructor?
On 12-Oct-12 01:16, monarch_dodra wrote: Except that you could write the invariant to be inclusive of the .init state. Which would completely defeat the purpose of the invariant in many cases. The point is that it is invalid to use the init value. You can pass it around and set stuff to it and whatnot, but actually calling functions on it would be invalid, because its init state isn't valid. SysTime is a prime example of this, because it requires a valid TimeZone object, but its init value can't have one, because TimeZone is a class. So ideally, it would have an invariant which asserts that its TimeZone is non-null, but it can't have that, because opAssign unfortunately checks the invariant before it's called (which makes no sense to me - why would the state of the object prior to assignment matter? you're replacing it), so assigning a valid value to a default-initialized SysTime would fail the invariant. - Jonathan M Davis This sounds more like a limitation of invariants, rather than a problem with .init. You make (imo) a valid point. Would it be complicated for opAssign to first check memcmp(this, T.init), and only do entry invariant check if the comparison fails? Potentially ditto on exit. With your rule T.init is a valid state. AFAICT in Jonathan's example it isn't. -- Dmitry Olshansky
Re: What is the case against a struct post-blit default constructor?
On Thursday, 11 October 2012 at 20:59:32 UTC, Jonathan M Davis wrote: On Thursday, October 11, 2012 13:06:34 Walter Bright wrote: On 10/11/2012 10:23 AM, Jonathan M Davis wrote: > but there _are_ cases > where you can't have an invariant because of it. Except that you could write the invariant to be inclusive of the .init state. Which would completely defeat the purpose of the invariant in many cases. The point is that it is invalid to use the init value. You can pass it around and set stuff to it and whatnot, but actually calling functions on it would be invalid, because its init state isn't valid. SysTime is a prime example of this, because it requires a valid TimeZone object, but its init value can't have one, because TimeZone is a class. So ideally, it would have an invariant which asserts that its TimeZone is non-null, but it can't have that, because opAssign unfortunately checks the invariant before it's called (which makes no sense to me - why would the state of the object prior to assignment matter? you're replacing it), so assigning a valid value to a default-initialized SysTime would fail the invariant. - Jonathan M Davis This sounds more like a limitation of invariants, rather than a problem with .init. You make (imo) a valid point. Would it be complicated for opAssign to first check memcmp(this, T.init), and only do entry invariant check if the comparison fails? Potentially ditto on exit.
Re: What is the case against a struct post-blit default constructor?
On Thursday, October 11, 2012 13:06:34 Walter Bright wrote: > On 10/11/2012 10:23 AM, Jonathan M Davis wrote: > > but there _are_ cases > > where you can't have an invariant because of it. > > Except that you could write the invariant to be inclusive of the .init > state. Which would completely defeat the purpose of the invariant in many cases. The point is that it is invalid to use the init value. You can pass it around and set stuff to it and whatnot, but actually calling functions on it would be invalid, because its init state isn't valid. SysTime is a prime example of this, because it requires a valid TimeZone object, but its init value can't have one, because TimeZone is a class. So ideally, it would have an invariant which asserts that its TimeZone is non-null, but it can't have that, because opAssign unfortunately checks the invariant before it's called (which makes no sense to me - why would the state of the object prior to assignment matter? you're replacing it), so assigning a valid value to a default-initialized SysTime would fail the invariant. - Jonathan M Davis
Re: List of reserved words
On 11-10-2012 20:55, Ali Çehreli wrote: On 10/11/2012 11:52 AM, Alex Rønne Petersen wrote: On 11-10-2012 20:41, Maxim Fomin wrote: On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote: In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Where this is claimed? 6.10.7.2: None of these macro names, nor the identifier defined, shall be the subject of a #define or a #undef preprocessing directive. Any other predefined macro names shall begin with a leading underscore followed by an uppercase letter or a second underscore. So, it's not explicitly reserved, but your code can suddenly start doing weird things if you prefix an identifier with an underscore. This is why new keywords/types are named like _Noreturn, _Thread_local, etc. I am sure Maxim knows about the "leading underscore" case. I think that's why "anything ending in _t" is being questioned. :) I would like to know that too. I have never heard that names ending with _t are reserved in C or C++. Ali Aaah, my bad. I somehow completely missed the _t. Disregard me! -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: List of reserved words
On Thursday, 11 October 2012 at 07:00:10 UTC, Jacob Carlborg wrote: On dlang.org there's a page containing all the keywords, which are reserved: http://dlang.org/lex.html But it would also be nice to have a list of words/symbols that are not keywords but could otherwise be thought of being reserved. These are words that will make it problematic if used in user code in the wrong context. I thinking mostly of naming a module "object" or a class "Object", the compiler will not be happy seeing that. What other "reserved" words like these does D have? From druntime: one underscore + lower letter: http://pastebin.com/iztLZh4m. I guess parsing for double underscores and one underscore + upper letter is meaningless, since defining such identifiers is looking for problems anyway.
Re: What is the case against a struct post-blit default constructor?
On 10/10/2012 01:59 PM, Don Clugston wrote:
On 10/10/12 13:27, Timon Gehr wrote:
On 10/10/2012 12:45 PM, Don Clugston wrote:
...
Really, there does not seem to me to be any point in having an invariant
for a struct, without a default constructor.
One can use a dented invariant.
struct S{
bool valid = false;
// ...
invariant(){ if(valid) assert(...); }
void establishInvariant()out{assert(valid);}body{...}
}
Yes, you have to do something like that. It's absolute garbage. When you
have a hack like that, I don't see the point of having invariants in the
language.
...
Well, all invariants in Spec# follow this pattern. Every object has an
implicit boolean 'valid' field.
Re: What is the case against a struct post-blit default constructor?
On 10/11/2012 10:23 AM, Jonathan M Davis wrote: but there _are_ cases where you can't have an invariant because of it. Except that you could write the invariant to be inclusive of the .init state.
Re: What is the case against a struct post-blit default constructor?
On 10/11/2012 02:19 PM, Andrei Alexandrescu wrote: [snip good points.] Those should be in the faq. Really, there does not seem to me to be any point in having an invariant for a struct, without a default constructor. Could you please give a few examples? (Honest question.) Most structures I define have an obvious quiescent state that vacuously satisfies the invariant. Exceptions that come to mind are: (a) value types that must always allocate something on the heap, see e.g. the contortions in std.container; (b) values as permits (the existence of the value guarantees a resource has been secured, as in scoped locks on mutexes). Andrei I presume that many structures you define are templated and how obvious their default state is often depends on the particular instantiation. A large fraction of structs are local in idiomatic D code because of local template instantiation. Local structs do not have an obvious valid default state outside their local context and there is no way to tell if it is valid in generic code. Therefore, the issues you mentioned remain.
Re: Any interest in libgit bindings?
On 10/11/12, Jacob Carlborg wrote:
> Actually I already do the same. But that's only for the C standard
> library and a couple of Posix headers, basically all files in core.stdc.
> But the problem is that I get the full path to the source file where the
> symbol is defined. How do I turn that in to an import declaration?
> Something relative to the include paths?
I guess it depends on what you get from clang. The XML I'm working on
has this sort of output:
This is translated into:
git2\submodule.d
mingw\include\inttypes.d
mingw\lib\gcc\mingw32\_4\_6\_1\include\stddef.d
The last one could use improvement (_4\_6\_1\ should be _4_6_1). I
call remDrive, chomp(".h"), chomp(".tcc"), translate slashes to dot,
and I make sure module names aren't keywords and it's done.
As for macros, I don't have access to those. If a symbol is
initialized with a macro then I get the post-processed value of the
macro, but I don't have the definition of the macro itself.
Re: #pragma comment (lib, ...)
On Thu, Oct 11, 2012 at 08:54:19PM +0200, Jacob Carlborg wrote: > On 2012-10-11 16:23, H. S. Teoh wrote: > > >Yeah, one of the poor design decisions of the early Redhat packaging > >system was to allow packages to depend on individual files, rather than > >packages. The result was a disastrous mess: some packages export > >different versions of the same file, and only a subset of them will > >work, leading to hair-tearing dependencies. Packages would step over > >each other's files, causing problems with each other and the rest of the > >system that depended on the same files, ad nauseum. > > That sounds even worse, a terrible, terrible idea. [...] Yeah, it was one of the things that convinced me to *not* use Redhat. I saw a similar thing back in the Bad Old Days of Win98, Win2k, and their ilk, where installing a driver would sometimes prompt you something to the effect of "this driver needs to install a file that already exists; overwrite the file, delete it, or skip it?" None of those options should be anything the *user* has to decide, IMO. It essentially amounted to "flip a coin and pray the OS won't crash, and if you're *really* lucky the driver might actually work". Things like that convinced me *not* to use Windows. (I don't know if Windows still does that, as I don't use it anyore; but for everyone else's sake I would certainly hope it doesn't!) Of course, IIRC Redhat has since fixed this broken design, but the horrible memory of it stuck. Debian, OTOH, has a depends-on-package policy, which results in a much saner system where a package can specify a dependency on other packages (with an entire package as a unit), optionally with a version constraint, and thus be ensured that it will get the correct versions of all related files. That was one of the things that convinced me to use Debian. :) T -- This is not a sentence.
Re: List of reserved words
On Thursday, October 11, 2012 21:00:58 Jacob Carlborg wrote: > This list starts to get fairly long. Would there be a point of adding > this to dlang.org, somewhere? A lot of it is there already: http://dlang.org/phobos/object.html - Jonathan M Davis
Re: List of reserved words
On Thursday, 11 October 2012 at 18:41:14 UTC, Maxim Fomin wrote: On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote: In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Where this is claimed? I seem to have been... "inaccurate" in my claim. This is actually a POSIX restriction, not an ISO C one. http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
Re: List of reserved words
On 2012-10-11 19:21, Alex Rønne Petersen wrote: It's Classinfo by the way (for whatever reason...). Some more: AssociativeArray OffsetTypeInfo MemberInfo MemberInfo_field MemberInfo_function _dg_t _dg2_t Functions: opEquals (there's a global function) setSameMutex _aaLen _aaGet _aaGetRvalue _aaIn _aaDel _aaValues _aaKeys _aaRehash _aaApply _aaApply2 _d_assocarrayliteralT destroy clear capacity reserve assumeSafeAppend _ArrayEq _xopEquals __ctfeWrite __ctfeWriteln Templates: _isStaticArray RTInfo I think that's about it. This list starts to get fairly long. Would there be a point of adding this to dlang.org, somewhere? -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-11 18:00, Iain Buclaw wrote: Not what the LDC compiler does, the actual /usr/bin/ldc executable itself. Is it in one pieces, or in pieces? eg: GDC is in two pieces, gdc and cc1d. Why is that? I know that Clang does the same, I've always wonder why. -- /Jacob Carlborg
Re: List of reserved words
On 2012-10-11 14:43, monarch_dodra wrote:
__ctfe
Although I should file that as a bug I guess:
//
void main()
{
bool __ctfe = true;
}
//
Internal error: ..\ztc\cgcs.c 522
//
An internal error or assert in the compiler is always a bug.
--
/Jacob Carlborg
Re: List of reserved words
On 2012-10-11 14:44, monarch_dodra wrote: Never mind, "Identifiers starting with __ (two underscores) are reserved" It's not enforced by the compiler. -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-11 14:36, Walter Bright wrote: Are you saying that just to support pragma(lib), we should write a new linker? No, not just because this feature alone. There are many other features that could be implemented with a smarter linker. There has been talk about this on the newsgroups several times. Better handling templates and overloaded functions, for example. -- /Jacob Carlborg
Re: List of reserved words
On 10/11/2012 11:52 AM, Alex Rønne Petersen wrote: On 11-10-2012 20:41, Maxim Fomin wrote: On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote: In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Where this is claimed? 6.10.7.2: None of these macro names, nor the identifier defined, shall be the subject of a #define or a #undef preprocessing directive. Any other predefined macro names shall begin with a leading underscore followed by an uppercase letter or a second underscore. So, it's not explicitly reserved, but your code can suddenly start doing weird things if you prefix an identifier with an underscore. This is why new keywords/types are named like _Noreturn, _Thread_local, etc. I am sure Maxim knows about the "leading underscore" case. I think that's why "anything ending in _t" is being questioned. :) I would like to know that too. I have never heard that names ending with _t are reserved in C or C++. Ali
Re: #pragma comment (lib, ...)
On 2012-10-11 16:23, H. S. Teoh wrote: Yeah, one of the poor design decisions of the early Redhat packaging system was to allow packages to depend on individual files, rather than packages. The result was a disastrous mess: some packages export different versions of the same file, and only a subset of them will work, leading to hair-tearing dependencies. Packages would step over each other's files, causing problems with each other and the rest of the system that depended on the same files, ad nauseum. That sounds even worse, a terrible, terrible idea. -- /Jacob Carlborg
Re: Any interest in libgit bindings?
On 2012-10-11 16:34, Andrej Mitrovic wrote: I don't have access to the include directives at all. The way I do it is to have a "toNativeType" function which translates C/C++ types to D and at the same time resolves includes. If a type is located in another module (all non-fundamental types have a fileID field in XML) then I insert that module's name to the currently generating module's imports. Once all the module's symbols are generated I generate the import directives. Actually I already do the same. But that's only for the C standard library and a couple of Posix headers, basically all files in core.stdc. But the problem is that I get the full path to the source file where the symbol is defined. How do I turn that in to an import declaration? Something relative to the include paths? With symbols from the standard library and the Posix headers there's the problem with many of the symbols actually are not defined in the header the documentation says. Instead they're included using various macro conditions from other "private" headers. Well if the library defines files which get converted to modules like 'std' you could easily conflict with Phobos. Some words I check are: std core gc rt object Object string toString toHash mangleof. But there's probably more, when something clashes I add it to the list. You could easily get standard aliases (the ones from implicitly imported object.d) hijacked, e.g. if there was a string typedef in a C library: alias const(char)* string; // hijacks string alias from object.d I actually started a new thread for this: http://forum.dlang.org/thread/k55qpq$20io$1...@digitalmars.com -- /Jacob Carlborg
Re: List of reserved words
On 11-10-2012 20:41, Maxim Fomin wrote: On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote: In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Where this is claimed? 6.10.7.2: None of these macro names, nor the identifier defined, shall be the subject of a #define or a #undef preprocessing directive. Any other predefined macro names shall begin with a leading underscore followed by an uppercase letter or a second underscore. So, it's not explicitly reserved, but your code can suddenly start doing weird things if you prefix an identifier with an underscore. This is why new keywords/types are named like _Noreturn, _Thread_local, etc. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: List of reserved words
On 11-10-2012 20:20, monarch_dodra wrote: On Thursday, 11 October 2012 at 17:57:01 UTC, Jonathan M Davis wrote: On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote: On 10/11/2012 10:13 AM, Jonathan M Davis wrote: > (arguably no one should really be using hash_t or equals_t > at this point, but > I don't know if they're ever going to actually go away). I've been assuming that they were relatively newer aliases. Is it recommended to use size_t and bool instead? They're old. equals_t was done because D1 uses (used?) int for opEquals instead of bool. I don't know if there was ever a good reason for hash_t to exist. I don't believe that TDPL uses either, and I believe that they've been mostly removed from druntime and Phobos (if they haven't been entirely removed yet, they will be, aside from the aliases themselves). So, I would definitely recommend not using equals_t or hash_t, but while some of us are definitely looking to get rid of them entirely, I suspect that they'll be around semi-permanently just to preserve backwards compatibility. - Jonathan M Davis In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Does D also reserve those names? Shouldn't it? In D, any identifier starting with two underscores is reserved for implementation-specific keywords/other magic. http://dlang.org/lex.html#IdentifierStart -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: List of reserved words
On Thursday, 11 October 2012 at 07:00:10 UTC, Jacob Carlborg wrote: On dlang.org there's a page containing all the keywords, which are reserved: http://dlang.org/lex.html But it would also be nice to have a list of words/symbols that are not keywords but could otherwise be thought of being reserved. These are words that will make it problematic if used in user code in the wrong context. I thinking mostly of naming a module "object" or a class "Object", the compiler will not be happy seeing that. What other "reserved" words like these does D have? http://dpaste.dzfl.pl/c67b25a9 _param_%x identifiers where %x is an integer from 0 are implicitly declared and correspond to anonymous function parameters.
Re: List of reserved words
On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote: In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Where this is claimed?
Re: List of reserved words
On Thursday, October 11, 2012 20:20:26 monarch_dodra wrote: > In C, *technically*, anything ending in _t is reserved for future > usage, but this is not enforced. > > Does D also reserve those names? Shouldn't it? We have no so such policy AFAIK, but it's not exactly considered good style to use them either - particularly since normally, user-defined types use PascalCase, and pretty much everything else uses camelCase. name_t isn't even really a valid name (though some people would probably still use that sort of name - not everyone sticks to the typical D naming style). Typically, we only use _t names for stuff that's related to C or which is a variable sized type, in which case we swiped the C name for it (e.g. size_t). equals_t and hash_t are a bit of an exception to that, so they're quite of odd regardless. In any case though, regardless of whether *_t are considered reserved in any way shape or form, that doesn't mean that we'd want to keep equals_t or hash_t around long term, let alone use them. And we're not likely to use them for anything new unless we're just aliasing more stuff from C for C bindings, but that kind of stuff would probably end up in the druntime C bindings and not object.di where it would affect everything. - Jonathan M Davis
Re: List of reserved words
On Thursday, 11 October 2012 at 17:57:01 UTC, Jonathan M Davis wrote: On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote: On 10/11/2012 10:13 AM, Jonathan M Davis wrote: > (arguably no one should really be using hash_t or equals_t > at this point, but > I don't know if they're ever going to actually go away). I've been assuming that they were relatively newer aliases. Is it recommended to use size_t and bool instead? They're old. equals_t was done because D1 uses (used?) int for opEquals instead of bool. I don't know if there was ever a good reason for hash_t to exist. I don't believe that TDPL uses either, and I believe that they've been mostly removed from druntime and Phobos (if they haven't been entirely removed yet, they will be, aside from the aliases themselves). So, I would definitely recommend not using equals_t or hash_t, but while some of us are definitely looking to get rid of them entirely, I suspect that they'll be around semi-permanently just to preserve backwards compatibility. - Jonathan M Davis In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced. Does D also reserve those names? Shouldn't it?
Re: Tips for debugging EXC_BAD_ACCESS
On 2012-10-11 06:52:24 +, Jacob Carlborg said: I didn't have any luck with this in the learn newsgroup so I'm trying here. I'm trying to debug the Mac OS X port of DWT. Almost as soon as a DWT application starts to process events I receive a segmentation fault. The error happens in the "objc_msgSend" C function when calling an Objective-C method. Most likely, the object objc_msgSend is called on has been deallocated, which would mean that windowSendEvent is called with a deallocated NSWindow object as its first argument. I don't know how DWT works, but I'd say there's something amiss with how DWT is retaining its NSWindow. Since you're on OS X, I'd suggest you try using Instruments to track the reference counters of all Objective-C objects within your program until it crashes, then search back the history for all retain/release/autorelease calls made to the address the EXEC_BAD_ACCESS happens on. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: List of reserved words
On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote: > On 10/11/2012 10:13 AM, Jonathan M Davis wrote: > > (arguably no one should really be using hash_t or equals_t at this > > point, but > > > I don't know if they're ever going to actually go away). > > I've been assuming that they were relatively newer aliases. Is it > recommended to use size_t and bool instead? They're old. equals_t was done because D1 uses (used?) int for opEquals instead of bool. I don't know if there was ever a good reason for hash_t to exist. I don't believe that TDPL uses either, and I believe that they've been mostly removed from druntime and Phobos (if they haven't been entirely removed yet, they will be, aside from the aliases themselves). So, I would definitely recommend not using equals_t or hash_t, but while some of us are definitely looking to get rid of them entirely, I suspect that they'll be around semi-permanently just to preserve backwards compatibility. - Jonathan M Davis
Re: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 16:01:09 UTC, Iain Buclaw wrote: On 11 October 2012 16:29, David Nadlinger wrote: On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote: Does LDC only build one executable? […] Not what the LDC compiler does, the actual /usr/bin/ldc executable itself. Is it in one pieces, or in pieces? eg: GDC is in two pieces, gdc and cc1d. Ah, now I see what you mean. Yes, LDC consists of only one executable. David
Re: List of reserved words
On 10/11/2012 10:13 AM, Jonathan M Davis wrote: > (arguably no one should really be using hash_t or equals_t at this point, but > I don't know if they're ever going to actually go away). I've been assuming that they were relatively newer aliases. Is it recommended to use size_t and bool instead? Ali
Re: T.init and @disable this
Le 06/10/2012 15:21, Andrei Alexandrescu a écrit : On 10/6/12 4:06 AM, kenji hara wrote: 2012/10/6 Jonathan M Davis: On Saturday, October 06, 2012 16:27:30 kenji hara wrote: 2012/10/6 Jonathan M Davis: Regardless, we need to better sort out how disabling init works. It was my understanding that the correct way to do it was to do @disable this(); but apparently that's in dispute (at least, Kenji doesn't seem to think that that's supposed to disable the init property), and it doesn't actually work. My argue is simple: If your argument is proper behavior, you never move NonNull object. What does disabling init have to do with moving? If you're moving an object, it already exists, so it doesn't need to be default initialized. Oh, sorry. I've talked about std.algorithm.move, didn't about proper move in language semantics. I understand. Clearly we have a problem here, and it's tricky (C++ dedicates a fair amount of machinery to it). I hope we find a simpler solution that disallowing 'T x;' but requiring 'T x = T.init;' for noncopyable objects. It's subtle and difficult to be explained and accepted by newcomers. I think the compiler should prevent anything using a moved object with @disable this(); before it has been reinitialized. The compiler will be able to do so if it is able to do it for the first initialization. This isn't more complicated. It require language support, but no more than what is planned to be implemented anyway.
Re: T.init and @disable this
Le 06/10/2012 08:54, Andrei Alexandrescu a écrit :
On 10/4/12 7:33 AM, kenji hara wrote:
But, I also agree that T.init _sometimes_ *unsafe*.
1) If T has @disable this(), T.init will returns an object which just
initialized (== the value itself is never undefined), but not
constructed (might be logically invalid object).
2) If T is nested struct, it's frame pointer is always null. It might
cause access violation by its member function call.
I came up with just now: The use of such unsafe T.init should be
allowed only inside @system/@trusted functions.
I think it is acceptable limitation.
Thoughts?
I think we should go back to the rationale for introducing @disable. The
most important motivating examples were:
1. Defining NonNull references
2. Defining objects that are movable but not copyable
For NonNull references, the existence of an usable T.init would be a
definite problem because it would suddenly allow the existence of, well,
a null reference.
For (2) there may also be breakage, although more subtle: uncopyable
objects are often associated with carefully-guarded resources (e.g.
mutex locks) and shouldn't exist without special creation.
However, T.init is good to have as an always available value inside
static code that tests e.g. for capabilities.
(There's been a long-standing similar problem in C++ as well.)
A possible solution is to allow T.init for uncopyable types as an
unresolved reference: code can use it symbolically, but if it tries to
actually do things with it at runtime that would be a link-time error.
Another solution would be to define T.init for uncopyable types as
function that just throws if ever called.
Thoughts?
Andrei
.init is needed .
It is what the struct is initialized to before any constructor is
called. It may be an invalid state (it is for chars, it is for float, it
is for many classes, so why can't it be for structs ?).
That property can be made unsafe to use.
And the compiler must ensure that the struct is initialized. IE:
struct S { @disable this(); }
S s; // OK
foo(s); // Error, s is not initialized.
s = S.init; // Error in @safe code.
foo(s); // OK is @system code.
s = S(); // Error no default constructor (or may be we should allow
argument-less constructor).
Re: List of reserved words
On 11-10-2012 13:00, Iain Buclaw wrote: On 11 October 2012 07:36, Jacob Carlborg wrote: On dlang.org there's a page containing all the keywords, which are reserved: http://dlang.org/lex.html But it would also be nice to have a list of words/symbols that are not keywords but could otherwise be thought of being reserved. These are words that will make it problematic if used in user code in the wrong context. I thinking mostly of naming a module "object" or a class "Object", the compiler will not be happy seeing that. What other "reserved" words like these does D have? -- /Jacob Carlborg Pick your list from object.d: Object Throwable Exception Error ClassInfo ModuleInfo TypeInfo TypeInfo_Class TypeInfo_Interface TypeInfo_Struct TypeInfo_Typedef TypeInfo_Pointer TypeInfo_Array TypeInfo_AssociativeArray TypeInfo_Enum TypeInfo_Function TypeInfo_Delegate TypeInfo_Tuple TypeInfo_Const TypeInfo_Invariant TypeInfo_Shared TypeInfo_Wild TypeInfo_Vector It's Classinfo by the way (for whatever reason...). Some more: AssociativeArray OffsetTypeInfo MemberInfo MemberInfo_field MemberInfo_function _dg_t _dg2_t Functions: opEquals (there's a global function) setSameMutex _aaLen _aaGet _aaGetRvalue _aaIn _aaDel _aaValues _aaKeys _aaRehash _aaApply _aaApply2 _d_assocarrayliteralT destroy clear capacity reserve assumeSafeAppend _ArrayEq _xopEquals __ctfeWrite __ctfeWriteln Templates: _isStaticArray RTInfo I think that's about it. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: What is the case against a struct post-blit default constructor?
On Thursday, October 11, 2012 08:19:23 Andrei Alexandrescu wrote: > Could you please give a few examples? (Honest question.) Most structures > I define have an obvious quiescent state that vacuously satisfies the > invariant. Exceptions that come to mind are: (a) value types that must > always allocate something on the heap, see e.g. the contortions in > std.container; (b) values as permits (the existence of the value > guarantees a resource has been secured, as in scoped locks on mutexes). std.datetime.SysTime requires a valid TimeZone to function properly, but SysTime.init ends up with a null TimeZone, because it's a class, and you can't directly initialize a member variable with class object. The result of this is that SysTime can't have an invariant, because then SysTime.init would be invalid, and thanks to the fact that http://d.puremagic.com/issues/show_bug.cgi?id=5058 was resolved as invalid (the invariant gets called before opAssign even though I'd strongly argue that it shouldn't be), even assigning a valid value to a SysTime which was SysTime.init would blow up with an invariant. So, no invariant, even though it really should have one. Any situation where the init value is essentially invalid (like it would be with floating point types) makes it so that you can't have an invariant, and in many of those cases, having a default constructor which was always called would solve the problem. I'm still in favor of _not_ trying to add default constructors given all of the issues involved, and I agree that on the whole, init is a superior solution (even if it isn't perfect), but there _are_ cases where you can't have an invariant because of it. - Jonathan M Davis
Re: List of reserved words
On Thursday, October 11, 2012 13:20:28 Jacob Carlborg wrote: > On 2012-10-11 13:00, Iain Buclaw wrote: > > Pick your list from object.d: > > > > Object > > Throwable > > Exception > > Error > > ClassInfo > > ModuleInfo > > TypeInfo > > TypeInfo_Class > > TypeInfo_Interface > > TypeInfo_Struct > > TypeInfo_Typedef > > TypeInfo_Pointer > > TypeInfo_Array > > TypeInfo_AssociativeArray > > TypeInfo_Enum > > TypeInfo_Function > > TypeInfo_Delegate > > TypeInfo_Tuple > > TypeInfo_Const > > TypeInfo_Invariant > > TypeInfo_Shared > > TypeInfo_Wild > > TypeInfo_Vector > > Right, any others hiding somewhere else? Also in object.di but not listed by Iain: size_t, ptrdiff_t, sizediff_t, string, wstirng, dstring, hash_t, and equals_t (arguably no one should really be using hash_t or equals_t at this point, but I don't know if they're ever going to actually go away). But I think that it's basically a matter of what the actual keywords are and what's listed in object.di, because everything implicitly imports object.di. I don't think that there's anything outside of that that you have to worry about. - Jonathan M Davis
Re: What is the case against a struct post-blit default constructor?
Le 11/10/2012 16:35, Andrei Alexandrescu a écrit : On 10/11/12 9:52 AM, deadalnix wrote: Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : Temporary object are used to store temporary state coming from some computation. In this case, the computation create the complexity, the object isn't created via default constructor. Or have you a use case in mind I don't think of ? Here I meant a named temporary, such as e.g. a pivot in quicksort. Well a pivot is not built out of nothing. So I don't see why any constructor have to be involved here. However, postblit will be involved and can be of arbitrary complexity already. 3. Two-phase object destruction (releasing state and then deallocating memory), which is useful, is made more difficult by default constructors. Essentially the .init "pre-default-constructor" state intervenes in all such cases and makes it more difficult for language users to define and understand object states. This one is made worse by the current state. You have to assume everywhere that your struct can be .init Even when it doesn't make any sense. RefCounted is a pathologic case of that. One point I was making is that even with a default constructor, the definition and existence of .init pops all over the place, like a bubble in the carpet. I think it is a good engineering decision to simply make it the default state. A giveaway state (as compile time state, not as runtime state) solve that problem nicely. 4. Same as above applies to an object post a move operation. What state is the object left after move? C++'s approach to this, forced by the existence of default constructors and other historical artifacts, has a conservative approach that I consider inferior to D's: the state of moved-from object is decided by the library, there's often unnecessary copying, and is essentially unspecified except that "it's valid" so the moved-from object can continue to be used. This is in effect a back-door introduction of a "no-resources-allocated" state for objects, which is what default constructors so hard tried to avoid in the first place. If we give struct a giveaway state (where the struct cannot be used unless it is reinitilized to a correct value) this problem disappear. It doesn't disappear - it manifests itself in a different way (complexity in the language definition). The complexity will have to be introduced anyway to handle @disable this() properly, so I don't really see that as an added complexity. It is more like getting the most of the complexity that is already planned to be added. Except in the case 5. (and heap allocated struct in general), that in fact seems to me the major issue. I agree heaps with required allocated state are unpleasant to deal with in the current design. My overall point, which is worth repeating, is not that these problems are insurmountable. Instead, we're looking at different choices with distinct tradeoffs. There's no solution with all pluses. Well, why not let the programer make the choice ? Nothing have to change in regard to struct with no default constructor. And no complexity is added for existing stuffs.
Re: #pragma comment (lib, ...)
On 11 October 2012 17:00, Iain Buclaw wrote: > On 11 October 2012 16:29, David Nadlinger wrote: >> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote: >>> >>> Does LDC only build one executable? >> >> >> What do you mean by "only one executable" – only one object file? If the >> latter, then the answer depends on whether you pass the -singleobj switch at >> compile time. If it is specified, all the LLVM modules which would be >> codegen'd as separate object files are linked together internally before >> emitting them, if not, individual object files are generated. >> >> David > > Not what the LDC compiler does, the actual /usr/bin/ldc executable > itself. Is it in one pieces, or in pieces? eg: GDC is in two > pieces, gdc and cc1d. > Effectively, is it one executable that handles the entire compilation process from parsing options, compiling and linking. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: #pragma comment (lib, ...)
On 11 October 2012 16:29, David Nadlinger wrote: > On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote: >> >> Does LDC only build one executable? > > > What do you mean by "only one executable" – only one object file? If the > latter, then the answer depends on whether you pass the -singleobj switch at > compile time. If it is specified, all the LLVM modules which would be > codegen'd as separate object files are linked together internally before > emitting them, if not, individual object files are generated. > > David Not what the LDC compiler does, the actual /usr/bin/ldc executable itself. Is it in one pieces, or in pieces? eg: GDC is in two pieces, gdc and cc1d. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: GC statistics
On Wed, 10 Oct 2012 20:11:29 +0100, Andrei Alexandrescu wrote: This is mostly for GC experts out there - what statistics are needed and useful, yet not too expensive to collect? https://github.com/D-Programming-Language/druntime/pull/236 I'm no GC expert, but I did just spend almost a week learning how to track down GC/memory related issues in C#. I found the following windows performance counters useful: http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Roadmap for Emacs D Mode?
On Thu, 2012-10-11 at 17:15 +0200, Thomas Koch wrote: > Hi Russel, > > while we're at it: Is there a roadmap for the D Mode? Will the mode someday > be as powerful as a Java IDE? What would we need for that? Would CEDET help? No there is no road map, but there can be if someone wants to get stuck in. I am not an "Emacs is my IDE" person, I am an "Emacs is my editor" type person. My IDE is Emacs/Bash/Debian or Eclipse, IntelliJ IDEA, PyCharm. I haven't been looking at CEDET but if it can be integrated so people who are "Emacs is my IDE" type people can use it then no problem. > So the feature requests in detail: > > - completion > - jump to declaration > - refactoring > - error check while writing > - run from emacs > - run unittests from emacs > > Some of them might be dreams... I have started using AutoComplete (I get the Git repositories from GitHub rather than use the download at http://cx4a.org/software/auto-complete/#Latest_Stable but can't decide if it is useful or annoying. Running from Emacs ought to be possible, perhaps with a D menu? Refactoring is probably a dream.. -- 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: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote: Does LDC only build one executable? What do you mean by "only one executable" – only one object file? If the latter, then the answer depends on whether you pass the -singleobj switch at compile time. If it is specified, all the LLVM modules which would be codegen'd as separate object files are linked together internally before emitting them, if not, individual object files are generated. David
Roadmap for Emacs D Mode?
Hi Russel, while we're at it: Is there a roadmap for the D Mode? Will the mode someday be as powerful as a Java IDE? What would we need for that? Would CEDET help? So the feature requests in detail: - completion - jump to declaration - refactoring - error check while writing - run from emacs - run unittests from emacs Some of them might be dreams... Best regards, Thomas Koch
Re: What is the case against a struct post-blit default constructor?
On 2012-10-11, 15:52, deadalnix wrote: Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : We could (after all, C++ does it). There are a few disadvantages to doing so, however. 1. Defining static data is more difficult. Currently, all static data is statically-initialized. With default constructors, we'd need to define the pre-construction state of such objects anyway, and then change the compiler to call constructors prior to main(). I find the current design simpler and easier to use. CTFE is probably the answer here. But not all functions are CTFE-able, so it's not a solution in all cases. -- Simen
Re: #pragma comment (lib, ...)
On 11 October 2012 13:18, David Nadlinger wrote: > On Thursday, 11 October 2012 at 12:11:47 UTC, Manu wrote: >> >> LLVM? > > > LLVM is capable of emitting directly to object files, but linking is not > part of its (core) agenda. In LDC, we currently depend on "the system > linker", i.e. GCC on Unixen and link.exe on MSVC/Windows. This might change > if/when LLD (http://lld.llvm.org/) becomes stable, though. > > David Does LDC only build one executable? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: DIP20: Volatile read/write intrinsics
On 11-10-2012 14:42, Chad J wrote: On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote: I suppose a simple D_Volatile version identifier will do, like we have D_SIMD for core.simd.__simd. Cool. OK, updated. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: What is the case against a struct post-blit default constructor?
On 10/11/12 9:56 AM, deadalnix wrote: Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : Could you please give a few examples? (Honest question.) Most structures I define have an obvious quiescent state that vacuously satisfies the invariant. Exceptions that come to mind are: (a) value types that must always allocate something on the heap, see e.g. the contortions in std.container; (b) values as permits (the existence of the value guarantees a resource has been secured, as in scoped locks on mutexes). invariant will explode at you face at runtime any time you use the struct wrong where a default constructor would have prevented such use in the first place. I just mentioned that most of my structs have a natural invariant-abiding state. Worse, the faulty case can be created at any place where the struct is used and is likely to create a problem. In fact, such design rely on the well known « a good programmer don't do » which is known to be a very good way to design hard to use and error prone constructs. There's a misunderstanding here. Andrei
Re: What is the case against a struct post-blit default constructor?
On 10/11/12 9:52 AM, deadalnix wrote: Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : Temporary object are used to store temporary state coming from some computation. In this case, the computation create the complexity, the object isn't created via default constructor. Or have you a use case in mind I don't think of ? Here I meant a named temporary, such as e.g. a pivot in quicksort. 3. Two-phase object destruction (releasing state and then deallocating memory), which is useful, is made more difficult by default constructors. Essentially the .init "pre-default-constructor" state intervenes in all such cases and makes it more difficult for language users to define and understand object states. This one is made worse by the current state. You have to assume everywhere that your struct can be .init Even when it doesn't make any sense. RefCounted is a pathologic case of that. One point I was making is that even with a default constructor, the definition and existence of .init pops all over the place, like a bubble in the carpet. I think it is a good engineering decision to simply make it the default state. 4. Same as above applies to an object post a move operation. What state is the object left after move? C++'s approach to this, forced by the existence of default constructors and other historical artifacts, has a conservative approach that I consider inferior to D's: the state of moved-from object is decided by the library, there's often unnecessary copying, and is essentially unspecified except that "it's valid" so the moved-from object can continue to be used. This is in effect a back-door introduction of a "no-resources-allocated" state for objects, which is what default constructors so hard tried to avoid in the first place. If we give struct a giveaway state (where the struct cannot be used unless it is reinitilized to a correct value) this problem disappear. It doesn't disappear - it manifests itself in a different way (complexity in the language definition). Except in the case 5. (and heap allocated struct in general), that in fact seems to me the major issue. I agree heaps with required allocated state are unpleasant to deal with in the current design. My overall point, which is worth repeating, is not that these problems are insurmountable. Instead, we're looking at different choices with distinct tradeoffs. There's no solution with all pluses. Andrei
Re: Any interest in libgit bindings?
> Another thing I haven't been able to figure out yet is to how to properly > translate > include directives. It's not easy to translate to the module system used > by D. I don't have access to the include directives at all. The way I do it is to have a "toNativeType" function which translates C/C++ types to D and at the same time resolves includes. If a type is located in another module (all non-fundamental types have a fileID field in XML) then I insert that module's name to the currently generating module's imports. Once all the module's symbols are generated I generate the import directives. > Right, I missed that. It's easy to forget this kind of symbols, they're > not really keywords but they are kind of reserved words. Any other > symbols behaving like this I could have missed? Well if the library defines files which get converted to modules like 'std' you could easily conflict with Phobos. Some words I check are: std core gc rt object Object string toString toHash mangleof. But there's probably more, when something clashes I add it to the list. You could easily get standard aliases (the ones from implicitly imported object.d) hijacked, e.g. if there was a string typedef in a C library: alias const(char)* string; // hijacks string alias from object.d
Re: #pragma comment (lib, ...)
On Thu, Oct 11, 2012 at 08:46:49AM +0200, Jacob Carlborg wrote: > On 2012-10-11 04:54, Jesse Phillips wrote: [...] > >"Mister programmer man, you have unspecified library versions for... > >What do would you like to do with them? Did the currently selected > >version work out for you?" The PM tells the programmer. > > So this is just a guessing game, trail and error? > > I think it would be much better to work with packages and not > individual libraries. You would just tell the build tool, compiler or > whatever to use package "foo". Then the package manager figures out > what libraries and dependencies it needs to link to and also the path > to the import files. [...] Yeah, one of the poor design decisions of the early Redhat packaging system was to allow packages to depend on individual files, rather than packages. The result was a disastrous mess: some packages export different versions of the same file, and only a subset of them will work, leading to hair-tearing dependencies. Packages would step over each other's files, causing problems with each other and the rest of the system that depended on the same files, ad nauseum. More modern packaging systems deal with packages as units, and do not allow packages to export the same files. Plus, packages can come with metadata that specify the exact version, build, etc., of a library, making it possible for multiple versions of the same library to exist on a system, and programs to pick up the exact version they were compiled with. A huge improvement indeed. You'll be surprised at how many applications will fail horribly because a careless library author changed the ABI (often without changing the API) without bumping the library version, causing calls to the old library functions to fail inexplicably, or worse, produce subtly wrong results. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Re: What is the case against a struct post-blit default constructor?
Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : Could you please give a few examples? (Honest question.) Most structures I define have an obvious quiescent state that vacuously satisfies the invariant. Exceptions that come to mind are: (a) value types that must always allocate something on the heap, see e.g. the contortions in std.container; (b) values as permits (the existence of the value guarantees a resource has been secured, as in scoped locks on mutexes). invariant will explode at you face at runtime any time you use the struct wrong where a default constructor would have prevented such use in the first place. Worse, the faulty case can be created at any place where the struct is used and is likely to create a problem. In fact, such design rely on the well known « a good programmer don't do ... » which is known to be a very good way to design hard to use and error prone constructs.
Re: What is the case against a struct post-blit default constructor?
Le 11/10/2012 14:19, Andrei Alexandrescu a écrit : We could (after all, C++ does it). There are a few disadvantages to doing so, however. 1. Defining static data is more difficult. Currently, all static data is statically-initialized. With default constructors, we'd need to define the pre-construction state of such objects anyway, and then change the compiler to call constructors prior to main(). I find the current design simpler and easier to use. CTFE is probably the answer here. 2. Creating a temporary object cannot be anymore assumed to be a O(1), no-resources-allocated deal. Instead, generic code must conservatively assume that objects are always arbitrarily expensive to create. That makes some generic functions more difficult to implement. Temporary object are used to store temporary state coming from some computation. In this case, the computation create the complexity, the object isn't created via default constructor. Or have you a use case in mind I don't think of ? 3. Two-phase object destruction (releasing state and then deallocating memory), which is useful, is made more difficult by default constructors. Essentially the .init "pre-default-constructor" state intervenes in all such cases and makes it more difficult for language users to define and understand object states. This one is made worse by the current state. You have to assume everywhere that your struct can be .init Even when it doesn't make any sense. RefCounted is a pathologic case of that. 4. Same as above applies to an object post a move operation. What state is the object left after move? C++'s approach to this, forced by the existence of default constructors and other historical artifacts, has a conservative approach that I consider inferior to D's: the state of moved-from object is decided by the library, there's often unnecessary copying, and is essentially unspecified except that "it's valid" so the moved-from object can continue to be used. This is in effect a back-door introduction of a "no-resources-allocated" state for objects, which is what default constructors so hard tried to avoid in the first place. If we give struct a giveaway state (where the struct cannot be used unless it is reinitilized to a correct value) this problem disappear. Except in the case 5. (and heap allocated struct in general), that in fact seems to me the major issue. 5. There are a few minor issues such as correct array creation etc. but I don't consider them decisive.
Re: List of reserved words
On Thursday, 11 October 2012 at 13:27:05 UTC, Simen Kjaeraas wrote: Still, it shouldn't exactly crash the compiler. http://d.puremagic.com/issues/show_bug.cgi?id=8801
Re: List of reserved words
On 2012-10-11, 14:44, monarch_dodra wrote:
On Thursday, 11 October 2012 at 13:07:28 UTC, monarch_dodra wrote:
On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg wrote:
On 2012-10-11 13:00, Iain Buclaw wrote:
Right, any others hiding somewhere else?
__ctfe
Although I should file that as a bug I guess:
//
void main()
{
bool __ctfe = true;
}
//
Internal error: ..\ztc\cgcs.c 522
//
Never mind, "Identifiers starting with __ (two underscores) are reserved"
Still, it shouldn't exactly crash the compiler.
--
Simen
Re: List of reserved words
On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg
wrote:
On 2012-10-11 13:00, Iain Buclaw wrote:
Right, any others hiding somewhere else?
__ctfe
Although I should file that as a bug I guess:
//
void main()
{
bool __ctfe = true;
}
//
Internal error: ..\ztc\cgcs.c 522
//
Re: DIP20: Volatile read/write intrinsics
On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote: I suppose a simple D_Volatile version identifier will do, like we have D_SIMD for core.simd.__simd. Cool.
Re: List of reserved words
On Thursday, 11 October 2012 at 13:07:28 UTC, monarch_dodra wrote:
On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg
wrote:
On 2012-10-11 13:00, Iain Buclaw wrote:
Right, any others hiding somewhere else?
__ctfe
Although I should file that as a bug I guess:
//
void main()
{
bool __ctfe = true;
}
//
Internal error: ..\ztc\cgcs.c 522
//
Never mind, "Identifiers starting with __ (two underscores) are
reserved"
Re: Emacs D Mode
On Thu, 2012-10-11 at 14:16 +0200, Joseph Rushton Wakeling wrote: > On 10/11/2012 02:09 PM, Russel Winder wrote: > > GDC is indeed currently in Debian, the fact that it is only 4.6 and not > > 4.7 is a GCC thinkg nto a Debian thing. GDC should be back in 4.8. > > Yes, my understanding too. The one concern I have here is how inclusion in > official GCC will interact with the still-quite-fast-moving updates of the > frontend, druntime and Phobos. The same way it does for all other languages: Debian Stable will be woefully out of date always whilst Debian Testing and Unstable will be reasonably up to date except during a freeze (which always last far too long :-( -- 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: #pragma comment (lib, ...)
On 10/11/2012 4:59 AM, Jacob Carlborg wrote: On 2012-10-11 13:35, Walter Bright wrote: Writing a new linker for each platform is a major undertaking. Of course, but isn't writing a new compiler for each platform that as well? Are you saying that just to support pragma(lib), we should write a new linker?
Re: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 12:11:47 UTC, Manu wrote: LLVM? LLVM is capable of emitting directly to object files, but linking is not part of its (core) agenda. In LDC, we currently depend on "the system linker", i.e. GCC on Unixen and link.exe on MSVC/Windows. This might change if/when LLD (http://lld.llvm.org/) becomes stable, though. David
Re: What is the case against a struct post-blit default constructor?
On 10/10/12 6:45 AM, Don Clugston wrote: On 10/10/12 11:21, Jonathan M Davis wrote: On Monday, October 08, 2012 18:47:43 Malte Skarupke wrote: So I really can't think of a reason for why you wouldn't want this. Yet this discussion has happened several times already. There is clear demand for it and very good reasons, such as those mentioned in all the linked discussions. So why is this being rejected? It buys you pretty much nothing. There are plenty of places in the language where init is required (e.g. member variables that can't be directly initialized and the elements in an array). So, init _will_ be used regardless of what you do with the default constructor. If you want to prevent that, then you need to disable init, which we can already do. But you're not going to get those things initialized with the default constructor, which kind of defeats the purpose of the default constructor. If you can't guarantee that every instance which isn't explicitly constructed is default constructed, then what's the point? Of course there would be no point. You have not answered the question. The issue is, WHY can we not guarantee that that the struct default constructor is called? We could (after all, C++ does it). There are a few disadvantages to doing so, however. 1. Defining static data is more difficult. Currently, all static data is statically-initialized. With default constructors, we'd need to define the pre-construction state of such objects anyway, and then change the compiler to call constructors prior to main(). I find the current design simpler and easier to use. 2. Creating a temporary object cannot be anymore assumed to be a O(1), no-resources-allocated deal. Instead, generic code must conservatively assume that objects are always arbitrarily expensive to create. That makes some generic functions more difficult to implement. 3. Two-phase object destruction (releasing state and then deallocating memory), which is useful, is made more difficult by default constructors. Essentially the .init "pre-default-constructor" state intervenes in all such cases and makes it more difficult for language users to define and understand object states. 4. Same as above applies to an object post a move operation. What state is the object left after move? C++'s approach to this, forced by the existence of default constructors and other historical artifacts, has a conservative approach that I consider inferior to D's: the state of moved-from object is decided by the library, there's often unnecessary copying, and is essentially unspecified except that "it's valid" so the moved-from object can continue to be used. This is in effect a back-door introduction of a "no-resources-allocated" state for objects, which is what default constructors so hard tried to avoid in the first place. 5. There are a few minor issues such as correct array creation etc. but I don't consider them decisive. There are obvious disadvantages of the lack of a default constructor. I believe they are overcome by the advantages, although clearly reasonable people may disagree. I have a vague memory that Walter mentioned a technical difficulty once but I don't remember anything about what it was. I can't imagine what it would be. Even in the worst case, it would be possible to run CTFE on the default constructor in order to create ..init. This would limit the default constructor to things which are CTFEable, but even that would still be useful for templated structs. Allowing a default constructor that's computable during compilation would be a very interesting idea. Really, there does not seem to me to be any point in having an invariant for a struct, without a default constructor. Could you please give a few examples? (Honest question.) Most structures I define have an obvious quiescent state that vacuously satisfies the invariant. Exceptions that come to mind are: (a) value types that must always allocate something on the heap, see e.g. the contortions in std.container; (b) values as permits (the existence of the value guarantees a resource has been secured, as in scoped locks on mutexes). Andrei
Re: Emacs D Mode
On 10/11/2012 02:09 PM, Russel Winder wrote: GDC is indeed currently in Debian, the fact that it is only 4.6 and not 4.7 is a GCC thinkg nto a Debian thing. GDC should be back in 4.8. Yes, my understanding too. The one concern I have here is how inclusion in official GCC will interact with the still-quite-fast-moving updates of the frontend, druntime and Phobos.
Re: Should reduce take range as first argument?
On Thursday, 11 October 2012 at 11:17:51 UTC, bearophile wrote: monarch_dodra: Well, I went and implemented the option of doing it Range first, then Seed, so that UFCS works. To reduce deprecation troubles there is a Bugzilla suggestion to call it fold(): http://d.puremagic.com/issues/show_bug.cgi?id=8755 Bye, bearophile Hum... I can go either way. Both have their ups and downs. *fold: **No ambiguity during a migration **No ambiguity regarding argument ordering **Duplicates function names **Changes a (relatively) established function name. **Higher code impact if we deprecate reduce *reduce **Will create some ambiguity, as both reduce(r,s) and reduce(s, r) will be valid. **Will only impact reduce with seed if we deprecate the old ordering. I wouldn't mind getting a nudge in the right direction if anybody has a stance on this (Andrei?)
Re: Emacs D Mode
On Thu, 2012-10-11 at 13:54 +0200, Joseph Rushton Wakeling wrote: > On 10/11/2012 09:31 AM, Russel Winder wrote: > > (*) Along with GDC and LDC. DMD would be nice as well but might there be > > licencing conflicts that intrude? > > GDC is in Debian, but is now a little out of date (4.6.3 last time I looked) > relative to DMD frontend and Phobos. GDC is indeed currently in Debian, the fact that it is only 4.6 and not 4.7 is a GCC thinkg nto a Debian thing. GDC should be back in 4.8. -- 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: #pragma comment (lib, ...)
On 11 October 2012 12:47, Manu wrote: > On 11 October 2012 14:35, Walter Bright wrote: >> >> On 10/10/2012 11:49 PM, Jacob Carlborg wrote: >>> >>> Maybe it's time to update the old tool chain that we inherited form the >>> 70s, but >>> this is a totally different discussion. >> >> >> Writing a new linker for each platform is a major undertaking. > > > Well Microsoft's linker is obviously capable of finding lib details in the > object files. > Iain almost sounded like he had a working theory for ld. > I know nothing of OSX. LLVM? I also said talk is cheap, and there are more great ideas than what will ever be implemented. In open source development, if you want to see a feature implemented, you are usually left to do it yourself and send patches to the right places. Core devs love patches, code is expensive. :~) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: #pragma comment (lib, ...)
On 2012-10-11 13:47, Manu wrote: Well Microsoft's linker is obviously capable of finding lib details in the object files. Iain almost sounded like he had a working theory for ld. I know nothing of OSX. LLVM? I think that Mac OS X is still using ld, but I'm not sure. LLVM do have a linker but I don't remember if it's the standard system linker. The LLVM linker most likely has a better chance of handling these kind of things if ld doesn't already do that. -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-11 13:35, Walter Bright wrote: Writing a new linker for each platform is a major undertaking. Of course, but isn't writing a new compiler for each platform that as well? -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-11 13:22, Manu wrote: Okay, so I'll stop being a dick for a minute, I'm actually curious to know how you imagine it working with a tool like VisualStudio. It sounds like you're not just talking about a tool to fetch libs and dependencies, but also perform the build? And the dependencies are detailed in the build script? An inflexible build system like Visual Studio doesn't really handle that very well. I'm talking about three separate tools that work close together. The package manager, the build tool and the compiler. The package manager handles packages, i.e. collection of files. The build tool tells the compiler what files to build, what compile and link flags to use. The build tool asks the package manager of any external dependencies. If it would be possible to interact with the package manager directly from the compiler or source code, i.e. pragma(package) that would be fine. But it's always a bigger step to modify the compiler than creating a separate tool. I also don't really think that the compiler should handle this. The compiler works with single files, the package manager works with collection of files, that is, packages. A package manager which collects libs and their dependencies into common include/lib paths sounds extremely useful. But to me it sounds even more useful when combined with #pragma lib! That conveniently eliminates the lib path issue. I don't think that pragma(lib) works that way. It doesn't for for headers/import files. Say you create library "foo" and an import file, foo.di. Compiling, say main.d, together with foo.di will not link with foo.lib. I can imagine a situation where libraries would imply their associated lib just by being imported into your module. With a package manager as you describe, and source-embedded lib linkage statements, your average user would be in a position to never concern themselves with libs at all. Sounds almost as good as Java/C#. Exactly. The source -> object files would ideally know, and the linker would extract that information its self. I think that's the topic of the conversation :) Yeah, but I don't think it's there it belongs. I would also say that a package manager can be more flexible then the current state of pragma(lib). When we start to mix in versions and other type of features. The linker knows standard places to search, and non-standard places would still need to be configured... but this marry's very nicely with a package manager as you describe, since there'll never be confusion about where to look under that system. Note that when I say "import path" I'm referring to the path where to search for header (.h) files/import files (.di). The linker has nothing to do with this. The point I'm trying to make is that a solution which is only convenient when working with a particular configurable/flexible build script isn't a sufficient solution. #pragma lib is very convenient, especially in the absence of a comprehensive build environment (such as Visual Studio). I maintain that there is absolutely nowhere that understands library dependencies better than the code that produces that dependency. I'd love to be able to describe all linker requirements in that way if I could, regardless of the toolchain/operating system. Well, if it's possible to add flags for the compiler and linker it should be possible. If it's possible to create a plugin for VisualStudio that can compile D code then I'm sure that plugin needs to be able to add these kind of flags. Instead of specifying libraries and link flags I want to specify packages. These packages know which libraries, link flags and other dependencies are needed to build with. So I am actually all for a package manager for libs, particularly in conjunction with #pragma lib. That beautiful union eliminates the linker from the things that a programmer cares about almost entirely. Actually, this works quite nicely in Ruby. In Ruby the package manager overrides the standard "require" function, that would be the same as overriding "import" in D or "#include" in C/C++. But that's not possible for a library to do, so I'm trying my best here. In Ruby you also don't need any link flags or other compile flags for that matter. I have my suspicions though that unless it gains universal acceptable by the D community, the libs either won't be up to date, or just not available - which may be a worse case, in that the management of libs would be fractured across multiple management mechanisms. Absolutely, that is a real problem. But we have to start somewhere. I'm drying to do what I think is best and then collect feedback from the newsgroups. -- /Jacob Carlborg
Re: Emacs D Mode
On 10/11/2012 09:31 AM, Russel Winder wrote: (*) Along with GDC and LDC. DMD would be nice as well but might there be licencing conflicts that intrude? GDC is in Debian, but is now a little out of date (4.6.3 last time I looked) relative to DMD frontend and Phobos.
Which build tool to package for Debian?
Hi, which build tool would you recommend to be the first one packaged for Debian? This build tool would then probably also be used to build other D libraries and applications on Debian. There a two outdated/sparse wiki pages on this subject. Please update them rather then responding in this thread: http://www.prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD/Tools/Build http://www.prowiki.org/wiki4d/wiki.cgi?ToolSIG It'd be espacially interesting to see, which tools are still active and which are not worth to have a look at. Thank you very much, Thomas Koch
Re: #pragma comment (lib, ...)
On 11 October 2012 14:35, Walter Bright wrote: > On 10/10/2012 11:49 PM, Jacob Carlborg wrote: > >> Maybe it's time to update the old tool chain that we inherited form the >> 70s, but >> this is a totally different discussion. >> > > Writing a new linker for each platform is a major undertaking. > Well Microsoft's linker is obviously capable of finding lib details in the object files. Iain almost sounded like he had a working theory for ld. I know nothing of OSX. LLVM?
Re: #pragma comment (lib, ...)
On 10/10/2012 11:49 PM, Jacob Carlborg wrote: Maybe it's time to update the old tool chain that we inherited form the 70s, but this is a totally different discussion. Writing a new linker for each platform is a major undertaking.
Re: #pragma comment (lib, ...)
On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote: On 11 October 2012 12:04, Jacob Carlborg wrote: On 2012-10-11 10:12, Manu wrote: Sorry, I do know what a package manager is. I was being facetious, in that windows has no such concept, and most people use windows. It's not practical to depend on anything like that. RubyGems is working perfectly fine on Windows. Just because most Windows does not have a built in package manager and most of these open source language seems to lean towards Posix than Windows doesn't mean that you can't have a working package manager in Windows. Okay, so I'll stop being a dick for a minute, I'm actually curious to know how you imagine it working with a tool like VisualStudio. It sounds like you're not just talking about a tool to fetch libs and dependencies, but also perform the build? And the dependencies are detailed in the build script? An inflexible build system like Visual Studio doesn't really handle that very well. A package manager which collects libs and their dependencies into common include/lib paths sounds extremely useful. But to me it sounds even more useful when combined with #pragma lib! That conveniently eliminates the lib path issue. I can imagine a situation where libraries would imply their associated lib just by being imported into your module. With a package manager as you describe, and source-embedded lib linkage statements, your average user would be in a position to never concern themselves with libs at all. Sounds almost as good as Java/C#. I also maintain that it's not stupid. The build script doesn't know what libs the code will link to. I guess you're arguing that your build-script should exclusively define the features/libs, not the other way around? So what does know which libraries to link with if not the build script. Something needs to know that. The source -> object files would ideally know, and the linker would extract that information its self. I think that's the topic of the conversation :) The linker would just need to be smart enough to gather the deps from the objects while linking. The linker doesn't know anything about the import paths. The linker knows standard places to search, and non-standard places would still need to be configured... but this marry's very nicely with a package manager as you describe, since there'll never be confusion about where to look under that system. Does it work in windows and integrate with Visual Studio? If not, sadly, it's irrelevant. Of course, I build all by software to work cross-platform, what is pointing to anything else. You're talking about "working on all platforms" but then you end with this comment making the rest of your comments not very believable. I can end with the same comment. Does Visual Studio work on other platforms than Windows? No, then it's irrelevant. The point I'm trying to make is that a solution which is only convenient when working with a particular configurable/flexible build script isn't a sufficient solution. #pragma lib is very convenient, especially in the absence of a comprehensive build environment (such as Visual Studio). I maintain that there is absolutely nowhere that understands library dependencies better than the code that produces that dependency. I'd love to be able to describe all linker requirements in that way if I could, regardless of the toolchain/operating system. So I am actually all for a package manager for libs, particularly in conjunction with #pragma lib. That beautiful union eliminates the linker from the things that a programmer cares about almost entirely. I have my suspicions though that unless it gains universal acceptable by the D community, the libs either won't be up to date, or just not available - which may be a worse case, in that the management of libs would be fractured across multiple management mechanisms. For those of us doing .NET development, the answer is NuGet. http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c And there is already a package manager for Windows that uses NuGet as infrastructure. http://chocolatey.org/ -- Paulo
Re: List of reserved words
On 2012-10-11 13:00, Iain Buclaw wrote: Pick your list from object.d: Object Throwable Exception Error ClassInfo ModuleInfo TypeInfo TypeInfo_Class TypeInfo_Interface TypeInfo_Struct TypeInfo_Typedef TypeInfo_Pointer TypeInfo_Array TypeInfo_AssociativeArray TypeInfo_Enum TypeInfo_Function TypeInfo_Delegate TypeInfo_Tuple TypeInfo_Const TypeInfo_Invariant TypeInfo_Shared TypeInfo_Wild TypeInfo_Vector Right, any others hiding somewhere else? -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 11 October 2012 12:04, Jacob Carlborg wrote: > On 2012-10-11 10:12, Manu wrote: > > Sorry, I do know what a package manager is. I was being facetious, in >> that windows has no such concept, and most people use windows. >> It's not practical to depend on anything like that. >> > > RubyGems is working perfectly fine on Windows. Just because most Windows > does not have a built in package manager and most of these open source > language seems to lean towards Posix than Windows doesn't mean that you > can't have a working package manager in Windows. Okay, so I'll stop being a dick for a minute, I'm actually curious to know how you imagine it working with a tool like VisualStudio. It sounds like you're not just talking about a tool to fetch libs and dependencies, but also perform the build? And the dependencies are detailed in the build script? An inflexible build system like Visual Studio doesn't really handle that very well. A package manager which collects libs and their dependencies into common include/lib paths sounds extremely useful. But to me it sounds even more useful when combined with #pragma lib! That conveniently eliminates the lib path issue. I can imagine a situation where libraries would imply their associated lib just by being imported into your module. With a package manager as you describe, and source-embedded lib linkage statements, your average user would be in a position to never concern themselves with libs at all. Sounds almost as good as Java/C#. I also maintain that it's not stupid. The build script doesn't know what > > libs the code will link to. I guess you're arguing that your >> build-script should exclusively define the features/libs, not the other >> way around? >> > > So what does know which libraries to link with if not the build script. > Something needs to know that. The source -> object files would ideally know, and the linker would extract that information its self. I think that's the topic of the conversation :) The linker would just need to be smart enough to gather the deps from >> the objects while linking. >> > > The linker doesn't know anything about the import paths. > The linker knows standard places to search, and non-standard places would still need to be configured... but this marry's very nicely with a package manager as you describe, since there'll never be confusion about where to look under that system. Does it work in windows and integrate with Visual Studio? >> If not, sadly, it's irrelevant. >> > > Of course, I build all by software to work cross-platform, what is > pointing to anything else. > > You're talking about "working on all platforms" but then you end with this > comment making the rest of your comments not very believable. > > I can end with the same comment. Does Visual Studio work on other > platforms than Windows? No, then it's irrelevant. > The point I'm trying to make is that a solution which is only convenient when working with a particular configurable/flexible build script isn't a sufficient solution. #pragma lib is very convenient, especially in the absence of a comprehensive build environment (such as Visual Studio). I maintain that there is absolutely nowhere that understands library dependencies better than the code that produces that dependency. I'd love to be able to describe all linker requirements in that way if I could, regardless of the toolchain/operating system. So I am actually all for a package manager for libs, particularly in conjunction with #pragma lib. That beautiful union eliminates the linker from the things that a programmer cares about almost entirely. I have my suspicions though that unless it gains universal acceptable by the D community, the libs either won't be up to date, or just not available - which may be a worse case, in that the management of libs would be fractured across multiple management mechanisms.
Re: List of reserved words
On 11 October 2012 07:36, Jacob Carlborg wrote: > On dlang.org there's a page containing all the keywords, which are reserved: > > http://dlang.org/lex.html > > But it would also be nice to have a list of words/symbols that are not > keywords but could otherwise be thought of being reserved. These are words > that will make it problematic if used in user code in the wrong context. I > thinking mostly of naming a module "object" or a class "Object", the > compiler will not be happy seeing that. > > What other "reserved" words like these does D have? > > -- > /Jacob Carlborg Pick your list from object.d: Object Throwable Exception Error ClassInfo ModuleInfo TypeInfo TypeInfo_Class TypeInfo_Interface TypeInfo_Struct TypeInfo_Typedef TypeInfo_Pointer TypeInfo_Array TypeInfo_AssociativeArray TypeInfo_Enum TypeInfo_Function TypeInfo_Delegate TypeInfo_Tuple TypeInfo_Const TypeInfo_Invariant TypeInfo_Shared TypeInfo_Wild TypeInfo_Vector -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Should reduce take range as first argument?
monarch_dodra: Well, I went and implemented the option of doing it Range first, then Seed, so that UFCS works. To reduce deprecation troubles there is a Bugzilla suggestion to call it fold(): http://d.puremagic.com/issues/show_bug.cgi?id=8755 Bye, bearophile
Re: GC is reclaiming live objects
Le 11/10/2012 12:39, Walter Bright a écrit : On 10/10/2012 9:43 AM, deadalnix wrote: And I don't use C stuff in the application. I don't explicitly free anything and use the last version of D. Obviously, the problem isn't easy to reproduce in a small program, But I get consistent crash in some test cases. So, What am I supposed to do now to investigate the issue ? These kinds of issues can be hard to debug. First off, this is the first report I've heard in years that the GC is reclaiming live objects. So, my first thought is some other memory corruption is happening in your program. Actually, I have a memory corruption. When trying to debug it, I noticed that the if I disable the GC, the memory corruption didn't happened anymore. Some more investigation lead me to conclude that the GC was reclaiming live memory. This is the first time I notice that, so indeed, I'm as surprised as you. My second thought is to make sure all the compiler checks are turned on - don't use -release. Try to use @safe. The gc has several debugging versions you can uncomment. These can generate a blizzard of data, but sometimes that's the last resort. I'm currently playing with that. Make sure you don't have escaping references to a function's stack frame. These aren't detected by the compiler/runtime, and will cause horrible corruption problems. Can you elaborate on that ? It may really be the problem as I use closures quite a lot.
Re: What is the case against a struct post-blit default constructor?
On 10/8/2012 9:47 AM, Malte Skarupke wrote: So why is this being rejected? So S.init is a valid instance of S.
Re: GC is reclaiming live objects
On 10/10/2012 9:43 AM, deadalnix wrote: And I don't use C stuff in the application. I don't explicitly free anything and use the last version of D. Obviously, the problem isn't easy to reproduce in a small program, But I get consistent crash in some test cases. So, What am I supposed to do now to investigate the issue ? These kinds of issues can be hard to debug. First off, this is the first report I've heard in years that the GC is reclaiming live objects. So, my first thought is some other memory corruption is happening in your program. My second thought is to make sure all the compiler checks are turned on - don't use -release. Try to use @safe. The gc has several debugging versions you can uncomment. These can generate a blizzard of data, but sometimes that's the last resort. Make sure you don't have escaping references to a function's stack frame. These aren't detected by the compiler/runtime, and will cause horrible corruption problems. Compiling and running your program under a different operating system can often flush out corruption problems. Try valgrind on Linux.
