www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - simple display (from: GUI library for D)

reply Adam D. Ruppe <destructionator gmail.com> writes:
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.

First, the simplest usage:

====
import simpledisplay;

void main() {
	auto image = new Image(255, 255);

	foreach(a; 0..255)
	foreach(b; 0..255)
		image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16));

	image.display();
}
===

Compile: dmd test.d simpledisplay.d


When run, it will pop up a window with a gradient thing with little
bars through it. Press any key and the window closes, exiting the
program.

On Windows, it uses GDI functions. On other systems, it tries to
use X Windows. Linux is the only one I've personally tested, but it
should work on OSX and FreeBSD too (without changing the code).


If you are making some data, then just want to display it, this
works. But, what if you want some interactivity?

Here's a simple HSL color picker:
http://arsdnet.net/dcode/simpledisplay_test2.d

Use these keys to pick your color: q/a change hue. s/w changes S.
e/d changes L. Press ESC to exit. Your color in rgb is printed to
stdout.


Here's the relevant parts of the code:

void main() {
	auto image = new Image(255, 255);
	auto win = new SimpleWindow(image);
	win.eventLoop(0,
		(dchar c) {
			writeln("Got a char event: ", c);

			if(c == 'q')
				h += 15;
                        // ...snip...

			foreach(a; 0..255)
			foreach(b; 0..255)
				image.putPixel(a, b, fromHsl(h, s, l));

			win.image = image;
		},
		(int key) {
			writeln("Got a keydown event: ", key);
			if(key == KEY_ESCAPE) {
				auto color = fromHsl(h, s, l);
				writefln("%02x%02x%02x", color.r, color.g, color.b);
				win.close();
			}
		});
}

First, we create an image. Then, a window based on that image. At
line two, your window will show up on the screen, just like
image.display() did above. But, here, instead of blocking, it
moves on to a user specified event loop.

SimpleWindow.eventLoop was inspired by std.concurrency.receive.
The first parameter is a pulse timer amount (not yet implemented).
If you set one, you'll get one of your delegates called at the
requested interval. The idea there is to make animations or games
easy to get started.

After that comes a list of delegates. They are matched to different
events by their signature. (dchar c) {} means a key was pressed,
and it passes you the character corresponding to that key.

(int c) {} is almost certain to change, but right now it matches
to key press events, and passes the platform-specific keycode. I'm
planning to put symbolic constants in with the same name across
platform to make that easier to use, but the values themselves are
likely to be platform-specific.



When we get a key event here, the image is redrawn with a new
color. win.image = image tells it you want the image redrawn with
the new image. It's a blunt instrument, but a simple and fairly
effective one.



The advantage of this approach is you can just have fun with
those pixels and handle keys, all right there inside main() - no
need to do subclasses just for a simple program. At the same time,
you can move those event handlers around easily enough, or even
change them at runtime, simply by using named delegates and assignment.

I plan to add more event possibilities so you can actually
make this do some good work for you. Ultimately, they'll also
be an (XEvent) {} and (HWND, LPARAM, WPARAM) event for when what
I provide isn't good enough, so you can always build more off it.
It's meant to be simple, but not horribly limiting.


======


Since last time I posted, I've reorganized the code inside
simpledisplay.d quite a bit. Instead of version Windows vs version
linux, it's now Windows and X11, reflecting the fact that X is
available on many operating systems. (Including Windows, actually,
but meh).

The Color struct is now rgba, but it doesn't use a. I like the
suggestion to template on different color spaces, but haven't gotten
around to that yet.

Next, Image and SimpleWindow are done pretty differently than before.
Now, the platform specific parts are put into a separate mixin
template: NativeImageImplementation!() and NativeSimpleWindowImpl...().
The public methods forward to those.

The reason for this is three fold:

a) It makes the public code a lot easier on the eyes. It was getting
into spaghetti version territory for a bit there... now it's nice
and clean.

b) The implementations can now be moved to their own modules. I haven't
simply because a single file is easier to distribute and play with,
but the final thing probably should split it up, and now it can.

c) It should be more obvious when something isn't implemented for an
operating system, while keeping the public ddoc all in one place.
versions


Before, Image was simply a byte array in a single format, meaning
to get to the native OS format for blitting, it had to be copied. Now,
the actual format is hidden inside impl. I'll add operator overloads
or structs (I really like Nick's idea of a fast vs cropped access
point) to hide it.

In the mean time though, the putPixel function forwards to the OS
implementation, which writes right to the image format expected there.

It's still not ultimately efficient, but it's better than copying
it twice every time we make a change.

I still like the idea of a set binary format being available so
we can save as a file, but that will be made a conversion function
instead of the default use. Actually, probably some kind of forward
range. Then the file save functions can accept those ranges and
translate them into .bmp or .png files as it streams in. (probably
image.byScanLine would be pretty useful for this!)

My HSL -> RGB converter is also in simpledisplay.d. It's actually
less than 500 lines, excluding the bindings pasted in at the bottom.
Not too bad.
Apr 08 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 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.

I'd like something like this in Phobos, or if this is not possible, a cabal-install-like command away. I sometimes use Python PyGame or Processing.
 import simpledisplay;
 
 void main() {
 	auto image = new Image(255, 255);
 
 	foreach(a; 0..255)
 	foreach(b; 0..255)
 		image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16));
 
 	image.display();
 }

Instead of: image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16)); I suggest something simpler like: image[a, b] = std.typecons.tuple(a, b, ((a + b) % 16) * 16); Instead of: image.display(); I suggest something like this, to swap the two image buffers: image.flip(); Plus maybe some image.event(); reader with callbacks... Bye, bearophile
Apr 08 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 I'd like something like this in Phobos

Me too. It's still pretty far from good enough right now, but that's where I want ultimately want it. My only concern is I don't want Phobos to depend on Xlib unless the module is actually imported. I don't think it will be a problem, but if it means a hello world won't run on a text only machine, that won't be ok.
 I suggest something simpler like:

Yeah, moving to opIndex is something I plan to do. But, I don't really like using a tuple for this - a regular struct makes it a little clearer what's going on, and can be made more efficient. (In the other thread, Nick suggested making it a simple uint internally, using property functions to emulate other outside faces. I like that.) A struct might also have accessors with different color types too.
 I suggest something like this, to swap the two image buffers

That's not really what you're doing there - display actually pops up a new window and waits for the user to close it.
 Plus maybe some image.event(); reader with callbacks...

What would it do?
Apr 08 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 My only concern is I don't want Phobos to depend on Xlib unless
 the module is actually imported. I don't think it will be a problem,
 but if it means a hello world won't run on a text only machine, that
 won't be ok.

I agree.
 But, I don't
 really like using a tuple for this - a regular struct makes it
 a little clearer what's going on, and can be made more efficient.

OK. (But for this module I think usage simplicity is more important than raw speed. Users that need more performance or more features are going to use something else and better. The idea here is to keep simple the things that are simple).
 (In the other thread, Nick suggested making it a simple uint
 internally, using property functions to emulate other outside
 faces. I like that.)

OK.
 I suggest something like this, to swap the two image buffers

That's not really what you're doing there - display actually pops up a new window and waits for the user to close it.

Indeed, I was suggesting to open the window at the top of the program, and at the bottom of the program to swap the two buffers and show the drawn one.
 Plus maybe some image.event(); reader with callbacks...

What would it do?

Read the events, like window closing, key pressed, mouse movements, etc. Take a look at Processing API, for ideas. There are many situations where a simple built-in graphics is useful. Beside the example of Processing (that has anti-aliasing), there are many programs/small games that need just some 2D graphics: http://rosettacode.org/wiki/Animate_a_pendulum Bye, bearophile
Apr 08 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 OK. (But for this module I think usage simplicity is more
 important than raw speed.

The struct is at least equal in simplicity: image[x, y] = Color(r, g, b); vs image[x, y] = tuple(r, g, b);
 Indeed, I was suggesting to open the window at the top of the
 program, and at the bottom of the program to swap the two buffers
 and show the drawn one.

Sure, that's what happens in my second example. Right now it uses "window.image = newImage;" to flip it but I think I want to change that.
 Read the events, like window closing, key pressed, mouse
 movements, etc. Take a look at Processing API, for ideas.

Yes, my window object does this too. See the example here: http://arsdnet.net/dcode/simpledisplay_test2.d win.eventLoop() does it.
 http://rosettacode.org/wiki/Animate_a_pendulum

Heh, I think D will be winning that by Monday!
Apr 08 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 The struct is at least equal in simplicity:
 
 image[x, y] = Color(r, g, b);
 
 vs
 
 image[x, y] = tuple(r, g, b);

A tuple is simpler, there is no new name to remember and use, new type to define, and 3-tuples come out of other generic computations, like zip: foreach (col; zip(reds, greens, blues)) image[x, y] = col; Generally D programmers probably need to learn to use tuples a bit more seriously and often :-)
 Yes, my window object does this too. See the example here:
 http://arsdnet.net/dcode/simpledisplay_test2.d
 
 win.eventLoop() does it.

I see. But those lambdas are a bit too much large put there. I suggest true named function moved elsewhere. Some other notes to your code: - generic imports like stdio are probably better before the most specific ones (this is done in well written Python code); - Inside the (dchar c) {} a switch seems better. - In Wrapped struct why are you using a checkLimits() instead of an invariant()?
 http://rosettacode.org/wiki/Animate_a_pendulum

Heh, I think D will be winning that by Monday!

Good, but Rosettacode site isn't a competition :-) Bye, bearophile
Apr 08 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 http://rosettacode.org/wiki/Animate_a_pendulum

Here's the D version using the direct to screen functions. I ported the C# version, since the APIs were most alike. (Not really surprising... C# and I both thinly wrapped GDI.) === import std.math; import simpledisplay; void main() { auto win = new SimpleWindow(512, 512); real angle = PI / 2; real angleVelocity = 0; immutable real dt = 0.1; int length = 150; win.eventLoop(50, () { auto anchorX = win.width / 2 - 12; auto anchorY = win.height / 4; auto ballX = anchorX + cast(int) (sin(angle) * length); auto ballY = anchorY + cast(int) (cos(angle) * length); auto angleAcceleration = -9.81 / length * sin(angle); angleVelocity += angleAcceleration * dt; angle += angleVelocity * dt; auto painter = win.draw(); painter.fillColor = Color(255, 255, 255); painter.drawRectangle(0, 0, win.width, win.height); painter.outlineColor = Color(0, 0, 0); painter.drawLine(anchorX, anchorY, ballX, ballY); painter.fillColor = Color(0, 0, 0); painter.drawEllipse(anchorX - 3, anchorY - 4, anchorX + 3, anchorY + 4); painter.fillColor = fromHsl(30, 0.8, 0.4); painter.drawEllipse(ballX - 7, ballY - 7, ballX + 7, ballY + 7); } ); } === Exit the program by closing the window. Some comments. First, you'll see that the pulse timer is implemented, allowing the animation to easily happen. Then, there's a dozen lines to actually do the drawing, starting with auto painter = win.draw(); win.draw (name might change) returns a ScreenPainter struct, which gives access to the drawing directly in the window, via a handful of native api calls. This struct is necessary to handle some state and cleanup that the native APIs require. (It's destructor does it all for you though, so no need to think about it here.) You can draw images, text, pixels (slowly), lines, rectangles, arcs, and polygons with solid colors for filling and outline. It's the lowest common denominator between Windows GDI and Xlib. I agree with what Michel said earlier about it being a lot of fairly pointless effort to go further than this. Instead, we'll offer a rich set of cross-platform functions to draw to an image, and simply copy those images to the windows when we want to get fancy. (That's easy to do here: painter.drawImage(x, y, image); ) Moving on, I first clear the screen by drawing a large, white rectangle over the window. fillColor and outlineColor are settable properties that are implicitly used in the drawing functions. (This reflects how pens and brushes are tied to the HDC on Windows and foreground and background colors are tied to the GC on X - you don't pass colors to the individual functions on either native API either.) Following Windows' lead, all the functions use the two separate colors, one for the outline of the shape and one for filling it in, hence their names. Note that only outline is used for drawline lines and pixels. If you want to draw a shape without filling it in, first set the fill color to transparent: painter.fillColor = Color.transparent; (Color.transparent is a static method to conveniently return a color with alpha = 0.) Also in there, you can see me using the fromHsl helper function to return a Color specifying HSL values instead of RGB. Finally, I said this draws directly to the screen, but it actually doesn't... it double buffers underneath. No need to call a buffer.flip function though. ScreenPainter's destructor does it for you. You don't have to think about it. The buffer is preserved across calls and used to automatically handle WM_PAINT/Expose messages. ====== There's still a handful of little things and a lot of error checking needed, but I'm pretty happy with this as the screen drawing base. It covers all the easy stuff. The hard stuff will be in platform independent images. Anyway, here's the updated simpledisplay.d: http://arsdnet.net/dcode/simpledisplay.d
Apr 09 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 Here's the D version using the direct to screen functions.

On Windows Vista the window often doesn't close when I hit the close window click at the top right. Probably quite more people will have to comment and think about this module and its API before adopting it. The length=150 too is better to be set as immutable. Most of the auto variables (but "painter") are better set to immutable. The delegate inside eventLoop doesn't need the (). Color(255, 255, 255) ==> Color.white Color(0, 0, 0) ==> Color.black painter.drawRectangle(0, 0, win.width, win.height) painter.clearAll(), or painter.clearAll(Color.white) or something similar. auto win = new SimpleWindow(512, 512); ==> auto win = new SimpleWindow(512, 512, "Pendulum"); win.eventLoop(10, {...}) does this semantics work with more than one window too? auto painter = win.draw(); painter.fillColor = Color(255, 255, 255); ==> sometimes a bit better: auto painter = win.draw(); with (painter) { fillColor = ... ... drawRectangle => rectangle or even "box" drawLine ==> line drawEllipse ==> ellipse circle fillColor ==> filling? outline => pen?
 This struct is necessary to handle some state
 and cleanup that the native APIs require.

This is not so nice...
 I agree with what Michel said earlier about it being a lot of
 fairly pointless effort to go further than this.

Reading keyboard chars, and mouse clicks & movements is very useful. Another useful thing is to plot a matrix of rgb or int or ubyte in grey shades, to speed up some basic usage. In PyGame/Numpy there is surfarray for this. Bye, bearophile
Apr 09 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 The length=150 too is better to be set as immutable.

Yeah, I made that change after copy/pasting the code into my newsgroup post. win, painter, angle, and angular velocity were the only things left mutable in the end.
 The delegate inside eventLoop doesn't need the ().

I put it there for consistency with other events. While there are no other handlers in this example, there can be, and all the other ones take arguments.
 Color(255, 255, 255) ==> Color.white
 painter.clearAll(Color.white)
 auto win = new SimpleWindow(512, 512, "Pendulum");

Yeah, those are reasonable.
 win.eventLoop(10, {...})  does this semantics work with more than
 one window too?

I believe so, yes, but I haven't tried it and wouldn't mind if it didn't. If you need to use multiple windows at the same time, it'd probably be better to use DFL, DWT, GTK, Qt, etc. etc.
 drawRectangle => rectangle or even "box"

Heh, I used to call it box in my DOS programs. But, the functions it forwards to are called Rectangle() and XDrawRectangle(), so I want to be consistent with them so it's not a surprise to someone already familiar with with the other APIs. The reason I went with drawShape instead of just Shape is that functions are verbs, so generally, I like their names to be verbs too. There's exceptions, of course, but I don't these fit.
 outline => pen?

Pens do more than just color. I guess the real question is how complex should it be able to get? In the underlying APIs, you can make a pen with a color, a width, and a style (solid, dashed, etc). Since they both can do it, I think I will add it. (Some more advanced APIs can even do things like gradient pens. I hope the image manipulation functions we write will eventually be able to do this too, but since plain old X can't, it won't happen for the display painter.) Perhaps: painter.pen = Pen(Color(r, g, b), 1, Pen.Style.solid); (Or maybe new Pen()... have to think about that.) And offer an overload for the simple case where you only care about color. (or keep the current fillColor property.) Then, of course, something similar for Brush, which is used to fill the background. But, here, the idea was to keep it simple, so I went with just color. I guess that might be too simple.
 This is not so nice...

I'm sympathetic, but I don't agree losing the struct would be good. Even if the struct proves to be unnecessary (which it might be - I think you can hold on to a window HDC as long as you like, but it's not something I see often so I think it's discouraged), I'd still keep it. Having an automatic constructor and destructor available gives some flexibility on the implementation side without inconveniencing the user beyond a single function. For example, the implicit double buffering done here. You don't have to think about flipping it. It just works. Better yet, the implementation can disable it at will. BitBlt is slow over Remote Desktop on Windows, making double buffering laggy. But, you, the user, don't really need to know that, since it wasn't your problem in the first place. The ScreenPainter can make it's own decision about it.
 Reading keyboard chars, and mouse clicks & movements is very
 useful.

For that, you can pass other handlers to eventLoop. I still intend to define a few more you can use.
 Another useful thing is to plot a matrix of rgb or int or ubyte
 in grey shades, to speed up some basic usage. In PyGame/Numpy
 there is surfarray for this.

Sounds like what you'd use the Image class for, so I think we're good on that too. ==== A note: since I posted last, I changed my mind on something, and bearophile, I rather doubt you'll like it... Before, it was drawRectangle(int x1, int y2, int width, int height); Now, it is drawRectangle(Point upperLeft, Size size); So, at the usage, you now need to put in some more parenthesis and say what you mean: painter.drawRectangle(Point(0, 0), Size(win.width, win.height)); Why did I do this? Well, consider the following: drawRectangle(int x1, int y1, int x2, int y2); (This is, in fact, the signature in Windows GDI, whereas Xlib user width/height.) The types there are no different than the above, but meaning has changed. I'd be ok with saying "RTFM" to avoid having to use the structs. But, RTFM doesn't let you overload it, whereas the types do. Now, it can offer both drawRectangle(Point upperLeft, Size size); *and* drawRectangle(Point upperLeft, Point lowerRight); I'm sure you were thinking about named arguments for a moment there about width/height vs x2/y2. I did too. But, named arguments don't really exist in D (you can do them via library magic but not without) so it's moot, and I don't believe named arguments would offer the overloading possibilities, which I like. It can save some math while being quite natural. The Point struct also makes drawPolygon look a lot better, so it's of general use.
Apr 09 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-08 20:11:10 -0400, Adam D. Ruppe <destructionator gmail.com> said:

 My only concern is I don't want Phobos to depend on Xlib unless
 the module is actually imported. I don't think it will be a problem,
 but if it means a hello world won't run on a text only machine, that
 won't be ok.

I'm concerned by this too. I think you need two modules. One for images images with absolutely no dependencies, and another for everything dealing with windows. Only if you import the window module you need to link with the relevant libraries. That means you'll need to change the image.display() shortcut to something else not a member of image. I don't think it's particularly good that images has such a member anyway, it'd be better as a standalone function in my opinion. (Actually, perhaps we need a third to deal with drawing which might also be dependent on system libraries, especially if needs to draw text.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 08 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-09 02:11, Adam D. Ruppe wrote:
 bearophile wrote:
 I'd like something like this in Phobos

Me too. It's still pretty far from good enough right now, but that's where I want ultimately want it. My only concern is I don't want Phobos to depend on Xlib unless the module is actually imported. I don't think it will be a problem, but if it means a hello world won't run on a text only machine, that won't be ok.

You can always dynamically link to the functions.
 I suggest something simpler like:

Yeah, moving to opIndex is something I plan to do. But, I don't really like using a tuple for this - a regular struct makes it a little clearer what's going on, and can be made more efficient. (In the other thread, Nick suggested making it a simple uint internally, using property functions to emulate other outside faces. I like that.) A struct might also have accessors with different color types too.
 I suggest something like this, to swap the two image buffers

That's not really what you're doing there - display actually pops up a new window and waits for the user to close it.
 Plus maybe some image.event(); reader with callbacks...

What would it do?

-- /Jacob Carlborg
Apr 10 2011
prev sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
--0016e6d976514c07e604a086055b
Content-Type: text/plain; charset=ISO-8859-1

One thing to consider, since I was impacted by this when writing a WPF app a
while back, is the difference between a 2-Vector and a Point.  In
particular, Vectors typically have some very useful methods on them, like
addition, rotation, transformations, etc. which frequently are not
associated with the Point type.  I don't know if you have or plan to support
this data type, but at least having simple transforms to/from Vector would
be nice.

- Cliff

On Sat, Apr 9, 2011 at 5:58 PM, Adam D. Ruppe <destructionator gmail.com>wrote:

 bearophile wrote:
 The length=150 too is better to be set as immutable.

Yeah, I made that change after copy/pasting the code into my newsgroup post. win, painter, angle, and angular velocity were the only things left mutable in the end.
 The delegate inside eventLoop doesn't need the ().

I put it there for consistency with other events. While there are no other handlers in this example, there can be, and all the other ones take arguments.
 Color(255, 255, 255) ==> Color.white
 painter.clearAll(Color.white)
 auto win = new SimpleWindow(512, 512, "Pendulum");

Yeah, those are reasonable.
 win.eventLoop(10, {...})  does this semantics work with more than
 one window too?

I believe so, yes, but I haven't tried it and wouldn't mind if it didn't. If you need to use multiple windows at the same time, it'd probably be better to use DFL, DWT, GTK, Qt, etc. etc.
 drawRectangle => rectangle or even "box"

Heh, I used to call it box in my DOS programs. But, the functions it forwards to are called Rectangle() and XDrawRectangle(), so I want to be consistent with them so it's not a surprise to someone already familiar with with the other APIs. The reason I went with drawShape instead of just Shape is that functions are verbs, so generally, I like their names to be verbs too. There's exceptions, of course, but I don't these fit.
 outline => pen?

Pens do more than just color. I guess the real question is how complex should it be able to get? In the underlying APIs, you can make a pen with a color, a width, and a style (solid, dashed, etc). Since they both can do it, I think I will add it. (Some more advanced APIs can even do things like gradient pens. I hope the image manipulation functions we write will eventually be able to do this too, but since plain old X can't, it won't happen for the display painter.) Perhaps: painter.pen = Pen(Color(r, g, b), 1, Pen.Style.solid); (Or maybe new Pen()... have to think about that.) And offer an overload for the simple case where you only care about color. (or keep the current fillColor property.) Then, of course, something similar for Brush, which is used to fill the background. But, here, the idea was to keep it simple, so I went with just color. I guess that might be too simple.
 This is not so nice...

I'm sympathetic, but I don't agree losing the struct would be good. Even if the struct proves to be unnecessary (which it might be - I think you can hold on to a window HDC as long as you like, but it's not something I see often so I think it's discouraged), I'd still keep it. Having an automatic constructor and destructor available gives some flexibility on the implementation side without inconveniencing the user beyond a single function. For example, the implicit double buffering done here. You don't have to think about flipping it. It just works. Better yet, the implementation can disable it at will. BitBlt is slow over Remote Desktop on Windows, making double buffering laggy. But, you, the user, don't really need to know that, since it wasn't your problem in the first place. The ScreenPainter can make it's own decision about it.
 Reading keyboard chars, and mouse clicks & movements is very
 useful.

For that, you can pass other handlers to eventLoop. I still intend to define a few more you can use.
 Another useful thing is to plot a matrix of rgb or int or ubyte
 in grey shades, to speed up some basic usage. In PyGame/Numpy
 there is surfarray for this.

Sounds like what you'd use the Image class for, so I think we're good on that too. ==== A note: since I posted last, I changed my mind on something, and bearophile, I rather doubt you'll like it... Before, it was drawRectangle(int x1, int y2, int width, int height); Now, it is drawRectangle(Point upperLeft, Size size); So, at the usage, you now need to put in some more parenthesis and say what you mean: painter.drawRectangle(Point(0, 0), Size(win.width, win.height)); Why did I do this? Well, consider the following: drawRectangle(int x1, int y1, int x2, int y2); (This is, in fact, the signature in Windows GDI, whereas Xlib user width/height.) The types there are no different than the above, but meaning has changed. I'd be ok with saying "RTFM" to avoid having to use the structs. But, RTFM doesn't let you overload it, whereas the types do. Now, it can offer both drawRectangle(Point upperLeft, Size size); *and* drawRectangle(Point upperLeft, Point lowerRight); I'm sure you were thinking about named arguments for a moment there about width/height vs x2/y2. I did too. But, named arguments don't really exist in D (you can do them via library magic but not without) so it's moot, and I don't believe named arguments would offer the overloading possibilities, which I like. It can save some math while being quite natural. The Point struct also makes drawPolygon look a lot better, so it's of general use.

--0016e6d976514c07e604a086055b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One thing to consider, since I was impacted by this when writing a WPF app = a while back, is the difference between a 2-Vector and a Point. =A0In parti= cular, Vectors typically have some very useful methods on them, like additi= on, rotation, transformations, etc. which frequently are not associated wit= h the Point type. =A0I don&#39;t know if you have or plan to support this d= ata type, but at least having simple transforms to/from Vector would be nic= e.<div> <br></div><div>- Cliff<br><br><div class=3D"gmail_quote">On Sat, Apr 9, 201= 1 at 5:58 PM, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destruc= tionator gmail.com">destructionator gmail.com</a>&gt;</span> wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex;"> <div class=3D"im">bearophile wrote:<br> &gt; The length=3D150 too is better to be set as immutable.<br> <br> </div>Yeah, I made that change after copy/pasting the code into my<br> newsgroup post. win, painter, angle, and angular velocity were<br> the only things left mutable in the end.<br> <div class=3D"im"><br> &gt; The delegate inside eventLoop doesn&#39;t need the ().<br> <br> </div>I put it there for consistency with other events. While there<br> are no other handlers in this example, there can be, and all the<br> other ones take arguments.<br> <div class=3D"im"><br> &gt; Color(255, 255, 255) =3D=3D&gt; Color.white<br> </div>&gt; painter.clearAll(Color.white)<br> <div class=3D"im">&gt; auto win =3D new SimpleWindow(512, 512, &quot;Pendul= um&quot;);<br> <br> </div>Yeah, those are reasonable.<br> <div class=3D"im"><br> &gt; win.eventLoop(10, {...}) =A0does this semantics work with more than<br=

<br> </div>I believe so, yes, but I haven&#39;t tried it and wouldn&#39;t mind i= f<br> it didn&#39;t. If you need to use multiple windows at the same time,<br> it&#39;d probably be better to use DFL, DWT, GTK, Qt, etc. etc.<br> <div class=3D"im"><br> &gt; drawRectangle =3D&gt; rectangle or even &quot;box&quot;<br> <br> </div>Heh, I used to call it box in my DOS programs. But, the functions<br> it forwards to are called Rectangle() and XDrawRectangle(), so<br> I want to be consistent with them so it&#39;s not a surprise to<br> someone already familiar with with the other APIs.<br> <br> The reason I went with drawShape instead of just Shape is that<br> functions are verbs, so generally, I like their names to be<br> verbs too. There&#39;s exceptions, of course, but I don&#39;t these<br> fit.<br> <br> &gt; outline =3D&gt; pen?<br> <br> Pens do more than just color. I guess the real question is how<br> complex should it be able to get?<br> <br> In the underlying APIs, you can make a pen with a color, a<br> width, and a style (solid, dashed, etc). Since they both can<br> do it, I think I will add it.<br> <br> (Some more advanced APIs can even do things like gradient pens. I<br> hope the image manipulation functions we write will eventually<br> be able to do this too, but since plain old X can&#39;t, it won&#39;t<br> happen for the display painter.)<br> <br> Perhaps:<br> <br> painter.pen =3D Pen(Color(r, g, b), 1, Pen.Style.solid);<br> <br> (Or maybe new Pen()... have to think about that.)<br> <br> And offer an overload for the simple case where you only care<br> about color. (or keep the current fillColor property.)<br> <br> Then, of course, something similar for Brush, which is used<br> to fill the background.<br> <br> But, here, the idea was to keep it simple, so I went with just<br> color. I guess that might be too simple.<br> <div class=3D"im"><br> &gt; This is not so nice...<br> <br> </div>I&#39;m sympathetic, but I don&#39;t agree losing the struct would be= good.<br> <br> Even if the struct proves to be unnecessary (which it might be - I<br> think you can hold on to a window HDC as long as you like, but it&#39;s<br> not something I see often so I think it&#39;s discouraged), I&#39;d still<b= r> keep it.<br> <br> Having an automatic constructor and destructor available gives<br> some flexibility on the implementation side without inconveniencing<br> the user beyond a single function.<br> <br> For example, the implicit double buffering done here. You don&#39;t<br> have to think about flipping it. It just works. Better yet, the<br> implementation can disable it at will. BitBlt is slow over Remote<br> Desktop on Windows, making double buffering laggy. But, you, the<br> user, don&#39;t really need to know that, since it wasn&#39;t your problem<= br> in the first place. The ScreenPainter can make it&#39;s own decision<br> about it.<br> <div class=3D"im"><br> &gt; Reading keyboard chars, and mouse clicks &amp; movements is very<br> &gt; useful.<br> <br> </div>For that, you can pass other handlers to eventLoop. I still intend<br=

<div class=3D"im"><br> &gt; Another useful thing is to plot a matrix of rgb or int or ubyte<br> &gt; in grey shades, to speed up some basic usage. In PyGame/Numpy<br> &gt; there is surfarray for this.<br> <br> </div>Sounds like what you&#39;d use the Image class for, so I think we&#39= ;re<br> good on that too.<br> <br> <br> =3D=3D=3D=3D<br> <br> A note: since I posted last, I changed my mind on something, and<br> bearophile, I rather doubt you&#39;ll like it...<br> <br> Before, it was drawRectangle(int x1, int y2, int width, int height);<br> <br> Now, it is drawRectangle(Point upperLeft, Size size);<br> <br> So, at the usage, you now need to put in some more parenthesis<br> and say what you mean:<br> <br> painter.drawRectangle(Point(0, 0), Size(win.width, win.height));<br> <br> <br> Why did I do this? Well, consider the following:<br> <br> drawRectangle(int x1, int y1, int x2, int y2);<br> <br> (This is, in fact, the signature in Windows GDI, whereas Xlib<br> =A0user width/height.)<br> <br> <br> The types there are no different than the above, but meaning has<br> changed. I&#39;d be ok with saying &quot;RTFM&quot; to avoid having to use<= br> the structs.<br> <br> But, RTFM doesn&#39;t let you overload it, whereas the types do. Now,<br> it can offer both<br> <br> drawRectangle(Point upperLeft, Size size);<br> <br> *and*<br> <br> drawRectangle(Point upperLeft, Point lowerRight);<br> <br> I&#39;m sure you were thinking about named arguments for a moment<br> there about width/height vs x2/y2. I did too. But, named arguments<br> don&#39;t really exist in D (you can do them via library magic but not<br> without) so it&#39;s moot, and I don&#39;t believe named arguments would<br=

some math while being quite natural.<br> <br> The Point struct also makes drawPolygon look a lot better, so<br> it&#39;s of general use.<br> </blockquote></div><br></div> --0016e6d976514c07e604a086055b--
Apr 09 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
simpledisplay.d - line 267:
int lol, wtf;

lol, wtf? :p

Btw, an exception will be thrown on unhandled key events, e.g. just hit CTRL:
object.Exception .\simpledisplay.d(299): GetMessage failed

Not a good thing if you use shortcut keys to move windows around.
Apr 08 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrej Mitrovic:
 lol, wtf? :p

My brilliant variable names! It reflects my feelings toward parts of the bmp format I forgot about when first writing it. I didn't account for the padding at first, then said "wtf" and added it... then "lol"'ed at myself for not doing it right the first time. You should have saw the original C version though: if(hbmp == NULL) goto fuck; :)
 Btw, an exception will be thrown on unhandled key events, e.g.
 just hit CTRL:

