Re: Firs step of D/Objective-C merged
On 2015-07-14 18:53:31 +, Jacob Carlborg said: Hmm, I see. I imagined something similar would need to be done for the new exception handling in Swift 2, but for every method, that was unexpected. Now when Swift goes open source someone can just have a look and see what's going on :) I'd be surprised if error handling had something to do with those thunks (they were there in Swift 1.2 after all). Error handling in Swift 2 is mostly a lowering of Cocoa's NSError handling pattern merged into the calling convention, where the compiler generates the necessary code in each function to propagate errors. Objective-C exceptions are still fatal errors when they reach Swift 2 code. I think those thunks are simply there so that Swift code can use Swift calling conventions everywhere, which makes things simpler on the Swift side and enables some optimizations that would not be allowed with Objective-C. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Firs step of D/Objective-C merged
On 2015-07-14 13:59:51 +, Jacob Carlborg said: On 2015-07-14 03:11, Michel Fortin wrote: More or less. If you define an `extern (Objective-C)` class in D (once all my work is merged), you can use it and derive from it in Swift. If you define an `@objc` class in Swift you can use it from Objective-C and from D, but you can't derive from it. Do you know why you can't derive from it? I'm not sure. Apple's documentation says: "You cannot subclass a Swift class in Objective-C." I assume there could be a variety of reasons, such as more aggressive optimizations. Note that the Swift ABI isn't stable yet. So the above might change at some point. But they need to follow the Objective-C ABI, for the @objc classes. I guess they technically can change the Objective-C ABI if they want to. Actually, they only need to follow it up what they guaranty will work. If you debug some Swift code mixed with Objective-C, you'll notice that every call to a Swift method from Objective-C first passes through a thunk function (not dissimilar to my first D/Objective-C bridge made using D template mixins). Now, suppose you override this function from the Objective-C side, only the thunk gets overriden and Swift calles and Objective-C callers will no longer call the same function. I haven't verified anything, but that's my theory. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Firs step of D/Objective-C merged
On 2015-07-13 14:02:54 +, Steven Schveighoffer said: I wanted to ask, swift can call into objective-C, so does this de-facto give us a D/swift binding as well? I haven't written a single line of swift yet, so apologies if this is a stupid question. More or less. If you define an `extern (Objective-C)` class in D (once all my work is merged), you can use it and derive from it in Swift. If you define an `@objc` class in Swift you can use it from Objective-C and from D, but you can't derive from it. Note that the Swift ABI isn't stable yet. So the above might change at some point. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-18 09:07:10 +, Christian Schneider said:
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
Why not use a constructor and let the compiler manage the boilerplate?
this(NSRect frame) [initWithFrame:] {
//my stuff
super(frame);
}
This should emit the same code as the function above (but I haven't
tested). And then you can write:
auto view = new KeyboardView(someFrame);
and have proper type safety.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: D/Objective-C 64bit
On 2014-11-01 10:47:54 +, Jacob Carlborg said: On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or "this.class" to get the metaclass) "this.class" could perhaps be called "this.classof", at least that's valid syntax. Although I don't know what to do about __selector. Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-04 09:07:08 +, "Christian Schneider"
said:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
That's indeed the best way to do it.
This should be the way to do it. Now in the implementation of the
action:
void doubleClickAction(ObjcObject sender) {
NSLog("double click action") ;
NSLog("the sender: %@", sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender:
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
There is no test for interface-to-class casts in the D/Objective-C test
suite, which means you're likely the first person to try that. It's
probably just an oversight in the compiler code.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
On 2014-10-30 09:16:34 +, "Martin Nowak" said:
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is available
here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
Nooo! Mangling is something different from the selector name. Mangling
is the linker symbol for the function. The selector is the name used to
find the function pointer for a given a dynamic object (with similar
purpose to a vtable offset). The function has both a mangled name and a
selector name, and they're always two different names.
Alternatively a compiler recognized UDA would work too.
@objcSel!("insertItemWithObjectValue", "atIndex")
void insertItem(ObjcObject object, NSInteger value);
Ah, that's better. Except you really should use a single string with
colons, otherwise you'll have a problem distinguishing no-parameter
selectors from single-parameter selectors.
Changing the lexer and parser would affect all D language tools
(editors, formatters, linters, other compilers). So now that we do have
UDAs I don't see a justification for changing the syntax and grammar of
D.
Very true. I agree. Now that UDAs exist, it'd be preferable to use them.
That said, there are other parts of D/Objective-C that could pose
difficulties to existing languages tools, some syntactic (__selector,
or "this.class" to get the metaclass), some semantic (overridable
static methods having a "this" pointing to the metaclass). I had to
bend the rules in some places to make all that work. But it's true that
nothing will be more confusing to those tools than the selector
declaration currently following a function name.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
On 2014-10-30 07:13:08 +, Jacob Carlborg said: I had a look at your fix. I see that you added a call to "release" in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all. D/Objective-C never allocates Objective-C objects on the GC heap. If an object derives from NSObject it is allocated using the usual Objective-C alloc class method when you use the "new" keyword. Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc". Whoever instantiated the object has no bearing on who will deallocate and call its destructor. When you call release() and the counter falls to zero, "dealloc" is called and the memory is then released. Whether that call to release() was made from D or Objective-C code is irrelevant. Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init". I can't remember if this is an oversight or just something that I hadn't got to yet. In my mind this was already done. Anyway, the answer is *yes*: the destructor should be mapped to the "dealloc" selector. It should also implicitly call the destructor for any struct within the object and call it's superclass's destructor (if present), the usual D semantics for a destructor (that part might already work actually). -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-13 18:13:44 +, Jacob Carlborg said: On 2014-03-13 17:16, Johannes Pfau wrote: Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff? I would guess so. I would need to take a look to see how coupled the code in objc.c is. Although, most code is for backend. I think that'd be a good idea too. When I wrote that code I wanted everything to be close by as it was easier to experiment, but there's no need for that now. Perhaps, instead of splitting, classes derived from frontend classes (Expression, Declaration, Type) should be moved to their corresponding files and live with other similar classes of the frontend, protected in #if DMD_OBJC blocks. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 19:02:10 +, Iain Buclaw said: From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. It all comes to how you integrate the thing with GCC. My guess is that you have three choices: 1. ignore Objective-C support: don't define DMD_OBJC in the code and the compiler will complain whenever it sees extern(Objective-C) 2. translate the calls to the DMD backend creating the various sections and segments to equivalent calls for creating sections and segments in GCC 3. replace the codegen for Objective-C data structures by what's already implemented in GCC for Objective-C This last option will support whatever ABI GCC has support for. That's probably the way to go if you want to make sure ABIs are compatible. All the Objective-C ABI DMD knows about is implemented in objc.c, so what you have to do is to rewrite objc.c to call the GCC equivalent implementation, probably getting rid of most of the code in there. NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: ".objc_class_name_%s" ".objc_category_name_%s_%s" GNU: "__objc_class_name_%s" "__objc_category_name_%s_%s" Most others look the same? Maybe you'll be able to find out more with this information. My understanding is that the differences are pretty trivial. But regardless, we probably don't have to care about them if you can hook directly to the GCC Objective-C codegen. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 17:53:35 +, Andrei Alexandrescu said: On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. The first question should about the review process. This patch touches a lot of things, so I wonder if Walter will be confortable reviewing it. Should different people review different parts? Here's a comparison view: DMD: 94 changed files with 8,005 additions and 48 deletions. https://github.com/jacob-carlborg/dmd/compare/d-objc druntime: 10 changed files with 1,263 additions and 0 deletions. https://github.com/jacob-carlborg/druntime/compare/d-objc Most of the changes to the compiler are inside #if DMD_OBJC/#endif blocks. Changes outside of those blocks shouldn't affect the semantics or the binary output of existing code. So I think a review could be done in two steps: 1. Review changes outside of those #if DMD_OBJC blocks. Those are the most critical changes as they'll affect the next version of the compiler that'll ship (I'm assuming Objective-C features won't be turned on until they're more usable). This includes some changes in the lexer, but it shouldn't affect current D code. This review could exclude the two files objc.h/objc.c, since the makefile ignores them without the D_OBJC flag. 2. Maybe review things inside of those #if DMD_OBJC blocks. Those things won't affect the compiler unless compiled with the D_OBJC flag, so it's less critical to review them. Most of them are there to implement Objective-C semantics so you'll need to be somewhat familiar with Objective-C to judge whether they're correct or not. What should be checked is whether an error would make them affect non-Objective-C constructs when they're compiled in. We also need to know what to do about the test suite. I made a separate test suite for D/Objective-C since those tests can only run on OS X and only with the compiler compiled with Objective-C support enabled. It could easily be merged with the main test suite, but the tests should be made conditional to whether the compiler is compiled with Objective-C or not. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 09:26:56 +, Iain Buclaw said: On 12 March 2014 07:10, Jacob Carlborg wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? Also, is there a list of differences between the two runtimes somewhere? Each combination being incompatible with each other subtly different ways... Which is why we have a test suite. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 08:06:47 +, "w0rp" said: This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library. Well, there's three ways. (a) The first one is to implement ARC for Objective-C objects, and to automatically add/remove roots to member variables when constructing/destroying Objective-C objects that were defined in D so the GC can those pointers. (b) The second one is to not implement ARC and implement something in the GC so it can track Objective-C objects: retain them on first sight, release them once no longer connected to a root. (c) The third one is to implement ARC as an alternative memory management scheme for D and bolt Objective-C object support on top of it. I'd tend to go for (a) at first, as it's the simplest thing that can be done. But I fear always adding/removing roots will impact performance in a negative way. There's also the issue in (a) and (b) that if the last reference to an object is released from the GC thread the Objective-C object's destructor will be called in a different thread than what is expected which might cause some bugs. So we might want to implement (c) later on to have something more solid and deterministic. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-11 22:43:58 +, "John Colvin" said: To what extent will this be portable to ldc/gdc? The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend. Shouldn't be too hard, I guess. [1]: https://github.com/jacob-carlborg/dmd/blob/d-objc/src/objc.c -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-11 18:23:07 +, Jacob Carlborg said: I just wanted to let everyone know that I have implemented D/Objective-C for 64bit. Everything that worked for 32bit should work, except for exceptions, which are not implemented yet. It's nice to see you're taking good care of that thing I started. For Objective-C exceptions to work right DMD will have to change its exception model for D exceptions to match the one used by Apple's C++ compiler. It'll make things better for everyone, and no other solution makes much sense really. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-11 20:28:58 +, Andrei Alexandrescu said: On 3/11/14, 11:23 AM, Jacob Carlborg wrote: [1] http://wiki.dlang.org/DIP43 [2] https://github.com/jacob-carlborg/dmd/tree/d-objc Wow, this is fantastic. Congratulations! Upon a quick scan, the DIP seems tasteful and well put together. Let's see how to merge this into dmd! Honestly, I don't think it's ready to be part of the official distribution (no memory management being the worse issue). But it doesn't mean it shouldn't be merged. You need to compile it with the D_OBJC define to get a compiler with Objective-C capabilities, which means that those capabilities don't necessarily need to be part of the official distribution even if the changes are merged. So merge ahead. Also, I'll be glad to participate in the review given I wrote most of that code. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C, extern (Objective-C)
On 2013-06-26 11:07:45 +, Sönke Ludwig said:
Naively I first thought that .class and .protocolof were candidates for
__traits, but actually it looks like they might simply be implemented
using a templated static property:
class ObjcObject {
static @property ProtocolType!T protocolof(this T)() {
return ProtocolType!T.staticInstance;
}
}
That's of course assuming that the static instance is somehow accessible
from normal D code.
I don't think you get what protocolof is, or if so I can't understand
what you're trying to suggest with the code above. It's a way to obtain
the pointer identifying a protocol. You don't "call" protocolof on a
class, but on the interface. Like this:
extern (Objective-C) interface MyInterface {}
NSObject object;
if (object.conformsToProtocol(MyInterface.protocolof))
{ … }
protocolof is a pointer generated by the compiler that represents the
Objective-C protocol for that interface. It's pretty much alike other
compiler generated properties such as mangleof and nameof. There's
nothing unusual about protocolof.
And that conformsToProtocol function above is a completely normal
function by the way.
As for .class, it's pretty much alike to .classinfo for D objects. The
difference is that it returns an instance of a different type depending
on the class (Objective-C has a metaclass hierarchy), so it needs to be
handled by the compiler. I used .class to mirror the name in
Objective-C code. Since this has to be compiler generated and it's type
is magic to be typeof(this).Class, I see no harm in using a keyword for
it. I could have called it .classinfo, but that'd be rather misleading
if you asked me (it's not a ClassInfo object, nor does it behave like
ClassInfo).
The __selector type class might be replaceable by a library type
Selector!(R, ARGS).
It could. But it needs compiler support for if you want to extract them
from functions in a type-safe manner. If the compiler has to understand
the type, better make it a language extension.
It would also be great to have general support for
implicit constructors and make string->NSString and delegate->ObjcBlock
available in the library instead of dedicated compiler special case.
String literals are implicitly convertible to NSString with absolutely
no overhead.
Not sure about constructors in interfaces, they seem a bit odd, but
using "init" instead and letting "new" call that is also odd...
Well, there's supported in Objective-C (as init methods), so we have to
support them.
You already mentioned @IBAction and @IBOutlet, those can obviously be
UDAs, as well as @optional and other similar keywords.
Indeed.
Maybe it's possible like this to reduce the syntax additions to
extern(Objective-C) and possibly constructors in interfaces.
Maybe. But not at the cost of memory safety.
The idea is that something written in @safe D should be memory-safe, it
should be provable by the compiler. And this should apply to
Objective-C code written in D too. Without this requirement we could
make it less magic, and allow, for instance, NSObject.alloc().init().
But that's not @safe, which is why constructors were implemented.
But we can't do this at the cost of disallowing existing idioms do in
Objective-C. For instance, I could get a pointer to a class object, and
create a new object for it. If you define this:
extern (Objective-C):
interface MyProtocol {
this(string);
}
class MyObject : NSObject, MyProtocol {
this(string) {}
}
you can then write this:
MyProtocol.Class c = MyObject.class;
NSObject o = new c("baca");
And the compiler then knows that the class pointer can allocate objects
that can be constructed with a string parameter. This is something that
can and is done in Objective-C (hence why you'll find constructors on
interfaces). The idea is to add provable memory safety on top of it.
(Note that the above example is not implemented yet, nor documented.)
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On 2013-06-25 18:06:33 +, Walter Bright said: On 6/24/2013 1:18 PM, Michel Fortin wrote: And I don't think it is very common in D either. Either way, if D was to implement ARC for its own memory allocator instead of the current GC (which would be great) there's noting to prevent implementing it so that reference counts could be incremented from the middle address of a memory block, it'd be quite easy in fact, and quite necessary too because of the way arrays work. From my reading about ARC, it seems to me that we should support it now rather than later because: 1. people will expect it of D 2. non-ARC is inherently unsafe 3. migrating non-ARC code to ARC is error-prone and a major nuisance 4. non-O-C programs can also benefit from ARC (after all, reliance on the GC is the perennial dealbreaker for people wanting to migrate high performance code to D) Exactly. Even without support for Objective-C, ARC in D is a very desirable feature. Beside that, the C++/COM WinRT API also uses ARC now, so I'd say it's becoming a must have pretty quickly. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On 2013-06-24 17:53:40 +, Walter Bright said: On 6/24/2013 6:27 AM, Michel Fortin wrote: Finally, there is a couple of features that were added to Objective-C since then that should be added to the todo list to keep feature parity. Some of those, if implemented right, could benefit the rest of D too. For instance: ARC (automatic reference counting) which is becoming a must in Objective-C. Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it. That's not a so big problem: just disallow taking pointers to member variables inside of reference-counted memory blocks. At least in SafeD. This is a quite rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone. And I don't think it is very common in D either. Either way, if D was to implement ARC for its own memory allocator instead of the current GC (which would be great) there's noting to prevent implementing it so that reference counts could be incremented from the middle address of a memory block, it'd be quite easy in fact, and quite necessary too because of the way arrays work. Usually, the most annoying part of ARC is retain cycles, especially implicit ones created by blocks (Objective-C's delegate literals). -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On 2013-06-24 10:04:01 +, Jacob Carlborg said: Regarding this syntax: void insertItem(ObjcObject object, NSInteger value) [insertItemWithObjectValue:atIndex:]; Is it possible and good to replace it with some UDA? We could use an attribute. But I don't think it would be possible to use an UDA. Currently the compiler doesn't know anything about a particular UDA, all UDA's are treated the same. It it's either a built in attribute or an UDA. Doing something in between would be a lot harder. Not necessarily. There's a couple of Objective-C classes that get special treatment by the compiler (identified by a pragma). One could do the same for an UDA so the compiler would know where to get that value. I'd surely have implemented it as an UDA if such a thing existed at the time. Perhaps we should use a string UDA. ;-) (joke) It seems contain some different things/syntax. I don't know how much Walter&Co will appreciate it. I would say that it's very little new syntax, surprisingly. But semantically there's a lot of new stuff. But the core things are just the same as with extern (C), making D ABI compatible with another language, Objective-C. I think that this is mostly is a non-breaking change. It indeed is an additive and non-breaking change. All new keywords are prefix with two underscores, which is reserved by the compiler. A lot of stuff only apply for classes/methods declared as extern (Objective-C). * extern (Objective-C) - I wouldn't really consider this new syntax * [foo:bar:] - New syntax. Does not have to use this exact syntax but the functionality it provides is essential. * Constructors in interfaces - Not really a new syntax. Just allows an existing syntax to be used in a new place. And it's only allowed in extern (Objective-C) interfaces because it does not make much sense for D interfaces. * Foo.class - I guess this technically is new syntax. The only thing making this new syntax is the use of keyword. I we really don't want this we could rename it to __class or similar. It is a new syntax. This "function" needs special semantic treatment by the compiler because it returns an object of a different class depending on the type or object you're calling it on. It also mirrors the method named "class" in Objective-C. Given these data points, it seemed appropriate to use the class keyword, which hints at the compiler magic. Hence why I tweaked the syntax to allow ".class" on Objective-C classes and objects. * __classext - Not implement yet, so that's up for discussion * String literals - No new syntax. Just an implicit conversion added I'm particularly proud of those string literals. They're way cleaner than their Objective-C counterparts. :-) * BOOL __selector(NSString) - New syntax. Kind of essential to have. Those too are better than their Objective-C counterpart too as they carry the argument and return type, making them less error-prone. * Foo.protocolof - Not really a new syntax either. I don't think this is as essential as the other features. It gives you the pointer for protocol (interface) Foo. You need that if you want to check at runtime if a class conforms to this protocol (or implements this interface in D parlance). * @IBOutlet and @IBAction - Not implemented. This could possibly be implemented as dummy UDA's. * Blocks - Not implemented. I'm wondering if we could use the delegate keyword for this. If a delegate is marked as extern (Objective-C) it's a block. Or that might perhaps be confusing. Blocks are reference-counted and don't share the two-pointer layout of a delegate. I'm not sure it'd be wise to call them delegates. But this needs some more thinking. Finally, there is a couple of features that were added to Objective-C since then that should be added to the todo list to keep feature parity. Some of those, if implemented right, could benefit the rest of D too. For instance: ARC (automatic reference counting) which is becoming a must in Objective-C. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: D/Objective-C, extern (Objective-C)
On 2013-06-23 20:24:41 +, Jacob Carlborg said: As some of you might know Michel Fortin created a fork of DMD a couple of years ago which add support for using Objective-C classes and calling Objective-C method. That is making D ABI compatible with Objective-C. I have now updated it to the latest version of DMD and druntime. All D/Objective-C tests pass and all standard tests pass. I know it was significant work to make it both play nice with the most recent OS X linker and port it to the newest DMD code base. Great achievement. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: [OT] Clang seems to implement modules
On 2012-11-19 20:43:22 +, Walter Bright said: On 11/17/2012 3:30 AM, bearophile wrote: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf One thing to note what it doesn't do - it doesn't produce a "module" scope. As far as I can tell, the symbols in imported modules all go into the global scope. It seems to be mainly a way of legitimizing precompiled headers. It's better semantically than precompiled headers because you're importing symbols only from the modules you import, not those from modules imported indirectly. Just that would be an incredible cleanup. It seems there are actually two models: you can make modules from existing headers (by writing module maps), or you can create modules directly by starting your .c/.cpp file with "export ;" as can see on the Writing a Module slide. The former approach is introduced as the transitional model, the later as the futuristic one that requires no headers. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: NaNs Just Don't Get No Respect
On 2012-08-19 05:54:49 +, Walter Bright said: On 8/18/2012 9:21 PM, Nick Sabalausky wrote: After actually *using* both D (default-initialization) and C# (statically/conservatively ensure things can't be accessed without being explicitly inited), and I'm convinced the benefits of the static checks easily outweigh the fear of a knee-jerk "=0". I'm less willing to throw default initialization out - I like it & rely on it. The C# approach pretty much ends default initialization, including for user defined types. I like default initialization too, and I rely on it. By that I mean that all the time I write "size_t count;" and assume it'll be default initialized to zero. I like it because it's less typing and it's simple: if I don't assign anything it's zero. I can't do that for floats or chars, because the default initialization gives me a unusable value. In my mind C#-style conservative flow analysis errors are better than default initialization to a bogus value because they catch the problem at compile time. But on the other side I'd rather not give up on integer default initialization to zero, as I actually prefer this over everything else. So Walter, which default initialization do you like an rely on? As I said, personally, I'd have everything initialized to zero by default. But at this point you can't really change this even if you want to: some program somewhere might rely on float being initialized to NaN by default and might start to give erroneous results if you change the default. (Notice the irony?) -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: New homepage design of d-p-l.org is now live.
On 2011-12-17 13:09:35 +, Stewart Gordon said: Strange. I don't recall ever seeing before HTML5 came along. But I am made to wonder why. What will happen when HTML6 comes out? Or have they decided that validators are just going to update themselves to the new standard rather than keeping separate HTML5/HTML6 DTDs (or whatever the HTML5+ equivalent of a DTD is)? Thing is, if they could have removed the doctype completely they would have done so. The doctype doesn't tell anything meaningful to a browser, except that today's browser use the presence of a doctype to switch between a quirk mode and a standard mode. was the shortest thing that'd make every browser use standard mode. The problem was that forcing everyone to specify either one or another HTML version is just a exercise in pointlessness. Most people get the doctype wrong, either initially or over time when someone updated the site to add some new content. If you're interested in validating your web page, likely you'll know which version you want to validate against and you can tell the validator. Stuff like improperly closed tags or bad entity encoding can break, but that's pretty well independent of doctype validation. That's simply a matter of the document being well-formed. No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. Perhaps for it matters for validation if you don't say which spec to validate against, but validating against a spec doesn't always reflect reality either. There is no SGML-based-HTML-compliant parser used by a browser out there. Browsers have two parsers: one for HTML and one for XML (and sometime the HTML parser behaves slightly differently in quirk mode, but that's not part of any spec). And whether a browser uses the HTML or the XML parser has nothing to do with the doctype at the top of the file: it depends on the MIME types given in the Content-Type HTTP header or the file extension if it is a local file. HTML 5 doesn't change that. Almost all web pages declared as XHTML out there are actually parsed using the HTML parser because they are served with the text/html content type and not application/xhtml+xml. A lot of them are not well formed XML and wouldn't be viewable anyway if parsed according to their doctype. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: New homepage design of d-p-l.org is now live.
On 2011-12-14 10:55:26 +, Robert Clipsham said: On 14/12/2011 10:12, Andrei Alexandrescu wrote: On 12/12/11 7:46 PM, Stewart Gordon wrote: On 06/12/2011 05:44, Andrei Alexandrescu wrote: http://d-p-l.org Andrei Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax??? Stewart. I wouldn't know. What needs to be done? Andrei http://validator.w3.org/check?uri=http%3A%2F%2Fwww.d-programming-language.org%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 ( http://goo.gl/pxtQE - the same link, just in case the above one gets wrapped and doesn't work) Basically, xHTML uses , html uses or depending on the tag. The rest of the issues are with non-standard tags, eg and I think. HTML 5 says and are equivalent and both valid for elements that are not expected to have a closing tag. What happens in practice, with any HTML version, is that browsers just ignore the "/". Maybe using the HTML 5 doctype will make the validator happier (although it might start to complain about other things): -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Orange 1.0.0 beta - serialization library
On 2011-08-23 06:51:57 +, Jacob Carlborg said: On 2011-08-22 21:50, Vladimir Panteleev wrote: On Sat, 20 Aug 2011 18:13:32 +0300, Jacob Carlborg wrote: I've almost finished the rewrite of my serialization library Orange. While I've never had the chance to use Orange myself, one of the problems I've often heard being associated with using Orange was large binary file sizes. What are your thoughts about this issue? If this is a real problem, do you think the toolchain could be improved in this regard (perhaps ideas such as merging bitwise-identical functions at link time)? I never heard anything being associated with using Orange. The library takes up 77.8 kb, compiled with dmd 1.067 on Mac OS X. A Hello World app using Orange takes up 1.2 mb, I don't know if that's a problem. I don't have any thoughts, I didn't know it was an issue. Yes I think the tool chain can be improved, at least I hope it can. If there's any truth in that (which I don't know), it'd probably have something to do with the amount of generated code through templates. When I was still developing the D/Objective-C bridge as a bunch of templates and stub objects, the binary size was growing significantly for each new Objective-C class I added (due to the insane number of stub functions instantiated). And at some point it became totally impractical to use, even though it worked. I doubt this is a problem for Orange because of its more limited scope, but it'd nevertheless be wise to measure how much the binary size grows when you add more types to serialize and unserialize and more code is generated as a result. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-12 16:52:10 -0400, Leandro Lucarella said: This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler! Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet. Now, I think the argument for scheduling things for deprecation is just an extreme of that: deprecating things is a nuisance because it breaks code, so we'll schedule them to be deprecated later. But then we add a warning for those things scheduled for deprecation because we don't want people to use them, and "scheduled for deprecation" has just become a synonym for "deprecated but not yet breaking your code". Fixing deprecated to not break code by default is a better option, I think. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-11 19:56:28 -0400, "Jonathan M Davis" said: The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately. Very true. I take this as an indication that the current implementation of the `deprecated` keyword is too strict by default. If it's bad that using a deprecated function breaks the code by default, then make using a deprecated function non-fatal unless the user asks for it to be fatal. To me, something scheduled for deprecation means that you know it'll be deprecated eventually, but that for now it's still okay using it. For instance, std.xml could be scheduled for deprecation, once we have a replacement we can deprecate it and nag people about using the new one. If you nag people immediately, then it's almost as good as deprecated already. That said, there's also the problem that the implementation of the "scheduled for deprecation" messages isn't very good. It'll work for modules, it'll work for template functions, but you don't know who imported the module or called the function. Moreover, calling a deprecated function from within a deprecated function yields no error; calling a scheduled-for-deprecation function from a scheduled-for-deprecation one or even a deprecated one will show an annoying message. Does that makes sense? Instead of working on fragile workarounds, better fix the problem, which is that `deprecated` is too strict by default. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-11 17:26:15 -0400, Andrew Wiley said: To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category. To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword. Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d. I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-11 05:49:14 -0400, Walter Bright said: On 7/11/2011 2:21 AM, Stephan wrote: But since phobos does not even build with it (in win32) it is pretty much useless: Right, that's why it was not made the default. It is there for people to experiment with. And also so that we can work on that problem. My work in progress: Phobos: <https://github.com/michelf/phobos/compare/master...%40property> Druntime: <https://github.com/michelf/druntime/compare/master...%40property> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 09:58:06 -0400, bearophile said: Michel Fortin: That said, if Walter doesn't like it I could change it to a more "standard" pragma syntax: pragma(objc_selector, "insertIdemWithObjectValue:atIndex:") void insertItem(ObjcObject object, NSInteger value); It's more verbose and less readable, but it'd work too. Another possible syntax, using ddoc: /// This is a selector for... void insertItem(ObjcObject object, NSInteger value); /// insertItemWithObjectValue:atIndex: Actually, that's not a very good idea because the selector is not documentation. The compiler cannot ignore it. With the Objective-C runtime, each function has a selector matching its actual Objective-C method name. The selector is what the compiler uses to call the function dynamically. The method name shouldn't be stripped like it was a comment or some documentation because that'll change and likely break the program. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 07:50:20 -0400, Robert Clipsham said: On 02/06/2011 12:49, Robert Clipsham wrote: This is pretty cool! I'd test it, but D for XCode doesn't seem to play well with XCode 4, and my XCode 3 installation appears to have disappeared since I installed 4. Will the complete OS X toolchain work with this eventually? (Interface builder, instruments etc) Does this mean in the not too distant future we'll be able to write iPhone apps in D? :o Define "not too distant". :-) DMD doesn't have an ARM backend, so you'll need to port it to LDC or GDC. It might not be that easy however since a couple of parts are in the glue code that links to the DMD backend. But if you want to start working on LDC/Objective-C or GDC/Objective-C, I'll try to help. The other issue is that it currently only support Apple's Legacy Objective-C runtime (used on 32-bit Mac OS X). iOS and 64-bit Mac OS X uses the Modern runtime which changed most of the ABI. I'll add support the Modern runtime eventually, but certainly not before DMD can emit 64-bit code on Mac OS X. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 07:49:25 -0400, Robert Clipsham said: This is pretty cool! I'd test it, but D for XCode doesn't seem to play well with XCode 4, and my XCode 3 installation appears to have disappeared since I installed 4. Will the complete OS X toolchain work with this eventually? (Interface builder, instruments etc) Current state the OSX toolchain: - Problems getting gdb recognize debug symbols. Perhaps this can be alleviated by replacing gdb with a fresh GNU version instead of Apple's... I haven't tested. Ideally, DMD would generate symbols that Apple's gdb understands. - Half-baked Xcode 4 support in D for Xcode. You can rely on Xcode 3 in the meanwhile. Given the Xcode plugin API is private and undocumented, it's not as trivial as it should be. - It might be nice to add a D parser to Interface Builder so it automatically recognize outlets and actions in D files that have Objective-C objects (thanks to D/Objective-C). I'd guess this is a private API too, but I haven't verified. Not having that is just an inconvenience however, since you can always add them manually in the IB file too. - I don't think you need to do anything for Instruments (and the underlying dtrace) to work with D code... except perhaps make debug symbols work so stack traces include line numbers. Perhaps one would want to create a custom instrument to observe the GC in druntime. I don't have much time to work on D for Xcode at the moment, mostly because I'm putting my spare time into developing D/Objective-C these days. But I'd be glad to accept pull requests for D for Xcode. <https://github.com/michelf/d-for-xcode> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 05:30:10 -0400, bearophile said: From the page: The ultimate goal is to merge the capabilities back into mainline DMD", Do you want to add a syntax like this to D/DMD? void insertItem(ObjcObject object, NSInteger value) [insertItemWithObjectValue:atIndex:]; Well, that's what I'd like. Given that you can't hide completely selectors as an implementation detail and that programmers might need to specify them from time to time -- which is all the time when declaring extern Objective-C classes! -- I thought it'd be very much appreciated if the syntax for that wasn't too unreadable. That said, if Walter doesn't like it I could change it to a more "standard" pragma syntax: pragma(objc_selector, "insertIdemWithObjectValue:atIndex:") void insertItem(ObjcObject object, NSInteger value); It's more verbose and less readable, but it'd work too. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
DMD/Objective-C Alpha 1
It's been some time since I announced I'd be attempting to hack the official D compiler to implement support for the Objective-C object model, with the ultimate goal to write Cocoa apps entirely in D. I spent about 160 hours on this project since the announcement last September, and now I'm pleased to have a first version to release. You can get it there: <http://michelf.com/projects/d-objc/> It's just the beginning. As the documentation says there is still a lot of things to implement, and there will be more bugs to fix after that. But it's nevertheless always good to make a first release of a project. It's also good to know you're not working alone. Jacob Carlborg has an automated binding generator in the works. Hopefully this will allow us to provide declarations for most of Cocoa soon. If you want to help in some way, let me know. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D for Xcode, version 1.2.2
This is a very minor update to D for Xcode. The only change is that the installer now add a "lib" symlink in the downloaded unpacked DMD 2.052 archive to make it work despite of a change in the directory layout. You can find D for Xcode here: <http://michelf.com/projects/d-for-xcode/> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Plot2kill 0.2
On 2011-03-05 18:42:26 -0500, dsimcha said: This is an extreme corner case, especially if a one-way semantic @property syntax is available to work around it. The percentage of functions that return callables is very small, and of these the percentage that would forget @property is probably very small. I'd rather bug-proneness in a ridiculous corner case than breaking tons of existing code code and losing a nice feature in the common case. The percentage of functions that return a callable is very small until you go to template land. I can easily make a container or a range of delegates, and if someone somewhere forgot to make 'front' a property in the container, in the container's range or in one of the filter range layered on top of it, then writing 'front()' to call the front delegate becomes unreliable. Is it a corner case? Yes. Is it ridiculous to expect the language to detect rare but hard to find bugs? No. Is it worth it in this case? I think so. That said, () being optional doesn't help you use setters with chaining. You'd have to not label your setters with @property for them to work with chaining, unless you want to play with a lot of nested parenthesis. (((Graph().title = abc).xTitle = def).yTitle = hij); Wow, that looks almost like Objective-C! Right. The point is that I can do the same thing with either property syntax or with chaining. The choice is up to me as the caller, if the API designer is ok with allowing this choice. Allowing optional '()' and allowing optional '=' are two different things. But contrary to optional '()' I don't see much of a problem with '=' as there's no ambiguity possible. It just looks a little strange to have a @property attribute and not restrict the property assignment syntax to it. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Plot2kill 0.2
On 2011-03-05 16:49:30 -0500, dsimcha said: On 3/5/2011 4:42 PM, Michel Fortin wrote: I've always been on the fence about this. I find it useful too, and I like the visual effect of optional parenthesis. But returning anything that is callable make things ambiguous to the reader and can even bring bugs when it comes to generic programming; and ambiguity and bugs are things I really don't want to see. So? Make the semantics of @property one-way instead of two-way and make it a best practice to always use it in generic code. @property functions **can't** be called with (), but ()s are **optional** for stuff not marked @property. There's still a small ambiguity with functions returning callable types. For instance, if you have a template defining a property of a parametrized type, forgetting to add @property to the getter could result in buggy behaviour with a callable type but work fine with everything else. Is making parenthesis optional worth making this kind of bug easier to slip by, I wonder. That said, () being optional doesn't help you use setters with chaining. You'd have to not label your setters with @property for them to work with chaining, unless you want to play with a lot of nested parenthesis. (((Graph().title = abc).xTitle = def).yTitle = hij); Wow, that looks almost like Objective-C! This discussion should probably happen somewhere else than the announcement forum though. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Plot2kill 0.2
On 2011-03-05 16:30:06 -0500, dsimcha said:
The problem with the with statement idea is that you still need to
declare the variable. I often throw up quick anonymous plots with
anonymous Figure objects, like:
Histogram(someDataSet).toFigure
.title("A Title")
.xLabel("Stuff")
.showAsMain();
But does 'with' really need a variable name? Wouldn't that work?
with (Histogram(someDataSet).toFigure()) {
title = "A Title";
xLabel = "Stuff";
showAsMain();
}
I'd even say it's more readable this way since you're now using '=' to
set your properties.
I consider the ability to have the same function be called with both
syntaxes to be a beautiful thing, not a defect. If @property is ever
fully implemented, I'll nag for an @optionalproperty tag to bring back
this **feature**.
I've always been on the fence about this. I find it useful too, and I
like the visual effect of optional parenthesis. But returning anything
that is callable make things ambiguous to the reader and can even bring
bugs when it comes to generic programming; and ambiguity and bugs are
things I really don't want to see.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Plot2kill 0.2
On 2011-03-05 15:22:15 -0500, "Robert Jacques" said:
On Sat, 05 Mar 2011 13:42:32 -0500, bearophile
wrote:
dsimcha:
I've done some major updating of my Plot2kill plotting library lately,
I see code that wants named arguments :-)
65 auto sleepinessFig = Figure(sleepinessPlot)
66 .title("Sleepiness Survey")
67 .yLabel("Sleepiness Rating")
68 .xLabel("Activity")
69 .legendLocation(LegendLocation.right)
70 .horizontalGrid(true)
71 .xTickLabels(
72 iota(3),
73 ["In Meeting", "On Phone", "Coding"]
74 );
Bye,
bearophile
Why? Each of those arguments should be able to be set after creation.
So given DRY principals, method chaining is the way to go. Besides,
Figure takes a variable number of plot arguments, which means you
couldn't support default arguments (at least with the current syntax).
The funny thing is what will happen to this code once @property is
properly implemented? I think this is a cleaner way to write the above,
and it'll work with @property:
auto sleepinessFig = Figure(sleepinessPlot);
with (sleepinessFig) {
title = "Sleepiness Survey";
yLabel = "Seeliness Rating";
xLabel = "Activity";
legendLocation = LegendLocation.right;
horizontalGrid = true;
xTickLabels(iota(3), ["In meeting, "On Phone", "Coding]);
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Alternative linker win32/64
On 2011-02-26 06:10:19 -0500, Sebastian Schuberth said: On 24.02.2011 19:41, Walter Bright wrote: The nice thing is reduction in half of the resulting binary size. That's indeed nice! The unnecessarily huge size of binaries created with D / Optlink was in fact something hindering me to use D at all! I'm sure that linker is doing it by writing compressed exe's. This means that it has the same memory footprint, and it loads slower because it must be decompressed. Also, if you store it in a zip file, the zip file IMHO, that is a common misbelief when it comes to executable compressors. AFAIK, the time required for decompression is overcompensated by the time required to read less data from disk, even still nowadays. True in general. But in the case of an executable file, how does it interacts with memory mapping in the virtual memory subsystem? If you need to actually load and decompress the whole executable upfront instead of relying on the virtual memory subsystem to load pages from disk as needed, it might very well increase your startup time. Also, if some parts of the executable needs to be paged out to disk because free physical memory is running low, this is almost free if the memory is directly mapped to a read-only file as the data is already on disk. So there's certainly some scenarios where a compressed executable will fare better, but there's surely plenty others where it's the reverse. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.067 and 2.052 release
On 2011-02-20 20:21:20 -0500, Graham St Jack said: In particular, are there any plans to re-examine the tail-const issue in light of the compiler patch proposed by Michel Fortin in his post: "const(Object)ref is here!" back in December? Note that there's now a pull request for that: <https://github.com/D-Programming-Language/dmd/pull/3> And if someone wants to test it, just download and compile the const-object-ref branch of my dmd fork: <https://github.com/michelf/dmd/tree/const-object-ref> I'm currently waiting for feedback from Walter about this (and possibly others who dare to test it before it's in the mainline) before putting more work on it. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DVM - D Version Manager
On 2011-01-26 15:24:56 -0500, Jacob Carlborg said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On 2011-01-24 07:52:24 -0500, Jacob Carlborg said: On 2011-01-24 05:26, Walter Bright wrote: https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it. BTW, what about the backend in the DMD repository. Is is ok now to just fork the repository? There's a big inviting 'Fork' button for that at the top of each page which duplicates the repository in your own account (without any warning I might add). So whether it's okay or not, I'm pretty sure most people who do not closely read the license will assume it is. A Github free account is meant for 'open-source' projects after all. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D for Xcode 1.2.1
A small update. <http://michelf.com/projects/d-for-xcode/> D for Xcode 1.2.1 (16 Jan 2011) * Fixed a link failure complaining about a missing "druntime" library on some systems. * Preliminary but very incomplete support for Xcode 4 beta. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: New home page
On 2010-10-04 14:42:22 -0400, Walter Bright said: Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says "don't use tables for layout, use CSS." Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. Very true. CSS is great, except when you want columns, especially more than 2 columns with where columns have a background that must end at the same height. That said, you could play with `display: table`. But the basic problem with `display: table` (like many "advanced" things in CSS) is that it won't work much with IE less than 8. Can you believe it took so long for Microsoft to implement this important part of a specification from 2009 (CSS 2.1)? This is really the problem with the web: the dominant browser stopped evolving during a long period and is only now beginning to catch up. So now we're navigating in a sea of workarounds because everyone needs columns and other things that need a hack to work in IE. Let's hope it gets better in the coming years as older versions of IE become obsolete. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-20 04:23:38 -0400, Jacob Carlborg said: On 2010-09-18 16:36, Michel Fortin wrote: Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading. What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way? There is no automatic conversion from a selector to a D method name: you specify the method name (as usual) and you specify the selector (if you care about the selector, like in bindings). If you have a script that automatically creates bindings, then that script is the one that must figure out what method name to use for what selector. Because of this, there is no need for the D method name to be related to the selector. When you call a method, the method name is used to find the method declaration; and the declaration contains the selector to use. Calling undeclared methods is unsupported (unlike in Objective-C). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-18 06:10:53 -0400, Jacob Carlborg said: Ok, now I'm not sure I understand. If you don't specify a selector for a declared method, how will the selector look like? In your example above, if you don't specify the selector how will it be something like: getObject:: ? Exactly. Note that this is a valid selector name. Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: QtD is suspended
On 2010-09-17 21:08:29 -0400, Walter Bright said: Andrei Alexandrescu wrote: On 9/17/10 10:48 CDT, Michel Fortin wrote: I understand the intent quite well. I'm talking about what happens if the source is const? The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it. Wouldn't copying a ref counted object require mutating the original? This is an interesting point. Reference counting requires updating the reference counter which lives alongside the referenced memory. So if you have a const reference-counting struct, you can't make a copy of it because const will transitively apply to the counter too, preventing it from being incremented. I'm not sure why you're talking about mutating "the original" though. You don't need to update the original smart pointer struct as the reference counter lives with the referenced memory to which you have access in postblit. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-17 14:48:54 -0400, Jacob Carlborg said: On 2010-09-17 19:45, Michel Fortin wrote: Also note that member functions of an extern (Objective-C) class or interface always have implicitly a selector (made from the function's name followed by as many colons as there are arguments). Will it use the parameter names to build the selector as well? No. This would be changing D's semantics. D, like C, does not require names for parameters in function prototypes, nor does it require names to be the same in overridden functions. And it's the same for Objective-C: parameters names are distinct from the selector and can be changed at will without changing the method's name. This Objective-C method: - (id)getObject:(id)anObject forKey:(id)aKey; becomes NSObject getObject(NSObject anObject, NSObject aKey) [getObject:forKey:]; In both cases, anObject and aKey can be changed without breaking compatibility. They're basically just names for local variables inside the function. Ideally blocks would be the same as delegates, but I hadn't given them much thought yet. Exactly, but I assume that would make them incompatible with existing D delegates. You misunderstood. I have no intention of changing the ABI for D delegates or anything already existing in D. But it shouldn't be too hard to wrap delegates in blocks. You probably don't even need help from the compiler to do this (unless you want it to be implicit). Take a look at the spec for blocks: <http://clang.llvm.org/docs/Block-ABI-Apple.txt> I'm not sure whether I want to support creating new categories in D; categories are quite "un-D-like" and despite their usefulness they're clash-prone. But I sure want to be able to access categories from existing Objective-C frameworks. So how exactly this would work? I don't know. Well, most of the stuff that makes Objective-C what it is, is not very D-like. D and Objective-C has different object models, D is Simula based and Objective-C is based on Smalltalk. But categories are a must, I mean a large part of the standard classes (i.e. NSObject) is split in categories. With the standard frameworks that wouldn't be such a big problem, just make regular methods of it in the class it extends, but when a non-standard framework have categories extending standard classes we start to have a problem. I know the importance of categories. I believe there should be a way to declare categories from existing Objective-C frameworks and use them. What I'm unsure of is if you should be allowed to *define* your own, but I admit being able to declare them but not define them would be strange. In any case, I have much work to do before it's time to think about categories and blocks. The most basic problem to solve in this all new Objective-C "bridge" is the memory management. But I don't want to look at this too much until I get the basics working. What about using AutoZone, the Objective-C garbage collector? But that would require memory barriers I assume. An idea would be to substitute the GC in druntime with AutoZone and have it manage every piece of memory, but Apple's garbage collector doesn't support pointers to interior of blocks so it's impossible to use for regular D even if we were to add the memory barriers it wants. And having two collectors running at the same time sounds like trouble. Please let me know when you start to think more about all this. I suggest you subscribe to my d-objc mailing list. I'll be posting about my progress there. <http://lists.michelf.com/mailman/listinfo/d-objc> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-17 11:50:51 -0400, Jacob Carlborg said:
Sounds good, I also once thought about adding extern (Objective-C) to
the language. About the selector syntax, wouldn't it be better to have
the same syntax as in Objective-C,
@selector(performSelector:withObject:). I mean D already has the
@annotation syntax for annotations/attributes I don't think we need yet
another one. I would also be nice to use
@selector(performSelector:withObject:) as an expression (or what is
called) to get the selector to a method just like in Objective-C.
I though about it, but decided against it. The @attribute syntax in D
isn't meant *at this time* to accept arguments. Nor is the DMD front
end ready to accept arguments for attributes. I don't want to inject my
code in the parsing of attributes and their propagation through the
frontend. Perhaps one day attributes will accept arguments and we could
reconsider. But in the meanwhile I try to avoid touching things which
are good candidates for possible future extensions to the regular D
language.
Also note that member functions of an extern (Objective-C) class or
interface always have implicitly a selector (made from the function's
name followed by as many colons as there are arguments). The special
selector syntax is only needed to specify a different selector than the
original. I'm not sure if this kind of implicit thing that you can
override fit very well with the notion of an attribute (certainly not
the current notion which is basically a binary flag).
For the same reason, I don't think reusing Objective-C's
"@selector(setObject:forKey:)" syntax for selector literals is a very
good idea. I'm not exactly sure what selector literals should look
like, but I'm currently leaning about simply making it a function
intrinsic:
import objc;
SEL s = objc.selector("setObject:forKey:");
Have you thought anything about the blocks that Apple added in Snow
Leopard, if those could be supported as well?
What about Objective-C categories?
Ideally blocks would be the same as delegates, but I hadn't given them
much thought yet.
I'm not sure whether I want to support creating new categories in D;
categories are quite "un-D-like" and despite their usefulness they're
clash-prone. But I sure want to be able to access categories from
existing Objective-C frameworks. So how exactly this would work? I
don't know.
In any case, I have much work to do before it's time to think about
categories and blocks. The most basic problem to solve in this all new
Objective-C "bridge" is the memory management. But I don't want to look
at this too much until I get the basics working.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: QtD is suspended
On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu
said:
On 9/17/10 9:18 CDT, Michel Fortin wrote:
On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
said:
On a funny note, we figured that for a number of reasons it would help
to allow C++-style constructors that offer access to the source; it
just turns out some idioms need to modify the source as well as the
destination.
One obvious example is the built-in hashtable that is not shared
properly when it's null. Making the copy constructor spring the
hashtable to life would make it more uniform in behavior.
At the basic level I feel uneasy with this whole idea of modifying the
source while copying. It means that you can't copy the source if it is
const. Do you really want to make const containers uncopyable?
Again, the scenario is motivated by this:
void main()
{
int[int] hash;
fun(hash);
assert(!(42 in hash));
hash[0] = 10;
fun(hash);
assert(42 in hash);
}
void fun(int[int] hash)
{
hash[42] = 42;
}
Walter's idea was as follows. If the hash's copy constructor has access
to the source, then that constructor could lazily initialize the
pointer internally shared by the existing instance (the one in main())
and the one being created (the one passed to fun()). Then, the program
would behave more predictably and also stay efficient - lazy
initialization for the win.
I understand the intent quite well. I'm talking about what happens if
the source is const? As in:
struct A {
int[int] hash;
int[int] fun() {
return hash; // hash can be altered, can copy
}
const const(int[int]) fun() {
return hash; // here hash is const, what happens?
}
}
With the second accessor the hash is const, so how can you copy it
anywhere if copying requires altering the original? Should it be an
error? Should the copy be detached when the source is const, breaking
reference semantics? Or should we add logical-const (in addition to
C++-style constructors)?
Now that I think of it, you don't need a fancy struct to make this
problem appear, you just need two layers of functions:
void fun(const(int[int]) hash) {
fun(hash); // calling ourself, how can we copy hash?
}
Although in this case we could probably assert() that hash is already
initialized.
In my mind it's simpler to just explain the notion that an
uninitialized hash is null and detached from anything else until
initialized. Objects works like this (minus the implicit initialization
part), so it shouldn't be too hard to understand. Better have pragmatic
semantics that work rather than idealistic semantics that fail at a
number of cases.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-17 10:06:27 -0400, Jacob Carlborg said:
Have you thought about what needs to be modified/added yet? Is it
basically better support for runtime reflection?
Basically I'm adding the necessary pieces so that DMD can generate
object files containing the exact same things an the Objective-C
compiler would generate. I am also adding the few necessary syntactic
additions to support this. The end result should be as efficient as the
Objective-C compiler itself.
One thing I am *not* doing is adding the alien Objective-C syntax to D.
Declaring an Objective-C class will look like this:
extern (Objective-C)
class NSObject {
NSString description() @property;
void perform(SEL selector, NSObject object)
[performSelector:withObject:];
}
and for the most part should be semantically equivalent to a regular D
class. The only cases where I'm adding to the syntax are those where
special things need to be expressed, such as the Objective-C selector
when necessary for one of the two methods above.
Most of the work is being done in the glue code that links the frontend
to the backend. I'm trying to not affect the semantics of any D
construct, simply binding them to the Objective-C runtime where
appropriate.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: QtD is suspended
On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu said: On a funny note, we figured that for a number of reasons it would help to allow C++-style constructors that offer access to the source; it just turns out some idioms need to modify the source as well as the destination. One obvious example is the built-in hashtable that is not shared properly when it's null. Making the copy constructor spring the hashtable to life would make it more uniform in behavior. At the basic level I feel uneasy with this whole idea of modifying the source while copying. It means that you can't copy the source if it is const. Do you really want to make const containers uncopyable? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-17 05:06:24 -0400, Jacob Carlborg said: On 2010-09-17 01:46, Michel Fortin wrote: <http://michelf.com/weblog/2010/dobjc-dead-end-start-anew/> The D/Objective-C bridge is a project that was aiming at making Cocoa usable from D. It's somewhat similar to QtD. The timing of this announcement isn't entirely coincidental with today's announcement about QtD: my announcement was ready, QtD's was the trigger for my Publish button. Even though the problems are probably quite different between the two projects, they both share a common need for runtime-reflection, playing with the object model from another language, static initialization from within mixins that shouldn't create circular module dependency, and probably a couple others. Are referring to the need for calling a static method on a class that should be able to be loaded from a nib? In that case have you tried, at runtime, inspecting the symbol table in the loaded binary and getting the address to the necessary functions and calling them. Do you mean creating my own parallel implementation of static constructors that disregards module dependencies? That could have worked indeed, but I had more pressing problems to handle. Lazy initialization worked as a replacement, it just was just suboptimal. It is my feeling that for dealing with Objective-C, things will be much cleaner by working directly inside of the compiler. D templates are fabulous, and I'm quite amazed that I could do what I did, but the bridge creates just too much generated code to make the whole thing usable. So I think it's time for a new approach. I noted this as well, it creates an insanely amount of code. I also noted that compiling as a dynamic library reduces the size about 50%. But even a size reduction of 50% doesn't make it much more attractive, it's still too big. That's basically why I've changed my approach. I've actually been working on my own implementation of an Objective-C/D bridge based on your blog posts and documentation. I've never released or announcement anything but I have a project at dsource: http://dsource.org/projects/dstep . I started this before your bridge supported DMD because of no support for DMD or Tango and I was not happy with the GPL license. I also added small enhancements in some places. I also have ruby scripts (based on bridgesupprt) for automatically creating bindings with results that are ok but not perfect. I was thinking about create a tool using Clang and hopefully have a completely automatic process when creating bindings. What would you say about working together on an Objective-C/D bridge? That'd be great. I'm probably not going to call it a bridge for long though: calling it a bridge won't make much sense once the object model is supported natively instead of through some abstraction. You seem well ahead of me about generating bindings. Once I have something usable inside the compiler, it shouldn't be too hard to change the output of your scripts so they generate something compatible with it. Or maybe you want to hack the compiler source with me? :-) One thing I'll have to figure out is how to share the modified compiler source code. I could publish patches against various versions of DMD, or I could provide the modified frontend source stripped from the backend, but I have no license to redistribute the backend so I can't expose directly my Git repository. I should probably ask Walter, perhaps he'll agree about having a second copy of DMD being hosted on dsource for this project. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D/Objective-C: hit a dead end, start anew
<http://michelf.com/weblog/2010/dobjc-dead-end-start-anew/> The D/Objective-C bridge is a project that was aiming at making Cocoa usable from D. It's somewhat similar to QtD. The timing of this announcement isn't entirely coincidental with today's announcement about QtD: my announcement was ready, QtD's was the trigger for my Publish button. Even though the problems are probably quite different between the two projects, they both share a common need for runtime-reflection, playing with the object model from another language, static initialization from within mixins that shouldn't create circular module dependency, and probably a couple others. It is my feeling that for dealing with Objective-C, things will be much cleaner by working directly inside of the compiler. D templates are fabulous, and I'm quite amazed that I could do what I did, but the bridge creates just too much generated code to make the whole thing usable. So I think it's time for a new approach. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Interview with InformIT part 2/3
On 2010-08-18 06:13:25 -0400, Andrei Alexandrescu said: http://www.informit.com/articles/article.aspx?p=1622265 Andrei Quoting: """ The most difficult scenario here is a class that has a struct as a member. If the struct has a destructor, it will be run non-deterministically—or possibly not at all. """ Or cause a race condition: <http://d.puremagic.com/issues/show_bug.cgi?id=4624> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D web site facelift
On 2010-07-05 18:41:25 -0400, Andrei Alexandrescu said: It appears on the left-hand side for me. He wasn't talking about that one. If you set the preferred language of your browser (or in some cases your OS) to something else than English, you'll see a big light-blue Google Translate bar at the top proposing you to translate the page in whatever preferred language you have. If your browser is set to English as the preferred language (same as the page), it doesn't appear. The three screenshots I posted earlier shows what the bar is like: http://michelf.com/img/shots/d-website-1.png http://michelf.com/img/shots/d-website-2.png http://michelf.com/img/shots/d-website-3.png That was the earlier design, but the bar is still there with this improved design and shift everything downwards when it appears, approximatively one second after the page has loaded. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D web site facelift
On 2010-07-03 14:06:26 -0400, Walter Bright said: Walter Bright wrote: Michel Fortin wrote: On a side note, I've noticed on other websites that Google Translation doesn't attempt to translate code inside a element. So I would suggest the website uses ... for its code blocks, and ... for keywords and other code-related terms in the text. That could actually make the translation useful. This must be new, it didn't use to do that. I'll take advantage of it! Sadly, it doesn't work, as it strips all the newlines out, putting your code all on one line. Bah :-( The problem is that the translator strips the line breaks. But that's still an improvement over the older "translated" code, where half the identifiers are changed, braces are changed to parenthesis and some newlines are removed randomly. I suggest you add anyway. At least this way Google can improve their translator engine and it'll then work fine. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D web site facelift
On 2010-07-02 22:29:04 -0400, Michel Fortin said: http://michelf.com/img/shots/d-website-3.png (Note: the last one is quite funny if you can read French, but perhaps also if you can't.) On a side note, I've noticed on other websites that Google Translation doesn't attempt to translate code inside a element. So I would suggest the website uses ... for its code blocks, and ... for keywords and other code-related terms in the text. That could actually make the translation useful. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D web site facelift
On 2010-07-02 21:54:15 -0400, Andrei Alexandrescu said: BCS wrote: Hello Walter, bearophile wrote: Please looks at your site with Firefox too. I did, it looks the same. What is the dot pitch of your monitor? Suggestion: attach screenshots. I think a photograph of the monitor is what you'd really need. Different monitors have different sharpness and different ways to render the same color values. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D web site facelift
On 2010-07-02 20:55:33 -0400, Walter Bright said: David Gileadi was kind enough to spend some time redesigning the look of the D web site. A preview of it is up on d-programming-language.org. This isn't about the content, just the look/style/feel. Comments welcome. Please don't put links to anything other than the front page yet, as the organization may change. It looks much better than the old one visually, but I have a few first impression comments about some things that could be improved: 1. That Google Translation bar that appears at the top of every page about one second after it has loaded is distracting from the content. Yes I can click the X, or the "turn off" button, but having all the content shift downwards a second after the page has loaded is annoying. And the "turn off" button probably won't work after I reset my cookies... hum, not even close: I see it doesn't work even if I keep my cookies, not sure why. :-/ (Note: this bar probably appears only when the default language for your browser/OS isn't English. Also, translation is overrated for a programming language website, because when you translate a page, most of the code becomes unreadable. It certainly can be useful, but I wouldn't promote it too much because the result is really suboptimal.) 2. Why is the Digital Mars logo so big? I realize it's about the same size as on the DM website, but because of the dark background it looks as if it was the main title of the website, shadowing the "D programming language 2.0" which looks like a subtitle. I think DM needs to be made a little smaller and somehow leave more room for D, and the "D programming language 2.0" below should be made more visible. This is D's website, so D should be the one getting the most attention. 3. As other have said, the contrast is suboptimal for the navigation menu on the left. As I learned myself when making websites, most people's monitors aren't properly calibrated and what looks good one one often looks bad on another. So you must account for this when choosing the colors. 4. I'd like if some unnecessary margins on some elements were reduced or removed. The site looks all squeezed if the window is not wide enough. The effect is particularly bad for code samples which have way too much margin (perhaps some margin/padding should be expressed in percents). Here are three screenshots at the size I generally keep my browser window: http://michelf.com/img/shots/d-website-1.png http://michelf.com/img/shots/d-website-2.png http://michelf.com/img/shots/d-website-3.png (Note: the last one is quite funny if you can read French, but perhaps also if you can't.) -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D/Objective-C Bridge still alive, now working on D2
On 2010-06-24 07:36:28 -0400, Trass3r said: How does it work? http://michelf.com/weblog/2007/d-objc-bridge/ Could something similar be created for C++ (automatically creating wrappers around C++ classes or whatever)? Hardly. You could probably manage it somewhat with a custom C++ preprocessor and imposing a common base class, sort of how Qt is build and probably more complex, but it wouldn't fit as well as it does with D. That all D classes derives from Object is quite handy for the bridge as it allows automatic mapping the Objective-C isEqual: method to opEquals, hash to hash, and compare: to opCmp. This automatically makes all D objects good citizens in Objective-C land, and vice-versa, even though you have to manually write mappings for method names if you have additional methods. D classes being always on the heap makes things much smoother too. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D/Objective-C Bridge still alive, now working on D2
Some of you already know my D/Objective-C bridge[1]. I know it has been a while since it was last updated, and it was limited to D1, and was left not working on Snow Leopard. Well, this morning I pushed a working D2 version on the Git repository mirror[2]. This is not an official release, it still lacks a lot of polish and some parts are in flux, but perhaps some of you will be interested in trying it out from the repository. [1]: http://michelf.com/projects/d-objc-bridge/ [2]: http://git.michelf.com/d-objc/ That said, I can't make it compile with the -inline switch. Seems like all those instantiated templates and mixins are too much for the compiler to handle... some files take forever to compile (literally). I guess I should try to reduce the template bloat, which should also reduce the insanely big output files. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: new layout on wiki4d
On 2010-06-05 21:16:32 -0400, Stewart Gordon said: Yes, people who gratuitously do text as images are another silly thing. But really puzzlingly, some people can't for their lives set appropriate alt attributes even on such images as these. Speaking of text as image, having the top header in the new wiki4d layout be a background image with no "real" content in the HTML markup doesn't ring very well with me. Actually, having a element with a proper alt="D programming lanuage" attribute instead would be better for those with stylesheet or images turned off, printed form (which often remove backgrounds including background images), screen readers, and search engines. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: struct vs. class containers (was: Re: dcollections 1.0 and 2.0a beta released)
On 2010-05-23 17:36:52 -0400, Andrei Alexandrescu said: I've thought for a very long time about the class vs. struct choice in a container, and I came to a startling conclusion: it (almost) doesn't matter. Could be either, and the tradeoffs involved are nonessential. I'm starting to wonder whether this discussion really belongs in D.announce. Perhaps you should repost this on the general newsgroup and we shall discuss it there? This newsgroup was obviously the right place for the initial dcollection announcement, be we've sidetracked quite a lot since then. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-22 16:01:37 -0400, Walter Bright said:
Michel Fortin wrote:
What's the point of having extra indirection here?
Good question. I think the answer is:
1. When do you ever want to copy a collection? I almost never do,
because copying one is an inherently expensive operation.
Whenever you need to preserve the previous state of something before
applying some transformation on it. But I agree that the copy should be
explicit because it is O(n), hence my suggestion of disabling implicit
copying for containers.
Since we're at it, a reference types container sometime makes it too
easy to just create a new reference to the same container when what you
really want is to make a copy. I happen to have a bug of this sort to
fix in my Objective-C program right now where a reference to a
container leaked where it should have been a copy, causing unwanted
mutations to the .
2. When you copy a collection, do you copy the container or the
elements in the container or both? One would have to carefully read the
documentation to see which it is. That increases substantially the
"cognitive load" of using them.
I don't see the extra cognitive load. Assuming you disable implicit
copying of the container, you'll have to use ".dup", which will work
exactly as an array. The way items are copied are exactly the same as
if the container was a reference type (you call a "dup" or equivalent
function and things get copied).
3. Going to lengths to make them value types, but then disabling
copying them because you want people to use them as reference types,
seems like a failure of design somewhere.
I agree in a way. But at the same time, forcing everyone to use a
reference type when sometime a value-type would be more adequate also
looks like a failure of design to me. To me, the best tradeoff seems to
use a value-type because it's quite trivial to create a reference-type
from a value type when you need it; the reverse is awkward.
4. That silly extra level of indirection actually isn't there. Consider
that even value locals are accessed via indirection: offset[ESP]. For a
reference collection we have: offset[EBX]. No difference (yes, EBX has
to be loaded, but if it is done more than once it gets cached in a
register by the compiler).
Have you ever worked with containers of containers? Surely yes since D
associative arrays are one of them. So assume we want to implement our
associative arrays like this:
class HashTable(Key, Value) {
Array!(Tuple!(Hash!Key, TreeSet!(Tuple!(Key, Value buckets;
}
Do you find it reasonable that the TreeSet be a reference type?
Reference-type containers would mean one indirection and one extra
allocated block for each bucket. Then add that 'Value' could itself be
a struct or class containing its own container, and you're stuck with a
third unnecessary level of indirection and extra calls to the GC
allocate containers and/or check for null. Sound quite wasteful to me.
In addition, those extra allocations add more logic to our hash table
and thus more chances for bugs.
Here I'm using a hash table as an example, the same problem applies to
many other data structures, whether they are generic or specific to a
particular problem. Container should be efficient and easy to use when
composed one inside another. That's the greatest strengths of C++
value-type containers in my opinion.
5. Just making them all reference types zeans the documentation and use
become a lot simpler.
Simpler to explain, maybe. Simpler to use, I have my doubts. You're
just moving the burden to somewhere else. A reference-type container
requires a "new Container()" somewhere, and some protection logic
against null. In exchange, you don't need to write 'ref' in functions
taking containers, and can easily copy references to the container
everywhere (sometime too easily). But the reference-type benefits
aren't entirely lost with a value-type, because it's trivial to change
a value-type as a reference-type.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-22 08:16:27 -0400, bearophile said:
Michel Fortin:
Couldn't we just make a struct that cannot be implicitly copied?
The @disable attribute was invented for this purpose too:
struct Foo {
int x;
@disable this(this) {}
}
void main() {
Foo f1;
Foo f2 = f1;
}
That prints:
test.d(7): Error: struct test9.Foo is not copyable because it is
annotated with @disable
Indeed, thanks. I figured it out by myself while you were writing this.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-22 07:56:31 -0400, Michel Fortin said:
@explicitdup struct Array { }
void testVal(Array array);
void testRef(ref Array array);
unittest {
Array array;
testVal(array); // error, cannot copy array implicitly
testVal(array.dup); // ok, array is copied
testRef(array); // ok, array is passed by reference
}
If there's already a way to achieve this, I couldn't find it.
Apparently it's already achievable this way:
struct Array {
@disable this(this);
Array dup() { return Array(...); }
...
}
It also blocks simple assignments:
Array array2 = array; // error, array is not copyable
Array array3 = array.dup; // ok
With this, I don't think we need containers to be reference types
anymore. The naive error of copying containers everywhere without you
knowing about it (as it occurs in C++) is simply no longer possible.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-21 22:55:16 -0400, Walter Bright said:
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: "impedance matching",
defined as the work necessary to get one library module to work with another
library module.
This makes me think about something.
In principle, I like the idea of containers being reference type. It
works well when passing a container to functions. But at the same time,
I despite it. By-reference containers forces you to have extra
indirections even when you don't need them, and you have to worry about
null. Sometime a value-type would be better, when creating more complex
data structures for instance:
class Channel {
private {
Array!Message inbound;
Array!Message outbound;
}
...
}
What's the point of having extra indirection here?
I've been thinking about having both by-value and by-reference
containers. The first-class name would be given to the by-reference
container to give it more visibility, but that by-reference container
would be a simple wrapper for a by-value container "part" implemented
in a struct:
struct ArrayPart(T) { ... } // by value array container.
class Array(T) {
ArrayPart!T part;
alias part this;
}
So now, if you want to reuse a container "part" to build some kind of
more complex data structure, you can do it like this:
class Channel {
private {
ArrayPart!Message inbound;
ArrayPart!Message outbound;
}
...
}
No silly extra indirection.
That said, all this gives me a feeling of an overcomplicated design.
After all, the problem is that you want to pass the container by
reference in function arguments, but it's __too easy to forget the
ref__. Perhaps that's the problem that should be fixed.
Couldn't we just make a struct that cannot be implicitly copied?
Perhaps something like this:
@explicitdup struct Array { }
void testVal(Array array);
void testRef(ref Array array);
unittest {
Array array;
testVal(array); // error, cannot copy array implicitly
testVal(array.dup); // ok, array is copied
testRef(array); // ok, array is passed by reference
}
If there's already a way to achieve this, I couldn't find it.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-20 15:47:22 -0400, bearophile said: Michel Fortin: Devirtualization is only possible in certain cases: when the function knows exactly which type it'll get.< You are wrong, in most cases there are ways to de-virtualize, even when the runtime type isn't exactly known, but sometimes to do it you have to work too much. This is probably why C# dotnet doesn't perform this optimization. It's a complex topic, I suggest you to read about it, I can't explain here, see polymorpic call points, megamorphic ones, dispatch trees, and so on. I know I simplified a bit, and I'll admit you may know more than me about dynamic dispatch optimizations. But if I'm not mistaken other devirtualizing solutions are creating multiple instances of the code path based on either static info or a runtime switch. All this isn't very different from calling a templated function, but it's more complex and less reliable (because those optimizations might not be in the compiler, or might not be applicable to all scenarios). My point all along was that it's better to stick with templates, where you're "guarantied" to get the "optimal" code path. The downside is that you lose the dynamic dispatch capabilities. But I believe those are rarely needed in most programs. And if you really need it it's quite easy and efficient to layer dynamic dispatch over static calls (much more than the reverse). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-20 09:22:27 -0400, Steven Schveighoffer said:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is instantiated to copy data from
all the other containers. The problem with using generic code is that
the compiler will needlessly duplicate functions that are identical.
One question. Have you calculated the speed difference between using an
interface and using generic code? Surely going through all those
virtual calls slows things down a lot.
I do like interfaces in principle, but I fear it'll make things much
slower when people implement things in term of interfaces. That's why
I'm not sure it's a good idea to offer container interfaces in the
standard library.
It's not that much slower. You get a much higher speedup when things
can be inlined than virtual vs. non-virtual.
Yes, but that was part of the equation: a call to a template function
can be inlined, not a virtual call (most of the time).
However, I should probably make all the functions in the concrete
implementations final. I made several of them final, but I should do
it across the board.
Yeah, probably.
One thing I just thought of -- in dcollections, similar types can be
compared to one another. For example, you can check to see if a
HashSet is equal to a TreeSet. But that would not be possible without
interfaces.
I'm not sure of what you're saying here. Are you saying it can be done
with an interface but not with a template type? Why can't this work:
class TreeSet {
bool opEquals(T)(T t) if (IsSet!T) {
if (t.length != this.length)
return false;
foreach (element; this) {
if (!t.has(element))
return false;
}
return true;
}
}
TreeSet a = new TreeSet;
HashSet b = new HashSet;
assert(a == b);
(sorry, I still have to start using the new operator overloading syntax.)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-20 08:30:59 -0400, bearophile said:
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.<
Right. But the purpose of a good compiler is to kill those,
devirtualizing. LLVM devs are working on this too. See:
http://llvm.org/bugs/show_bug.cgi?id=6054
http://llvm.org/bugs/show_bug.cgi?id=3100
Devirtualization is only possible in certain cases: when the function
knows exactly which type it'll get. But downcasting to a more generic
type and passing it around function calls strips it of this precise
information required for devirtualization. The only way to propagate
the exact type is to either instanciate a new version of the function
you call for that specific type (which is what a template does) or
inline it (because it also creates a new instance of the function,
inline inside the caller).
For instance:
void test1(List list) {
list.clear(); // can't devirtualize since we do now know which kind
of list we'll get
}
void test2() {
List list = new ArrayList;
list.clear(); // now the compiler can see we'll always have an
ArrayList, can devritualize
}
void test3(L)(L list) {
list.clear(); // parent's type is propagated, can devirtualize
if parent can.
}
Steven Schveighoffer:
The problem with using generic code is that the compiler will
needlessly duplicate functions that are identical.<
See the -mergefunc compiler switch of LDC, to merge identical
functions (like ones produced by template instantiations). This feature
is not very powerful yet, but it's present and I have seen it works.
Indeed. I'm no expert in linkers, but in my opinion this is one of the
most basic optimizations a linker should perform. And C++ has pushed
linkers to do that for years now so I'd expect most linkers to do that
already...
The problem with templates are more the multiple slightly different
instanciations. In general this is good for performance, but it's only
needed for the code paths that need to be fast. I think generic
containers should be fast.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer said: I understand these points, but I'm already using interfaces to copy data between containers. I don't have to, I could have used generic code, but this way, only one function is instantiated to copy data from all the other containers. The problem with using generic code is that the compiler will needlessly duplicate functions that are identical. One question. Have you calculated the speed difference between using an interface and using generic code? Surely going through all those virtual calls slows things down a lot. I do like interfaces in principle, but I fear it'll make things much slower when people implement things in term of interfaces. That's why I'm not sure it's a good idea to offer container interfaces in the standard library. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-19 19:01:51 -0400, Andrei Alexandrescu
said:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add and purge ...
}
Are you sure this is necessary? I'm wondering how the above is different from:
void messWith(C)(C i) if (IsAddable!C && IsPurgeable!C) {
... use i's capabilities to add and purge
}
where IsAddable just checks for an 'add' function and IsPurgeable
checks for a 'purge' function. Obviously, one is a template and the
other isn't. I'd expect the template function to be more performant
since it doesn't require an indirection to call into the container. Is
the need for runtime-swappable containers really common enough to
justify adding it to the standard library? Won't adding this encourage
people to use it without realizing the downside in performance and
failed optimization opportunities because of the hidden dynamic
dispatch? It's a quite nice idea, but I don't like the tradeoff.
This criticism is valid for containers implementing interfaces too. In
my first Java programs, I was always declaring variables as the List
interface, then instantiating an ArrayList for them, thinking it'd make
things more generic and easier to change later. Generic sometime is
good, but if you do that with containers in D you're in for an
important performance drop. Personally, I'd scrap anything that's not
made of static calls (final functions in a class are fine) so people
can't easily make these kind of mistakes (and then believe D is slow).
Also, addable and purgeable above being or'ed constants makes the
system difficult to scale to new concepts. The template predicates on
the other hand are infinitely extendable: if my containers have
'commit' and 'rollback' functions, I can define IsTransactional to
check for the presence of the functions and make some algorithms that
benefits from this. In fact, this can apply to anything, not just
containers. Range are already using this pattern. Wouldn't it make
things easier to learn if we could just reuse the same principle with
containers?
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dmd 1.060 and 2.045 release
On 2010-05-05 23:45:50 -0400, Walter Bright said: Walter Bright wrote: Alex Makhotin wrote: It takes ~40 seconds 50% load on the dual core processor(CentOS 5.3 kernel 2.6.32.4), to get the actual error messages about the undefined identifier. Definitely there's a problem. The problem is the spell checker is O(n*n) on the number of characters in the undefined identifier. That's an algorithm that can't scale then. Checking the Levenshtein distance for each known identifier within a small difference in length would be a better idea. (Clang is said to use the Levenshtein distance, it probably does something of the sort.) http://en.wikipedia.org/wiki/Levenshtein_distance -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Masahiro Nakagawa and SHOO invited to join Phobos developers
On 2010-04-30 05:02:27 -0400, SHOO said: Hmm... OK, I'll try to rewrite it. I'll thoroughly eliminate codes that resembles Tango's one by the next contribution. And I intend to refer to boost::time. If you want something concrete to restart your effort, you could use the TimeSpan/DateTime construct I've posted at the start of this thread. I guaranty it isn't based on Tango, as I've never took a look at Tango's date/time module. I got inspired from boost a little (because I've used boost::date_time a lot in the past), but I haven't copied it either. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: I made std.time for Phobos, please review my code.
On 2010-04-27 10:58:33 -0400, bearophile said: In D2 the runtime of Phobos and Tango have being merged, so all D programmers can install both libs. So the two libs must have distinct contents. So I'm for removing the time module from Phobos, and keep only the Tango one. So this module is waste of time, and efforts have to be redirected in improving or rewriting the time module of Tango. Othrwise in D2 it will happen the same mess it's happend in D1, where you have two partially duplicated libs. All D2 programmers will want to install both libs, and they will not desire to choose what time lib to use. One time lit is enough. Tango's license is more restrictive than Phobos. It might not be a concern to you, but this is one reason someone might not want to use Tango in a project. Saying everyone will always want to use both libs is a little too much optimistic in my opinion. Phobos isn't using the Boost license for nothing. About the mess, as long as both libraries run on the same runtime, the problems should be confined to writing conversion function to convert the data types that differs between the two libraries. I don't think this is anything to worry about: those things happens all the time when you're using libraries from different sources. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: I made std.time for Phobos, please review my code.
On 2010-04-27 07:22:12 -0400, SHOO said: Thanks to your response. I think that handling DST is necessary too. But I am unfamiliar about DST so that people of the Ascii character string zone are unfamiliar about multi-byte character string. (I live in Japan which does not use DST.) I may not exactly recognize bugs even if I implemented it. I want to leave the implementation to other people who knows DST well. The problem with DST (and time zones in general) is that it's subject to change. DST dates were changed a couple of years ago here in Canada and in the United States; operating system vendors made a patch for this and things went smoothy (for the most part) for applications using the OS to know about DST. This can get more complicated though: for Israel (post 2005) you'll need to follow the hebrew calendar[1], and before 2005 it's mostly arbitrary. I think timezones and DST management are better left to the OS. What is most important to have is a way to convert local dates and times to UTC and the reverse, and to determine the local UTC offset for a given time. I'd leave the rest to other libraries, or OS-specific APIs. [1]: http://en.wikipedia.org/wiki/Israel_Summer_Time -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: I made std.time for Phobos, please review my code.
// The length in each unit since epoch.
alias span.ticks ticks;
alias span.milliseconds milliseconds;
alias span.seconds seconds;
alias span.minutes minutes;
alias span.hours hours;
alias span.days days;
// The truncated value for each unit (seconds can never exceed 60)
T millisecond() { return span.milliseconds % 1000; }
T second() { return span.seconds % 60; }
T minute() { return span.minutes % 60; }
T hour() { return span.hours % 24; }
T day() { return span.days; }
// UTC Offset
TimeSpan!(short, Unit.minute) offset;
}
alias UtcDateTime!(int, Unit.tick) UtcTime;
alias DateTime!(int, Unit.tick) Time;
alias UtcDateTime!(int, Unit.day) UtcDate;
alias DateTime!(int, Unit.day) Date;
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: MessagePack for D released
On 2010-04-25 08:20:17 -0400, "Masahiro Nakagawa" said:
I release a serialization library for Phobos(D2).
Project repository: http://www.bitbucket.org/repeatedly/msgpack4d
MessagePack is a binary-based serialization spec.
See official site for details: http://msgpack.sourceforge.net/
Some application replace JSON with MessagePack for performance improvement.
msgpack4d ver 0.1.0 has an equal features with reference implementation.
* Zero copy serialization / deserialization
* Stream deserializer
* Support some D features(Range, Tuple)
Currently, Phobos doesn't have a real serialization module(std.json
lacks some features)
I hope Phobos adopts this library for serialization(std.msgpack or
std.serialization?).
Looks well done. There's one thing I'd suggest though. I'm pretty sure
you could make it even faster by skipping the mp_Object intermediary
representation and using templates. I know it's possible since I've
done it for a surprisingly similar serialization library I'm working on.
The trick is to reuse the same pattern in the unpacker as you're
already using in the packer. For instance, the packer has this function:
ref Packer pack(T)(in T value) if (is(Unqual!T == long))
so the unpacker could have this function (just changed 'in' by 'out'):
ref Unpacker unpack(T)(out T value) if (is(Unqual!T == long))
My library works by unserializing everything directly a the right place
in a data structure while it parses the stream. Looks like this:
MyStruct original;
Archiver archiver;
archiver.encode(original);
immutable(byte)[] data = archiver.outout;
MyStruct copy;
Unarchiver unarchiver;
unarchiver.input = data
unarchiver.decode(copy);
This is unlike mp_Object which is in itself an intermediary
representation that sits between the serialized data and the data
structure you actually want to rebuild. I still have something similar
to mp_Object as a convenience for types that prefer to implement a
custom unserialization process in an order not dictated by the input
stream, but this is less efficient:
void decode(ref KeyUnarchiver archive) {
archive.decode("var1", var1);
archive.decode("var2", var2);
}
What I'm trying to put to work now is a way to deal with multiple
references to the same object. I'd also like a nice way to deal with
Variant, but I'm under the impression this won't be possible without
adding serialization support directly into Variant, or into TypeInfo.
Masahiro, sorry: this started as a useful commentary on your
unserializer's approach and I ended up instead promoting what I am
doing. Your library seems targeted at making a MessagePack serializer,
with an emphasis on having a simple and portable serialization format,
which is great when you want to communicate in this format. But on my
side, I care more about being able of recreating object graphs and
reinstantiating objects of the correct class when unserializing. That
does not seem possible with your library, and MessagePack doesn't
support this so it doesn't seem likely it can be added easily, am I
right?
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: D for Xcode 1.2
On 2010-04-02 04:40:11 -0400, Jacob Carlborg said: I had no idea that DMD2 supported the -noboundscheck flag. It's quite new, it disables bound checking in @safe function (safe functions normally keep bound checks in release mode). It's not really gone. You can add a build rule in each target specifying GDC as the compiler for D source files. I would like to have a better solution, but right now I don't. Ideally, there would be a build setting for choosing the default compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2, GCC-LLVM and Clang. But I haven't been able to make something similar. If you ever implement this there could be separate options for DMD1 and DMD2. You can also choose between DMD1 and DMD2 by creating a per-target custom build rule (if you have both versions installed). But I agree it'd make more sense to have this as a build setting similar to how you can choose your C/C++/Objective-C compiler. I was referring to Interface Builder recognizing D files with the IBOutlet and IBAction templates. I was thinking that since you already have an XCode plugin and if you could access the mentioned methods it could be easier using the first option. But as a long term solution the second option would be the preferred one. Note that you don't really need IB integration to use actions and outlet in IB: you can create a class definition directly in IB and add your actions and outlets manually. Obviously, IB will think it's Objective-C, so your action names will have a colon suffix. More importantly it's not automated. Generating Objective-C files and making them visible to IB can't be made to be easy to use in my opinion, but you should be able to write a script with a regular expression to do that and integrate it into your build process if you want. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D for Xcode 1.2
On 2010-04-01 15:24:59 -0400, Jacob Carlborg said: I've download the new version of your plugin and have tested it and have few comments. The first thing I noticed when I compiled a project was that it tries to pass the '-noboundscheck' flag to DMD, which it doesn't support. Yes it does, but only for D2. It should not do that by default though... I'll look at it. Ideally this option wouldn't be available for D1, but the way the default compiler version is chosen makes it difficult to know which one is used. I also noted that now the plugin overwrites/removes the GDC support. It would be nice if both could be supported. It's not really gone. You can add a build rule in each target specifying GDC as the compiler for D source files. I would like to have a better solution, but right now I don't. Ideally, there would be a build setting for choosing the default compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2, GCC-LLVM and Clang. But I haven't been able to make something similar. Have you ever investigated if it would be possible create a plugin for Interface Builder that would add D support? I've been thinking of two ways this might be done. I've found this blog post which I think is quite interesting: http://cocoawithlove.com/2009/02/interprocess-communication-snooping.html . I was thinking if the method described there could be used to add D support to Interface Builder. I was thinking of implementing a class that generates temporary Objective-C header files out of D files, implementing the methods described in the post and responding with the temporary Objective-C files. I've tried to implement a kind of dummy class which responds to the methods but Interface Builder didn't like them for some reason. The other idea I was thinking of was to create an actual plugin for Interface Builder containing a D parser that does the same as Interface Builder does but for D files. I'm not sure I understand clearly what you mean by 'D support for IB', but here's what I can say: Interface Builder generates some sort of serialization of Objective-C objects. You need the D/Objective-C bridge to load Nib files instantiating D classes (but it works!). If you want Interface Builder to recognize D files with the IBOutlet and IBAction templates found in the D/Objective-C bridge, then making a parser plugin for IB (your second option) would make most sense. But I'm not there yet. making the bridge work on Snow Leopard has a higher priority right now (even though I'm not really working on that currently). Great work by the way with the plugin, I specially like that D files are correctly recognized now. Thanks for your comments. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D for Xcode 1.2
On 2010-03-23 14:38:17 -0400, Wayne Anderson said: I too, initially, misinterpreted the language and checked the version of my copy of XCode to see if it was 1.2. I would suggest "D plugin, version 1.2, for Xcode" or "version 1.2 of the D Plugin for Xcode" Not having "plugin" in the name leaves more room for growth. The current package downloads and installs a compiler, so in a way it's already more than a plugin. Adding modules for OS X APIs might be the next step. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D for Xcode 1.2
On 2010-03-22 17:19:02 -0400, Bernard Helyer said: On 23/03/10 10:03, Michel Fortin wrote: Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any suggestion? D for Xcode, 1.2 Good idea. Thanks. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D for Xcode 1.2
On 2010-03-22 14:41:45 -0400, Nekuromento said: Great! Thank you for your efforts! Btw, is there any progress with your D to Objective-C bridge ? Well, I made the necessary changes to make it compile with DMD, and I think I got it to work on Leopard, but right now it's crashing on Snow Leopard for some reasons hard to figure out. GDB not working right with DMD-generated code doesn't help working on this. I'm not sure if I should continue working on the D 1.0 branch of if I should jump directly to D 2.0 for future development. Porting it to D 2.0 would also be a good opportunity to add support for the Objective-C 2.0 "advanced" runtime. Because it only supports the 1.0 "legacy" runtime, the current bridge wouldn't work with Cocoa 64-bit, or on an iPhone, assuming we had a the proper backends and D runtime to go with it. You can look at the current state by fetching from the git repository. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D for Xcode 1.2
On 2010-03-22 14:51:31 -0400, Jacob Carlborg said: On 2010-03-22 14.30, Michel Fortin wrote: More details and some screenshots on the website: <http://michelf.com/projects/d-for-xcode/> Very nice. Two things: 1. It's possible to misinterpret that the version number in "D for Xcode 1.2" is for Xcode and not for the plugin Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any suggestion? 2. Are D files still recognized as DTrace files by default? This is now fixed, thanks to method swizzling. :-) You can look at the version history on the website for a list of changes and the remaining known issues. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D for Xcode 1.2
It's been a while since DMD has been available on Mac OS X, but I haven't made an official release of D for Xcode to support DMD. Today I'm fixing that. So D for Xcode 2.1 now supports DMD. It comes with an installer package that does the following: * Install D plugin for Xcode * Install Xcode file and project templates for D * Download and install latest version of DMD 2.x * Download and install latest version of DMD 1.x This means that someone can just run the installer and immediately start writing/compiling D code within Xcode. It's using DMD 2.x by default, but there is no problem installing both versions at the same time and changing the default. More details and some screenshots on the website: <http://michelf.com/projects/d-for-xcode/> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Tango built as a dynamic library
On 2010-03-16 15:01:43 -0400, Walter Bright said: Jacob Carlborg wrote: I've managed to build Tango as a dynamic library with DMD on Mac OS X. I had some problems first but I managed to solve them and everything seems to work now. Thanks for doing this. In the next update, I plan to remove the special deh sections, and instead make the EH tables available through the ModuleInfo. This should simplify the management of multiple sections, as the only data structure that needs to be aggregated will be the ModuleInfo array. Shouldn't that also apply to TLS sections for when the linker does not support the feature? I'm thinking of Mac OS X and Windows XP with dynamically-loaded DLLs. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.056 and 2.040 release
On 2010-02-04 01:39:44 -0500, Walter Bright said: Michel Fortin wrote: It's about something interesting I added to this bug report. I submitted a patch for it, 363. Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.056 and 2.040 release
On 2010-01-30 22:35:28 -0500, Walter Bright said: Michel Fortin wrote: It's great to have TLS working on Mac OS X. But it looks like it suffers from the same linking problem as the module info section. I've added some useful observations to bugzilla that might help fix the issue in case you want to revisit it: http://d.puremagic.com/issues/show_bug.cgi?id=3453 You have to recompile *everything* with the new dmd, or anything dependent on the ModuleInfo will not work. This has nothing to do with a partially recompiled program. It's about something interesting I added to this bug report. And trust me, I compiled the test case from scratch before using dumpobj and objdump on the object files and the linked executables. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.056 and 2.040 release
On 2010-01-30 02:13:48 -0500, Walter Bright said: http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.040.zip It's great to have TLS working on Mac OS X. But it looks like it suffers from the same linking problem as the module info section. I've added some useful observations to bugzilla that might help fix the issue in case you want to revisit it: http://d.puremagic.com/issues/show_bug.cgi?id=3453 -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.056 and 2.040 release
$ dmd Digital Mars D Compiler v2.040 Copyright (c) 1999-2009 by Digital Mars written by Walter Bright Interestingly, copyright date is still 2009. Is this a bug or a feature? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.054 and 2.038 release
On 2009-12-31 13:48:09 -0500, Walter Bright said: Happy New Year! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.054.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.038.zip Many thanks to the numerous people who contributed to this update. Thanks. There's a quite annoying bug on Mac OS X that I've been able to reduce to a very simple test case. Depending on link order, static initializers might not work, resulting in, among other things, a non-functional writeln. Also when that happens even 'throw' often does not work (execution continues after throw!). It seems linked. This makes 'enforce' non-functional and you get a null dereference when calling writeln instead of an exception. The workaround seems to be to always link first the module containing 'main'. But it's quite annoying that you can get a segfault with a program as simple as hello world split in two modules. Would it be possible to look at it? <http://d.puremagic.com/issues/show_bug.cgi?id=3453> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.052 for Mac OSX 10.6
On 2009-11-13 01:52:07 -0500, Walter Bright said: Anders Bergh wrote: No, but you'll need to use the 10.4 SDK (it's optional when you install Xcode though). Same problem as last time, between 10.4 and 10.5. But any binaries you compile for 10.4 should work on 10.6 as well. I did have the 10.4 SDK installed, but apparently the upgrade deleted it because the makefiles that referred to it all broke. Yeah, it does so. Unless you check the "Mac OS X 10.4 Support" subpackage, which is unchecked by default, in the custom installation panel of the Xcode installer. Also, you can keep your old installations of Xcode on 10.6. I have Xcode 2.5 from Tiger, 3.0 and 3.1 from Leopard, and 3.2 from Snow Leopard running all side by side just fine on my computer. This includes both the IDE and the command line utilities. Even the old compilers and linkers work fine. Before installing a new version, I just rename the old "/Developer" folder to something else so the new one won't override it. It is documented to work in the Read Me file accompanying Xcode, and it does indeed work fine. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.052 for Mac OSX 10.6
On 2009-11-13 05:20:44 -0500, Walter Bright said: No way to test on 10.5 without buying yet another machine. I don't know if it works or not on 10.5. The "bus error" for 10.4 is probably back because installing the 10.6 dev system from Apple seems to have deleted the 10.4 stuff. Really? Can't you just partition your hard disk in two for 10.5? I'm not saying you should take the burden of testing with both, but saying you can't install 10.5 alongside 10.6 seems dubious to me: 1. Use Disk Utility to resize your current partition and create a new one. 2. Boot using your 10.5 installer DVD and install on the new partition. 3. Press option at startup to see a boot menu; open the Startup preference pane to set the default boot partition (or use "bless" on the command line). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: ACCU 2010 Call for Papers
On 2009-07-20 23:12:00 -0400, Andrei Alexandrescu said: Michel Fortin wrote: On 2009-07-20 17:30:19 -0400, Andrei Alexandrescu said: * Talking about a particular library or framework is always very popular. Example: "Dux: A High-Performance windowing/building/constraint solving/matrix/math/logging/networking/persistence/you got the idea library for D" I've been wondering if a talk about how I built a bridge between D and Objective-C would be interesting: an explanation of how each successive template layer improves on the previous one, working for making it easy and safe to use at the end. Since the bridge is all written in D, it'd be a showcase for D templates and mixins, and for the limited compile-time reflexion from D1 that's needed. It'd also be an introduction to the Objective-C runtime and how two languages can be made to pass objects and throw exceptions at each other seamlessly. All this in one package (but is 90 minutes enough?). Seems to be an interesting topic. Any time is enough for the right level of detail. That said, even if it's an interesting subject, I'm not sure I'm fluent enough in english, and I'm not much interested in defraying the cost to go there either, and I'm not sure of how much time I'll have to prepare it. As always there are many reasons for which something cannot be done, and there's one good reason for which something can, which is your desire to do it and overcome difficulties. When I landed in the States in January 1998 I had studied virtually no English, and K&R, Stroustrup and Hollywood movies had been pretty much all my resources; to this day I have not taken one class of English at any level. By any reasonable estimation, a book project would have simply been out of the question. Well, I'm better off than you were then. I'm pretty good at writing english, and although I'm able to speak and being understood I guess I just have not enough practice to be confident. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: ACCU 2010 Call for Papers
On 2009-07-20 17:30:19 -0400, Andrei Alexandrescu said: * Talking about a particular library or framework is always very popular. Example: "Dux: A High-Performance windowing/building/constraint solving/matrix/math/logging/networking/persistence/you got the idea library for D" I've been wondering if a talk about how I built a bridge between D and Objective-C would be interesting: an explanation of how each successive template layer improves on the previous one, working for making it easy and safe to use at the end. Since the bridge is all written in D, it'd be a showcase for D templates and mixins, and for the limited compile-time reflexion from D1 that's needed. It'd also be an introduction to the Objective-C runtime and how two languages can be made to pass objects and throw exceptions at each other seamlessly. All this in one package (but is 90 minutes enough?). That said, even if it's an interesting subject, I'm not sure I'm fluent enough in english, and I'm not much interested in defraying the cost to go there either, and I'm not sure of how much time I'll have to prepare it. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.046 and 2.031 releases
On 2009-07-07 01:12:12 -0400, Andrei Alexandrescu said: Nick Sabalausky wrote: Those examples are all cases where the meaning and context are wildly different fbetween one use and the other. But with '..', both uses are very similar: "From xxx to (incl/excl) yyy". Big differences are ok, they stand out as obvious. Small differences can be more problematic. You'd have an uphill battle using a counterfeit Swiss army knife against a battery of Gatling guns arguing that case 'a': .. case 'z': is very similar with 0 .. 10 That's actually much more different than e.g. a = b * c; versus b * c; They aren't so much different if you consider "case 'a':" and "case 'z':" as two items joined by a "..", which I believe is the expected way to read it. In the first case "case 'a':" and "case 'z':" joined by a ".." means an inclusive range, in the second case "0" and "10" joined by a ".." means an exclusive one. With "b * c", the meaning is completly different depending on whether b is a type or not. If "b" is a type, you can't reasonabily expect "b * c" to do a multiplication and you'll get an error about it if that's what you're trying to do. Wheras with "case 'a': .. case 'b':" you can reasonably expect an exclusive range if you aren't too familiar with the syntax (and that's a resonable expectation if you know about ranges), and you won't get an error of you mix things up; thus, clarity of the syntax becomes more important. I still think that having that syntax is better than nothing, but I do believe it's an inconsistency and that it may looks ambiguous to someone unfamiliar with it. But my worse grief about that new feature is the restriction about 256 values which is pretty limitating if you're writing a parser dealing with ranges of unicode characters. I guess I'll have to continue using ifs for that. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Slide design
On 2009-05-04 14:47:10 -0400, Sean Kelly said: For lectures I basically have a choice between two options: 1. Take notes and not remember a darn thing that was said. 2. Not take any notes and remember the lecture. I've seen a few raised eyebrows at times, but this is why I never write anything down at a meeting or lecture I'm attending--it draws my focus away from the material being presented. What I really like is when a lecturer provides pre-written notes for their presentation. This way I can get everything out of the lecture itself, and still have material to review later if I want to be reminded of some detail. Other than a professor or two I've seen precious few people actually do this however. Strangely enough, I was doing this most of the time during lectures at university. I was taking notes, but only scarcely, and often not at all in the many courses where there was enough supporting material. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
