Assigning a block to a variable in Ruby

ruby-talk
21

I don't know if you can do it directly from ruby, but you can use a
system command.
On windows

irb(main):005:0> system "MODE COM3 BAUD=1200"

Status for device COM3:

···

On 12/15/05, dperkins@frii.com <dperkins@frii.com> wrote:

I'm writing a simple script that talks to a device on a PC serial port. I
need to be able to set the port settings (baud, bits, parity) but I have
not found a way to do this. How can I do this?

-----------------------
    Baud: 1200
    Parity: Even
    Data Bits: 7
    Stop Bits: 1
    Timeout: OFF
    XON/XOFF: OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit: ON
    RTS circuit: ON

=> true

C:\>help mode
Configures system devices.

Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
                                [to=on|off] [xon=on|off] [odsr=on|off]
                                [octs=on|off] [dtr=on|off|hs]
                                [rts=on|off|hs|tg] [idsr=on|off]

...

This script will run in a DOS window on Windows, but I might need to use
it with Linux later.

I'll let a linux guru tell you the correct command there.

-Adam

22

On Linux you can use stty:

  `stty -echo raw ospeed 38400 ispeed 38400 < /dev/ttyS0`

You may also want to look at <http://raa.ruby-lang.org/project/ruby-serialport/&gt;

Viele Grüße,
Levin

···

On 12/15/05, dperkins@frii.com <dperkins@frii.com> wrote:

I'm writing a simple script that talks to a device on a PC serial port. I
need to be able to set the port settings (baud, bits, parity) but I have
not found a way to do this. How can I do this?

This script will run in a DOS window on Windows, but I might need to use
it with Linux later.

23

This is an area that has been a bit fuzzy for me.