That's weird, I've never seen GetMessage fail... ever. I'll have to try it in real Windows later (I'm on linux / Wine right now).
Apr 08 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Adam D. Ruppe (destructionator gmail.com)'s article
 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.

Can it render text? If so, I'll probably port Plot2kill to it if it becomes part of Phobos at some point. It would be kind of cool to have minimal Plot2kill functionality with zero third-party dependencies. If it's so basic that it can't even do text rendering, then I have my doubts about whether there are very many use cases for something so simple.
Apr 08 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
dsimcha wrote:
 Can it render text?

Not yet, but it's on the list. Anything that's reasonably easy in both Windows API and Xlib should be supported here. At the least, text, lines, rectangles - all the basics.
Apr 08 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-08 20:18:03 -0400, Adam D. Ruppe <destructionator gmail.com> said:

 dsimcha wrote:
 Can it render text?

Not yet, but it's on the list. Anything that's reasonably easy in both Windows API and Xlib should be supported here. At the least, text, lines, rectangles - all the basics.

One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I wonder if it might not be better to implement our own drawing algorithms for geometric shapes, which in addition won't be dependent on any system library. I guess text drawing would need to be left system-dependent however... -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 08 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Michel Fortin wrote:
 One issue is that different operating system will draw things with
 slightly different algorithms, which will result in slightly different
images, which might introduce glitches from platform to platform.

I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls.
Apr 08 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-08 21:45:20 -0400, Adam D. Ruppe <destructionator gmail.com> said:

 Michel Fortin wrote:
 One issue is that different operating system will draw things with
 slightly different algorithms, which will result in slightly different
 images, which might introduce glitches from platform to platform.

I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls.

Personally, I wouldn't even bother with direct screen drawing in that case. Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead. As for text, which library does the X server uses to draw text? Freetype? You could link directly to it when you need to draw text... and on other OS use similar OS services. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 08 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Michel Fortin wrote:
 Direct screen drawing will need a different implementation for
 each OS, which means a lot of duplicated effort that could be put in
 implementing dependency-less cross-platform drawing primitives
 instead.

I'd agree if not for one thing: it isn't really much duplicated effort - most the functions are just a few lines long; it wraps C. There's a good chance I'll be able to finish them in the next hour for Win32 and X11.
 As for text, which library does the X server uses to draw text?

I think it's freetype for ttf and for bitmap fonts it's built into it. Linking directly to it is a good idea.
Apr 08 2011
prev sibling parent reply Matthias Pleh <jens konrad.net> writes:
Am 09.04.2011 03:55, schrieb Michel Fortin:
 On 2011-04-08 21:45:20 -0400, Adam D. Ruppe <destructionator gmail.com>
 said:

 Michel Fortin wrote:
 One issue is that different operating system will draw things with
 slightly different algorithms, which will result in slightly different
 images, which might introduce glitches from platform to platform.

I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls.

Personally, I wouldn't even bother with direct screen drawing in that case. Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead. As for text, which library does the X server uses to draw text? Freetype? You could link directly to it when you need to draw text... and on other OS use similar OS services.

For the drawingt part. I'm currently working on a rednerer with scanline algorithm. This will be completly OS-independent. It's in a single file with 2kLOC, and rather low level drawing. I just render on a simple ubyte-array, but it already support polygon-rendering, antialiasing and different color-structs. This is how it looks like for now: http://img683.imageshack.us/i/testawa.jpg/ this takes currently 62ms to render, don't know if this is fast enough, but can definitley improved. °Matthias
Apr 08 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-08 22:31:11 -0400, Matthias Pleh <jens konrad.net> said:

 For the drawingt part. I'm currently working on a rednerer with 
 scanline algorithm. This will be completly OS-independent. It's in a 
 single file with 2kLOC, and rather low level drawing. I just render on 
 a simple ubyte-array, but it already support polygon-rendering, 
 antialiasing and different color-structs.

Oh! really nice.
 This is how it looks like for now:
 http://img683.imageshack.us/i/testawa.jpg/
 this takes currently 62ms to render, don't know if this is fast enough,
 but can definitley improved.

The important thing is to have an API. Once it works we can concern ourselves with speed. What's the API like? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 09 2011
parent reply Matthias Pleh <jens konrad.net> writes:
Am 09.04.2011 13:11, schrieb Michel Fortin:
 On 2011-04-08 22:31:11 -0400, Matthias Pleh <jens konrad.net> said:

 For the drawingt part. I'm currently working on a rednerer with
 scanline algorithm. This will be completly OS-independent. It's in a
 single file with 2kLOC, and rather low level drawing. I just render on
 a simple ubyte-array, but it already support polygon-rendering,
 antialiasing and different color-structs.

Oh! really nice.
 This is how it looks like for now:
 http://img683.imageshack.us/i/testawa.jpg/
 this takes currently 62ms to render, don't know if this is fast enough,
 but can definitley improved.

The important thing is to have an API. Once it works we can concern ourselves with speed. What's the API like?

Currntly, it's rather low level API. It looks like this: void draw() { buf = new ubyte[width * height * 3]; // create render buffer, just a ubyte-arrray (no color info) PixelBuffer pixBuff = new PixelBuffer(buf, width, height, width*3); auto ren= new Renderer!(Rgb24)(pixBuff); // -> Rgb24 // manages the correct Color Rasterizer ras = new Rasterizer; // create the path // per primitive min. 3 vertexes needed ras.movTo(20,40); // -> moves the point without drawing ras.lineTo(30,80); // -> moves the point with drawing [...snip...] // finally render it to the PixelBuffer ras.render(ren, Color(255,0,0)); } on this we could add more abstraction to directly render lines, rectangles and circles ... (the posted image is completly renderd whit the API above) I hope, I will find time this weekend, clean it up and post it here. Maybe Adam then could add it to his source. °Matthias
Apr 09 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Matthias Pleh:
 I hope, I will find time this weekend, clean it up and post it here.
 Maybe Adam then could add it to his source.

Cool!
Apr 09 2011
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrej Mitrovic wrote:
 Text drawing is as simple as TextDraw or TextOut on Windows. Dunno
 about the nixes.

It's XDrawString() - almost the same. Text output is now implemented on my local copy of the module for both systems.
Apr 08 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Text drawing is as simple as TextDraw or TextOut on Windows. Dunno
about the nixes.
Apr 08 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
It looks like SDL (1.3) will be under zlib license soon[1] so maybe
using it or parts of it or whatever may be feasible, even in Phobos -
the zlib license should be "free" enough, it says
"If you use this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required."
so there's no binary attribution clause.

Cheers,
- Daniel

[1]
http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526
Apr 08 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Daniel Gibson wrote:
 It looks like SDL (1.3) will be under zlib license soon

