Am 11.04.2011 07:51, schrieb Jonathan M Davis:
>> Nick Sabalausky:
>>> What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?
>>
>> It's a module theoretically meant for Phobos, and the Phobos coding standard are spaces.
> 
> Yes. Phobos follows the convention of indenting with spaces and that levels of indentation are 4 spaces. So, anything which goes into Phobos needs to follow this convention.
> 
> the only way that tabs work is if you use them consistently, which in my experience almost never happens.

How can people mess that up?

> And pretty much everywhere that I've worked has required that spaces be used and no tabs. When people _have_ used tabs, it's been a mess. Personally, I'm completely against using tabs in source code.
> 
> Regardless, Phobos doesn't use tabs. So, whatever someone may prefer in their own code, code that they intend to get into Phobos shouldn't use tabs.
> 
> - Jonathan M Davis

Of course there's always the possibility to use a code-beautifier to fix this when you're done writing, like http://uncrustify.sourceforge.net/ which even officially supports D.

Cheers,
- Daniel

> Am 11.04.2011 07:51, schrieb Jonathan M Davis:
> >> Nick Sabalausky:
> >>> What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?
> >> 
> >> It's a module theoretically meant for Phobos, and the Phobos coding standard are spaces.
> > 
> > Yes. Phobos follows the convention of indenting with spaces and that levels of indentation are 4 spaces. So, anything which goes into Phobos needs to follow this convention.
> > 
> > the only way that tabs work is if you use them consistently, which in my experience almost never happens.
> 
> How can people mess that up?

They mix tabs and spaces. On some lines, they use spaces and on others they use tabs. If the tab size isn't set exactly the same on your machine as however it was set up on the other person's machine, then the indentation is totally screwed up. And if multiple people have edited the file, it gets that much worse. On top of that, even if the rule is to use tabs for indentation and spaces elsewhere and people are consistent with tabs for indentation, they'll often use tabs elswhere where they should have used spaces. The only way that using tabs works is if you're completely consistent with them. You use tabs where you're supposed to use tabs and spaces where you're supposed to use spaces, and everyone does the same thing. Odds are, that's not going to happen - _especially_ if the tabs don't show up differently in your editor and you can't see when you've screwed up and used tabs when you're not supposed to or not used them where you are supposed to.

Personally, I think that it's _horrible_ to use tabs, and I know plenty of programmers who agree, but as with many stylistic things in programming, there are plenty who would disagree.

- Jonathan M Davis

Jonathan M Davis:

> Yes. Phobos follows the convention of indenting with spaces and that levels of
> indentation are 4 spaces. So, anything which goes into Phobos needs to follow
> this convention.
> ...
> Regardless, Phobos doesn't use tabs. So, whatever someone may prefer in their
> own code, code that they intend to get into Phobos shouldn't use tabs.

If you allow me, I have a stylistic suggestion for your posts, that I usually appreciate: in a single post don't repeat two times most of the things you want to say, once is enough :-)

Bye,
bearophile

Daniel Gibson Wrote:

> > the only way that tabs work is if you use them consistently, which in my experience almost never happens.
> 
> How can people mess that up?

They're CHAOTIC EVIL programmers! They can mess anything.

> Of course there's always the possibility to use a code-beautifier to fix this when you're done writing, like http://uncrustify.sourceforge.net/ which even officially supports D.

If they can't get tabs right, how can they use beautifiers? They just write and commit.

On 2011-04-10 23:39, KennyTM~ wrote:
> On Apr 9, 11 04:26, Adam D. Ruppe wrote:
>> We discussed this first in the GUI library thread, but since it
>> meandered so much, I decided to split off into a new subject. Much
>> of what I say here will be old to anyone who saw the previous thread.
>> There's some new stuff nearer to the bottom though.
>>
>> I, with input from others, have started writing a little module
>> for simple uses of a display. You can write to a bitmap, display it
>> to a window, and handle events all in an easy way. The basics are
>> cross platform, but you can use native function calls too.
>>
>> http://arsdnet.net/dcode/simpledisplay.d
>>
>> It's still very much in progress, but I think it's now at the point
>> where the direction I'm taking it is clear.
>>
> [snip]
>
> Thanks for the great work!
>
> Taking the version on that link, I have ported it to use the native
> Cocoa/Core Graphics in OS X, instead of X11. You can check out the diff
> in https://github.com/kennytm/simpledisplay.d/commit/a790.

When using objc_msgSend and friends you need to cast the function to the right signature, to the same signature as the method you're calling via objc_msgSend, before calling it. See http://www.dsource.org/projects/dstep/browser/dstep/objc/message.d#L74

If you start passing floats to objc_msgSend you'll soon notice that you get some weird behaviors if you don't cast it to the right signature.

You also need to use different versions of objc_msgSend depending on what the return type is and on that platform you're on. If you're returning a struct or an floating point number of some kind you need to use a different version of objc_msgSend. You can have a look at: http://www.dsource.org/projects/dstep/browser/dstep/objc/bridge/Bridge.d#L779 . Also look the function being called: http://www.dsource.org/projects/dstep/browser/dstep/objc/message.d

