headers
koicat | 1 Jul 2010 01:40
Picon

drb problem? ringy-dingy won't answer...

The following code works fine as long as I don't try to run it through
the distributed server.  It doesn't get there...
It runs fine out of delayed_job, runs fine if called directly.
But if 'distrib' is true (the default) it runs right up to the call to
the server and right past it without getting to the server or raising
any errors.

Am using Ruby 1.8.6.26 , Ringy-Dingy 1.2.1, dj 1.8.4.

*********The server:
require 'rinda/ring'
class ScriptServer
  include DRbUndumped
  attr_accessor :result
  def run(fullScript)
    myTS  = Time.now.strftime("%Y%m%d%H%M%S")
    msg = "===> Starting #{scriptname} in run #{scriptrun} on
#{scriptenv} at #{myTS}"
    puts msg
     <at> result = "***#{scriptname} Launched [#{scriptlaunch}]"
    rslt = fullScript.run
     <at> result << rslt
    msg = "#{scriptname} Completed [#{Time.now.strftime("%Y%m%d%H%M
%S")}]"
     <at> result << "***#{msg}"
  rescue
     <at> result << "#{scriptname} Aborted [#{Time.now.strftime("%Y%m%d%H%M
%S")}] \n #{$!} \n #{caller.to_yaml}"
  ensure
    return  <at> result
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Edward Gray II | 1 Jul 2010 02:45
Gravatar

Re: Reading String Data as a File

On Jun 30, 2010, at 10:41 AM, Brian Candler wrote:

> James Edward Gray II wrote:
>> I'm open to suggestions and I do take patches.
> 
> Specifically, I'd like to see how to parse CSV from stdin. You provide 
> an example in the opposite direction:
> 
> #   FCSV($stderr)    { |csv_err| csv_err << %w{my data here} }  # to 
> $stderr

On Jun 30, 2010, at 11:35 AM, Robert Klemme wrote:

> On 30.06.2010 17:05, James Edward Gray II wrote:
>> 
>> Do you think it would help if I added Wrapping an IO under the
>> Shortcut Interface on this page?
>> 
>> http://fastercsv.rubyforge.org/classes/FasterCSV.html
> 
> +1

Better?

http://fastercsv.rubyforge.org/classes/FasterCSV.html

James Edward Gray II
Permalink | Reply | 5 comments |
headers
Colin Bartlett | 1 Jul 2010 03:46

Re: Increase significant digits in Float

On Wed, Jun 30, 2010 at 3:56 PM, Javier Goizueta <jgoizueta <at> gmail.com>wrote:

> You may also want to take a look at http://flt.rubyforge.org/
>
> It's an implementation of arbitrary precision floating point numbers
> (decimal and binary). If you don't need it to be fast it has some
> advantages over BigDecimal.
> --
> Posted via http://www.ruby-forum.com/.
>
Also: I recall a short thread from December 2008:
Proposing an arbitrary precision class building on BigDecimal and being
derived from Numeric
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/322100
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/322174 and
subsequent
  or as a user friendly all in one place:
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/66f505b9460464cc/e9a0142b118d66a8?q=
  with links to:
https://rubyforge.org/projects/appmath/
http://appmath.rubyforge.org/
http://www.ulrichmutze.de/index.html

(I should observe that I haven't tried this code: I simply made a mental
note at the time of the thread that it might be useful.)
Permalink | Reply | 0 comments |
headers
R.. Kumar 1.9.1 OSX | 1 Jul 2010 07:48
Picon

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

Brian Candler wrote:
> R.. Kumar 1.9.1 OSX wrote:
>> /opt/local/lib/ruby1.9/1.9.1/pathname.rb:270: warning: `*' interpreted
>> as argument prefix
> 
> Can you post line 270 of that file, with a few lines of context?
> 
> Can you replicate the problem standalone? e.g.
> 
 #!/usr/bin/ruby19 -w
 require 'pathname'

The above is enough to give the error.

1. I do not want to fix the problem in my own copy of ruby 1.9 and have 
it keep returning when i upgrade versions, or have others get it.

2. While googling, I found that the problem was fixed in 1.8.x but 
perhaps not in 1.9. Is that the case ?

The code in pathname.rb is

 259   # Return a pathname which is substituted by String#sub.
 260   def sub(pattern, *rest, &block)
 261     if block
 262       path =  <at> path.sub(pattern, *rest) {|*args|
 263         begin
 264           old = Thread.current[:pathname_sub_matchdata]
 265           Thread.current[:pathname_sub_matchdata] = $~
 266           eval("$~ = Thread.current[:pathname_sub_matchdata]",
(Continue reading)

Permalink | Reply | 0 comments |
headers
R.. Kumar 1.9.1 OSX | 1 Jul 2010 07:55
Picon

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

Josh Cheek wrote:

> Anyway, if it bothers you, you can go put parens around it so it becomes
> yield(*args) and is not ambiguous. But you don't need to worry about it,
> look where it got those args from:

Okay, i've put a parens around the *args. I no longer get the warning. 
However, why i did not do this earlier, is that when i was googling and 
i saw the commit (change) for this issue, there seemed to be several 
lines of change involved.

I hope i am not altering the behavior by putting the parens.
--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 5 comments |
headers
Josh Cheek | 1 Jul 2010 08:46
Picon
Gravatar

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

On Thu, Jul 1, 2010 at 12:55 AM, R.. Kumar 1.9.1 OSX <sentinel1879 <at> gmail.com
> wrote:

> Josh Cheek wrote:
>
> > Anyway, if it bothers you, you can go put parens around it so it becomes
> > yield(*args) and is not ambiguous. But you don't need to worry about it,
> > look where it got those args from:
>
> Okay, i've put a parens around the *args. I no longer get the warning.
> However, why i did not do this earlier, is that when i was googling and
> i saw the commit (change) for this issue, there seemed to be several
> lines of change involved.
>
> I hope i am not altering the behavior by putting the parens.
> --
> Posted via http://www.ruby-forum.com/.
>
>
You aren't, you probably see them because your warning levels are different
than other people's

$ ruby -we "def x; yield *[12] end; puts x{|n|n}"
-e:1: warning: `*' interpreted as argument prefix
12

