Draw 1280, 1024

ruby-talk
1

20 years ago, the subject line would have drawn me a line across one of my screen's diagonals. Ruby is awesomely more powerful than BBC BASIC, but why no trivial graphics support?

My two requirements are that it should be really easy to draw, and it should be possible to do so interactively (from irb).

I've looked unsuccessfully in the past, but if this is a solved problem then I'd really like to know. Otherwise, does anyone have a suggestion of where to start?

Personally, I'm on a Mac. If there is a solution for my world, that would do for me. Something global would rock though.

Hope you have a lovely weekend,
  Benjohn

2

Benjohn Barnes wrote:

20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?

Because there is no trivial way to make graphics facilities
platform-independent. You may notice that Ruby has native libraries for
graphic interfaces, but these are also not platform-independent. Through
those graphic interfaces, you can make drawings, but you then cannot run
the program anywhere but on the original platform (with some exceptions).

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

Well, "irb" has a special purpose, and being a user interface for a drawing
program isn't the purpose.

I've looked unsuccessfully in the past, but if this is a solved
problem then I'd really like to know. Otherwise, does anyone have a
suggestion of where to start?

Personally, I'm on a Mac. If there is a solution for my world, that
would do for me. Something global would rock though.

Global, there's the rub. I am sure there are libraries on the Mac that allow
graphic interfaces to Ruby programs, but they aren't likely to be portable.

···

--
Paul Lutus
http://www.arachnoid.com

3