Now, that's pretty cool!
Apr 08 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/09/2011 02:42 AM, Adam D. Ruppe wrote:
 OK. (But for this module I think usage simplicity is more
  important than raw speed.


image[x, y] = Color(r, g, b); vs image[x, y] = tuple(r, g, b);

Indeed; and then: image[x, y].g versus image[x, y][1] Denis -- _________________ vita es estrany spir.wikidot.com
Apr 09 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/09/2011 06:50 AM, Cliff Hudson wrote:
 So is the objective to create a windowing library, or a drawing library for
 (for example) games?  The two are rather different - though you can build a
 windowing library on top of a drawing library, doing so is pointless given
 the plethora of GUI libraries already out there, several with D bindings.
   If the bindings are hard to use, I'd address that directly rather than
 creating a whole new one.

 If you are building a drawing library, I'd definitely co-opt an existing one
 (SDL would be a good place, in particular since its license seems favorable
 and the API is well known.)  In fact, a good game-oriented library for D I
 think would be a fabulous idea.  D has a lot to offer game developers, a
 great mix of the high level and the low.  I don't know if it is popular with
 this crowd, but Microsoft DirectX or the XNA Framework might be a good place
 to go for pattern ideas as well.

 But generally I'd strive to not create new APIs, just new implementations
 (as necessary.)

I guess you are simply missing the point. You should re-read start-of-thread messages. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 09 2011
prev sibling next sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
--20cf301fbeff5dea3104a07eb4f7
Content-Type: text/plain; charset=ISO-8859-1

Yeah, I'm certainly not suggesting you necessarily rip off implementation,
just possibly API design.  But to be fair it has been a while since I used
that API - maybe the design is crap by comparison to others these days.
 OpenGL or DirectX for quick rendering is definitely the way to go under the
covers.

On Sat, Apr 9, 2011 at 8:05 AM, Adam D. Ruppe <destructionator gmail.com>wrote:

 On Fri, Apr 08, 2011 at 09:50:11PM -0700, Cliff Hudson wrote:
 So is the objective to create a windowing library, or a drawing library

 (for example) games?

Drawing. I have a windowing library in the works too, but it's much much more effort (even building off existing ones!) so it won't be ready to share for a long time still.
 If you are building a drawing library, I'd definitely co-opt an existing

 (SDL would be a good place, in particular since its license seems

 and the API is well known.)

I actually find SDL's drawing facilities to be almost useless... in my D1 game lib, even doing NES type games, I found it was simply too slow and redid the graphics with OpenGL. It's image loaders and sound/music parts are good though.
 I don't know if it is popular with
 this crowd, but Microsoft DirectX or the XNA Framework might be a good

 to go for pattern ideas as well.

I've heard good things about XNA, but I've never used it...

--20cf301fbeff5dea3104a07eb4f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, I&#39;m certainly not suggesting you necessarily rip off implementati= on, just possibly API design. =A0But to be fair it has been a while since I= used that API - maybe the design is crap by comparison to others these day= s. =A0OpenGL or DirectX for quick rendering is definitely the way to go und= er the covers.<br> <br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 at 8:05 AM, Adam D. Rupp= e <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destru= ctionator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;= "> <div class=3D"im">On Fri, Apr 08, 2011 at 09:50:11PM -0700, Cliff Hudson wr= ote:<br> &gt; So is the objective to create a windowing library, or a drawing librar= y for<br> &gt; (for example) games?<br> <br> </div>Drawing. I have a windowing library in the works too, but it&#39;s mu= ch much<br> more effort (even building off existing ones!) so it won&#39;t be ready to = share<br> for a long time still.<br> <div class=3D"im"><br> &gt; If you are building a drawing library, I&#39;d definitely co-opt an ex= isting one<br> &gt; (SDL would be a good place, in particular since its license seems favo= rable<br> &gt; and the API is well known.)<br> <br> </div>I actually find SDL&#39;s drawing facilities to be almost useless... = in my D1<br> game lib, even doing NES type games, I found it was simply too slow and<br> redid the graphics with OpenGL.<br> <br> It&#39;s image loaders and sound/music parts are good though.<br> <div class=3D"im"><br> &gt; I don&#39;t know if it is popular with<br> &gt; this crowd, but Microsoft DirectX or the XNA Framework might be a good= place<br> &gt; to go for pattern ideas as well.<br> <br> </div>I&#39;ve heard good things about XNA, but I&#39;ve never used it...<b= r> <br> </blockquote></div><br> --20cf301fbeff5dea3104a07eb4f7--
Apr 09 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/09/2011 11:45 PM, Adam D. Ruppe wrote:

 There's still a handful of little things and a lot of error checking
 needed, but I'm pretty happy with this as the screen drawing base.
 It covers all the easy stuff. The hard stuff will be in platform
 independent images.

 Anyway, here's the updated simpledisplay.d:

 http://arsdnet.net/dcode/simpledisplay.d

That's great, Adam, thank you! Denis -- _________________ vita es estrany spir.wikidot.com
Apr 10 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/10/2011 02:58 AM, Adam D. Ruppe wrote:
 A note: since I posted last, I changed my mind on something, and
 bearophile, I rather doubt you'll like it...

 Before, it was drawRectangle(int x1, int y2, int width, int height);

 Now, it is drawRectangle(Point upperLeft, Size size);

 So, at the usage, you now need to put in some more parenthesis
 and say what you mean:

 painter.drawRectangle(Point(0, 0), Size(win.width, win.height));


 Why did I do this? Well, consider the following:

 drawRectangle(int x1, int y1, int x2, int y2);

 (This is, in fact, the signature in Windows GDI, whereas Xlib
   user width/height.)


 The types there are no different than the above, but meaning has
 changed. I'd be ok with saying "RTFM" to avoid having to use
 the structs.

 But, RTFM doesn't let you overload it, whereas the types do. Now,
 it can offer both

 drawRectangle(Point upperLeft, Size size);

 *and*

 drawRectangle(Point upperLeft, Point lowerRight);

 I'm sure you were thinking about named arguments for a moment
 there about width/height vs x2/y2. I did too. But, named arguments
 don't really exist in D (you can do them via library magic but not
 without) so it's moot, and I don't believe named arguments would
 offer the overloading possibilities, which I like. It can save
 some math while being quite natural.

 The Point struct also makes drawPolygon look a lot better, so
 it's of general use.

That was about the first change I intended to do on my side, after reading your code :-) In addition to the practical side you describe well, Point (or maybe better Position) is a nearly necessary semantic/conceptual type on the user side. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 10 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/10/2011 03:03 AM, Cliff Hudson wrote:
 One thing to consider, since I was impacted by this when writing a WPF app a
 while back, is the difference between a 2-Vector and a Point.  In
 particular, Vectors typically have some very useful methods on them, like
 addition, rotation, transformations, etc. which frequently are not
 associated with the Point type.  I don't know if you have or plan to support
 this data type, but at least having simple transforms to/from Vector would
 be nice.

Very good remark. Eg a line can be defined by a point and a vector (a single-point one). denis -- _________________ vita es estrany spir.wikidot.com
Apr 10 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
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.

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. 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.
Apr 10 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
 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.
Apr 10 2011
parent KennyTM~ <kennytm gmail.com> writes:
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.
Apr 11 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:int88l$uaf$1 digitalmars.com...
 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.

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. 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.*

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? And frankly, I this strategy renders all the pro-space and pro-tab arguments obsolete, and it's still based on tabs anyway: http://nickgravgaard.com/elastictabstops/ Spaces for indentation are just the worst of all worlds. And it's a total abuse of what space is even for in the first place.
Apr 10 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 07:00, schrieb Nick Sabalausky:
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:int88l$uaf$1 digitalmars.com...
 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.

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. 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.*

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?

Yeah. Indent with tabs, align with spaces. I find reading code with two or eight spaces for indentation hard to read. However both styles are widely used.. if everybody just indented with tabs and configured his editor to display 2/4/8/42 spaces for a tab everybody could be happy.
 And frankly, I this strategy renders all the pro-space and pro-tab arguments 
 obsolete, and it's still based on tabs anyway:
 
 http://nickgravgaard.com/elastictabstops/
 

Hmm looks neat, but I'm not sure I really need that.
 Spaces for indentation are just the worst of all worlds. And it's a total 
 abuse of what space is even for in the first place.
 

The only thing that is more horrible than indentation with spaces is mixing indentation with spaces and tabs so it's completely broken when your editor uses another tab-width than the authors editor. Cheers, - Danie
Apr 10 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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. Bye, bearophile
Apr 10 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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
Apr 10 2011
next sibling parent Kagamin <spam here.lot> writes:
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.
Apr 11 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

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

Why would one fear tabs?
Apr 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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.
Apr 11 2011
next sibling parent reply Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

 So, if 
 you do use tabs, you will end up with mixed tabs and spaces unless everyone 
 involved is very careful, which isn't going to happen.

If no one is careful, you end up with mixed tabs and spaces, no matter what policies you're trying to enforce.
Apr 11 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 17:25, schrieb Kagamin:
 Jonathan M Davis Wrote:
 
 So, if 
 you do use tabs, you will end up with mixed tabs and spaces unless everyone 
 involved is very careful, which isn't going to happen.

If no one is careful, you end up with mixed tabs and spaces, no matter what policies you're trying to enforce.

This is a good point.
Apr 11 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

 Every place that I've ever worked 
 at has gone for spaces only, and I've only ever heard of one place where it 
 was required that tabs be used for indentation. I'm sure that there are 
 others, but it's rare that I've heard of anyone thinking that using tabs in 
 code was a good idea.

People often follow wrong traditions blindly.
Apr 11 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/11/11 10:30 AM, Kagamin wrote:
 Jonathan M Davis Wrote:

 Every place that I've ever worked
 at has gone for spaces only, and I've only ever heard of one place where it
 was required that tabs be used for indentation. I'm sure that there are
 others, but it's rare that I've heard of anyone thinking that using tabs in
 code was a good idea.

People often follow wrong traditions blindly.

That is actually very true about tab. It's a straight carryover from typing machines that has no justification today. Andrei
Apr 11 2011
parent Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 That is actually very true about tab. It's a straight carryover from 
 typing machines that has no justification today.

If it's useful, it doesn't matter, where it came from.
Apr 11 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:inv6q0$1hmi$1 digitalmars.com...
 Jonathan M Davis Wrote:

 Every place that I've ever worked
 at has gone for spaces only, and I've only ever heard of one place where 
 it
 was required that tabs be used for indentation. I'm sure that there are
 others, but it's rare that I've heard of anyone thinking that using tabs 
 in
 code was a good idea.

People often follow wrong traditions blindly.

Especially in corporations.
Apr 11 2011
prev sibling parent Ruben <chromium hybridsource.org> writes:
 One of the reasons to switch to FreeBSD was to spend less time
 tinkering with the OS and "just use it".

 I?m not familiar enough with FreeBSD, but the message from the subject
 is what one gets when attempting to install DMD-2 on x86_64, so I
 believe that 32bit executable on 64bit OS is not the right combo on
 FreeBSD.

FreeBSD ports, after getting permission from Walter. I simply marked the port as i386 since I read that there wasn't a 64-bit binary: I never tried building dmd as 64-bit. 32-bit binaries will run on FreeBSD amd64, but they might require a bit more work. I read that some people simply compile i386 packages in a 32-bit system or jail and then install them in the 64-bit system. So I'd guess that you should be able to use dmd2 on FreeBSD amd64, but it might take a bit more work.
Apr 11 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/11/2011 10:01 AM, Jonathan M Davis wrote:
 Jonathan M Davis Wrote:
  >  Personally, I think that it's _horrible_ to use tabs

Why would one fear tabs?



That's precisely what they are meant for... unlike space-indentation, tab-indentation respects you :-) Using spaces for indent is using *content* to describe *display*. It's messing up model with view, just like using <b> instead of <strong>. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others they
 use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2011 10:58 PM, Daniel Gibson wrote:
 Am 11.04.2011 07:51, schrieb 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.

 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?

In the beginning, God created tabs. Tab stops were 8 spaces. That was engraved in tty and printer hardware, and there was nothing any user could do about it. And it was good, and there was peace in the land. But then in the 80's satan thought that it would be a good idea to make tabs user settable (soft tabs) in his text editor. Various demons and trolls thought this was a fab idea, and propagated it to every text editor. Unfortunately, text files have no way to specify the tab size expected by the text. Conventions were proffered, noobs were sacrificed, and hymns sung, but nobody could ever agree on what the tab size should be. Bikeshed wars raged and devastated the land. Hence, the use of tabs was utterly, totally and perpetually ruined for everyone. And satan laughed at the folly of programmers.
Jun 03 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
8 space tabs are the One True Way. All other tabstops are evil.
Jun 03 2011
prev sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 06/03/2011 02:48 PM, Walter Bright wrote:
 In the beginning, God created tabs. Tab stops were 8 spaces

It's 2011. The idea that some character means 8 spaces and should be used to layout code is ass-backwards, regardless if everybody actually followed that rule. It was a fine rule for 1960.
Jun 04 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Apr 11 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile:
 It's a module theoretically meant for Phobos, and the Phobos coding
 standard are spaces.

Yeah, that's all that matters in the end. "When in Rome..." But it's trivial to do a find and replace all before submitting so really, it's just not a big deal.
Apr 11 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2011 8:31 AM, Adam D. Ruppe wrote:
 Yeah, that's all that matters in the end. "When in Rome..."

 But it's trivial to do a find and replace all before submitting so
 really, it's just not a big deal.

Before I check in, I run tolf and detab on the source files.
Jun 03 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/04/2011 20:54, Steven Schveighoffer wrote:
 In most of the editors I use, the default is to use spaces for
 indentation.  So what happens is someone opens a file that uses tabs for
 indentation, then adds some lines.  However, their editor only uses
 spaces *for those lines they added*, which results in a hybrid.
 However, the person editing doesn't notice because it all lines up on
 their screen.