> Only Snow Leopard (10.6) is supported.
>
> I have only tested that it works on the pendulum example and the HSL
> picker, so things like drawText and drawPixel may not work properly yet.
> The implementation part is quite messy right now due to Objective-C.
>
> Since dmd does not have "pragma(framework)", you'll need to supply the
> "-L-framework -LAppKit" options to dmd to link it.
>
> And a few things:
>
> 1. *Please use spaces instead of tabs.*
> 2. Color's constructor's arguments should better be "red" "green" "blue"
> "alpha" rather than "a" "b" "c" "d".
> 3. The unit of "pulseTimeout" should be documented (milliseconds).
> 4. In the function "fromHsl", there is a (h is real.nan). However, 'is'
> on primitives is reduced to '==' and (nan == nan) is false, so (h is
> real.nan) will always be false. You should use std.math.isNaN().
> 5. Why use the ANSI version (LoadIconA, etc.), not the Unicode version
> (LoadIconW, etc.) of API on Windows? I think the latter is preferred.


-- 
/Jacob Carlborg

Jonathan M Davis Wrote:

> Personally, I think that it's _horrible_ to use tabs

Why would one fear tabs?

> Jonathan M Davis Wrote:
> > Personally, I think that it's _horrible_ to use tabs
> 
> Why would one fear tabs?

They change depending on your editor settings. Indenting gets screwed up if tabs and spaces are mixed. It's just plain annoying to have an indentation of multiple spaces which isn't actually multiple spaces.

The biggest problem though is that it just totally screws with indentation if tabs and spaces are mixed and that invariably happens.

Tabs serve no useful purpose IMHO.

- Jonathan M Davis

Am 11.04.2011 10:01, schrieb Jonathan M Davis:
>> Jonathan M Davis Wrote:
>>> Personally, I think that it's _horrible_ to use tabs
>>
>> Why would one fear tabs?
>
> They change depending on your editor settings. Indenting gets screwed up if
> tabs and spaces are mixed. It's just plain annoying to have an indentation of
> multiple spaces which isn't actually multiple spaces.
>
> The biggest problem though is that it just totally screws with indentation if
> tabs and spaces are mixed and that invariably happens.
>
> Tabs serve no useful purpose IMHO.
>
> - Jonathan M Davis

So tabs are horrible because some people use spaces instead of tabs.

On Apr 11, 11 15:43, Jacob Carlborg wrote:
> When using objc_msgSend and friends you need to cast the function to the
> right signature, to the same signature as the method you're calling via
> objc_msgSend, before calling it. See
> http://www.dsource.org/projects/dstep/browser/dstep/objc/message.d#L74
>
> If you start passing floats to objc_msgSend you'll soon notice that you
> get some weird behaviors if you don't cast it to the right signature.
>
> You also need to use different versions of objc_msgSend depending on
> what the return type is and on that platform you're on. If you're
> returning a struct or an floating point number of some kind you need to
> use a different version of objc_msgSend. You can have a look at:
> http://www.dsource.org/projects/dstep/browser/dstep/objc/bridge/Bridge.d#L779
> . Also look the function being called:
> http://www.dsource.org/projects/dstep/browser/dstep/objc/message.d

Yes I know. Since all objc_msgSend used only operate on integers and pointers and structs and doubles, and they only return pointers or void, I didn't bother to cast them.

Anyway, those calls are now updated to handled it properly, please check https://github.com/kennytm/simpledisplay.d/commit/18b6.

On Apr 11, 11 09:54, Adam D. Ruppe wrote:
> KennyTM~ wrote:
>> Taking the version on that link, I have ported it to use the native
>> Cocoa/Core Graphics in OS X, instead of X11
>
> Thanks!
>
>> 1. *Please use spaces instead of tabs.*
>
> Spaces are the spawn of Satan! I hate them, but when it comes time
> to submit to phobos, I'll run a find/replace of them so it's
> consistent with the prevailing style there. Until then though,
> I'll write it in my native style... so these early drafts will
> remain tabs, but spaces will be used in the final copy.
>

OK.

>> 2. Color's constructor's arguments should better be "red" "green"
>> "blue" "alpha" rather than "a" "b" "c" "d".
>> 3. The unit of "pulseTimeout" should be documented (milliseconds).
>
> Indeed.
>
>>   4. In the function "fromHsl", there is a (h is real.nan).
>> However, 'is' on primitives is reduced to '==' and (nan == nan)
>> is false, so (his real.nan) will always be false. You should use
>> std.math.isNaN().
>
> Ah, so that's what it is. I was sure it was some form of "is nan"
> but it's not something I use often so I assumed it was like null.
>
> Changed.
>
>> 5. Why use the ANSI version (LoadIconA, etc.), not the Unicode
>> version (LoadIconW, etc.) of API on Windows? I think the latter
>> is preferred.
>
> Yeah. core.sys.windows.windows is woefully incomplete though, and
> only defined the A versions. Since I was already sick of
> copy/pasting headers after Xlib, I took the path of least
> resistance and aliased to what it had. (Annoyingly though, I still
> had to copy/paste a bunch of GDI prototypes! Not a big deal -
> structs and enums are way more painful than functions, but
> still, aaargh.)
>
> I'll fix it up next time I have some time to kill. They're all
> aliased in one place so it will be easy to find.

I see.