If you're willing to try a different language, there's always Logo. In
particular, I like UCBLogo (which, unlike other Logo versions,
implements macros along with the rest of the Lispishness of the
language). It has a very friendly functional syntax, has an excellent
lineup of native graphics procedures (aka "functions), and is the
example language used for an excellent trilogy of computer science books
that are available free, online.

Since this is a bit off-topic for this venue, I'll shut up now, but let
me know if you want more information (links to resources, et cetera).

As for Ruby . . . I don't know of any capabilities such as those you
suggest, and I don't see them arising any time soon. I could be
mistaken, however.

···

On Sat, Sep 09, 2006 at 04:39:04PM +0900, Benjohn Barnes wrote:

20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

I've looked unsuccessfully in the past, but if this is a solved
problem then I'd really like to know. Otherwise, does anyone have a
suggestion of where to start?

Personally, I'm on a Mac. If there is a solution for my world, that
would do for me. Something global would rock though.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

4

You could build something atop Rubygame [ http://rubygame.seul.org/ ]
fairly easily. In fact you could probably write a BBC graphics
emulator, though the cursor-based thing would seem slightly odd in
this day and age :slight_smile: A QBasic graphics emulator otoh might be a
worthwhile effort - IIRC it was pretty well thought-out and simple to
use. Here's a quick example using plain Rubygame:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'rubygame'
=> false
irb(main):003:0> Rubygame.init
=> nil
irb(main):004:0> screen = Rubygame::Screen.set_mode([640, 480])
=> #<Rubygame::Screen:0xb78ebc20>
irb(main):005:0> red = [255, 0, 0]
=> [255, 0, 0]
irb(main):006:0> Rubygame::Draw.line(screen, [0, 0], [639, 479], red)
=> #<Rubygame::Screen:0xb78ebc20>
irb(main):007:0> screen.update
=> #<Rubygame::Screen:0xb78ebc20>

The simplest way would be to have a class that automatically
initialized a screen and held it as an instance variable, and a set of
methods that wrapped the methods in Rubygame::Draw but passed in the
default screen and remembered the last colour that was used in case no
colour was supplied. For example

···

On 9/9/06, Benjohn Barnes <benjohn@fysh.org> wrote:

20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

-------------------------------------------------------------------------------------------
require 'rubygems'
require 'rubygame'

class Sketchpad
  def initialize(x,y)
    @screen = Rubygame::Screen.set_mode([x, y])
    @color = [255, 255, 255] #white
    Thread.new {
      loop {
        @screen.update
        sleep 0.01
      }
    }
  end

  def line(x1, y1, x2, y2, color=@color)
    @color = color
    Rubygame::Draw.line(@screen, [x1, y1], [x2, y2], @color)
    @screen.update
  end
end
-------------------------------------------------------------------------------------------
irb(main):001:0> require 'sketchpad.rb'
=> true
irb(main):002:0> s = Sketchpad.new(640, 480)
=> #<Sketchpad:0xb791b808 @color=[255, 255, 255],
@screen=#<Rubygame::Screen:0xb791b7cc>>
irb(main):003:0> s.line(0, 0, 639, 479)
=> #<Rubygame::Screen:0xb791b7cc>
irb(main):004:0> s.line(0, 479, 639, 0, [0, 0, 255])
=> #<Rubygame::Screen:0xb791b7cc>

martin

5

Benjohn Barnes wrote:

Personally, I'm on a Mac. If there is a solution for my world, that would do for me. Something global would rock though.

The best I can think of in portability is using wxWidgets / FOX / Gtk to draw inside a 2D buffer in a window / GUI widget. OpenGL or SDL to draw full-screen. I don't think it's trivially easy to doodle over someone's GUI though - though OpenGL or SDL might be able to draw on the overlay too. Lookup bindings to those libraries, I'm fairly sure that they're both available, and reasonably cross-platform.

David Vallner

6

Benjohn Barnes wrote:

20 years ago, the subject line would have drawn me a line across one of
my screen's diagonals. Ruby is awesomely more powerful than BBC BASIC,
but why no trivial graphics support?

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

I've looked unsuccessfully in the past, but if this is a solved problem
then I'd really like to know. Otherwise, does anyone have a suggestion
of where to start?

Personally, I'm on a Mac. If there is a solution for my world, that
would do for me. Something global would rock though.

Hope you have a lovely weekend,
    Benjohn

Well ... the closest to "global" that you're likely to get is Ruby/Tk,
which is a port of Perl/Tk. There are some hints about getting started
with it in the Pickaxe book, but you'll end up wanting a good Perl/Tk
book to learn everything that it can do. As far as global is concerned,
it at least runs on Windows, Mac and Linux. I'm sure it works on AIX,
Tru64 and Solaris and can be made to work on HP-UX :).

Another source of inspiration/guidance is to install a full Tcl/Tk
distribution. It's available on all the major Linux distributions and
from ActiveState (www.activestate.com) for Windows. It's probably
available for MacOS if not installed by default. The worst case is that
you need to build it from source.

Inside the Tcl/Tk distribution is a rather nifty collection of demos --
really cool things like drag and drop, sketchpads, etc. The source code
is in the Tcl scripting language, but is easily translated into Perl,
Python or Ruby.

If you're really adventurous, you might try Rails and Ajax. Most of the
common GUI things, including drag and drop, are available in libraries.

Hmmmm ... there's an interesting Ruby quiz/ smallish educational project
... write a translator that converts the Tcl scripts in the Tcl/Tk demo
package to Ruby/Tk.

7

Benjohn Barnes wrote:

20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?

Because there is no trivial way to make graphics facilities
platform-independent. You may notice that Ruby has native libraries for
graphic interfaces, but these are also not platform-independent. Through
those graphic interfaces, you can make drawings, but you then cannot run
the program anywhere but on the original platform (with some exceptions).

It may not be trivial, but it's hardly difficult. There must be dozens of Ruby modules that have varying implementation by platform (sockets, for example)? Ruby itself pulls the feat of quite nicely too. Note that I'm not talking about taking full control of graphics hardware and exploiting all features. It's just really basic drawing support that would be good.

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

Well, "irb" has a special purpose, and being a user interface for a drawing
program isn't the purpose.

I'm not suggesting that irb needs changing. I'm suggesting that the design of the graphics API I'm hoping for should be "irb friendly", which I believe it will be if well designed. Thus, using irb, I should be able to issue a commands and see the result. I shouldn't have to create contexts and windows, program up call backs, cache my drawing commands somewhere ready for a re-paint and string the lot together.

I've looked unsuccessfully in the past, but if this is a solved
problem then I'd really like to know. Otherwise, does anyone have a
suggestion of where to start?

Personally, I'm on a Mac. If there is a solution for my world, that
would do for me. Something global would rock though.

Global, there's the rub. I am sure there are libraries on the Mac that allow
graphic interfaces to Ruby programs, but they aren't likely to be portable.

I've not even found something that merely works on the Mac, yet alone globally!

I apologise if I sound exasperated Paul, and thank you for replying. It's not like I'm asking for a flying car here though: I just want my bicycle back.

···

On 9 Sep 2006, at 09:20, Paul Lutus wrote:

8

Chad
maybe you remember the post where I was discarding D and you kind of made me
think about it twice. This is a good time to come back [ I consider this
group flexible enough not to be bothered by slighly off topic posts but feel
free to tell me if I am wrong ] to you on this point.
I do not regret at all looking at D a second time and it indeed seems a very
nice thing to have in your toolbox!!!.
So why not toss in the links for UCBLogo?
I feel it might be of interest for more folks than just OP and myself.
If you feel differently about it could you reply to me offlist?
Thx in advance

anyway I will google right away on it.

Cheers
Robert

···

On 9/9/06, Chad Perrin <perrin@apotheon.com> wrote:

On Sat, Sep 09, 2006 at 04:39:04PM +0900, Benjohn Barnes wrote:
> 20 years ago, the subject line would have drawn me a line across one
> of my screen's diagonals. Ruby is awesomely more powerful than BBC
> BASIC, but why no trivial graphics support?
>
> My two requirements are that it should be really easy to draw, and it
> should be possible to do so interactively (from irb).
>
> I've looked unsuccessfully in the past, but if this is a solved
> problem then I'd really like to know. Otherwise, does anyone have a
> suggestion of where to start?
>
> Personally, I'm on a Mac. If there is a solution for my world, that
> would do for me. Something global would rock though.

If you're willing to try a different language, there's always Logo. In
particular, I like UCBLogo (which, unlike other Logo versions,
implements macros along with the rest of the Lispishness of the
language). It has a very friendly functional syntax, has an excellent
lineup of native graphics procedures (aka "functions), and is the
example language used for an excellent trilogy of computer science books
that are available free, online.

Since this is a bit off-topic for this venue, I'll shut up now, but let
me know if you want more information (links to resources, et cetera).

As for Ruby . . . I don't know of any capabilities such as those you
suggest, and I don't see them arising any time soon. I could be
mistaken, however.

--

CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

9

Benjohn Barnes wrote:
> Personally, I'm on a Mac. If there is a solution for my world, that
> would do for me. Something global would rock though.

The best I can think of in portability is using wxWidgets / FOX / Gtk to
draw inside a 2D buffer in a window / GUI widget.

I think all the GUI toolkits insist on running their own mainloop,
which plays badly with IRB

OpenGL or SDL to draw full-screen.

You can run OpenGL or SDL inside their own windows. I think this is
the way to go.

I don't think it's trivially easy to doodle over someone's
GUI though - though OpenGL or SDL might be able to draw on the overlay
too. Lookup bindings to those libraries, I'm fairly sure that they're
both available, and reasonably cross-platform.

Doodling over a GUI is of limited use anyway. Simply having a canvas
you can interactively draw on from IRB is a neat thing. It was one of
the features I'd planned for FXIrb, but I don't have the time to
maintain that these days :frowning:

martin

···

On 9/9/06, David Vallner <david@vallner.net> wrote:

10

Thanks very much for all of the posts - I'll read them all on the bus in a moment!

Cheers,
  Benjohn

11

On 9 Sep 2006, at 19:12, M. Edward (Ed) Borasky wrote about tcl/tk

Thanks for this pointer - I'll have a look at tcl/tc too, although it seemed like a lot to get a little thing done last time I had a play. I think it is part of OS X by default.

Cheers,
  Benj

12

*snip*

If you're willing to try a different language, there's always Logo. In
particular, I like UCBLogo (which, unlike other Logo versions,
implements macros along with the rest of the Lispishness of the
language). It has a very friendly functional syntax, has an excellent
lineup of native graphics procedures (aka "functions), and is the
example language used for an excellent trilogy of computer science books
that are available free, online.

*snip*

I'll definitely give this a look. Logo was my first language, and I had a lot of fun with it. It would be nice to see what I can do with it these days.

Cheers,
  Benj

···

On 9 Sep 2006, at 10:16, Chad Perrin wrote:

13

There's no getting around the "have to create contexts and windows"
part - base ruby has absolutely no built-in idea of a graphics
context. However, you can do this automatically as follows: to the
bottom of sketchpad.rb add

@sketchpad = Sketchpad.new(640, 480)

def line(*args)
  @sketchpad.line(*args)
end

(that is, outside the class definition)

now 'require sketchpad.rb' will execute the lines, create a @sketchpad
object accessible from within irb, and let you call line as a function
straight from the prompt. As a final touch, you can automatically
require sketchpad.rb from your irbrc.

Look also at the Delegator and Forwardable modules for some ways of
automating the method wrapping.

martin

···

On 9/9/06, Benjohn Barnes <benjohn@fysh.org> wrote:

I'm not suggesting that irb needs changing. I'm suggesting that the
design of the graphics API I'm hoping for should be "irb friendly",
which I believe it will be if well designed. Thus, using irb, I
should be able to issue a commands and see the result. I shouldn't
have to create contexts and windows, program up call backs, cache my
drawing commands somewhere ready for a re-paint and string the lot
together.

14

Good point(s). I'll post links here, at least:

central UCBLogo resources page:
  http://www.cs.berkeley.edu/~bh/logo.html

Computer Science Logo Style
Volume 1: Symbolic Computing
  http://www.cs.berkeley.edu/~bh/v1-toc2.html

Computer Science Logo Style
Volume 2: Advanced Techniques
  http://www.cs.berkeley.edu/~bh/v2-toc2.html

Computer Science Logo Style
Volume 3: Beyond Programming
  http://www.cs.berkeley.edu/~bh/v3-toc2.html

At least some Linux distributions (Debian included) provide UCBLogo
packages in their software archives. I was delighted to find that I
could install UCBLogo on my Debian systems by typing "apt-get install
ucblogo" (without the quotes) into a root shell. Quite convenient.

Logo has been called the "Lisp without parentheses", and that's pretty
much what it is. Most implementations have been somewhat neutered in
the creators' zeal for producing a language implementation that is
friendly to young students, but UCBLogo is not of that ilk -- it goes so
far as to include support for Lisp macros (though I haven't personally
explored their use enough to be able to make a determination about how
well they're supported, the syntax and use seems quite similar to that
of ANSI Common Lisp).

It's an open source distribution of Logo created by a Berkeley
professor, Bryan Harvey, who is also the author of the above-mentioned
university computer science textbooks that make use of UCBLogo as the
example language. I've found the books to be well-written (so far -- I
have been often and thoroughly distracted by the demands of other
languages in my life, alas), and the language absurdly easy to learn.
It has been the single biggest factor in my growing appreciation for
arithmetic prefix notation, and functional syntax in general, so far.

Suddenly, I'm considering creating a mailing list . . . damn. Like I
don't have enough on my plate already.

···

On Sat, Sep 09, 2006 at 06:46:51PM +0900, Robert Dober wrote:

Chad
maybe you remember the post where I was discarding D and you kind of made me
think about it twice. This is a good time to come back [ I consider this
group flexible enough not to be bothered by slighly off topic posts but feel
free to tell me if I am wrong ] to you on this point.
I do not regret at all looking at D a second time and it indeed seems a very
nice thing to have in your toolbox!!!.
So why not toss in the links for UCBLogo?
I feel it might be of interest for more folks than just OP and myself.
If you feel differently about it could you reply to me offlist?
Thx in advance

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham

15

Martin DeMello wrote:

I think all the GUI toolkits insist on running their own mainloop,
which plays badly with IRB

Spawn off inna thread, then jump through event posting hoops?

Just ranting, SDL would be prolly both easier to get to work and with a richer API for drawing.

16

Benjohn Barnes wrote:

Benjohn Barnes wrote:

20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?

Because there is no trivial way to make graphics facilities
platform-independent. You may notice that Ruby has native libraries
for
graphic interfaces, but these are also not platform-independent.
Through
those graphic interfaces, you can make drawings, but you then
cannot run
the program anywhere but on the original platform (with some
exceptions).

It may not be trivial, but it's hardly difficult. There must be
dozens of Ruby modules that have varying implementation by platform
(sockets, for example)?

Yes, but sockets don't compare well with a graphic interface. Sockets talk
to the network, which all environments want to do in the same way. Graphic
interfaces talk to the hardware and the OS, which have less in common with
each other than sockets do.

Ruby itself pulls the feat of quite nicely
too. Note that I'm not talking about taking full control of graphics
hardware and exploiting all features. It's just really basic drawing
support that would be good.

And it exists, and you can easily write a drawing program, but it won't be
particularly platform-portable.

My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).

Well, "irb" has a special purpose, and being a user interface for a
drawing
program isn't the purpose.

I'm not suggesting that irb needs changing. I'm suggesting that the
design of the graphics API I'm hoping for should be "irb friendly",
which I believe it will be if well designed.

I gather that you want is user friendliness, and you have hit upon irb's
friendliness as an example for immediacy of results. You appear to want
your user to be able to enter instructions interactively and see the
results drawn. For this, "eval" would do nicely, better than irb, because
the latter has a rather specialized purpose. But this doesn't address the
more important issue of graphic interface.

Thus, using irb, I
should be able to issue a commands and see the result. I shouldn't
have to create contexts and windows, program up call backs, cache my
drawing commands somewhere ready for a re-paint and string the lot
together.

But yes, you would have to do that, at least once. You would have to so that
because, apart from Logo, there are few ready-built graphic facilities such
as you are describing. You would have to write the program, then you would
have to integrate a graphic interface. And in the worst case, you would
have to perform the second step for each platform of interest.

I've not even found something that merely works on the Mac, yet alone
globally!

This addresses the state of the art. A suitable "bicycle" analog is Ruby as
we find it today, which is quite remarkable in and of itself. But from my
perspective as a computer programmer in 2006, you are actually asking for a
Porsche.

I apologise if I sound exasperated Paul, and thank you for replying.
It's not like I'm asking for a flying car here though: I just want my
bicycle back.

This is why computer programming hasn't withered away as a profession, even
though some might argue that it should.

···

On 9 Sep 2006, at 09:20, Paul Lutus wrote:

--
Paul Lutus
http://www.arachnoid.com

17

Martin DeMello wrote:

Benjohn Barnes wrote:
> Personally, I'm on a Mac. If there is a solution for my world, that
> would do for me. Something global would rock though.

The best I can think of in portability is using wxWidgets / FOX / Gtk to
draw inside a 2D buffer in a window / GUI widget.

I think all the GUI toolkits insist on running their own mainloop,
which plays badly with IRB

But (IMHO) you shouldn't be using irb anyway. You should be using a user
entry event loop that evaluates the user's entries with "eval".

/ ...

Doodling over a GUI is of limited use anyway. Simply having a canvas
you can interactively draw on from IRB is a neat thing. It was one of
the features I'd planned for FXIrb, but I don't have the time to
maintain that these days :frowning:

I am at a loss to understand why you think irb is essential to your plan.
There are much better solutions for talking to the user.

···

On 9/9/06, David Vallner <david@vallner.net> wrote:

--
Paul Lutus
http://www.arachnoid.com

18

"Martin DeMello" <martindemello@gmail.com> writes:

Benjohn Barnes wrote:
> Personally, I'm on a Mac. If there is a solution for my world, that
> would do for me. Something global would rock though.

The best I can think of in portability is using wxWidgets / FOX / Gtk to
draw inside a 2D buffer in a window / GUI widget.

I think all the GUI toolkits insist on running their own mainloop,
which plays badly with IRB

OpenGL or SDL to draw full-screen.

You can run OpenGL or SDL inside their own windows. I think this is
the way to go.

rcairo works without a main loop if you only are interested in
drawing. (I.e. you'll see inactive windows.)

However, the source for the X11 and Quartz canvas are unreleased and
only on my disk.

And the drawing API needs a nice and easy wrapper, of course.

···

On 9/9/06, David Vallner <david@vallner.net> wrote:

martin

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

19

David Vallner wrote:

Martin DeMello wrote:

I think all the GUI toolkits insist on running their own mainloop,
which plays badly with IRB

Spawn off inna thread, then jump through event posting hoops?

Not in Ruby, unfortunately. Ruby's threads implementation doesn't work. I
have lately torn out my hair trying to get Ruby threads to play nice with
the main event loop in GUI-based applications.

···

--
Paul Lutus
http://www.arachnoid.com

20

Because IRB has already solved the general problem of a good, robust
REPL. Why should drawing to a canvas be treated as a separate problem?
Ideally it should just be another set of things you can do from the
ruby REPL.

martin

···

On 9/9/06, Paul Lutus <nospam@nosite.zzz> wrote:

Martin DeMello wrote:

But (IMHO) you shouldn't be using irb anyway. You should be using a user
entry event loop that evaluates the user's entries with "eval".

> Doodling over a GUI is of limited use anyway. Simply having a canvas
> you can interactively draw on from IRB is a neat thing. It was one of
> the features I'd planned for FXIrb, but I don't have the time to
> maintain that these days :frowning:

I am at a loss to understand why you think irb is essential to your plan.
There are much better solutions for talking to the user.