recent experimental core builds

Brief notes on items found in the latest experimental versions: Serial port support under windows and unix (others are being added as we go along..) Tcp ports are now asynchronous. If you want the "old" behavior, you need to do OPEN/wait, ie: tcp-port: open/lines/wait tcp://example.com:80 (Jim said he'll come along and say more about some changes to ports...) LOAD has a new refinement: /ALL -- this will ignore REBOL headers when loading. The current and previous experimental versions use the new command line argument passing scheme. There have been a number of bug fixes here and there as well. See if *your* favorite bug is still in there! :-) For lack of any better current documentation on these new features, below are our REPs for the new serial ports, the change in command line passing, and the new LOAD/all refinement. I did not make them into attachments. Hope you all don't mind. -jeff ------------------------------------------------------------------ REBOL SERIAL PORT SPECIFICATION REBOL Enhancement Proposal: REP004 Version: 1.0.1 Author: Jim Goodnow II ===PURPOSE This specification describes the creation and operation of serial communication ports within REBOL. ===CREATION Serial ports are created in the same manner as other ports within REBOL. The scheme name for serial ports is "serial:". The specification of a serial port may include the device number, the communication speed, the number of data bits, the parity and number of stop bits. The specification information can be specified directly by setting the appropriate fields within the port specification object or by creating a URL which contains the same information. Any field not specified will be given a default value. The default values are: device: port1 speed: 9600 data bits: 8 parity: none stop bits: 1 URL's are encoded with the different fields separated by slashes. For example, serial://port1/9600/8/none/1 The order of fields is not significant, as the type of field can be determined by the content. Within a port specification, the various parameters are stored in the following object fields: host: device speed: speed data-bits: data bits parity: parity stop-bits: stop bits The portN specification is an indirect reference to the communication device. It refers to the Nth device defined in the System/ports/serial block. This block is initialized by default depending on the system being used and can be modified in user.r to reflect any local requirements. For example, on Windows the block might be defined as: System/ports/serial: [ com1 com2 ] or if COM1 is being used by the mouse, it might just be: System/ports/serial: [ com2 ] On unix-style systems, the block might be defined as: System/ports/serial: [ ttyS0 ttyS1 ] or if the first device should correspond to COM2: System/ports/serial: [ ttyS1 ttyS0 ] Thus, the ports can be specified in a machine indpendent manner while the machine specific definition can be controlled using the serial definition block in System/ports/serial. ===OPERATION Serial ports are always opened as direct ports in much the same way as console and network ports. They may be opened as either /STRING or /BINARY with the default being /STRING. They are opened by default as asynchronous, but may be made synchronous by using the /WAIT refinement. When operating asynchronously, any attempts to copy data from the port will return NONE if no data is present. When operating synchronously, the copy will block until data is available. Data can be written to the port using the INSERT native. Data can be read from the port using the PICK, FIRST or COPY natives with the usual ramifications. As usual with direct ports, the REMOVE, CLEAR, CHANGE and FIND functions are not supported. The UPDATE function can be used to change port parameters. For example, to change the speed after an initial connection has been established, you could just do: ser-port: open serial://9600 ser-port/speed: 2400 update ser-port Changing the device number or the System/ports/serial and calling UPDATE will have no effect. Once the port has been opened with a particular device, the device can't be changed. There are two additional port fields that can't be set with a URL, but can be set in a port specification block or by manually changing them. The RTS-CTS field specifies whether hardware handshaking should be used on the port. The default is ON. To change the default, do: ser-port/rts-cts: off update ser-port A timeout value can be specified by modifying the timeout field in the port structure. The timeout value only applies to serial ports that are opened with the /wait refinement. When the timeout expires, a serial port timeout error will be generated. To set the timeout value do: ser-port/timeout: 10 ; 10 second timeout Serial ports work properly with the WAIT native. ### REBOL [] do/args %makespec.r %rep004.txt REBOL Command Line Args REBOL Enhancement Proposal: REP001 Version 1.0.0 Author: Jeff Kreis ===Overview Users report that the current treatment of command line arguments is inadequate for their needs. Presenting the entirety of the command line arguments in a single string destroys the distinction between separate arguments. Proposed enhancement provides two views of command line arguments: one as a single line of text, another as a block of separated arguments as strings. *Command line arguments need to be a readily DOable expression. In providing the command line argument as a single string (as is done now) this requirement is met. *Command line arguments should be distinguishable with out the user having to explicitly insert delimiters. REBOL should be able to deal with command line arguments in a manner that is functionally equivalent to other command line utilities (shell scripts, perl, sed, awk, etc..) By providing a block with the arguments separated in strings this requirement is met. *Command line arguments should not be able to prevent a script from running. This requirement means that the arguments can not be prescanned due to the fact that a syntax error found in the command line arguments will interrupt REBOL booting. *Impact on system object should be minimal. To accomplish this requirement, we reuse one of our system object fields that is currently supplying redundant information. After starting REBOL from the command line, the present behavior is that system/options/args and system/script/args are set to the same string which contains all of the arguments. This behavior will be changed like this: system/options/args == command line args as block of strings system/script/args == command line args as string ===Impact to DO/args There is no change to the behavior of do/args. ### REBOL [] do/args %makespec.r %rep001.txt REBOL Load/ALL REBOL Enhancement Proposal: REP005 Versio: 1.0.0 Author: Jeff Kreis ===Overview A new refinement /ALL is provided which will load REBOL data without attempting to evaluate the header. LOAD/next causes all words and values in a file, including those that comprise a REBOL header, to be scanned and returned as a block. ---Breakdown of refinement precedence Evaluate Returns Header? (pseudo example) : ----------------------------------------------------------------------------- load/next no [first-val { rest of script }] load/next/header yes make object! [Just the header] load/header yes [make object! [header] rest of script] load/all no [all of script as data] load/next/all no [first-val { rest of script }] load/header/all yes [make object! [header] rest of script] load/next/header/all yes make object! [Just the header] ---General refinement precedence The ALL refinement will be ignored when other refinements are present. Previous table shows the current behavior of the various refinement combinations with LOAD. ---That's all. That's all. ### REBOL [] do/args %makespec.r %rep005.txt

Will these enhancements be posted somewhere consolidated or perhaps a new user guide. For those of us that bought the book we may want to get a better more concise view of the changes since alot of us are new to REBOL. Paul Tretter