stdlib/range issue

[Pablo Fernandez]

Dear stdlib'ers...

I have just discovered the wonders of the parser functions, and got
impressed with the tens of functions that come with stdlib. First things
first... good work!!! Thanks!!

And now the issue. It seems like the writer of the range() function did
not think about ranges with more than one digit that need leading zeros
in the first items, like "01..99", when you usually want to have 01, 02,
and so on. Ruby allows you to do ("01".."99") and that will do the right
thing, but the range() function provided with stdlib does some type
conversion (detects if it's a number, and changes the type to integer)
which converts "01" to 1 breaking this possibility. I tried to submit a
bug report, but I just can list the open ones, can't make one myself. Is
this intentional? How do I properly address this request?

So, I tried to change that myself, but no matter what I do to the
range.rb file, the changes are not picked up by the node. Do I have to
do something to force a reload of the file? This runs in the server, right?

What I did then was to create a range_custom() which is a copy of the
former, but without the type conversion. I tried that and it works like
a charm.

Thanks!
Pablo

[Gary Larizza]

On Thu, Mar 29, 2012 at 8:48 AM, Pablo Fernandez <pablo.f...@cscs.ch> wrote:

Dear stdlib'ers...

I have just discovered the wonders of the parser functions, and got impressed with the tens of functions that come with stdlib. First things first... good work!!! Thanks!!

And now the issue. It seems like the writer of the range() function did not think about ranges with more than one digit that need leading zeros in the first items, like "01..99", when you usually want to have 01, 02, and so on. Ruby allows you to do ("01".."99") and that will do the right thing, but the range() function provided with stdlib does some type conversion (detects if it's a number, and changes the type to integer) which converts "01" to 1 breaking this possibility.

Hey Pablo,

Just a question - do you have a NEED for it to be [01...99] with the leading zero?  If I understand correctly, the end result is the same, as the range function will cast 01 to 1 and not BREAK because you pass it 01 - correct?  Maybe I'm missing why you would need to use 01 explicitly?

 

I tried to submit a bug report, but I just can list the open ones, can't make one myself. Is this intentional? How do I properly address this request?

No problem.  We've turned off Github Issues because we use our central Redmine server for bug tracking --> http://projects.puppetlabs.com/projects/modules/issues  Please feel free to file any module tickets here!

 

So, I tried to change that myself, but no matter what I do to the range.rb file, the changes are not picked up by the node. Do I have to do something to force a reload of the file? This runs in the server, right?

What I did then was to create a range_custom() which is a copy of the former, but without the type conversion. I tried that and it works like a charm.

Thanks!

Pablo

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--

Gary Larizza

Professional Services Engineer

Puppet Labs

[Jeff McCune]

On Thu, Mar 29, 2012 at 8:57 AM, Gary Larizza <ga...@puppetlabs.com> wrote:

I tried to submit a bug report, but I just can list the open ones, can't make one myself. Is this intentional? How do I properly address this request?

No problem.  We've turned off Github Issues because we use our central Redmine server for bug tracking --> http://projects.puppetlabs.com/projects/modules/issues  Please feel free to file any module tickets here!

Gary, Pablo,

I actually just created a dedicated project [1] for the Standard Library.  Ken Barber and I talked about this a couple of weeks ago; we're of the opinion stdlib has grown enough to warrant a specific place to file issues.  The main motivation is to enable everyone to easily target specific semantic versions in the issue tracker.  For example, "stdlib misbehaves in 2.1.x but not in 2.2.x"  This will allow us to target 2.1.x in without stdlib dominating all of the versions in the modules project.

Pablo, if you file an issue, please file it in either project.  I'm going to spend much of today ticket gardening and moving the stdlib tickets to the new project.

The new project is set to "self subscribe" so please feel free to join the project in your account settings.

[1] http://projects.puppetlabs.com/projects/stdlib

Cheers,

-Jeff

[Pablo Fernandez]

Hi,

And now the issue. It seems like the writer of the range() function did not think about ranges with more than one digit that need leading zeros in the first items, like "01..99", when you usually want to have 01, 02, and so on. Ruby allows you to do ("01".."99") and that will do the right thing, but the range() function provided with stdlib does some type conversion (detects if it's a number, and changes the type to integer) which converts "01" to 1 breaking this possibility.

Hey Pablo,

Just a question - do you have a NEED for it to be [01...99] with the leading zero?  If I understand correctly, the end result is the same, as the range function will cast 01 to 1 and not BREAK because you pass it 01 - correct?  Maybe I'm missing why you would need to use 01 explicitly?

Yes, some of our machines are like "node01-node50", that's why I tried to do that. The thing is that Ruby allows you to do that if you say ("00".."50") instead of (0..50). The only difference is that the array will be of strings, and the second of integers. Maybe an example illustrates better:

irb(main):008:0> ("08".."12").to_a
=> ["08", "09", "10", "11", "12"]

irb(main):010:0> (8..12).to_a
=> [8, 9, 10, 11, 12]

But then, the range() function in stdlib, makes a type conversion, that breaks this possibility. I don't understand why do you do that conversion... the function is just an interface to the "range" capability of Ruby, right? I think it should allow the programmer to choose the type he wants.

No problem.  We've turned off Github Issues because we use our central Redmine server for bug tracking --> http://projects.puppetlabs.com/projects/modules/issues  Please feel free to file any module tickets here!

I saw that, but I can only see the tickets, cannot open one myself.  Do I have to create myself an account? How?

So, I tried to change that myself, but no matter what I do to the range.rb file, the changes are not picked up by the node. Do I have to do something to force a reload of the file? This runs in the server, right?

Do you know if, after editing a .rb file, I have to force some kind of reload to pick up the changes?


Thanks!
Pablo

[Pablo Fernandez]

Gotcha, thanks!

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[Ashley Penney]

I needed this just yesterday, actually, for NFS mounts.

  $PO_0_9 = prefix(range("0","9"),'/PO_0')

  $PO_10_31 = prefix(range("10","31"),'/PO_')

  $PO_32_76 = prefix(range("32","76"),'/PO_')

  

  nfs::po_mounts_50{ $PO_0_9:

    options => 'soft,bg,tcp',

  }

  nfs::po_mounts_50{ $PO_10_31:

    options => 'soft,bg,tcp',

  }

  

  nfs::po_mounts_55{ $PO_32_76:

    options  => 'soft,bg,tcp',

  }

I know how ugly this is, but I had to split the range in two just to get the leading 0.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[Krzysztof Wilczynski]

Hi,

irb(main):008:0> ("08".."12").to_a

=> ["08", "09", "10", "11", "12"]

irb(main):010:0> (8..12).to_a
=> [8, 9, 10, 11, 12]

But then, the range() function in stdlib, makes a type conversion, that breaks this possibility. I don't understand why do you do that conversion... the function is just an interface to the "range" capability of Ruby, right? I think it should allow the programmer to choose the type he wants.

"With great power comes great responsibility" -- said that, please allow yourself to understand the following example:

("abc01".."abc99 ").to_a

Observe this little (which may happen) mistake after "abc99". That is the easily over-looked single space.

If you do that in your manifest, let say ... by accident... then your Puppet Master will more likely become a happy candidate for OOM Killer to consider :)

Do you know if, after editing a .rb file, I have to force some kind of reload to pick up the changes?

No, there is no need to reload, but this is not the solution. Instead, in order to guarantee safe execution and also provide desired effect a different approach can be taken: You can scan for how many string-encoded digits you can fine within start of the range, count then and then based on this counter collect (or map if you like Perl so much) generated range with relevant substitution. If done right, then it will allow you to zero-padding of any size at any place in the string e.g. test00, 00test this00test, etc ...

I will update my version f range shortly to do precisely that.

KW

[Jeff McCune]

On Thu, Mar 29, 2012 at 8:48 AM, Pablo Fernandez <pablo.f...@cscs.ch> wrote:

Dear stdlib'ers...

I have just discovered the wonders of the parser functions, and got impressed with the tens of functions that come with stdlib. First things first... good work!!! Thanks!!

And now the issue. It seems like the writer of the range() function did not think about ranges with more than one digit that need leading zeros in the first items, like "01..99", when you usually want to have 01, 02, and so on. Ruby allows you to do ("01".."99") and that will do the right thing, but the range() function provided with stdlib does some type conversion (detects if it's a number, and changes the type to integer) which converts "01" to 1 breaking this possibility. I tried to submit a bug report, but I just can list the open ones, can't make one myself. Is this intentional? How do I properly address this request?

Pablo, I just tried to reproduce this in the issue you reported at http://projects.puppetlabs.com/issues/13494

It looks like range("host01", "host99") works fine, returning [ "host01", "host02", ..., "host98", "host99" ]

Is this what you're looking for, or is it an issue only if the leading portion of the string is zero padded?

-Jeff

[Pablo Fernandez]

Hi,

> It looks like range("host01", "host99") works fine, returning [
> "host01", "host02", ..., "host98", "host99" ]
>
> Is this what you're looking for, or is it an issue only if the leading
> portion of the string is zero padded?

This is exactly what I was looking for, which indeed is much nicer than
doing prefix(range(blabla)).

In any case, I still don't see the reason for the artificial type change
inside that function, but anyway...

BR/Pablo

[Jeff McCune]

The function isn't actually doing the type change.  Puppet itself massages strings that look like integers into actual integers.

 

-Jeff

[Krzysztof Wilczynski]

Hi,

[...]

I changed how the range works (also making it resists Ruby's string permutation bomb).

Ideas implemented so far:

https://gist.github.com/2277148
https://gist.github.com/2277144
https://gist.github.com/2270106

Also, the "a..b" and "a...b" notation should also be supported.

I will push new version later.

KW

[Pablo Fernandez]

I think you are wrong, check the source code:

 # Check whether we have integer value if so then make it so ...
      if start.match(/^\d+$/)
        start = start.to_i
        stop  = stop.to_i
      else
        start = start.to_s
        stop  = stop.to_s
      end

Besides, the change made by Krzysztof are awesome, specially "node[01-45]", simply perfect.

Thanks!
Pablo