I could not find a standard "assert" in Ruby. Is there one?
Thanks!
Outside of Test::Unit
raise "message" if condition
and
raise "meassge" unless condition
···
On Nov 12, 2004, at 10:53 AM, itsme213 wrote:
I could not find a standard "assert" in Ruby. Is there one?
I asked a similar question some time ago. This is the thread:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/102412
Kind Regards,
Ed
···
On Sat, 13 Nov 2004 03:53:27 +0900, itsme213 <itsme213@hotmail.com> wrote:
I could not find a standard "assert" in Ruby. Is there one?
--
Despite the surge of power you feel upon learning Ruby,
resist the urge to trip others or slap them in the bald head.
DO NOT LORD YOUR RUBYNESS OVER OTHERS!
itsme213 wrote:
I could not find a standard "assert" in Ruby. Is there one?
There's one in the dev-utils package. It will automatically set a breakpoint if the application is run in debug mode and therefore give you an irb shell where you can find out why your assert failed.
"Despite the surge of power you feel upon learning Ruby,
resist the urge to trip others or slap them in the bald head.
DO NOT LORD YOUR RUBYNESS OVER OTHERS!"
This is the most wonderful quote I ever heard about ruby.
sorry to write off-topic .
···
On Fri, 2004-11-12 at 15:09, Edgardo Hames wrote:
On Sat, 13 Nov 2004 03:53:27 +0900, itsme213 <itsme213@hotmail.com> wrote:
> I could not find a standard "assert" in Ruby. Is there one?
>I asked a similar question some time ago. This is the thread:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/102412
Kind Regards,
Ed
--
Mohammad
There's one in the dev-utils package. It will automatically set a
breakpoint if the application is run in debug mode and therefore give
you an irb shell where you can find out why your assert failed.
That would work nice ... but I could not find it.
It's not there at the moment (I don't think). And the OP probably
wants an exception raised, not an IRB session 
Cheers,
Gavin
···
On Saturday, November 13, 2004, 7:28:26 AM, Florian wrote:
itsme213 wrote:
I could not find a standard "assert" in Ruby. Is there one?
There's one in the dev-utils package. It will automatically set a
breakpoint if the application is run in debug mode and therefore give
you an irb shell where you can find out why your assert failed.
Qbviously, this quote belongs to why the lucky stiff. Today I feel
like searching back in old mails...
Please, see this thread:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/117900
Regards,
Ed
···
On Sat, 13 Nov 2004 05:24:15 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
On Fri, 2004-11-12 at 15:09, Edgardo Hames wrote:
> On Sat, 13 Nov 2004 03:53:27 +0900, itsme213 <itsme213@hotmail.com> wrote:
> > I could not find a standard "assert" in Ruby. Is there one?
> >
>
> I asked a similar question some time ago. This is the thread:
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/102412
>
> Kind Regards,
> Ed"Despite the surge of power you feel upon learning Ruby,
resist the urge to trip others or slap them in the bald head.
DO NOT LORD YOUR RUBYNESS OVER OTHERS!"This is the most wonderful quote I ever heard about ruby.
sorry to write off-topic .
--
Despite the surge of power you feel upon learning Ruby,
resist the urge to trip others or slap them in the bald head.
DO NOT LORD YOUR RUBYNESS OVER OTHERS!
itsme213 wrote:
I could not find a standard "assert" in Ruby. Is there one?
There's one in the dev-utils package. It will automatically set a
breakpoint if the application is run in debug mode and therefore give
you an irb shell where you can find out why your assert failed.
It's not there at the moment (I don't think). And the OP probably
wants an exception raised, not an IRB session
While writing that message, I realised why a breakpoint-inducing
assert would be handy. Let's call it assert_bp, since the bare name
'assert' so strongly implies "raise an error if expression is false".
Code:
x = 5
y = 6
assert_bp "x + y = 100"
Console:
Assert failed: x + y = 100 (foo/bar.rb:51)
> _
Now, can anyone suggest a better name than 'assert_bp'?
Gavin
···
On Saturday, November 13, 2004, 12:46:23 PM, Gavin wrote:
On Saturday, November 13, 2004, 7:28:26 AM, Florian wrote:
itsme213 wrote:
There's one in the dev-utils package. It will automatically set a
breakpoint if the application is run in debug mode and therefore give
you an irb shell where you can find out why your assert failed.That would work nice ... but I could not find it.
Oh, you are right. It is not yet included in dev-utils because of its name. I have attached my local version of breakpoint.rb which includes it.
I have thought about changing the name to "assume" so it can be included in dev-utils, but I'm not sure if that name is better.
breakpoint_client.rb (2.24 KB)
binding_of_caller.rb (2.54 KB)
breakpoint.rb (9.57 KB)
Now, can anyone suggest a better name than 'assert_bp'?
assert?
i.e. tentative assert
though i would use it everywhere by default. it would be nice if there were
a couple of eiffel-like switches to modify its behavior.
Maybe
breakpoint :unless => 'x + y == 10'
?
Gavin
···
On Saturday, November 13, 2004, 7:38:28 PM, Florian wrote:
itsme213 wrote:
There's one in the dev-utils package. It will automatically set a
breakpoint if the application is run in debug mode and therefore give
you an irb shell where you can find out why your assert failed.That would work nice ... but I could not find it.
Oh, you are right. It is not yet included in dev-utils because of its
name. I have attached my local version of breakpoint.rb which includes it.
I have thought about changing the name to "assume" so it can be included
in dev-utils, but I'm not sure if that name is better.
#break_unless
#break_if
···
On Nov 12, 2004, at 6:59 PM, Gavin Sinclair wrote:
Now, can anyone suggest a better name than 'assert_bp'?
Gavin Sinclair wrote:
I have thought about changing the name to "assume" so it can be included
in dev-utils, but I'm not sure if that name is better.Maybe
breakpoint :unless => 'x + y == 10'
?
I think that would be way too much magic. I'd expect the method to just take a block.
Why a block? The breakpoint code uses Binding.of_caller anyway, so a
block is not needed for evaluation. I don't see any other reason,
technical or stylistic, why a block should be preferred.
I suppose we might as well dispose of the symbolic argument and just
do this:
breakpoint_unless 'x + y == 10'
Can you expand on the "too much magic"?
Gavin
···
On Sunday, November 14, 2004, 1:18:24 AM, Florian wrote:
Gavin Sinclair wrote:
I have thought about changing the name to "assume" so it can be included
in dev-utils, but I'm not sure if that name is better.Maybe
breakpoint :unless => 'x + y == 10'
?
I think that would be way too much magic. I'd expect the method to just
take a block.
Gavin Sinclair wrote:
I have thought about changing the name to "assume" so it can be included
in dev-utils, but I'm not sure if that name is better.I think that would be way too much magic. I'd expect the method to just
take a block.Why a block? The breakpoint code uses Binding.of_caller anyway, so a
block is not needed for evaluation. I don't see any other reason,
technical or stylistic, why a block should be preferred.
Using strings for code is a bit ugly. We have blocks in Ruby, why not use them? Using a String also causes a bit of escaping trouble (I know this can be worked around via the %{} or <<-END syntax, but I still think blocks are clearer than that.)
I suppose we might as well dispose of the symbolic argument and just
do this:breakpoint_unless 'x + y == 10'
Why don't just use "breakpoint unless x + y == 10" then? I think it makes sense to use something more concise here.
Can you expand on the "too much magic"?
I don't know -- the syntax just seemed so very unnatural. Like something you wouldn't meet anywhere in the standard library...
Gavin Sinclair wrote:
I have thought about changing the name to "assume" so it can be included
in dev-utils, but I'm not sure if that name is better.I think that would be way too much magic. I'd expect the method to just
take a block.Why a block? The breakpoint code uses Binding.of_caller anyway, so a
block is not needed for evaluation. I don't see any other reason,
technical or stylistic, why a block should be preferred.
Using strings for code is a bit ugly. We have blocks in Ruby, why not
use them? Using a String also causes a bit of escaping trouble (I know
this can be worked around via the %{} or <<-END syntax, but I still
think blocks are clearer than that.)
Agreed, but you can print strings. You can't print blocks. See
below.
I suppose we might as well dispose of the symbolic argument and just
do this:breakpoint_unless 'x + y == 10'
Why don't just use "breakpoint unless x + y == 10" then? I think it
makes sense to use something more concise here.
That option is still available. breakpoint_unless 'x + y == 10' has
the added benefit that the breakpoint can be identified by the
condition that triggered it. E.g. you run the program and see on the
console:
Breakpoint because 'x + y == 10' is false.
>
Is that a convincing benefit?
Can you expand on the "too much magic"?
I don't know -- the syntax just seemed so very unnatural. Like something
you wouldn't meet anywhere in the standard library...
Debugging code often stands out in this unfortunate way, though. It's
lower level than normal code.
Now let me ask you: since you proposed
assume { x + y == 10 }
what does that provide over
breakpoint unless x + y == 10
?
Gavin
···
On Sunday, November 14, 2004, 2:48:24 AM, Florian wrote:
Gavin Sinclair wrote:
Why don't just use "breakpoint unless x + y == 10" then? I think it makes sense to use something more concise here.
That option is still available. breakpoint_unless 'x + y == 10' has
the added benefit that the breakpoint can be identified by the
condition that triggered it. E.g. you run the program and see on the
console:Breakpoint because 'x + y == 10' is false.
>Is that a convincing benefit?
This does indeed sound nice.
I don't know -- the syntax just seemed so very unnatural. Like something
you wouldn't meet anywhere in the standard library...Debugging code often stands out in this unfortunate way, though. It's
lower level than normal code.
But note that this is something that can even remain in production code.
Now let me ask you: since you proposed
assume { x + y == 10 }
what does that provide over
breakpoint unless x + y == 10
?
I think it looks nicer and it can be ignored if the code is not run in debug mode.
What would you think about an assume() method that could take either a block or a String?
Hm, has someone tried ParseTree
(zenspider projects | software projects | by ryan davis) to print out blocks?
Would be really great if that works.
trace { x + y } #=> x+y = 5
assert { x + y == 0 } #=> assertion 'x+y==0' failed...
Uhm, seems that's only possible to dump methods in classes, not
arbitrary code. But maybe, it's possible.
Regards,
Michael
···
On Sun, Nov 14, 2004 at 01:20:49AM +0900, Gavin Sinclair wrote:
On Sunday, November 14, 2004, 2:48:24 AM, Florian wrote:
> Gavin Sinclair wrote:
>>>>>I have thought about changing the name to "assume" so it can be included
>>>>>in dev-utils, but I'm not sure if that name is better.
>>>I think that would be way too much magic. I'd expect the method to just
>>>take a block.
>>
>> Why a block? The breakpoint code uses Binding.of_caller anyway, so a
>> block is not needed for evaluation. I don't see any other reason,
>> technical or stylistic, why a block should be preferred.> Using strings for code is a bit ugly. We have blocks in Ruby, why not
> use them? Using a String also causes a bit of escaping trouble (I know
> this can be worked around via the %{} or <<-END syntax, but I still
> think blocks are clearer than that.)Agreed, but you can print strings. You can't print blocks. See
below.
[ ... breakpoint_unless 'x + y == 10' ... ]
Breakpoint because 'x + y == 10' is false.
>Is that a convincing benefit?
This does indeed sound nice.
Now let me ask you: since you proposed
assume { x + y == 10 }
what does that provide over
breakpoint unless x + y == 10
?
I think it looks nicer and it can be ignored if the code is not run in
debug mode.
Are you suggesting that all breakpoint would only be enabled in debug
mode, or just the 'assume' ones? What kind of debug mode do you mean?
$DEBUG?
What would you think about an assume() method that could take either a
block or a String?
I agree it looks nicer, but I feel that breakpoint_unless is actually
a more appropriate name, even though it's a little ugly. 'assume'
doesn't tell you what it does. Setting breakpoints in this manner is
such a specific and irregular thing to do that I think the name needs
to be clear.
I'm happy with a method taking either a block or a string, though.
Gavin
···
On Sunday, November 14, 2004, 3:48:28 AM, Florian wrote: