Just checking, are you aware of "rinda" in Ruby's standard library?
James Edward Gray II
···
On Jan 16, 2005, at 10:15 AM, Glenn Parker wrote:
My personal favorite is "Linda" from David Gelernter.
How to Write Parallel Programs
Hi,
···
On 16.1.2005, at 16:46, gabriele renzi wrote:
Jim Menard ha scritto:
On Jan 15, 2005, at 7:23 PM, trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?Two very different things: a truly cross-platform GUI and IO's concurrency.
talking about Io and crossp'latform.. a student from robert feldt made a thesis about a ruby+opengl gui toolkit inspired from Io's one and Squeak's one. It would be a long way behind wx or tk, anyway
Interesting, is this anywhere to be found? Since, I need to write a GUI toolkit this year. Going the way of everything in OpenGL, naked objects+theme stylesheet+layout stylesheet, distributed with DRb-centric middleware, programmable, make it work, make it right, make it fast.
-Ilmari
Two very different things: a truly cross-platform GUI and IO's
concurrency.I honestly believe a "truly cross-platform GUI" to be one of the
secrets to world domination.+1
and one more +1
(But only if it has a Ruby API and not a mere reflection of the C API
that the toolkit has itself. The way I drowned in a gtk tree in Ruby does
not contribute to world domination.)
That's not to say Tk isn't portable. It was even native look'n'feel on
windows when I peeked there (contrary to the ugly *nix stuff).
Hopefully I can leave http://arena.game-server.cc/ running without paying
much attention soon (it's ruby from the ground up) and continue working
on http://rvv.rubyforge.org/ so that might trick me into working on Wise
again. maybe. don't count on it.
+--- Kero ----------------------- kero@chello@nl ---+
all the meaningless and empty words I spoke |
Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+
> Real OS-based threading.
I have used Ruby threading quite a bit and I must say I have _no_ desire
for this feature.In fact I hate the very notion.
[...]
The trouble is C threading just has so many ways it which it can go wrong
it really frightens me.Ruby would simply loose it's rock solid stability if they did OS level
multi-threading.
I more-or-less agree with John here -- I found Java's threading model
to be the first threading model that I actually understood, and I
think that Ruby's threading model is better even than that. However, I
would say that this:
Make Ruby Place Nice with OS Threading.
is what we really need.
Right now, Ruby can't be safely used with multithreaded applications
or libraries; that should change if at all possible. This probably
means that we need OS-level threading, but I'd love to keep Ruby's
green threads as it's all that I've ever needed.
-austin
···
On Mon, 17 Jan 2005 06:20:02 +0900, John Carter <john.carter@tait.co.nz> wrote:
On Sun, 16 Jan 2005, Glenn Parker wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
I will strongly agree with this one.
A truly "Ruby Way" GUI framework would be a pleasure.
But for heavens sake don't copy Swing.
The Java table gadget is many thousands of lines of Java and still sucks.
The Java layout tools are just plain freakily horrible.
Elegant simplicity is what is required.
Ps: You can do a lot worse than just embedding Gecko Mozilla's layout engine.
That would fit supremely elegantly with the Ruby Way.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
"The notes I handle no better than many pianists. But the pauses
between the notes -
ah, that is where the art resides!' - Artur Schnabel
···
On Mon, 17 Jan 2005, James Edward Gray II wrote:
On Jan 16, 2005, at 7:20 AM, Jim Menard wrote:
Two very different things: a truly cross-platform GUI
I honestly believe a "truly cross-platform GUI" to be one of the secrets to world domination.
John Carter wrote:
Almost always threading is a fast and filthy fix on something that can be done better as multiprocesses. It is a kludge resulting from early MS-Windows not having a fast implementation of "fork()"
I strongly disagree, but I've met enough folks that run screaming from threads that I'm not surprised by your concern. I certainly won't waste my breath trying to convince anybody that threading is more than a "kludge" or a "fast and filthy fix". Threading has its place in almost any programmer's toolkit.
Austin Ziegler wrote:
>
> Right now, Ruby can't be safely used with multithreaded applications
> or libraries; that should change if at all possible. This probably
> means that we need OS-level threading, but I'd love to keep Ruby's
> green threads as it's all that I've ever needed.
If Ruby is not thread-safe, that's just an annoying bug, not a missing feature. Making Ruby thread-safe is almost certainly simpler than implementing OS-level threading, but it would be a good first step.
···
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
In fact, the present rdoc syntax would suffice. Just integrate rdoc with
ruby, as follows: depending on a commandline option and/or an
environment variable and/or requiring some stuff, the interpreter either
treats the rdoc stuff just as it does now (so in this case no memory
burden), or parses and attaches them as instance variables to
Modules/Classes/(Unbound)methods (and we would have the appropriate
accessor interface to query these variables).
The default would be running with docs turned off, so if you don't use
ruby interactively or for some other reason you don't like the idea, you
just could ignore the whole issue and you'd feel no change.
Csaba
···
On 2005-01-16, Austin Ziegler <halostatue@gmail.com> wrote:
On Sun, 16 Jan 2005 18:21:08 +0900, Csaba Henk ><csaba@phony_for_avoiding_spam.org> wrote:
(With appropriate docsstring syntax, the interpreter could either regard
them as comments or attach them as variables to the corresponding class
or method [depending on options], so the "memory burden" argument is not
valid.)No, "memory burden" is quite valid. Come up with a clean way for Ruby
to have docstrings, but yet easily allow someone to dump them if
necessary. I find I rarely use Ruby for serious work interactively
(e.g., I do so when verifying stuff). In this case, I feel that it's
probably better that we have the ri/irb integrations that are ongoing
than docstrings.
+84
···
On Mon, 17 Jan 2005 01:22:26 +0900, James Edward Gray II <james@grayproductions.net> wrote:
On Jan 16, 2005, at 7:20 AM, Jim Menard wrote:
> Two very different things: a truly cross-platform GUI and IO's
> concurrency.I honestly believe a "truly cross-platform GUI" to be one of the
secrets to world domination.+1
James Edward Gray II
--
$stdout.sync = true
"Just another Ruby hacker.".each_byte do |b|
('a'..'z').step do|c|print c+"\b";sleep 0.007 end;print b.chr
end; print "\n"
Yes, but you take a huge performance hit, which is why I'd like to see a
fast 'native' way to do them.
martin
···
gabriele renzi <rff_rff@remove-yahoo.it> wrote:
Martin DeMello ha scritto:
>
> C-core lazy generators (or Icon's 'suspend', though I'm not sure how
> well that will play with the rest of ruby).aren't this a kind of coroutine? Can't you build them with callcc easily?
I vote against for the same reason as shell PATH values.
···
On Jan 17, 2005, at 8:31 AM, Daniel Berger wrote:
Oh, I also forgot to add that I would like 'require' to check its
current directory first, so I can stop doing "$:.unshift Dir.pwd".
So then, why open-uri, you have curl, don't you?
Things work better when they are integrated, and there is no need to
serialize and de-serialize all the time.
If you just want to dump out the basic documentation, ri is good enough.
But consider the following behaviour of ri: if you do "ri aClass", it
shows you a summary of the purpose of the class, and the list of the
class/instance methods, nothing more. If you do "ri aClass#some_method",
it shows you the description of that specific method.
That ri does so hardcoded. What if you want to see the description of
the class and all of the class/instance methods together? You can hack
such an option on ri if it's not there yet, but it's a rigid model
anyway. The user should be able to display/process docs in a customised
way with the well-known feeling of easiness ruby gives you in general.
With docstrings, it would be a one-liner to dump out all the stuff about
the class and it's methods. You could easily search the docs as well in
a very high-level fashion.
You could interact with docs in a programmable way.
* * *
And there were no problems about docs not being installed. Eg., I check
out a new package foo. I don't want install it as I don't know whether I
like it or not. I just do
"tar xvzf foo.tar.gz && cd foo && irb -r ./foo.rb"
What an ease it were if I could access the docs right then from irb!
I thought ruby's philosophy is "everything is an object, unless there is
a good reason for the opposite". Docs should be objectified as well.
Csaba
···
On 2005-01-16, Sam Roberts <sroberts@uniserve.com> wrote:
irb can be extended to support ri, why isn't this better than
docstrings?
Me too!
It's on their "todo" list:
• a Mac OS X driver
http://www.tecgraf.puc-rio.br/iup/en/to_do.html
In the meantime, there is always X11:
Cheers
···
On Jan 16, 2005, at 15:39, Jim Menard wrote:
Hmm...Windows and Motif. I'm looking for OS X support as well, personally.
James Edward Gray II wrote:
Just checking, are you aware of "rinda" in Ruby's standard library?
No, I hadn't really looked for it yet, but I'm not surprised to hear that somebody beat me to it, in a way. Now, what I really want is a fast Linda tuple-space model running within a single process, not a "distributed" system.
As an aside, I wonder why doesn't rubycentral.com have a site-wide search option on the home page? It seems to me that "The Source for Ruby" is rather obtuse.
···
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
I'm more a fan of make it right, make it work, make it fast.
···
On Jan 16, 2005, at 8:30 AM, Ilmari Heikkinen wrote:
Interesting, is this anywhere to be found? Since, I need to write a GUI toolkit this year. Going the way of everything in OpenGL, naked objects+theme stylesheet+layout stylesheet, distributed with DRb-centric middleware, programmable, make it work, make it right, make it fast.
Austin Ziegler ha scritto:
Right now, Ruby can't be safely used with multithreaded applications
or libraries; that should change if at all possible. This probably
means that we need OS-level threading, but I'd love to keep Ruby's
green threads as it's all that I've ever needed.
well, but at least it would be nice if they would'nt block everything when working on files on windows 
I can think of at least one good us for the current @@ variables -
subclassable GUI components that inherit hierarchy-shared look-and-feel
properties from the parent class. What would be the elegant way to do
this if @@ variables go per-class?
martin
···
David A. Black <dblack@wobblini.net> wrote:
You're right -- I meant to clarify that I'm talking about 2.0 class
vars, which as I understand it will be truly per-class and will differ
from instance variables of Class objects principally in that they will
be in scope in instance methods. I would rather not have a separate
construct that overlaps so much with instance variables.
Thanks. I think this is kind of funny in that I just spoke of REM and was
obliged 
There some good in such a thing --an app could use this as part of a help
system.
T.
···
On Sunday 16 January 2005 09:16 am, gabriele renzi wrote:
trans. (T. Onoma) ha scritto:
> Could you briefly explain what are Docstrings?strings attached to a function/method/object in python world, i.e.
def foo(a,b):
"""this method sums a and b.
stuff in triple quotes is almosty like here documents"""
return a+bYou can access them via reflection (they're the __doc__ attribute).
I generally agree with you. I wonder if @@vars could just become somesort of
across the board initializer/accessor for instance vars (ie. @vars).
class C
@@a = 10
def a; @a; end
end
C.new.a #=> 10
Just exploring out loud here.
T.
···
On Sunday 16 January 2005 09:09 am, David A. Black wrote:
Hi --
On Sun, 16 Jan 2005, trans. (T. Onoma) wrote:
> On Sunday 16 January 2005 07:35 am, David A. Black wrote:
> > Hi --
> >
> > On Sun, 16 Jan 2005, trans. (T. Onoma) wrote:
> > > I'm taking a little poll.
> > >
> > > Let say you're Matz, but without any of the pressures of keeping up
> > > with a previous version of Ruby. What one thing above all others
> > > would you like to see differ about Ruby?
> >
> > I would be happy to see class variables (@@var) disappear. But I
> > don't like the idea of class_attr_reader and things like that. Just
> > use the existing attr_* methods, which Class objects already have just
> > as much access to as other objects. If a Class object needs its own
> > state, let it keep its own state. If it wants other objects to have
> > access to it, let it give them access.
>
> But @@vars cut upwardly across the class hierarchy, which is a bit
> different. Is that right? Please correct me if I'm wrong.You're right -- I meant to clarify that I'm talking about 2.0 class
vars, which as I understand it will be truly per-class and will differ
from instance variables of Class objects principally in that they will
be in scope in instance methods. I would rather not have a separate
construct that overlaps so much with instance variables.As for the current way class variables work... I'm not convinced that
would be a big loss either. I've seen class variables arise as a
source of confusion over and over again -- and while I don't mind
there being things that have to be explained and that take a bit of
study to grasp, the weight of experience suggests to me that there's
room for refinement in this area. My chosen method of refinement
would be to eliminate them
a binding system that would allow ipc of
sorts between controller ruby thread and
threads interacting with service threads
from 3rd api's would rock.
but in the main, i'd much prefer the work
of abstractions of IO/select/poll/epoll to
handle concurrency in a much more efficient
way. i'm not very fond of threading, however
some external libraries are, and the above
controller/service-thread ipc mechanic
would solve that.
Alex
···
On Jan 16, 2005, at 10:27 PM, Austin Ziegler wrote:
I more-or-less agree with John here -- I found Java's threading model
to be the first threading model that I actually understood, and I
think that Ruby's threading model is better even than that. However, I
would say that this:Make Ruby Place Nice with OS Threading.
is what we really need.
It's my opinion that a real OS X GUI needs to be Aqua based. X11 is a poor substitute (in OS X land), I think.
James Edward Gray II
···
On Jan 16, 2005, at 9:01 AM, PA wrote:
In the meantime, there is always X11: