ruby wish-list

[Robert Klemme]

All right ruby-genie. My next wish!
That 1.9 had an option that represents a cross between thread models 2
and 3[1] [i.e. sometimes threads could run simultaneous, a la].

guaranteed_thread_safe do
# thread multi threaded code
end

Though I suppose this is accomplishable using some C code, currently.

http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html

http://www.ruby-doc.org/stdlib/libdoc/monitor/rdoc/index.html
http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/index.html

My next wish: yeah, you guessed right.

robert

 

[Roger Pack]

Back to the wishing well...
I wish there were some elegant way to do .=
a = a.method
as a cleaner syntax. Only problem being I can't even think of an
elegant syntax for that.


Oh, and a gripe:

array.map &:id

I think this syntax is good, but slightly confusing. I know what it
does, but wish it were deprecated for ugliness, and ruby would
automatically call .to_proc on parameters, or something better than what
it does now. Of course, that's just me, and I can't think of an elegant
syntax for it
-R

 

[Marc Heiler]

I have a big wish

Since 1.9 will be/is quite different, I want docu docu docu. And
examples. And more examples. And more docu. And ...

 

[Dave Bass]

I really wish I was forced to declare all my variables.

This could be an option (like Perl's "use strict") so people wouldn't
have to declare things if they don't want to.

Dave

 

[Roger Pack]

I have a big wish

Since 1.9 will be/is quite different, I want docu docu docu. And
examples. And more examples. And more docu. And ...

+1 on wishing for tons of documentation and examples.

 

[Roger Pack]

why do you wish for that?
I did have the wish that instance variables couldn't be used before
being assigned [ugh], but it's less code to write the way it currently
is, so I'm ok with it. I guess there's always defined?(var_name), too.

Dave Bass

 

[Tim Hunter]

+1 on wishing for tons of documentation and examples.

My mother used to say "Wish in one hand and spit in the other. See which
one fills up first."

There is a way to ensure that what you wish for happens.

 

[Dave Bass]

I really wish I was forced to declare all my variables.

why do you wish for that?

declare x1 = 0
declare x, y, z = x1 + 2

xl = z * y + x

=> Error: variable xl undeclared.
(Perhaps you mean x or x1?)

 

[Mark Wilden]

declare x1 = 0
declare x, y, z = x1 + 2

xl = z * y + x

=> Error: variable xl undeclared.
(Perhaps you mean x or x1?)

This will be caught the first time you try to read x1.

(To say nothing of your numerous unit tests, right?

///ark

 

[Roger Pack]

latest wish:
gem install package_name --checkout_latest_svn_trunk_and_build_it
or is this possible?
Thanks!
-R

 

[Suraj Kurapati]

gem install package_name --checkout_latest_svn_trunk_and_build_it

Not everyone uses Subversion.

One way to achieve your request would be for you to manually check out
the sources of your favorite project from their code repository and run
the "gem" task in their Rakefile (most projects do). This will build a
gem which you can then install.

 

[David Masover]

Not everyone uses Subversion.

No reason it has to be SCM-specific.

 

[Suraj Kurapati]

No reason it has to be SCM-specific.

From my understanding of the problem, implementing this kind of feature
would require gem creators to supply some kind of resource identifier in
the gem's meta-data.

Let us assume that the aforementioned resource identifier is an
SCM-dependent URL to a project's code repository. RubyGems would then
be responsible for (1) checking out the latest copy of the code
repository, (2) constructing a gem out of it, and (2) installing the
constructed gem.

In contrast, if we were to make this feature fully SCM-independent, then
the aforementioned resource identifier would need to be something like a
URL to a ZIP file that contains the latest code for a particular
project. RubyGems would then be responsible for (1) fetching the ZIP
file, (2) constructing a gem out of it, and (2) installing the
constructed gem.

All that's needed then is to have some automated process that publishes
a ZIP file of a project's code repository whenever someone commits new
changes to the repository. This would obviously be SCM-specific.

 

[David Masover]

From my understanding of the problem, implementing this kind of feature
would require gem creators to supply some kind of resource identifier in
the gem's meta-data.

Let us assume that the aforementioned resource identifier is an
SCM-dependent URL to a project's code repository. RubyGems would then
be responsible for (1) checking out the latest copy of the code
repository, (2) constructing a gem out of it, and (2) installing the
constructed gem.

Make RubyGems pluggable, in some sense, if it isn't already.

Simplest possible implementation that I can think of: Create a mostly static
gem which depends on (or includes) everything required to interact with the
SCM, and to run whatever is needed to build the gem file. After which, it
replaces itself with the built gem (which, in turn, builds native extensions,
etc etc).

I don't know enough about RubyGems to know if this can be made entirely
automatic, or if it'd end up being something stupid like:

sudo gem install foo-svn
sudo foo-svn bootstrap
(bootstrap script will automatically run 'gem uninstall foo-svn' on successful
installation of /var/some/where/foo.gem)

However, every system-level package manager I've worked with (dpkg, etc) has
support for running arbitrary scripts at various points along the
installation. For example, I can install Ubuntu's "msttcorefonts" package,
which, due to licensing strangeness, will actually download and unpack a
bunch of EXEs as part of the install.

I should probably go read more about RubyGems, though.

In contrast, if we were to make this feature fully SCM-independent, then
the aforementioned resource identifier would need to be something like a
URL to a ZIP file that contains the latest code for a particular
project. RubyGems would then be responsible for (1) fetching the ZIP
file, (2) constructing a gem out of it, and (2) installing the
constructed gem.

I don't like that, because then you're downloading the entire project every
time, and you're not getting project metadata. It would be nice to be able to
have, say, /var/lib/gems/checkouts/foo, with which to develop the occasional
patch against foo.

 

[Roger Pack]

Seems like minimalistically you'd need
scm_type = :git
scm_url = git://whatever # or something less scm dependent
scm_build_command = 'cd subdir; rake build;'
scm_output_gem = 'subdir/built.gem'

Just my $0.02
-R

 

[Roger Pack]

my latest wish
File.write 'filename', contents

 

[Roger Pack]

my latest wish
File.write 'filename', contents

Doh that one's in facets already

Question does this exist already?

Some central 'rubydoc' index that has links to the docs for installed
gems and/or the core docs? Like an updated index of docs? If that
existed I'd be tempted to actually use the rdocs instead of not even
knowing where they install to, with the current gem stuff [it's painful
to go after rdocs that are buried X folders deep].
Twould be swell if rubygems automatically updated the doc index. Or
does it exist?
-R

 

[Roger Pack]

If I wanted something "intuitive",

/*
I'd probably prefer something like this,
*/

since that's what I'm used to for multiline comments. On the other
hand,

=begin
this seems a lot more Ruby-idiomatic to me,
=end

so I like it just fine.

Yeah /* comments */ would be sweet. Then you could also have 'inline'
comments, like
a = [8..9 /* bread id's */, 900..990 /* butter id's */]

Which would be awesome in some instances. Obviously these are poor
examples, but with some it would be nice.
-R

 

[David Palacio]

If I wanted something "intuitive",

/*
I'd probably prefer something like this,
*/

since that's what I'm used to for multiline comments. On the other
hand,

=begin
this seems a lot more Ruby-idiomatic to me,
=end

so I like it just fine.

Yeah /* comments */ would be sweet. Then you could also have 'inline'
comments, like
a = [8..9 /* bread id's */, 900..990 /* butter id's */]

Which would be awesome in some instances. Obviously these are poor
examples, but with some it would be nice.
-R

a = [ 8..9, #ids pan
900..990 ] #ids mantequilla

 

[Roger Pack]

a = [ 8..9, #ids pan

900..990 ] #ids mantequilla

That would work, but forces you to insert line breaks per comment, which
is livable, but exactly the reason for my wish
-R