Just FYI, in Eclipse, the auto-indentation that happen when you press Enter will use the indentation from the previous line (whether it's spaces, tabs, or even mixed). However, other editing operations that generate lines of code (like code templates, auto-generated code, refactorings like extracting a method, etc.) are not so smart and will indent with according to the default indentation you specify in the settings, they won't look at how the file is already indented. -- Bruno Medeiros - Software Engineer
Apr 13 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 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. 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
Apr 10 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 Apr 2011 06:17:58 -0400, spir <denis.spir gmail.com> wrote:

 On 04/11/2011 07:51 AM, Jonathan M Davis wrote:
 the only way that tabs work is if you use them consistently, which in my
 experience almost never happens. And

How so? If you probably set your editor, inconsistency simply cannot happen... The same is true for using spaces, anyway.

Don't want to get too much into this obviously polarized debate, but in my experience, people vary as much as editors. And editors vary quite a bit. In most of the editors I use, the default is to use spaces for indentation. So what happens is someone opens a file that uses tabs for indentation, then adds some lines. However, their editor only uses spaces *for those lines they added*, which results in a hybrid. However, the person editing doesn't notice because it all lines up on their screen. You may have philosophical objections to all of this, but this answers your question straightforwardly -- it happens, all the time, and this is how. The easiest rule to follow is -- always use spaces to indent. Almost all editors support this (and are set to this by default). Almost all editors provide some sort of auto-indentation, or some command to indent a highlighted section of code. The "oh crap, now I have to go back through and convert tabs to spaces" argument just isn't valid anymore. -Steve
Apr 11 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.

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
Apr 11 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
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.
Apr 11 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-11 11:41, KennyTM~ wrote:
 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.

Fair point. But since we are talking about GUI libraries, images and drawing 2D graphics it's most likely floating point numbers will be used eventually, at least somewhere.
 Anyway, those calls are now updated to handled it properly, please check
 https://github.com/kennytm/simpledisplay.d/commit/18b6.

Ok. -- /Jacob Carlborg
Apr 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/11/2011 03:54 AM, Adam D. Ruppe wrote:
 1. *Please use spaces instead of tabs.*

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.

Using spaces is confusing model & view, and forcing your preferred indent width over all readers. Tab means "align columns". Using tabs is respectful attitude ;-) I still use spaces only because most email clients do not allow setting tab width :-( Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-10 17:39:03 -0400, KennyTM~ <kennytm gmail.com> said:

 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.
 

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.

Nice, you're the second one to do that. :-) (I made a Cocoa port of the earlier version when all there was to do was image.display(), but I didn't release the code.) The major difference between our approaches is that I made it by putting Objective-C code in a separate Objective-C file instead of doing that objc_msgSend boilerplate directly in 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.

Ideally we'd be using the extern(Objective-C) syntax I'm working on, but I still have polishing to do on that thing before it's ready to be integrated in mainline DMD (and then it'll probably take some time before Walter reviews and applies the pull request) so it's not an option right now. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 11 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Smart editors also allow you to unindent with a single backspace
regardless if you're using tabs or spaces.
Apr 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.

In other words, *some* editors handle space-indentation intelligently (and do so by reinventing *tabs*), while *all* editors handle tab-indentation intelligently.
Apr 11 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message=20
 news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.

In other words, *some* editors handle space-indentation intelligently (=

 do so by reinventing *tabs*), while *all* editors handle tab-indentatio=

 intelligently.
=20

delete one space when hitting backspace ;) Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 11 2011
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 4/11/11 1:51 PM, "Jérôme M. Berger" wrote:
 Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.

In other words, *some* editors handle space-indentation intelligently (and do so by reinventing *tabs*), while *all* editors handle tab-indentation intelligently.

delete one space when hitting backspace ;) Jerome

Eclipse, I'm looking at you!
Apr 11 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 23:03, schrieb David Gileadi:
 On 4/11/11 1:51 PM, "Jérôme M. Berger" wrote:
 Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.

In other words, *some* editors handle space-indentation intelligently (and do so by reinventing *tabs*), while *all* editors handle tab-indentation intelligently.

delete one space when hitting backspace ;) Jerome

Eclipse, I'm looking at you!

By default Eclipse doesn't convert tab to spaces, though.
Apr 11 2011
prev sibling next sibling parent Kagamin <spam here.lot> writes:
David Gileadi Wrote:

 	I have seen editors that would convert a tab to spaces and only
 delete one space when hitting backspace ;)

 		Jerome

Eclipse, I'm looking at you!

Also Visual Studio and I don't see the "delete unindents" option.
Apr 12 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/04/2011 22:03, David Gileadi wrote:
 On 4/11/11 1:51 PM, "Jérôme M. Berger" wrote:
 Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com> wrote in message
 news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.

In other words, *some* editors handle space-indentation intelligently (and do so by reinventing *tabs*), while *all* editors handle tab-indentation intelligently.

delete one space when hitting backspace ;) Jerome

Eclipse, I'm looking at you!

In Eclipse you can press Shift-Tab to reduce the indentation by one level, regardless of whether it's using spaces or tabs. This also works if you have multiple lines of code selected in the editor. (so if you have 4 spaces of indentation and you press Shift-Tab anywhere on the line it will delete those 4 spaces, assuming you configured a level of indentation to be 4 spaces (that's usually the default though)) -- Bruno Medeiros - Software Engineer
Apr 13 2011
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

J=C3=A9r=C3=B4me M. Berger wrote:
 Nick Sabalausky wrote:
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message=20
 news:mailman.3396.1302548836.4748.digitalmars-d puremagic.com...
 Smart editors also allow you to unindent with a single backspace
 regardless if you're using tabs or spaces.



 do so by reinventing *tabs*), while *all* editors handle tab-indentati=


 intelligently.

delete one space when hitting backspace ;) =20

editor would accept the tab and insert a tab character, it is only when hitting backspace after a tab that the editor would convert the tab to N-1 space (assuming tabs are equivalent to N spaces). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2011 1:31 PM, Nick Sabalausky wrote:
 In other words, *some* editors handle space-indentation intelligently (and
 do so by reinventing *tabs*), while *all* editors handle tab-indentation
 intelligently.

There is no way to handle tabs intelligently. Take a source file that has tab characters in it. There is no algorithm in the world that will discern what the tab size is supposed to be. Heck, I've seen plenty of source files that assume a tab size of X in some sections and Y in others, and Z in still others. The only way to win is to not use tabs.
Jun 03 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.06.2011 20:54, schrieb Walter Bright:
 On 4/11/2011 1:31 PM, Nick Sabalausky wrote:
 In other words, *some* editors handle space-indentation intelligently
 (and
 do so by reinventing *tabs*), while *all* editors handle tab-indentation
 intelligently.

There is no way to handle tabs intelligently. Take a source file that has tab characters in it. There is no algorithm in the world that will discern what the tab size is supposed to be. Heck, I've seen plenty of source files that assume a tab size of X in some sections and Y in others, and Z in still others. The only way to win is to not use tabs.

If you use tabs for indentation and spaces for alignment the tabsize doesn't matter.
Jun 03 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Daniel Gibson wrote:
 Am 03.06.2011 20:54, schrieb Walter Bright:
 On 4/11/2011 1:31 PM, Nick Sabalausky wrote:
 In other words, *some* editors handle space-indentation intelligently
 (and
 do so by reinventing *tabs*), while *all* editors handle tab-indentation
 intelligently.

There is no way to handle tabs intelligently. Take a source file that has tab characters in it. There is no algorithm in the world that will discern what the tab size is supposed to be. Heck, I've seen plenty of source files that assume a tab size of X in some sections and Y in others, and Z in still others. The only way to win is to not use tabs.

If you use tabs for indentation and spaces for alignment the tabsize doesn't matter.

http://www.emacswiki.org/emacs/SmartTabs In a perfect world, everyone would do that. But if multiple people are working on the same source, one of them will mess up the formatting...
Jun 03 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/06/2011 20:15, Timon Gehr wrote:
 Daniel Gibson wrote:

 If you use tabs for indentation and spaces for alignment the tabsize
 doesn't matter.

http://www.emacswiki.org/emacs/SmartTabs

Taken the words out of my mouth there. I've been faced with files that are a mishmash of tabs and spaces, and been tidying them up to this style. The problem is that some editors will, when you indent a block of code, change the alignment spaces back into tabs. Though I do find that feature useful as a first step in cleaning up sources that are in a total mess in terms of tab/space indentation. At work we use Visual Studio, but when I find that a source file needs tidying I would open it in Notepad++ as it behaves in this way. I also tend to use its Trim Trailing Space feature quite often.... Stewart.
Jun 03 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/3/2011 5:14 PM, Stewart Gordon wrote:
 On 03/06/2011 20:15, Timon Gehr wrote:
 Daniel Gibson wrote:

 If you use tabs for indentation and spaces for alignment the tabsize
 doesn't matter.

http://www.emacswiki.org/emacs/SmartTabs

Taken the words out of my mouth there. I've been faced with files that are a mishmash of tabs and spaces, and been tidying them up to this style.

Good luck making that work.
Jun 03 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
DigitalMarsTV Headlines:
"Newlines: Why is Microsoft still ignoring the public's demand to
eliminate the carriage return?"
"Breaking News: Police investigators are on the lookout for the
monster lunatic who originally designed the number system layout for
PC-keyboards. As a reminder for the viewers just tuning in, the
suspect is charged with felonies in regards to the following Laws: 1.
By Law, numbers shall always start from digit zero. 2. By Law,
Function Keys shall be vertically aligned against number keys, so as
to have the same order as the number keys. The authorities are asking
for anyone with information on the suspect to come forward and send an
e-mail to protect_our_GNUFreedom gnu.org"
Apr 11 2011
prev sibling parent Adam Richardson <simpleshot gmail.com> writes:
--0016e6d77d25d8473604a4d3a8a1
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 3, 2011 at 3:04 PM, Daniel Gibson <metalcaedes gmail.com> wrote:

 Am 03.06.2011 20:54, schrieb Walter Bright:
 On 4/11/2011 1:31 PM, Nick Sabalausky wrote:
 In other words, *some* editors handle space-indentation intelligently
 (and
 do so by reinventing *tabs*), while *all* editors handle tab-indentation
 intelligently.

There is no way to handle tabs intelligently. Take a source file that has tab characters in it. There is no algorithm in the world that will discern what the tab size is supposed to be. Heck, I've seen plenty of source files that assume a tab size of X in some sections and Y in others, and Z in still others. The only way to win is to not use tabs.

If you use tabs for indentation and spaces for alignment the tabsize doesn't matter.

This is my preferred approach, too. Adam --0016e6d77d25d8473604a4d3a8a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 3, 2011 at 3:04 PM, Daniel Gibson <span dir=3D"ltr">&lt;<a href= =3D"mailto:metalcaedes gmail.com">metalcaedes gmail.com</a>&gt;</span> wrot= e:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Am 03.06.2011 20:54, schrieb Walter Bright:<br> <div><div></div><div class=3D"h5">&gt; On 4/11/2011 1:31 PM, Nick Sabalausk= y wrote:<br> &gt;&gt; In other words, *some* editors handle space-indentation intelligen= tly<br> &gt;&gt; (and<br> &gt;&gt; do so by reinventing *tabs*), while *all* editors handle tab-inden= tation<br> &gt;&gt; intelligently.<br> &gt;<br> &gt; There is no way to handle tabs intelligently.<br> &gt;<br> &gt; Take a source file that has tab characters in it. There is no algorith= m<br> &gt; in the world that will discern what the tab size is supposed to be.<br=

in<br> &gt; some sections and Y in others, and Z in still others.<br> &gt;<br> &gt; The only way to win is to not use tabs.<br> &gt;<br> <br> </div></div>If you use tabs for indentation and spaces for alignment the ta= bsize<br> doesn&#39;t matter.<br> </blockquote></div><br>This is my preferred approach, too.<br clear=3D"all"=
<br>

--0016e6d77d25d8473604a4d3a8a1--
Jun 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 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
Apr 10 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
 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
Apr 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.3371.1302508910.4748.digitalmars-d puremagic.com...
 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.

You're drawing a completely invalid conclusion from that, because it works the same both ways. If I have a bunch of code indented with spaces, all it takes is a few things to be indented with tabs instead to create the *exact same screwup*. You've chosen tabs as the villian completely arbitrarily. Also I find your argument that the mixup is significantly more likely when tabs are used for indentation to be extremely questionable. You admit yourself that you've rarely come across situations where tabs are the default. So how would you know? Based on that *one* piece of anecdotal evidence? And even that can be suspect, because if you were involved, we know you're accustomed to using spaces for indentation, so that could very well have been the reason for the mixup. I have worked with code that used spaces as indentation on various occasions, and I always did wind up accidentally sticking some tabs in there. So I know first hand that the idea of the mixups not happening with space-indentation is a load of crap. They're equally likely. And as far as needing to use spaces in code anyway: That's not remotely a problem. People know damn well the difference between a space and indentation. Fuck, if MS Word users can figure it out, so can programmers.
 Tabs serve no useful purpose IMHO.

Well, IMO, using spaces for indentation serves no useful purpose. At least tabs actually *mean* alignment and indentation. Spaces don't and never have. Plus, what's the use of being able place the cursor at arbtrary points within the "4 spaces" (or 8 spaces, or whatever)? All it does is make me have to press left/right-arrow-key a whole hell of a lot more (which I really do find to be a PITA). And makes it easier to accidentally end up with a messed up indentation of +/- 1 space somewhere. Spaces for indentation is just a misuse and a kludge to force on each other the idiologies of how large indentation should be.
Apr 11 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-11 22:09, Nick Sabalausky wrote:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.3371.1302508910.4748.digitalmars-d puremagic.com...
 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.

You're drawing a completely invalid conclusion from that, because it works the same both ways. If I have a bunch of code indented with spaces, all it takes is a few things to be indented with tabs instead to create the *exact same screwup*. You've chosen tabs as the villian completely arbitrarily. Also I find your argument that the mixup is significantly more likely when tabs are used for indentation to be extremely questionable. You admit yourself that you've rarely come across situations where tabs are the default. So how would you know? Based on that *one* piece of anecdotal evidence? And even that can be suspect, because if you were involved, we know you're accustomed to using spaces for indentation, so that could very well have been the reason for the mixup. I have worked with code that used spaces as indentation on various occasions, and I always did wind up accidentally sticking some tabs in there. So I know first hand that the idea of the mixups not happening with space-indentation is a load of crap. They're equally likely. And as far as needing to use spaces in code anyway: That's not remotely a problem. People know damn well the difference between a space and indentation. Fuck, if MS Word users can figure it out, so can programmers.
 Tabs serve no useful purpose IMHO.

Well, IMO, using spaces for indentation serves no useful purpose. At least tabs actually *mean* alignment and indentation. Spaces don't and never have. Plus, what's the use of being able place the cursor at arbtrary points within the "4 spaces" (or 8 spaces, or whatever)? All it does is make me have to press left/right-arrow-key a whole hell of a lot more (which I really do find to be a PITA). And makes it easier to accidentally end up with a messed up indentation of +/- 1 space somewhere. Spaces for indentation is just a misuse and a kludge to force on each other the idiologies of how large indentation should be.

So true. -- /Jacob Carlborg
Apr 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 09:24 AM, Jacob Carlborg wrote:
 Well, IMO, using spaces for indentation serves no useful purpose. At least
 tabs actually *mean* alignment and indentation. Spaces don't and never have.
 Plus, what's the use of being able place the cursor at arbtrary points
 within the "4 spaces" (or 8 spaces, or whatever)? All it does is make me
 have to press left/right-arrow-key a whole hell of a lot more (which I
 really do find to be a PITA). And makes it easier to accidentally end up
 with a messed up indentation of +/- 1 space somewhere. Spaces for
 indentation is just a misuse and a kludge to force on each other the
 idiologies of how large indentation should be.

So true.

Especially "Spaces for indentation is just a misuse". Space are not meant for alignment, have never been, and should never have been used for that. Tabs are intended for that role, & they play it well. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 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.

I hate the very concept of tabs to begin with. The fact that they're variable in size is _not_ something that I find to be desirable. Regardless of that however, if you try and use tabs for indentation they invariably get mixed with spaces, totally ruining whatever usefulness the tabs might have had. Code will _always_ contain spaces. You can't reasonably write code with only tabs. However, you _can_ easily and reasonably write code without tabs. Most code editors can be set up such that all tabs are converted to spaces. So, if you use only spaces, you can easily avoid the problem of tabs and spaces being mixed. On the other hand, you _can't_ do the same by using only tabs. So, if you do use tabs, you will end up with mixed tabs and spaces unless everyone involved is very careful, which isn't going to happen. So, I suppose that you could say that tabs are horrible because some people use spaces, but I don't see any value in them to begin with anyway. However, the fact that you invariably end up with mixed tabs and spaces when you try and use tabs makes tabs completely useless. Every place that I've ever worked at has gone for spaces only, and I've only ever heard of one place where it was required that tabs be used for indentation. I'm sure that there are others, but it's rare that I've heard of anyone thinking that using tabs in code was a good idea. - Jonathan M Davis
Apr 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/11/2011 07:51 AM, Jonathan M Davis wrote:
 the only way that tabs work is if you use them consistently, which in my
 experience almost never happens. And

How so? If you probably set your editor, inconsistency simply cannot happen... The same is true for using spaces, anyway. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/11/2011 05:31 PM, Adam D. Ruppe wrote:
 bearophile:
 It's a module theoretically meant for Phobos, and the Phobos coding
 standard are spaces.

Yeah, that's all that matters in the end. "When in Rome..." But it's trivial to do a find and replace all before submitting so really, it's just not a big deal.