Is it fair to say that the only difference between
  Proc.new {#some code}
and
  lambda {#some code}

is the behavior when 'return' is explicitly called in the block?
Are there any other differences?

Am I correct in saying that when a formal argument list explicitly
captures a block:
  def foo(&block);end
that Ruby converts the actual block to a Proc instance via
Proc.new as opposed to Kernel#lambda?

And finally, is there a way to create a lambda-like object via
a class method of Proc or is that behavior only available via
Kernel#lambda? I seems unusual that Kernel#lambda returns an
instance of Proc but that there is no way to get Proc itself
to generate that type of an object.

···

On Dec 15, 2005, at 5:41 PM, dblack@wobblini.net wrote:

Except... they're not quite identical, and actually as of RubyConf
2003 (I think) Matz agreed that 'proc' would be deprecated in favor of
'lambda', because having something called proc and something called
Proc.new that weren't the same was confusing.

24

Technically, Ruby is really an 'incremental compiler'. That there is no
final code generation step actually doesn't change this.

Normally we make the following distinctions

An INTERPRETER reads source code and processes each symbol in the code
each time it encounters the symbol. This is very inefficient, of
course. Thus a loop with an inner expression will require that the
inner expression be parsed and transformed into an evaluation stack
each time it is encountered. Early versions of BASIC were pure
interpreters, and performance was consequently far removed from native
code.

An INCREMENTAL COMPILER (most scripting languages fall into this
category) transforms source into an internal structure with a symbol
table and expression stacks etc as it reads the source. Subsequently
this structure is modified, but not discarded, if the source is changed
or additional source code is fed into the system. (The first popular
example of an incremental compiler was Microsoft QuickBasic, as far as
I can recall. At the time, this was a miracle to behold). The internal
representation can then be 'executed', usually by what is in effect a
virtual machine within the system.

A TRUE COMPILER normally operates as a batch process. All the tasks
that an incremental compiler performs are done once on the whole source
tree. Subsequently, the code generator emits code either for the native
hardware architecture or for a virtual machine. Source code changes
require that the entire batch process be repeated.

There are also 'just in time' compilers for virtual machines which can,
at runtime, evaluate 'hotspots' in the code which would benefit from
further compilation - more technically, translation - into native
machine code.

It is because modern scripting languages are incremental compilers and
not merely interpreters that their performance is so good. If they were
pure interpreters they would be hundreds of times slower.

Possibly Wikipedia could benefit from some clarification in its
explanation.

25

Hi --

Except... they're not quite identical, and actually as of RubyConf
2003 (I think) Matz agreed that 'proc' would be deprecated in favor of
'lambda', because having something called proc and something called
Proc.new that weren't the same was confusing.

This is an area that has been a bit fuzzy for me.

And for many of us :slight_smile:

Is it fair to say that the only difference between
  Proc.new {#some code}
and
  lambda {#some code}

is the behavior when 'return' is explicitly called in the block?
Are there any other differences?

I think the matter of arity strictness is still different. Frankly I
could never remember the details, and I know that I am by no means
alone in this. Basically, lambdas will give you an error if you send
them the wrong number of arguments. Unless they take only one
argument, in which case you'll get a warning. If the lambda takes no
arguments, then it doesn't care, unless the no-arguments is specified
with || (instead of just nothing), in which case you have to send
exactly zero arguments.

Procs are different. They give you the warning sometimes, but I don't
think they ever raise an exception because of wrong number of
arguments. (I really wish that warning would disappear.)

And so on. I'm not making fun of it, though it may sound that way. I
find it genuinely confusing, and it's a bit notorious for this. If
anyone wishes to come along and claim that it's simple and easy to
remember, please provide instructions for remembering it :slight_smile:

Am I correct in saying that when a formal argument list explicitly
captures a block:
  def foo(&block);end
that Ruby converts the actual block to a Proc instance via
Proc.new as opposed to Kernel#lambda?

There's actually no Kernel#lambda (lambda is a keyword, not a method),
but yes, it becomes a Proc. Although... if you do this:

   meth &lambda { ... }

it remains a lambda in the method (or so it appears from what irb is
telling me).

And finally, is there a way to create a lambda-like object via
a class method of Proc or is that behavior only available via
Kernel#lambda? I seems unusual that Kernel#lambda returns an
instance of Proc but that there is no way to get Proc itself
to generate that type of an object.

Well, lambda is a kind of specialization of Proc -- almost in the
spirit of being a subclass. So Proc has no knowledge of that
specialization. I agree that it should be of a different class. I've
been seeing people (including myself) having a hard time keeping all
of this straight for years. Not that the users have to be coddled :slight_smile:
but I think there's evidence that it is indeed confusing.

David

···

On Fri, 16 Dec 2005, gwtmp01@mac.com wrote:

On Dec 15, 2005, at 5:41 PM, dblack@wobblini.net wrote:

--
David A. Black
dblack@wobblini.net

"Ruby for Rails: Ruby techniques for Rails developers",
coming April 2006 (http://www.manning.com/books/black\)

26

Then... possibly you should add such clarifications if yours are in
fact clear?

I can't speak to your accuracy, I'm just saying... it's a wiki... *ahem*

27

ajmayo@my-deja.com wrote:

Technically, Ruby is really an 'incremental compiler'. That there is no
final code generation step actually doesn't change this.

Normally we make the following distinctions

An INTERPRETER reads source code and processes each symbol in the code
each time it encounters the symbol. This is very inefficient, of
course. Thus a loop with an inner expression will require that the
inner expression be parsed and transformed into an evaluation stack
each time it is encountered. Early versions of BASIC were pure
interpreters, and performance was consequently far removed from native
code.

An INCREMENTAL COMPILER (most scripting languages fall into this
category) transforms source into an internal structure with a symbol
table and expression stacks etc as it reads the source. Subsequently
this structure is modified, but not discarded, if the source is changed
or additional source code is fed into the system. (The first popular
example of an incremental compiler was Microsoft QuickBasic, as far as
I can recall. At the time, this was a miracle to behold). The internal
representation can then be 'executed', usually by what is in effect a
virtual machine within the system.

A TRUE COMPILER normally operates as a batch process. All the tasks
that an incremental compiler performs are done once on the whole source
tree. Subsequently, the code generator emits code either for the native
hardware architecture or for a virtual machine. Source code changes
require that the entire batch process be repeated.

There are also 'just in time' compilers for virtual machines which can,
at runtime, evaluate 'hotspots' in the code which would benefit from
further compilation - more technically, translation - into native
machine code.

It is because modern scripting languages are incremental compilers and
not merely interpreters that their performance is so good. If they were
pure interpreters they would be hundreds of times slower.

Possibly Wikipedia could benefit from some clarification in its
explanation.

Don't forget "dynamic translation," a la Smalltalk. Code is compiled for a virtual machine, but all VM instructions (not just hot spots) are translated into native instructions the first time they are encountered.

28

So Proc has no knowledge of that
specialization. I agree that it should be of a different class. I've
been seeing people (including myself) having a hard time keeping all
of this straight for years. Not that the users have to be coddled :slight_smile:
but I think there's evidence that it is indeed confusing.

Thanks for the clarifications Dave. I wonder if some sort of unification
of all these rules/behaviors is possible. I'm not sure exactly what I
mean by that, maybe it is just some better documentation, maybe it is
something else...

There's actually no Kernel#lambda (lambda is a keyword, not a method),

I assume this is so the parser can make special arrangements while
constructing the AST rather then waiting until the code is actually
executed. I think matz has mentioned changing eval from a method to a
keyword for this reason, no?

···

On Dec 16, 2005, at 8:17 AM, dblack@wobblini.net wrote:

29

I assume you mean Ruby garden (http://www.rubygarden.org/ruby\)?
That would be a great place to add clarifications to all this stuff but
it isn't the 'official' documentation so that doesn't completely address
the issue.

My comfort level isn't high enough yet to author something myself but
maybe soon...

···

On Dec 16, 2005, at 12:22 PM, magnus wrote:

Then... possibly you should add such clarifications if yours are in
fact clear?

I can't speak to your accuracy, I'm just saying... it's a wiki... *ahem*

30

Actually, I think that was in reference to this:

"Possibly Wikipedia could benefit from some clarification in its
explanation."

···

On Sat, Dec 17, 2005 at 03:47:10AM +0900, gwtmp01@mac.com wrote:

On Dec 16, 2005, at 12:22 PM, magnus wrote:

>Then... possibly you should add such clarifications if yours are in
>fact clear?
>
>I can't speak to your accuracy, I'm just saying... it's a wiki...
>*ahem*

I assume you mean Ruby garden (http://www.rubygarden.org/ruby\)?
That would be a great place to add clarifications to all this stuff but
it isn't the 'official' documentation so that doesn't completely address
the issue.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.