Re: D/Objective-C 64bit
Do you get a compile time error or runtime error? Compiling using dmd... source/document.d(79): Error: function foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is not callable using argument types (Class, Class, typeof(null)) compile time. hmm, a class object is of course not an ObjcObject, how could it be. I think here is a limit to what is possible, this is the darn id of Objective-C that makes all this funky convenience possible. Actually, it's not a big deal, there is other methods to get what you want and the above mentioned function in question is by itself just a convenience.
Re: D/Objective-C 64bit
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self =
[super...]. KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
// Initialization code here.
}
return self;
}
@end
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame)
[initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
This compiles and does not throw any runtime error, but it's a
bit against the idea, because in Objective-C the idea is to first
call the super class, then adapt and override what is necessary.
When calling super in the very end, this of course is no longer
guaranteed.
Re: Devisualization.Image
15.11.2014 07:48, Rikki Cattermole пишет: To further Devisualization, I have got the start of an image library. It should be fairly interface complete now. For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted. Goal: to act as the image representation within memory (including colors). Usage: Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?). Devisualization.Font heavily uses it for glyphs and the output of its rasterization. [0] https://github.com/Devisualization/image I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib There're also importers for BMP and TGA.
Re: Devisualization.Image
On 18/11/2014 10:37 p.m., Timur Gafarov wrote: 15.11.2014 07:48, Rikki Cattermole пишет: To further Devisualization, I have got the start of an image library. It should be fairly interface complete now. For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted. Goal: to act as the image representation within memory (including colors). Usage: Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?). Devisualization.Font heavily uses it for glyphs and the output of its rasterization. [0] https://github.com/Devisualization/image I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib There're also importers for BMP and TGA. Hmm I see. There is quite a few incompatibilities so porting or reusing isn't really an option without hitting the filesystem at this time. Unfortunately. While I like the idea of dlib, I'm not a fan of all encompassing libraries atleast now (yes yes I know Cmsed and all). I don't feel adding a dependency on the entire package is worth it. However by the looks of things, you definitely have better quality code. At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it.
Re: Devisualization.Image
On Tuesday, 18 November 2014 at 10:04:15 UTC, Rikki Cattermole wrote: However by the looks of things, you definitely have better quality code. At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it. Please consider the abstraction in ae-graphics. http://code.dlang.org/packages/ae-graphics CyberShadow has presented his image abstraction here: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ It seems to be the best we have in D ecosystem and in the same spirit of Phobos. If using it we could have loader/exporters, resizing, and various processing in separate libraries with a lot of reusability, instead of each one having an incompatible image abstraction.
Re: D/Objective-C 64bit
Speaking of drawing, I have a very serious problem wit NSView. I cannot call frame() nor bounds() on instances or subclasses and get a valid NSRect. (same goes for NSWindow frame()). I had similar problems when working with NSAttributedString and NSRange, because NSRange from Chocolat was still 32 bit. After fixing this, it all worked perfectly. The parameter to drawRect, which is a NSRect as well contains correct values. So it seems to me that the NSRect struct declared as is should work just fine. I am trying to implement drawRect in an NSView subclass (in the Portmidi example, KeyboardView). Everything works fine, NSBezierPath drawing methods etc., but I cannot call this.frame() nor this.bounds() from within that method without triggering a runtime segmentation fault. Often I see this in the crash log as last message: misaligned_stack_error_entering_dyld_stub_binder Sometimes there is other stuff, but always indicating a memory corruption. I have not the slightest idea what could be the problem here, it most likely is not a threading issue, as drawRect is anyway called on the main thread, and usually one only has crashes if one tries to update widgets from background threads, which of course is not allowed in Cocoa, as the AppKit is not thread safe. I just checked back, for any widget it fails. You can easily reproduce it by e.g. opening the SimpleWebBrowser example and add in applicationDidFinishLaunching (this is a good point, because all the UI element should be ready): NSRect backButtonFrame = backButton.frame() ; NSLog(frame %f %f %f %f, backButtonFrame.origin.x, backButtonFrame.origin.y, backButtonFrame.size.width, backButtonFrame.size.height) ; For custom components, if this won't work, it is almost a deal breaker for using Cocoa through D. This is quite a setback, all the rest so far encountered is working so beautifully.
Re: D/Objective-C 64bit
On 2014-11-18 09:46, Christian Schneider wrote: Compiling using dmd... source/document.d(79): Error: function foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is not callable using argument types (Class, Class, typeof(null)) compile time. hmm, a class object is of course not an ObjcObject, how could it be. I think here is a limit to what is possible, this is the darn id of Objective-C that makes all this funky convenience possible. Actually, it's not a big deal, there is other methods to get what you want and the above mentioned function in question is by itself just a convenience. Hmm, I don't know. Can you use a cast to get around the problem? Perhaps use a variadic template to make the API simpler. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 10:07, Christian Schneider wrote:
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self = [super...].
KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
// Initialization code here.
}
return self;
}
@end
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
This compiles and does not throw any runtime error, but it's a bit
against the idea, because in Objective-C the idea is to first call the
super class, then adapt and override what is necessary. When calling
super in the very end, this of course is no longer guaranteed.
Can't you just call super in the beginning of the method and then call
return this at the end. Something like this:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
super.initWithFrame(frame);
// my stuff
return this;
}
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 13:47, Christian Schneider wrote: Speaking of drawing, I have a very serious problem wit NSView. I cannot call frame() nor bounds() on instances or subclasses and get a valid NSRect. (same goes for NSWindow frame()). I had similar problems when working with NSAttributedString and NSRange, because NSRange from Chocolat was still 32 bit. After fixing this, it all worked perfectly. The parameter to drawRect, which is a NSRect as well contains correct values. So it seems to me that the NSRect struct declared as is should work just fine. I am trying to implement drawRect in an NSView subclass (in the Portmidi example, KeyboardView). Everything works fine, NSBezierPath drawing methods etc., but I cannot call this.frame() nor this.bounds() from within that method without triggering a runtime segmentation fault. Often I see this in the crash log as last message: misaligned_stack_error_entering_dyld_stub_binder Sometimes there is other stuff, but always indicating a memory corruption. Could it be this issue [1]? Can you please see if you can reproduce it using just plain C. https://issues.dlang.org/show_bug.cgi?id=5570 -- /Jacob Carlborg
Re: Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
On 11/17/14 4:41 PM, Martin Nowak wrote: Second part on my series to reduce vibe.d turnaround time. In this part we'll reduce compilation time by 60%. https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html http://www.reddit.com/r/programming/comments/2moam6/reducing_vibed_turnaround_time_part_2_less/ https://twitter.com/D_Programming/status/534741185693089793 Andrei
vibe.d 0.7.21 has been released
Just quickly (finally) announcing the release of the next vibe.d version. This one was originally scheduled for start of September, but I got extremely busy with no time left for tidying everything up. The list of changes is long with notable improvements to the web interface generator, the Redis client and the SSL/TLS implementation (including added SNI support). However, the improvements are all over the place. It also compiles on the latest DMD compiler releases (there have been some breaking changes in 2.066). The full list of changes/fixes can be found at http://vibed.org/blog/posts/vibe-release-0.7.21 Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d
Re: Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
On 11/17/2014 4:41 PM, Martin Nowak wrote: Second part on my series to reduce vibe.d turnaround time. In this part we'll reduce compilation time by 60%. https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html -Martin Should say in the title that you reduced build times by 60%. Otherwise, have to read all the way to the end to find it! It's a great statistic, and having it in the title people will have more reason to read the article.
Re: Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
On 11/17/2014 4:41 PM, Martin Nowak wrote: Second part on my series to reduce vibe.d turnaround time. In this part we'll reduce compilation time by 60%. https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html -Martin There's no mention of your name as author in the blog!?
Re: D/Objective-C 64bit
Compiling using dmd... source/document.d(79): Error: function foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is not callable using argument types (Class, Class, typeof(null)) Hmm, I don't know. Can you use a cast to get around the problem? Perhaps use a variadic template to make the API simpler. Yes, of course, and this is really not an issue! And this convenience function can be rewritten in a few lines of code, if really necessary.
Re: D/Objective-C 64bit
Could it be this issue [1]? Can you please see if you can reproduce it using just plain C. https://issues.dlang.org/show_bug.cgi?id=5570 Uh, oh, that bug looks like a major annoyance in 64bit! I made a few checks, all appkit methods returning a NSRect currently produce a runtime segfault. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work. What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do.
Re: Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
On 11/18/2014 08:34 PM, Walter Bright wrote: Should say in the title that you reduced build times by 60%. Otherwise, have to read all the way to the end to find it! It's a great statistic, and having it in the title people will have more reason to read the article. Thanks for the tip, I now mention it in the second paragraph.
Re: D/Objective-C 64bit
Can't you just call super in the beginning of the method and
then call return this at the end. Something like this:
override KeyboardView initWithFrame(NSRect frame)
[initWithFrame:] {
super.initWithFrame(frame);
// my stuff
return this;
}
Ups, sorry, my bad! I was trying this and had an exception, but
not from the constructor! Of course this works just fine! Excuse
me for the noise, I should remove my post (if I only could ;).
Re: Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
On 11/18/2014 1:08 PM, Martin Nowak wrote: On 11/18/2014 08:34 PM, Walter Bright wrote: Should say in the title that you reduced build times by 60%. Otherwise, have to read all the way to the end to find it! It's a great statistic, and having it in the title people will have more reason to read the article. Thanks for the tip, I now mention it in the second paragraph. Much better! You might also want to introduce yourself in the reddit post and offer to answer any questions.
Re: Devisualization.Image
Am Tue, 18 Nov 2014 12:37:54 +0300 schrieb Timur Gafarov gecko0...@gmail.com: 15.11.2014 07:48, Rikki Cattermole пишет: To further Devisualization, I have got the start of an image library. It should be fairly interface complete now. For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted. Goal: to act as the image representation within memory (including colors). Usage: Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?). Devisualization.Font heavily uses it for glyphs and the output of its rasterization. [0] https://github.com/Devisualization/image I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib There're also importers for BMP and TGA. I also just wrote a TGA importer and found RLE and 16-bit in particular badly supported on Linux. E.g. eye-of-gnome (Gnome's picture viewer) doesn't correctly restore the last pixel's color in an RLE image and most software doesn't handle 16-bit at all. Add to that, that the specs are not very specific as to what allowed values are and you get all sorts of funny implementations quirks. -- Marco
Re: Devisualization.Image
Am Wed, 19 Nov 2014 00:35:09 +0100 schrieb Marco Leise marco.le...@gmx.de: I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib There're also importers for BMP and TGA. I also just wrote a TGA importer and found RLE and 16-bit in particular badly supported on Linux. E.g. eye-of-gnome (Gnome's picture viewer) doesn't correctly restore the last pixel's color in an RLE image and most software doesn't handle 16-bit at all. Add to that, that the specs are not very specific as to what allowed values are and you get all sorts of funny implementations quirks. For example: - the original Targa paint software TIPS used to store a palette even for TrueColor images, meaning you should actually calculate the data offset as header + id + palette even for 24- and 32-bit images. - the number of channels for a TrueColor TGA is always 3, plus as many attribute bits as given in the descriptor. If you only support 8-bits per color channel, you should check if bitsPerPixel is = 24. Otherwise, bitsPerPixel == 16 would be interpreted as a two color channel image instead of three channels à 5-bits. And bitsPerPixel == 15 would become a one channel image. :p The 15-/16-bit variants were used quite a bit in the early days of 3D games, like in the menu graphics for Trespasser. They are the same except that 16-bit allows for an additional attribute bit that could be used for a transparency mask. -- Marco
Re: vibe.d 0.7.21 has been released
Thank you for all of the work you've done with Vibe.D.
Re: D/Objective-C 64bit
On 2014-11-18 21:46, Christian Schneider wrote: Yes, of course, and this is really not an issue! And this convenience function can be rewritten in a few lines of code, if really necessary. Good, I just want to make sure you can continue. Than we can figure out the minor issues later. Anyway, I added it to my todo list. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 21:54, Christian Schneider wrote: Uh, oh, that bug looks like a major annoyance in 64bit! I made a few checks, all appkit methods returning a NSRect currently produce a runtime segfault. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work. What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do. If this is works for extern(C) functions then it might be a problem with the extern(Objective-C) functions. Perhaps it's not using the correct objc_msgSend functions under the hood. -- /Jacob Carlborg
Re: vibe.d 0.7.21 has been released
On Tuesday, 18 November 2014 at 17:23:48 UTC, Sönke Ludwig wrote: Just quickly (finally) announcing the release of the next vibe.d version. This one was originally scheduled for start of September, but I got extremely busy with no time left for tidying everything up. The list of changes is long with notable improvements to the web interface generator, the Redis client and the SSL/TLS implementation (including added SNI support). However, the improvements are all over the place. It also compiles on the latest DMD compiler releases (there have been some breaking changes in 2.066). The full list of changes/fixes can be found at http://vibed.org/blog/posts/vibe-release-0.7.21 Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d For some reason, the download link in the top right corner suggests a 0.7.20 beta.