Smart editors actually differentiate between indentation and spacing elsewhere (meaning they won't mess up with spacing inline / in comments / docs / strings). Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 11 Apr 2011 03:26:26 -0700
Ruben <chromium hybridsource.org> wrote:

 Let me address this, since I wrote the ldc, dmd, and dmd2 Makefiles
 in FreeBSD ports, after getting permission from Walter. =20

Thank you for your work.
 I simply marked the port as i386 since I read that there wasn't a
 64-bit binary:

That's fair.
 32-bit binaries will run on FreeBSD amd64, but they might require a
 bit more work.  I read that some people simply compile i386 packages
 in a 32-bit system or jail and then install them in the 64-bit
 system.  So I'd guess that you should be able to use dmd2 on FreeBSD
 amd64, but it might take a bit more work.

I understand that "it might work"...today I've installed wine on my x86_64, but I simply expect to run 64bit compiler on 64bit OS and therefore hope that gdc2/ldc2 will fill the hole. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 11 2011
prev sibling next sibling parent reply teo <teo.ubuntu yahoo.com> writes:
On Fri, 08 Apr 2011 20:26:07 +0000, 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
 

I admit I didn't read the whole thread... I just wanted to point out the following: - XCB (http://xcb.freedesktop.org/) - aims to replace Xlib - Wayland (http://wayland.freedesktop.org/) - aims to replace the X server A quick look at the source code shows that you are targeting the X server, which might not be the best idea. Please ignore my post, if the above is well known and has already been discussed.
Apr 11 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
teo wrote:
 XCB (http://xcb.freedesktop.org/) - aims to replace Xlib

I've heard of it, but never used it before. Since I wanted to write this quickly I stuck to what I knew (xlib on linux and gdi on windows). Replacing it later, if necessary, won't be hard (the target specific code is only about 300 lines, all straightforward. We were considering changing to DirectX / OpenGL a bit later anyway, so the xlib might actually be secondary in any case). But I doubt xlib is going anywhere any time soon. It's older than I am!
Apr 11 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"teo" <teo.ubuntu yahoo.com> wrote in message 
news:io00gq$5rc$1 digitalmars.com...
 On Fri, 08 Apr 2011 20:26:07 +0000, 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

I admit I didn't read the whole thread... I just wanted to point out the following: - XCB (http://xcb.freedesktop.org/) - aims to replace Xlib - Wayland (http://wayland.freedesktop.org/) - aims to replace the X server A quick look at the source code shows that you are targeting the X server, which might not be the best idea. Please ignore my post, if the above is well known and has already been discussed.

Even the Wayland site says that it's not going to replace X server anytime soon and that they're going to co-exist for the forseeable future. Don't know anything about XCB though.
Apr 11 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 "teo" <teo.ubuntu yahoo.com> wrote in message=20
 news:io00gq$5rc$1 digitalmars.com...
 On Fri, 08 Apr 2011 20:26:07 +0000, 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

I just wanted to point out the following: - XCB (http://xcb.freedesktop.org/) - aims to replace Xlib - Wayland (http://wayland.freedesktop.org/) - aims to replace the X se=


 A quick look at the source code shows that you are targeting the X
 server, which might not be the best idea.

 Please ignore my post, if the above is well known and has already been=


 discussed.

Even the Wayland site says that it's not going to replace X server anyt=

 soon and that they're going to co-exist for the forseeable future. Don'=

 know anything about XCB though.
=20

"big" GUI toolkits (Gtk, Qt, ...) are staying on Xlib (some of them did take a stab at XCB and dropped it as not worth the trouble). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
prev sibling parent teo <teo.ubuntu yahoo.com> writes:
On Mon, 11 Apr 2011 23:08:12 +0000, Adam D. Ruppe wrote:

 teo wrote:
 XCB (http://xcb.freedesktop.org/) - aims to replace Xlib

I've heard of it, but never used it before. Since I wanted to write this quickly I stuck to what I knew (xlib on linux and gdi on windows). Replacing it later, if necessary, won't be hard (the target specific code is only about 300 lines, all straightforward. We were considering changing to DirectX / OpenGL a bit later anyway, so the xlib might actually be secondary in any case).

Yes, it won't be hard, but it is also not that straightforward, because XCB is a bit lower-level compared to Xlib.
 
 But I doubt xlib is going anywhere any time soon. It's older than I am!

Exactly that is the problem. It is old and clumsy (state-of-the-1980s) and I suspect that Wayland will eventually replace it. Xlib and the X server will remain there for legacy applications. Wayland is still alpha, however I would consider at least looking more closer at it. Currently it uses OpenGL ES (will use OpenGL later) and is oriented towards the future of Linux graphics. Two of the leading Linux distributions (Ubuntu and Fedora) stated that they will switch to Wayland in one of the coming releases.
Apr 12 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
 On 04/11/2011 10:01 AM, Jonathan M Davis wrote:
 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.

That's precisely what they are meant for... unlike space-indentation, tab-indentation respects you :-) Using spaces for indent is using *content* to describe *display*. It's messing up model with view, just like using <b> instead of <strong>.

I don't believe that the model-view issue really applies to code. For that to work, the model and view would have to be truly separate, and they aren't. Editors would have to understand the language and be able to format it based on what you wanted, then you could format code however you liked without affecting anyone else. But things just don't work that way. So, how you format your code matters. Using tabs screws with that unless you're completely consistent, and while a single developer may be consistent, groups of developers rarely are. - Jonathan M Davis
Apr 11 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 05:15, schrieb Jonathan M Davis:
 Using tabs screws with that unless you're completely 
 consistent, and while a single developer may be consistent, groups of 
 developers rarely are.
 
 - Jonathan M Davis

Yeah that is why using spaces screws with that: While a single developer may be consistent, groups of developers rarely are. So there may be a developer who uses tabs instead of spaces (maybe because he thinks his editor will convert the tabs to spaces but he forgot to check that option in the editors settings).. And of course then there's that guy who uses two spaces instead of four (or whatever the convention is), at least from a level of 3 indentations on, to save space on the screen. And this other guy who uses eight spaces in his performance critical code because he thinks that'll prevent unnecessary nesting.. So much for consistency. As someone else said before: This argument works for both directions. Cheers, - Daniel
Apr 11 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others
 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings. Using only spaces and no tabs avoids the entire issue and is one of the major reasons (if not _the_ major reason) why it is incredibly common for coding standards to require spaces and prohibit tabs. Obviously, you _can_ use tabs if you're careful - especially if you're the only programmer involved - but it's just simpler to disallow tabs when you're dealing with a group of developers. - Jonathan M Davis
Apr 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.3412.1302578409.4748.digitalmars-d puremagic.com...
 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others
 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings.

That applies the other way around, too.
 Using only spaces and no tabs avoids the entire issue...

It avoid the issue *as well as* using only tabs for indentation.
Apr 11 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 07:13 AM, Jonathan M Davis wrote:
 It's true that people occasionally end up inserting tabs in space-only
 environments, but in my experience, it's fairly rare. It's pretty much a
 guarantee, however, that _someone_ will insert spaces in an environment where
 it's supposed to be tabs.

How can you assert that? you stated yourself that in all your work environments the convention was spaces. So, logically, all mess up cases you have ever experienced are due to the standard beeing spaces. Your assertion about tab-as-standard causing more mess up is complete guessing. Please, be fair. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 On 04/12/2011 07:13 AM, Jonathan M Davis wrote:
 It's true that people occasionally end up inserting tabs in space-only=


 environments, but in my experience, it's fairly rare. It's pretty much=


 guarantee, however, that _someone_ will insert spaces in an
 environment where
 it's supposed to be tabs.

How can you assert that? you stated yourself that in all your work environments the convention was spaces. So, logically, all mess up case=

 you have ever experienced are due to the standard beeing spaces.
 Your assertion about tab-as-standard causing more mess up is complete
 guessing.
 Please, be fair.
=20

more mess ups with tabs than with spaces... Other than that (and the fact that almost *no* editors are able to do it properly), I would really prefer "tabs for indent, spaces for align". Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:io230l$1ldc$3 digitalmars.com...
Well, I have worked in both environments, and I have seen a lot
more mess ups with tabs than with spaces... Other than that (and the
fact that almost *no* editors are able to do it properly), I would
really prefer "tabs for indent, spaces for align".

I prefer "tabs for indent, tabs for align, spaces for separation", but that requires elastic tabstops. And at least one of the biggest code-edit controls out there (the one I use), Scintilla, doesn't support them :(
Apr 12 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 ""J=EF=BF=BDr=EF=BF=BDme M. Berger"" <jeberger free.fr> wrote in messag=

 news:io230l$1ldc$3 digitalmars.com...
 Well, I have worked in both environments, and I have seen a lot
 more mess ups with tabs than with spaces... Other than that (and the
 fact that almost *no* editors are able to do it properly), I would
 really prefer "tabs for indent, spaces for align".

I prefer "tabs for indent, tabs for align, spaces for separation", but =

 requires elastic tabstops. And at least one of the biggest code-edit=20
 controls out there (the one I use), Scintilla, doesn't support them :(
=20
=20

following, elastic tab stops would be best: int a; SomeType b; However, for this, I think that spaces are better: doSomething (someLongParameterThatJustifiesBreakingTheLine, someOtherLongParameterJustInCase); Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 13 2011
parent reply "Nick Sabalausky" <a a.a> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:io4sng$1p9b$1 digitalmars.com...
Nick Sabalausky wrote:
 ""J?r?me M. Berger"" <jeberger free.fr> wrote in message
 news:io230l$1ldc$3 digitalmars.com...
 Well, I have worked in both environments, and I have seen a lot
 more mess ups with tabs than with spaces... Other than that (and the
 fact that almost *no* editors are able to do it properly), I would
 really prefer "tabs for indent, spaces for align".

I prefer "tabs for indent, tabs for align, spaces for separation", but that requires elastic tabstops. And at least one of the biggest code-edit controls out there (the one I use), Scintilla, doesn't support them :(

following, elastic tab stops would be best: int a; SomeType b; However, for this, I think that spaces are better: doSomething (someLongParameterThatJustifiesBreakingTheLine, someOtherLongParameterJustInCase);

I guess we disagree on that. Like I said in another branch, I used to do that, but then I found that mixing tabs/spaces before the first non-whitespace on a line is just asking for trouble. I'd rather do it like this (assuming elastic tabstops): doSomething(->someLongParameterThatJustifiesBreakingTheLine, -> someOtherLongParameterJustInCase); Of course, that does demonstrate that I've never liked putting any whitespace between a function name (or if/while/etc.) and the opening paren. YMMV.
Apr 13 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 ""J=EF=BF=BDr=EF=BF=BDme M. Berger"" <jeberger free.fr> wrote in messag=

 news:io4sng$1p9b$1 digitalmars.com...
 Nick Sabalausky wrote:
 ""J?r?me M. Berger"" <jeberger free.fr> wrote in message
 news:io230l$1ldc$3 digitalmars.com...
 Well, I have worked in both environments, and I have seen a lot
 more mess ups with tabs than with spaces... Other than that (and the=




 fact that almost *no* editors are able to do it properly), I would
 really prefer "tabs for indent, spaces for align".




 that
 requires elastic tabstops. And at least one of the biggest code-edit
 controls out there (the one I use), Scintilla, doesn't support them :=




following, elastic tab stops would be best: int a; SomeType b; However, for this, I think that spaces are better: doSomething (someLongParameterThatJustifiesBreakingTheLine, someOtherLongParameterJustInCase);

I guess we disagree on that. Like I said in another branch, I used to d=

 that, but then I found that mixing tabs/spaces before the first=20
 non-whitespace on a line is just asking for trouble.
=20

 I'd rather do it like this (assuming elastic tabstops):
=20
 doSomething(->someLongParameterThatJustifiesBreakingTheLine,
 ->            someOtherLongParameterJustInCase);
=20
 Of course, that does demonstrate that I've never liked putting any=20
 whitespace between a function name (or if/while/etc.) and the opening p=

 YMMV.
=20

the parenthesis and none inside. And as opposed to a lot of typographic rules, that one is a constant across languages and variants. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 13 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:
 Nick Sabalausky wrote:
 ""J�r�me M. Berger""<jeberger free.fr>  wrote in message
 news:io4sng$1p9b$1 digitalmars.com...
 Nick Sabalausky wrote:
 ""J?r?me M. Berger""<jeberger free.fr>  wrote in message
 news:io230l$1ldc$3 digitalmars.com...
 Well, I have worked in both environments, and I have seen a lot
 more mess ups with tabs than with spaces... Other than that (and the
 fact that almost *no* editors are able to do it properly), I would
 really prefer "tabs for indent, spaces for align".

that requires elastic tabstops. And at least one of the biggest code-edit controls out there (the one I use), Scintilla, doesn't support them :(

following, elastic tab stops would be best: int a; SomeType b; However, for this, I think that spaces are better: doSomething (someLongParameterThatJustifiesBreakingTheLine, someOtherLongParameterJustInCase);

I guess we disagree on that. Like I said in another branch, I used to do that, but then I found that mixing tabs/spaces before the first non-whitespace on a line is just asking for trouble.

 I'd rather do it like this (assuming elastic tabstops):

 doSomething(->someLongParameterThatJustifiesBreakingTheLine,
 ->             someOtherLongParameterJustInCase);

 Of course, that does demonstrate that I've never liked putting any
 whitespace between a function name (or if/while/etc.) and the opening paren.
 YMMV.

the parenthesis and none inside. And as opposed to a lot of typographic rules, that one is a constant across languages and variants.

Math typography rules also preclude inserting a space between a function's name and the opening brace. That's why I consistently go with no space after the opening paren or before the closing paren. Also, that's why there's no need to make if (condition) and func(args) consistent with regard to space before opening paren. In the first case the paren is pure punctuation; in the latter it is an organic part of the function invocation syntax. So one should never leave a space between function name and opening paren, and decide independently regarding the existence of a space between if/while etc. and the opening paren. Andrei
Apr 13 2011
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 Actually, I have never been pleased that func defs (1) look like func
 calls (2) have an exceptional syntax compared to other definitions. I'd=

 like instead eg:
=20
     square =3D function (int n) int {
         return n * n;
     }
=20

first. But the following would work too: function (int n) int square =3D { return n*n; } And both would be easier to parse to boot:) There are actually languages out there with this kind of syntax. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 14 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 07:58 PM, "Jérôme M. Berger" wrote:
 spir wrote:
 Actually, I have never been pleased that func defs (1) look like func
 calls (2) have an exceptional syntax compared to other definitions. I'd
 like instead eg:

      square = function (int n) int {
          return n * n;
      }

first.

True. I was firstly evoking the "x = y" form.
  But the following would work too:

 function (int n) int square = {
     return n*n;
 }

 	And both would be easier to parse to boot:)

Yes, I like your format as well.
  There are actually
 languages out there with this kind of syntax.

Yop, I know (my example was Lua-like: we are not reinventing the wheel ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Apr 14 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/13/2011 11:44 PM, Andrei Alexandrescu wrote:
 On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:
 Well, standard (printed) typographic practices put spaces outside
 the parenthesis and none inside. And as opposed to a lot of
 typographic rules, that one is a constant across languages and variants.

Math typography rules also preclude inserting a space between a function's name and the opening brace. That's why I consistently go with no space after the opening paren or before the closing paren. Also, that's why there's no need to make if (condition) and func(args) consistent with regard to space before opening paren. In the first case the paren is pure punctuation; in the latter it is an organic part of the function invocation syntax. So one should never leave a space between function name and opening paren, and decide independently regarding the existence of a space between if/while etc. and the opening paren.

Agreed. In the same vein, function definition is not a function call; thus I use to write: int square (int n) { return n * n; } sq = square(3); Actually, I have never been pleased that func defs (1) look like func calls (2) have an exceptional syntax compared to other definitions. I'd like instead eg: square = function (int n) int { return n * n; } Denis -- _________________ vita es estrany spir.wikidot.com
Apr 14 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-12 05:19, Jonathan M Davis wrote:
 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others
 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings.

How can it not be as easy to use tabs without realizing that someone else used spaces?
 Using only spaces and no tabs avoids the entire issue and is one of the major
 reasons (if not _the_ major reason) why it is incredibly common for coding
 standards to require spaces and prohibit tabs. Obviously, you _can_ use tabs
 if you're careful - especially if you're the only programmer involved - but
 it's just simpler to disallow tabs when you're dealing with a group of
 developers.

 - Jonathan M Davis

-- /Jacob Carlborg
Apr 12 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.3412.1302578409.4748.digitalmars-d puremagic.com...
 
 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others
 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings.

That applies the other way around, too.
 Using only spaces and no tabs avoids the entire issue...

It avoid the issue *as well as* using only tabs for indentation.

No, because you _always_ have spaces. It's not like you stop using the spacebar just because your tab key is actually inserting tab characters. If you have tabs, then you're still going to have spaces. It's just a question of whether those involved in the project are disciplined enough to avoid ever using spaces for indenting. If, on the other hand, you only allow spaces, then you don't have the same concern about tabs being inserted. True, someone's editor could be set up poorly for either situation and insert spaces where they shouldn't or tabs where they shouldn't, but it's generally trivial to set up an editor to _never_ input tabs that it's easy to make it so that tabs are never used. However, the same can't be said of using tabs, because it's always possible to input spaces with the spacebar. It's true that people occasionally end up inserting tabs in space-only environments, but in my experience, it's fairly rare. It's pretty much a guarantee, however, that _someone_ will insert spaces in an environment where it's supposed to be tabs. There's not much point in arguing the matter. Some folks prefer tabs, and some prefer spaces, but I believe that it's most common for spaces to be preferred as far as style guides go, and they're generally less error-prone simply because it's easy enough to set up editors so that tabs are never used, and you can't do the same with spaces when you're using tabs for indentation. - Jonathan M Davis
Apr 11 2011
prev sibling next sibling parent reply Cliff Hudson <cliff.s.hudson gmail.com> writes:
--0016e6d99c7b94233e04a0b2061c
Content-Type: text/plain; charset=ISO-8859-1

Spaces *should* only be used within string constants (as needed), or when
the language otherwise requires them.  The editor should format the code
according to user preferences.

Absent that, spaces represent the lowest common denominator of formatting,
so we can all use them and our text shows up as we desire regardless of
editor or setting.

Can we move along now?  This argument was old 30 years ago.  Perhaps we
should do VI vs. EMACS while we are at it.

</snipe>

On Mon, Apr 11, 2011 at 10:13 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.3412.1302578409.4748.digitalmars-d puremagic.com...

 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on




 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes


 tabs,
 but as soon as you get a mix of developers, you invariably get a mix of
 spaces
 and tabs unless _everyone_ involved is really careful, and that rarely
 happens. It's just too easy to use spaces without realizing that


 else
 used tabs or even that you yourself are using spaces, depending on your
 editor's settings.

That applies the other way around, too.
 Using only spaces and no tabs avoids the entire issue...

It avoid the issue *as well as* using only tabs for indentation.

No, because you _always_ have spaces. It's not like you stop using the spacebar just because your tab key is actually inserting tab characters. If you have tabs, then you're still going to have spaces. It's just a question of whether those involved in the project are disciplined enough to avoid ever using spaces for indenting. If, on the other hand, you only allow spaces, then you don't have the same concern about tabs being inserted. True, someone's editor could be set up poorly for either situation and insert spaces where they shouldn't or tabs where they shouldn't, but it's generally trivial to set up an editor to _never_ input tabs that it's easy to make it so that tabs are never used. However, the same can't be said of using tabs, because it's always possible to input spaces with the spacebar. It's true that people occasionally end up inserting tabs in space-only environments, but in my experience, it's fairly rare. It's pretty much a guarantee, however, that _someone_ will insert spaces in an environment where it's supposed to be tabs. There's not much point in arguing the matter. Some folks prefer tabs, and some prefer spaces, but I believe that it's most common for spaces to be preferred as far as style guides go, and they're generally less error-prone simply because it's easy enough to set up editors so that tabs are never used, and you can't do the same with spaces when you're using tabs for indentation. - Jonathan M Davis

--0016e6d99c7b94233e04a0b2061c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Spaces *should* only be used within string constants (as needed), or when t= he language otherwise requires them. =A0The editor should format the code a= ccording to user preferences.<div><br></div><div>Absent that, spaces repres= ent the lowest common denominator of formatting, so we can all use them and= our text shows up as we desire regardless of editor or setting.</div> <div><br></div><div>Can we move along now? =A0This argument was old 30 year= s ago. =A0Perhaps we should do VI vs. EMACS while we are at it.<br><br></di= v><div>&lt;/snipe&gt;</div><div><br><div class=3D"gmail_quote">On Mon, Apr = 11, 2011 at 10:13 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mai= lto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div><div></div><div class=3D"h5">&gt; &quo= t;Jonathan M Davis&quot; &lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavis= Prog gmx.com</a>&gt; wrote in message<br> &gt; news:mailman.3412.1302578409.4748.digitalmars-d puremagic.com...<br> &gt;<br> &gt; &gt;&gt; On 04/11/2011 08:13 AM, Jonathan M Davis wrote:<br> &gt; &gt;&gt; &gt; They mix tabs and spaces. On some lines, they use spaces= and on others<br> &gt; &gt;&gt; &gt; they use tabs.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Never seen this, not even once. Messing can only happen when = one<br> &gt; &gt;&gt; copy-pastes from modules using spaces.<br> &gt; &gt;<br> &gt; &gt; As Steve pointed out, it frequently happens when you have multipl= e<br> &gt; &gt; developers<br> &gt; &gt; working on the same code. It may work with one developer who like= s using<br> &gt; &gt; tabs,<br> &gt; &gt; but as soon as you get a mix of developers, you invariably get a = mix of<br> &gt; &gt; spaces<br> &gt; &gt; and tabs unless _everyone_ involved is really careful, and that r= arely<br> &gt; &gt; happens. It&#39;s just too easy to use spaces without realizing t= hat someone<br> &gt; &gt; else<br> &gt; &gt; used tabs or even that you yourself are using spaces, depending o= n your<br> &gt; &gt; editor&#39;s settings.<br> &gt;<br> &gt; That applies the other way around, too.<br> &gt;<br> &gt; &gt; Using only spaces and no tabs avoids the entire issue...<br> &gt;<br> &gt; It avoid the issue *as well as* using only tabs for indentation.<br> <br> </div></div>No, because you _always_ have spaces. It&#39;s not like you sto= p using the<br> spacebar just because your tab key is actually inserting tab characters. If= <br> you have tabs, then you&#39;re still going to have spaces. It&#39;s just a = question of<br> whether those involved in the project are disciplined enough to avoid ever<= br> using spaces for indenting. If, on the other hand, you only allow spaces, t= hen<br> you don&#39;t have the same concern about tabs being inserted. True, someon= e&#39;s<br> editor could be set up poorly for either situation and insert spaces where<= br> they shouldn&#39;t or tabs where they shouldn&#39;t, but it&#39;s generally= trivial to set<br> up an editor to _never_ input tabs that it&#39;s easy to make it so that ta= bs are<br> never used. However, the same can&#39;t be said of using tabs, because it&#= 39;s always<br> possible to input spaces with the spacebar.<br> <br> It&#39;s true that people occasionally end up inserting tabs in space-only<= br> environments, but in my experience, it&#39;s fairly rare. It&#39;s pretty m= uch a<br> guarantee, however, that _someone_ will insert spaces in an environment whe= re<br> it&#39;s supposed to be tabs.<br> <br> There&#39;s not much point in arguing the matter. Some folks prefer tabs, a= nd some<br> prefer spaces, but I believe that it&#39;s most common for spaces to be pre= ferred<br> as far as style guides go, and they&#39;re generally less error-prone simpl= y<br> because it&#39;s easy enough to set up editors so that tabs are never used,= and<br> you can&#39;t do the same with spaces when you&#39;re using tabs for indent= ation.<br> <font color=3D"#888888"><br> - Jonathan M Davis<br> </font></blockquote></div><br></div> --0016e6d99c7b94233e04a0b2061c--
Apr 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Cliff Hudson" <cliff.s.hudson gmail.com> wrote in message 
news:mailman.3414.1302586393.4748.digitalmars-d puremagic.com...
 Spaces *should* only be used within string constants (as needed), or when
 the language otherwise requires them.  The editor should format the code
 according to user preferences.

 Absent that, spaces represent the lowest common denominator of formatting,
 so we can all use them and our text shows up as we desire regardless of
 editor or setting.

I'd rather my text show up indented the way the person reading it desires.
 Can we move along now?  This argument was old 30 years ago.  Perhaps we
 should do VI vs. EMACS while we are at it.

Pico rules them all! ;)
Apr 12 2011
next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 12/04/2011 20:49, Nick Sabalausky wrote:
 Can we move along now?  This argument was old 30 years ago.  Perhaps we
 should do VI vs. EMACS while we are at it.

Pico rules them all! ;)

Vi *and* Emacs suck. Argument settled :P (yes, that was hyperbolic rhetoric) -- Bruno Medeiros - Software Engineer
Jun 03 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-06-03 05:45, Bruno Medeiros wrote:
 On 12/04/2011 20:49, Nick Sabalausky wrote:
 Can we move along now? This argument was old 30 years ago. Perhaps we
 should do VI vs. EMACS while we are at it.

Pico rules them all! ;)

