Ruby wish-list


#121

2008/4/21, Roger P. removed_email_address@domain.invalid:

from (irb):3
irb(main):001:0> def a(x)end
=> nil
irb(main):002:0> a(:b=>true)
=> nil
irb(main):003:0>

I have no idea why it doesn’t consider a hash a parameter.

Precedence.

Cheers

robert


#122

On Mon, Apr 21, 2008 at 9:23 AM, Roger P.
removed_email_address@domain.invalid wrote:

Cheers.

def a(hash)
hash
end
=> nil

a :a => false, :b =>true
=> {:a=>false, :b=>true}


#123

I have no idea why it doesn’t consider a hash a parameter.

Precedence.
Yeah for some reason it is considering my function a block a higher
predencdence than a hash parameter.
So my next wish would be:
That ruby-core would allow us to make suggestions for how to better
their error messages :slight_smile:
And also [sigh] that hashes and blocks used a different syntax, or that
the ambiguity noted could be overcome.
Cheers.
-R


#124

Robert K. wrote:

2008/4/21, Roger P. removed_email_address@domain.invalid:

from (irb):3
irb(main):001:0> def a(x)end
=> nil
irb(main):002:0> a(:b=>true)
Wow. Rock on. Now that you’ve pointed out this syntax I find it
addictive and use it a lot.

My next wish:
that
string =~ ‘abc’

would work. It’s not a regex, but I would imagine it makes sense to
auto-convert it :slight_smile:
At least I’d use it.
-R


#125

2008/4/21, Roger P. removed_email_address@domain.invalid:

I have no idea why it doesn’t consider a hash a parameter.

Precedence.

Yeah for some reason

That “some reason” is probably the language’s syntax definition.

it is considering my function a block a higher
predencdence than a hash parameter.
So my next wish would be:
That ruby-core would allow us to make suggestions for how to better
their error messages :slight_smile:

I have never heard someone was turned down who made a reasonable
suggestion.

And also [sigh] that hashes and blocks used a different syntax, or that

Not going to happen. Just think of the mess that would do to existing
code.

the ambiguity noted could be overcome.

Is it just me or does this issue come up rarely? My impression is
that people stumble over it at most once and never again. This does
not feel like a big deal - certainly was never for me. But of course
YMMV.

Cheers

robert


#126

On 12.05.2008 08:58, Roger P. wrote:

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


#127

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 :wink:
-R


#128

I have a big wish :slight_smile:

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


#129

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


#130

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.
Thanks genie!
-R
:slight_smile:

[1] http://www.atdot.net/yarv/rc2006_sasada_yarv_on_rails.pdf


#131

Marc H. wrote:

I have a big wish :slight_smile:

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

+1 on wishing for tons of documentation and examples.


#132

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

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


#133

Roger P. wrote:

Marc H. wrote:

I have a big wish :slight_smile:

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

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


#134

On May 27, 2008, at 3:08 AM, Dave B. wrote:

(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? :slight_smile:

///ark


#135

I really wish I was forced to declare all my variables.
Roger P. wrote:
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?)


#136

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


#137

On Wednesday 28 May 2008 20:51:15 Suraj K. wrote:

Roger P. wrote:

gem install package_name --checkout_latest_svn_trunk_and_build_it

Not everyone uses Subversion. :slight_smile:

No reason it has to be SCM-specific.


#138

David M. wrote:

On Wednesday 28 May 2008 20:51:15 Suraj K. wrote:

Roger P. wrote:

gem install package_name --checkout_latest_svn_trunk_and_build_it

Not everyone uses Subversion. :slight_smile:

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.


#139

Roger P. wrote:

gem install package_name --checkout_latest_svn_trunk_and_build_it

Not everyone uses Subversion. :slight_smile:

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.


#140

On Thursday 29 May 2008 01:26:08 Suraj K. wrote:

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.