$ ruby -e "def x; yield *[12] end; puts x{|n|n}"
12

-----
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jesús Gabriel y Galán | 1 Jul 2010 08:51
Picon
Gravatar

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

On Thu, Jul 1, 2010 at 8:46 AM, Josh Cheek <josh.cheek <at> gmail.com> wrote:
> On Thu, Jul 1, 2010 at 12:55 AM, R.. Kumar 1.9.1 OSX <sentinel1879 <at> gmail.com
>> wrote:
>
>> Josh Cheek wrote:
>>
>> > Anyway, if it bothers you, you can go put parens around it so it becomes
>> > yield(*args) and is not ambiguous. But you don't need to worry about it,
>> > look where it got those args from:
>>
>> Okay, i've put a parens around the *args. I no longer get the warning.
>> However, why i did not do this earlier, is that when i was googling and
>> i saw the commit (change) for this issue, there seemed to be several
>> lines of change involved.
>>
>> I hope i am not altering the behavior by putting the parens.
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>>
> You aren't, you probably see them because your warning levels are different
> than other people's
>
>
> $ ruby -we "def x; yield *[12] end; puts x{|n|n}"
> -e:1: warning: `*' interpreted as argument prefix
> 12
>
> $ ruby -e "def x; yield *[12] end; puts x{|n|n}"
> 12
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jesús Gabriel y Galán | 1 Jul 2010 08:51
Picon
Gravatar

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

2010/7/1 Jesús Gabriel y Galán <jgabrielygalan <at> gmail.com>:
> On Thu, Jul 1, 2010 at 8:46 AM, Josh Cheek <josh.cheek <at> gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 12:55 AM, R.. Kumar 1.9.1 OSX <sentinel1879 <at> gmail.com
>>> wrote:
>>
>>> Josh Cheek wrote:
>>>
>>> > Anyway, if it bothers you, you can go put parens around it so it becomes
>>> > yield(*args) and is not ambiguous. But you don't need to worry about it,
>>> > look where it got those args from:
>>>
>>> Okay, i've put a parens around the *args. I no longer get the warning.
>>> However, why i did not do this earlier, is that when i was googling and
>>> i saw the commit (change) for this issue, there seemed to be several
>>> lines of change involved.
>>>
>>> I hope i am not altering the behavior by putting the parens.
>>> --
>>> Posted via http://www.ruby-forum.com/.
>>>
>>>
>> You aren't, you probably see them because your warning levels are different
>> than other people's
>>
>>
>> $ ruby -we "def x; yield *[12] end; puts x{|n|n}"
>> -e:1: warning: `*' interpreted as argument prefix
>> 12
>>
>> $ ruby -e "def x; yield *[12] end; puts x{|n|n}"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Josh Cheek | 1 Jul 2010 10:05
Picon
Gravatar

Re: pathname.rb:270: warning: `*' interpreted as argument prefix

2010/7/1 Jesús Gabriel y Galán <jgabrielygalan <at> gmail.com>

> 2010/7/1 Jesús Gabriel y Galán <jgabrielygalan <at> gmail.com>:
> > On Thu, Jul 1, 2010 at 8:46 AM, Josh Cheek <josh.cheek <at> gmail.com> wrote:
> >> On Thu, Jul 1, 2010 at 12:55 AM, R.. Kumar 1.9.1 OSX <
> sentinel1879 <at> gmail.com
> >>> wrote:
> >>
> >>> Josh Cheek wrote:
> >>>
> >>> > Anyway, if it bothers you, you can go put parens around it so it
> becomes
> >>> > yield(*args) and is not ambiguous. But you don't need to worry about
> it,
> >>> > look where it got those args from:
> >>>
> >>> Okay, i've put a parens around the *args. I no longer get the warning.
> >>> However, why i did not do this earlier, is that when i was googling and
> >>> i saw the commit (change) for this issue, there seemed to be several
> >>> lines of change involved.
> >>>
> >>> I hope i am not altering the behavior by putting the parens.
> >>> --
> >>> Posted via http://www.ruby-forum.com/.
> >>>
> >>>
> >> You aren't, you probably see them because your warning levels are
> different
> >> than other people's
> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Dalton | 1 Jul 2010 10:31
Picon
Gravatar

Synchronized Circular Buffer

I'm relatively new to Ruby, having switched from a PHP and Java
background, and I'm having some trouble with the Monitor class trying to
implement a synchronised circular buffer. The other posts here on
synchronised methods aren't quite relevant enough unfortunately.

My current implementation is the following

require 'monitor'

class SynchronisedBuffer < Monitor

   def initialize(capacity)
       <at> capacity = capacity
       <at> front = 0
       <at> back = 0
       <at> elements = Array.new(capacity)
       <at> empty_cond = new_cond
       <at> full_cond = new_cond
      super()
   end

   def get
        <at> empty_cond.wait_while {empty?}
       element = nil
       synchronize do
           element =  <at> elements[ <at> front]
            <at> elements[ <at> front] = nil
            <at> front = ( <at> front + 1) %  <at> capacity
            <at> full_cond.signal
        end
(Continue reading)

Permalink | Reply | 3 comments |

Gmane