Re: D/Objective-C 64bit
On 2014-10-29 22:51, Christian Schneider wrote: Btw, fixed the example, thanks for giving me the right clues. Of course, it was just the manual memory management à la Objective-C that was missing! I am really lucky that I spent already days, maybe weeks debugging retain / release / autorelease on many projects, so for me this will be peanuts! I just had a little flashback. I love ARC and am looking forward for D to feature it as well, but for now, manual memory management is really not the thing that will put me off. 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. 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. 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 have all the tools ready now! I can't believe how this all rocks ;) Awesome :) -- /Jacob Carlborg
Re: D/Objective-C 64bit
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.
extern (Objective-C)
class NSComboBox : NSTextField
{
private void* _dataSource;
pragma(mangle, objcMangle!(NSComboBox,
insertItemWithObjectValue, atIndex)
void insertItem(ObjcObject object, NSInteger value);
}
Alternatively a compiler recognized UDA would work too.
@objcSel!(insertItemWithObjectValue, atIndex)
void insertItem(ObjcObject object, NSInteger value);
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.
Re: D/Objective-C 64bit
On Thursday, 30 October 2014 at 07:13:09 UTC, Jacob Carlborg wrote: On 2014-10-29 22:51, Christian Schneider wrote: Btw, fixed the example, thanks for giving me the right clues. Of course, it was just the manual memory management à la Objective-C that was missing! I am really lucky that I spent already days, maybe weeks debugging retain / release / autorelease on many projects, so for me this will be peanuts! I just had a little flashback. I love ARC and am looking forward for D to feature it as well, but for now, manual memory management is really not the thing that will put me off. 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. Slightly derailing the conversation, but I see this all the time... Isn't the situation actually this: GC allocated objects are not guaranteed to be de-allocated before program termination. If a GC allocated object is deallocated, its destructor *is* guaranteed to be called. Except: Destructors are not called for arrays of objects, whether they are structs or emplaced classes, even when they are de-allocated.
Re: D/Objective-C 64bit
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. Omg, how embarrassing ;) of course I need to put it in dealloc so that it will work with NSMutableArray et al. if I am going Objective-C memory management, then I should do it the intended way indeed! 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. So far, I was not even considering a D library that would be used through Objective-C code, but yeah, that's a good point as well. Hmm, I'm wondering if it's a good idea to lower a destructor to dealloc, just like a constructor is lowered to init. We will have to find out, but dealloc definitely is the destructor in Objc.
Re: LDC 0.15.0 alpha1 released! Please help test!
On 25/10/2014 12:58, David Nadlinger wrote: On Saturday, 25 October 2014 at 09:38:45 UTC, E.S. Quinn wrote: I notice that there's no mingw based windows version with his release. That's just an issue with building the packages for the alpha, the release will have a MinGW version. David But does the LDC MinGW build support debugging information now? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Blog Post - Reducing vibe.d turnaround time (Part 1 Faster Linking)
On Thursday, 30 October 2014 at 01:02:40 UTC, Martin Nowak wrote: This is the first post on my new blog https://code.dawg.eu/. It starts with a 3 part series on reducing vibe.d turnaround times during development. https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html There is also a friendly comment system. I've been using gold for years but still find the linking time for a vibe.d project to be a bit too long. I never did profile the build though. Atila
Re: D/Objective-C 64bit
On 2014-10-30 16:28, Christian Schneider wrote: So far, I was not even considering a D library that would be used through Objective-C code, but yeah, that's a good point as well. Isn't that what's usually happens when using something like an app delegate. It will be instantiated by the framework when loading a nib. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-10-30 10:23, John Colvin wrote: Slightly derailing the conversation, but I see this all the time... Isn't the situation actually this: GC allocated objects are not guaranteed to be de-allocated before program termination. If a GC allocated object is deallocated, its destructor *is* guaranteed to be called. Except: Destructors are not called for arrays of objects, whether they are structs or emplaced classes, even when they are de-allocated. Yes, that's the longer explanation :) -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-10-30 10:16, Martin Nowak wrote:
Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
extern (Objective-C)
class NSComboBox : NSTextField
{
private void* _dataSource;
pragma(mangle, objcMangle!(NSComboBox, insertItemWithObjectValue,
atIndex)
void insertItem(ObjcObject object, NSInteger value);
}
Alternatively a compiler recognized UDA would work too.
@objcSel!(insertItemWithObjectValue, atIndex)
void insertItem(ObjcObject object, NSInteger value);
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.
Seems like a fair point, I guess I could change that. I prefer using a
UDA for this.
--
/Jacob Carlborg
Re: D2 port of Sociomantic CDGC available for early experiments
On 30.10.2014 04:02, Martin Nowak wrote: On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze wrote: I'm benchmarking my Windows version of a concurrent GC with it. It does quite a lot of allocations, and this is causing some serious trouble because marking cannot compete with the rate of allocation, causing some tests to allocate a lot of memory, slowing down marking even more. I'm still looking for a solution... Well ultimatively you got to throttle your mutators to a throughput that the GC can handle. That's actually a nice thing about the forking GC, the mutator has to pay for the COW page faults, so there is some built-in throttling. How does your GC work? There's sort of a description here: http://rainers.github.io/visuald/druntime/concurrentgc.html There are actually two variations: - one uses Memory-Write-Watches to detect modified pages and rescans all pages modified during a background scan. It could be improved to reschedule the second scan to the background, again, until there are only few modified pages. - the other uses COW protection on the pool memory, but has to copy modified memory back when restoring unprotected memory mappings.