Vi *and* Emacs suck. Argument settled :P

Yeah, I got sucked in by vim, and I've never gotten away. ;) - Jonathan M Davis
Jun 03 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I bet you wrote std.datetime with a call to a single Vim macro.

Just kidding. :P
Jun 03 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/11, Cliff Hudson <cliff.s.hudson gmail.com> wrote:
 Perhaps we
 should do VI vs. EMACS while we are at it.

Don't bring operating systems into this... ... just kidding. :P
Apr 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 05:15 AM, Jonathan M Davis wrote:
 So, how you format
 your code matters. Using tabs screws with that unless you're completely
 consistent, and while a single developer may be consistent, groups of
 developers rarely are.

This is as true in the case of spaces. With the additional issue of indent-width. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 05:19 AM, Jonathan M Davis wrote:
 Using only spaces and no tabs avoids the entire issue

spaces <--> tabs works as fine Why are programmers so blindly unfair when discussing this point?
 and is one of the major reasons (if not _the_ major reason) why it is
incredibly common for coding

you're careful - especially if you're the only programmer involved - but it's just simpler to disallow tabs when you're dealing with a group of developers. I guess the true reason why spaces are required in guidelines is a mix of conformism and "virality". At one point in time, people started to face the issue, thay had to make a choice for coding standard in language libs, corporation code, school/university works, etc. They chose spaces because, at that time, most people used spaces and did not want to change. Then, even more programmers get used to use spaces and don't want to change, so that new coding standards are forced to enforce spaces, and so on... There is no, and there has never been any, logical reason for this choice. There cannot be, in fact: 1. Tabs properly separate code content from view, 2. and respect each reader's preference. In addition to those main reasons, they have a few nice side-effects: * No indent width issue (!), * 1 tab <--> 1 indent level conceptually, * deletion is 1 key press, even with stupid editors. A drawback is one cannot directly have different indent levels, for instance to indent collection contents more, or less, than blocks of code. This can also be considered an advantage; and is simply solved by using... spaces ;-) void f () { -> while (true) { -> -> table = [ -> -> .."aaa" : 1, -> -> .."bbb" : 2, -> -> .."ccc" : 3, -> -> ]; -> -> auto a = this(table); -> -> if (! a) break; -> } } (yes, the example is stupid) Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 In addition to those main reasons, they have a few nice side-effects:
=20
 * No indent width issue (!),

 * 1 tab <--> 1 indent level conceptually,

 * deletion is 1 key press, even with stupid editors.

=20
 A drawback is one cannot directly have different indent levels, for
 instance to indent collection contents more, or less, than blocks of
 code. This can also be considered an advantage; and is simply solved by=

 using... spaces ;-)
=20
 void f () {
  -> while (true) {
  ->  -> table =3D [
  ->  -> .."aaa" : 1,
  ->  -> .."bbb" : 2,
  ->  -> .."ccc" : 3,
  ->  -> ];
  ->  -> auto a =3D this(table);
  ->  -> if (! a) break;
  -> }
 }
=20
 (yes, the example is stupid)
=20

example properly: sure they will *display* it fine, but they will not allow you to *enter* it right (especially if you need more spaces for alignment than the tab size). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:io2396$1nuo$1 digitalmars.com...
spir wrote:
 A drawback is one cannot directly have different indent levels, for
 instance to indent collection contents more, or less, than blocks of
 code. This can also be considered an advantage; and is simply solved by
 using... spaces ;-)

 void f () {
  -> while (true) {
  ->  -> table = [
  ->  -> .."aaa" : 1,
  ->  -> .."bbb" : 2,
  ->  -> .."ccc" : 3,
  ->  -> ];
  ->  -> auto a = this(table);
  ->  -> if (! a) break;
  -> }
 }

 (yes, the example is stupid)

example properly: sure they will *display* it fine, but they will not allow you to *enter* it right (especially if you need more spaces for alignment than the tab size).

That's unfortunately true. I used to try to do that in cases like this: if(blah) { -> foo(.bigLongArg1, -> .....bigLongArg2, -> .....bigLongArg3 -> ); } But editors just choke on that like crazy. It's a pain to type it in that way, and then when you go back to edit (add another arg on another line, for instance), it just screws it all up again, likely without me even noticing right away. (And I even have most auto-formatting turned off.) I decided it was far more trouble than it was worth. So I've changed my style to this: if(blah) { -> foo( -> -> bigLongArg1, -> -> bigLongArg2, -> -> bigLongArg3 -> ); } Much better. Of course, it would be even better still if Scintilla would be willing to add elastic tabstops (I'm getting increasingly annoyed that it doesn't, and that it doesn't even seem receptive to the idea, for technical reasons), because then I *could* do exactly what I used to with absolutely no problem: if(blah) { -> foo(->bigLongArg1, -> -> bigLongArg2, -> -> bigLongArg3 -> ); } And everything would always align properly.
Apr 12 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 So I've changed my style to this:

 if(blah)
 {
 ->  foo(
 ->  ->  bigLongArg1,
 ->  ->  bigLongArg2,
 ->  ->  bigLongArg3
 ->  );
 }

That's something I've started doing too. It's not just a matter of alignment either - I think the first argument on the same line as the function name is easy to miss. It all blends in together.
Apr 12 2011
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:

 So I've changed my style to this:
 
 if(blah)
 {
 ->  foo(
 ->  ->  bigLongArg1,
 ->  ->  bigLongArg2,
 ->  ->  bigLongArg3
 ->  );
 }
 
 Much better. Of course, it would be even better still if Scintilla would be 
 willing to add elastic tabstops (I'm getting increasingly annoyed that it 
 doesn't, and that it doesn't even seem receptive to the idea, for technical 
 reasons), because then I *could* do exactly what I used to with absolutely 
 no problem:

Scintilla has 3 word wrapping modes, so long lines should not be a problem.
Apr 12 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 12/04/2011 21:08, Nick Sabalausky wrote:
 ""Jérôme M. Berger""<jeberger free.fr>  wrote in message
 news:io2396$1nuo$1 digitalmars.com...
 spir wrote:
 A drawback is one cannot directly have different indent levels, for
 instance to indent collection contents more, or less, than blocks of
 code. This can also be considered an advantage; and is simply solved by
 using... spaces ;-)

 void f () {
   ->  while (true) {
   ->   ->  table = [
   ->   ->  .."aaa" : 1,
   ->   ->  .."bbb" : 2,
   ->   ->  .."ccc" : 3,
   ->   ->  ];
   ->   ->  auto a = this(table);
   ->   ->  if (! a) break;
   ->  }
 }

 (yes, the example is stupid)

example properly: sure they will *display* it fine, but they will not allow you to *enter* it right (especially if you need more spaces for alignment than the tab size).


Why would editors not allow you to enter that right? I don't see what the problem would be, unless you configured your editor to replaces N spaces into a tab for indentation.
 That's unfortunately true. I used to try to do that in cases like this:

 if(blah)
 {
 ->   foo(.bigLongArg1,
 ->   .....bigLongArg2,
 ->   .....bigLongArg3
 ->   );
 }

 But editors just choke on that like crazy. It's a pain to type it in that
 way, and then when you go back to edit (add another arg on another line, for
 instance), it just screws it all up again, likely without me even noticing
 right away. (And I even have most auto-formatting turned off.) I decided it
 was far more trouble than it was worth.

Works fine in Eclipse, again because when it auto-indents on Enter, it uses the indentation of the previous line. :) -- Bruno Medeiros - Software Engineer
Apr 13 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 10:08 PM, Nick Sabalausky wrote:
 ""Jérôme M. Berger""<jeberger free.fr>  wrote in message
 news:io2396$1nuo$1 digitalmars.com...
 spir wrote:
 A drawback is one cannot directly have different indent levels, for
 instance to indent collection contents more, or less, than blocks of
 code. This can also be considered an advantage; and is simply solved by
 using... spaces ;-)

 void f () {
   ->  while (true) {
   ->   ->  table = [
   ->   ->  .."aaa" : 1,
   ->   ->  .."bbb" : 2,
   ->   ->  .."ccc" : 3,
   ->   ->  ];
   ->   ->  auto a = this(table);
   ->   ->  if (! a) break;
   ->  }
 }

 (yes, the example is stupid)

example properly: sure they will *display* it fine, but they will not allow you to *enter* it right (especially if you need more spaces for alignment than the tab size).

That's unfortunately true.

Strange... did not know that, but I have only used geany for a while already. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 2011-04-12 05:19, Jonathan M Davis wrote:
 On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
 They mix tabs and spaces. On some lines, they use spaces and on others
 they use tabs.

Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.

As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings.

How can it not be as easy to use tabs without realizing that someone else used spaces?

Oh, it can be. But what generally happens in environments where spaces are required is that everyone sets up their editors to insert spaces when you hit the tab key instead of a tab (if everyone is using a common IDE, it's probably even required), so it becomes pretty much impossible to enter tabs by accident, whereas in an environment where tabs are used, you're not going to disable the spacebar, so spaces can still be inserted. So, generally, in a spaces-only environment, you don't run into problems with tabs. - Jonathan M Davis
Apr 12 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-06-03 11:01, Andrej Mitrovic wrote:
 I bet you wrote std.datetime with a call to a single Vim macro.
 
 Just kidding. :P

That sort of talk leads to things like this: http://xkcd.com/378/ - Jonathan M Davis
Jun 03 2011
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/06/2011 19:06, Jonathan M Davis wrote:
<snip>
 That sort of talk leads to things like this: http://xkcd.com/378/

I was told that Real Programmers use punch cards. Someone must've found some even realer programmers.... Stewart.
Jun 03 2011