AltME groups: search

Gabriele, the problem is, that if you for example want to form JS 
code from REBOL, you will hardly have matched {} pairs. At least 
that's my experience.

What Robert wants (and I second that) is something like "heredoc" 
notation.
http://en.wikipedia.org/wiki/Heredoc

What is obscure about a syntax which permits literal strings to be 
literal strings?  Try assigning  set lit "{test} {" in your favorite 
Tcl interpreter.  I am not a JSON expert but [{ looks like JSON to 
me so #{[ "looks worrisome to me"   JSON or YAML or something other 
than XML is going to be important whether REBOL likes it or not. 
 Take RDF as one exmaple ( I prefer Topic Maps - please do not attack 
the example, but the isea ).  The fact that most people seem to think 
that RDF is XML does not make it so.  Tim Berners-Lee prefers some 
form of Triple notation for RDF.  Not XML.  As soon as a notation 
uses curly braces we have a problem using Curl on the server-side. 
 Please don't point to QM.  IT is not just tightly coupled to HTML 
it is married to it.  The web is not HTML it is HTTP with Content-Type: 
 set in the response header.  If that content type uses curly braces 
we have to start escaping characters in Rebol.  Awkward templating 
is dooked templating.  Let me repeat: doomed.  Folly.

So now you are generating code with Rebol but then preporcessing 
hte code with Perl to strip out the escaping carets on the ^{ and 
^}

Completely unnecessary. REBOL escaping is only a REBOL syntax trick 
- in memory the escaping carets don't exist. If you don't want carets 
in your output use PRINT, FORM, WRITE, or anything but MOLD. There 
is no interoperability argument for heredocs whatsoever.

I just read it, and was about to reply to your counter-post, just 
to one point.
External

 is an adjective. When used as a noun, its subject is implied. Bad 
 form.

(in current form  of syntax)

User-defined datatypes won't be recognized lexically, except perhaps 
in serialized form. However, serialized datatypes have to be REBOL 
syntax inside the block. It's too much to hope for REBOL to become 
Perl, or get Lisp's read macros.

i can work on it, what form of evaluation graph do you expect ?

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

I havn't commented much on parse because I tend to only use it in 
its most simple form:

	parse string delimiter


which got me thinking that, if we havn't already, perhaps this major 
use case is deserving of its own "split" function?

Because change still doesn't work , the best i can do is that:

parse/case opcode [
    any [
          "nn" remove -2 (new: get-word) insert new
        | #"n" remove -1 (new: form get-byte) insert new
        | "+d" remove -2 (new: get-d) insert new
        | #"e" remove -1 (new: get-e) insert new
        | skip
    ]
]

What the gain ? nothing...

First of all, Steeve, what you are suggesting is the original INSERT, 
CHANGE and REMOVE proposals. Which Carl said were infeasible to implement, 
which is why we have the new ones. Besides that, your example code 
is still too awkward. Try this:

parse/case opcode [
    any [ start:
          "nn" remove start insert (get-word)
        | #"n" remove start insert (form get-byte)
        | "+d" remove start insert (get-d)
        | #"e" remove start insert (get-e)
        | skip
    ]
]


If you are worried about change not working yet, don't be. It is 
still planned.

The change version of the above would be this:

parse/case opcode [
    any [ start:
          "nn" change start (get-word)
        | #"n" change start (form get-byte)
        | "+d" change start (get-d)
        | #"e" change start (get-e)
        | skip
    ]
]

If the paren value form hasn't made it into alpha 83, it will make 
it into a new alpha soon.

Brian, it's possibly forlorn, but I can forsee a pattern of [and 
map! here: change to-block here/1 :here into []] (sorry, rough approximation) 
in order to serialise in one form or other.  Given there could be 
no other possible use for [into map!] perhaps parse could imply that 
conversion?

I would not do it that way, as we surely want it to have in a form 
of a dtype, so unless you get utypes, you can't do it ...

yep that is a limitation.  it would be easy to implement on top of 
it... because there is an explcit serialized form right in the language.

Would be cool if REBOL interpreter could generate some form of symbol 
file for encapped scripts.

Even if we can't get that it would be cool to at least to get a some 
form of symbol file for the core.

The serialised would be acceptable, if that were the literal form 
too, instead of - make map! []


It's too bad there's no succinct way left to represent that (and 
objects for that matter)

MOLD/all generates the serialized form, and LOAD reads it. You can 
even write the serialized form literally in your scripts. For map! 
there is no problem with using the serialized form. For objects and 
functions, you'll have binding issues.

Have you tested with prefix form math? The implementation of op! 
has changed, and the new implementation would probably be slower 
(at a guess) but is more flexible. Please test with prefix math so 
we can categorize the ticket properly.

I got all the decimals after a while with this:

for a 4.0 5.9 0.1 [print a]

so I changed it to:

for ma $4.0 $5.9 0.1 [a: load next form ma print a]

I fixed my StRIP packer (based on RIP but the result is enbased instead 
of binary data - I had a reason to do this) for R3. Packs directories 
and I added one refinement - /code - you can add additional code 
that is run after unpacking the archive. So you can use that directory 
just as a temp dir and then move files somewhere else or anything 
you want. It's basically  a package manager, a very spartan one, 
but good enough for me. Get form next line (to prevent that extremly 
old and stupid AltME links bug).

then this has nothing to do with cheyenne, add something like
join %? checksum form now/precise ad the end of requested url

?t= url-encode form now/time/precise

with a redirect and wireshark, u should see both response headers, 
your browser is requesting two resources, one form Cheyenne, one 
from the redirected url

What technique does cheyenne use in regards to spawning of new processes? 
I mean - it either uses 'launch or some form of 'call. I wonder, 
what is the IPC (inter-process communication) strategy. E.g. I have 
10 requests I want to handle simultaneously, I spawn 10 processes. 
How do I pass TCP port to them? Or does it work some different way?

SVN r17 : big update, lot of code added mostly for the new embedded 
async Mail Transfer Agent (MTA)

FEAT: email async sending sub-system (MTA) added . 

FEAT: added two new functions for email support in RSP/CGI scripts: 
'send-email and 'email-info?
FEAT: added email sending demo form %www/email.rsp.

FEAT: Cheyenne's main process ID is now exported in /tmp/cheyenne.pid 
on start and deleted on quit. (All platforms except Windows).

FIX: fixed broken global words protection in RSP.r.
FIX: HTTP Date headers are now in UTC format.

FIX: "Reset Workers" menu wasn't working in service mode. Fixed now. 
(Thanks Will)

FIX: SVNr4 regression bug on system port for UNIX fixed. (Thanks 
Will)

FIX: multipart file uploading code refactored. Fixes many bugs in 
file uploading.

the email form has no action

While testing now, I've noticed a few issue with send-email/attach: 
header and multipart/form-data encoding. I'll fix them tonight, need 
to go now.

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

doesn't sound like a common case? Using FORM should be enough : 
<%= url-encode form %file %>

yes I am using form already .. but forme it's a common scenario to 
display files from the web server's directories

Nice idea! A REST-like interface to Cheyenne's MTA using the demo 
email form. :-)

I assumed it only put file data there and still captured the non 
file data into request/content

 => it requires to send data using "multipart/form-data" encoding.

I think I can just include the S3 libraries in the Cheyenne binary, 
and do a S3 download as a rsp form where I submit the filename, bucketname, 
and access keys

ahh, ok, I saw it the other way round... it always caches in it current 
form...

It's possible, but you need to add code for that in mod-static/logging 
handler. Also note that writting data on disk is a performance killer, 
so you need to implement some form of memory buffering to keep good 
server performances.

its just an abstraction layer.  whatever form it takes has advantages 
and disadvantages.

Will, such Comet solutions will probably include web sockets soon, 
as web sockets is an advanced form of Comet

Web sockets are not an advanced form of Comet.

REBOL's own form of lightweight protected memory will be there: contexts

BTW.. i use PHP as a language, not for it's "Hypertext preprocess" 
... 85% of my php has no html in it at all.   Mainly use PHP to receive 
and process AJAX form requests

I would call this "design refactoring" ... a high level form of "code 
refactoring".

SVN r59 : experimental mod-upload released.  This new mod adds server-side 
API for querying realtime progress info on uploaded files. See the 
demo : http://localhost/upload.html(not commented yet).

Current restrictions:
- works only when posting one file at a time in a given <form>.

- can't make it work for IE (IE seems to have an issue with setTimeout( 
) method).

There's a blur with websockets.. traditional usage takes a form, 
serialize and send to the server as a associative array in the url.. 
With sockets, that's not necessary. 

Forms are becoming less relevant.. As individual fields can do their 
own thing.. 

<input type="text" onblur="ws.send(this.val());">

Even non-form elements can be used.. 

<p id="myparagraph"  onchange="ws.send(this.text);">
Lorem ipsum
</p>

Binary support / upload: these are 2 different things. Uploading 
files (access to local filesystem) still requires FORM with multipart/form-data 
encoding.

29/1-01:03:23.766-## Error in [task-handler-1055] : Make object! 
[
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'arg1
    arg2: 'attributes
    arg3: [block!]
    near: [arg1: err/arg1 
        arg2: err/arg2 
        arg3:
    ]
    where: 'html-form-error
] !

It seems that error argument passing in 'html-form-error is not secured 
for unset! values. I'll patch that today.

Looking in my code, the unset! issue in html-form-error is already 
fixed in current version.

POST /cgi-bin/rebdev HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: host.rebol.net
User-Agent: REBOL
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 56


[0.4.0 "Graham" password  login]HTTP/1.1 500 Internal error in REBOL 
CGI Proxy
Date: Sun, 14 Feb 2010 02:05:45 GMT
Server: Apache/2.0.53 (Fedora)
Content-Type: text/plain; charset=UTF-8
Via: 1.1 bc7
Connection: close

Cannot connect (3)

that static form for localised strings is a great idea #[...] 


does localisation effect performance much? I suppose it increases 
RAM usage since app holds the two hashtables in memory (which is 
needed I know for speed)

I agree that #[...] really makes things easier and cleaner. Performance 
impact is not significant, the overhead is just a string! PICK in 
a block with a static index as argument (that's one of the nice advantage 
of compiling RSP scripts). OTOH, the SAY function has to do a hash 
table lookup to get the right index (so a tiny little bit slower 
than the literal form).

Well, that's a good idea, but the SDK license is quite restrictive, 
I shouldn't distribute Cheyenne in binary form (see "REBOL API Restriction" 
part at http://www.rebol.com/docs/sdk/sdkintro.html). RT didn't asked 
me to pay any additional license so far, so I don't want to push 
it further by giving away a free /Command with Cheyenne.

If a pdf is loaded into a browser .. it allows one to post the data 
in an acrobat form ... but if it is loaded into acrobat reader alone, 
then it can post, but it can't understand any html returned by the 
web server

I use websockets for passing javascript and JSON to a static page. 
 The pages start off with a single javascript function, then i use 
websockets to lazy load.


Here's  pseudo for an email client using Cy (shorting Cheyenne to 
Cy from C.. keep confusing myself)


- Start with a blank page with the websocket function. No HTML, No 
css.. link to Jquery only  .. this page is under 1k

- Send an initial message to Cy with the page name, Cy responds by 
pushing the necessary HTML (simple email form), CSS and JS (a single 
function to send back the form results to Cy) to the DOM

- User fills out form, and submits.. pushing an array (JSON, string.. 
whatever) with the message details to Cy
- Cy sends the message via rebol mail

... but then 


.. Cy polls the users pop mail acount on a regular basis, and upon 
finding a new message, sends <i> sends a javascript function</i> 
to the page, that gets EVAL 'd . This could do some animation in 
a canvas tag, push some message to the browser's chrome.. whatever.
 

All using the same tiny webpage. When you look at the source, you 
see 20 lines of code.

FYI, Gabrielle is the female form of Gabriele

UniServe worker processes don't support multiplexed requests (multiplexing 
is the right word used in FastCGI specs IIRC). The FastCGI multiplexing 
mode requires a form of multitasking support to be able to handle 
all the incoming requests in a multiplexed way. Without that, you'll 
end up with just multiprocessing, which is what UniServe+Taskmaster 
are doing for CGI and RSP scripts.

To open a console window for each worker process, you need to change 
the CALL command line from %UniServe/uni-engine.r:

    call join form to-local-file system/options/boot [" -qws " cmd]

Replace:
* CALL with CALL/SHOW
* -qws with -s


Also, in that case it is also more practical to reduce the worker 
number to 1 using Cheyenne command line option: -w 1

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

how can i implement a login form without sending the password in 
clear text?

ok, probably im trying to do something forbidden there


6/5-17:27:41.971934-[Logger] New request: T6/5-17:27:41.948903-## 
Error in [task-handler-55484] : Make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [switch debug-banner/opts/error [
            inline [html-form-error err file] 
            popup [debug-banner/rsp-error: make err [src: file]]
        ]]
    where: 'protected-exec
] !

If you would FORM that error, it may be a bit more like English. 
Or at least in R3

Just one question, nothing urgent. Would it be possible or smart 
if cheyenne would return http 401 to ajax request when the session 
times out? Now it basically return 200 and login form html (so I 
have to test for presence of </form>) instead of usuall JSON.

In such case, Cheyenne would just return an HTTP code with no content 
and would let the client handle the redirection to login form (or 
whatever other action is suited).

I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment 
database section in my http.cfg it works, when I uncomment it gives 
the following error in chey-pid-9036.log file:


25/1-17:58:14.625-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: "/E/cheyenne/www/centrex//index.rsp"
    arg2: none
    arg3: none
    near: [info? new [
            req/in/target: form file 
            if ext: find/last req/in/target dot [
                req/in/ext: to word! ext 
                req/handler: select service/handlers req/in/ext
            ] 
            if not req/in/file [req/in/file: new] 
            if d?: declined? req [return false]
        ]]
    where: 'throw-on-error
] !


note that there is double slash before index.rsp I don't know why. 
Error happens before I use any do-sql or something. Web page doesn't 
work at all.

Point of Information;


users.r was not on the list.  But this vote is the first official 
name pass.  There will be a way to ammend the name, but it will require 
a 3/4 majority vote to open the issue, according to existing Roberts 
Rules, which still require some form of ammendment and ratification 
for this esteemed group.

Point of Information;  The user.r 2009 roty vote code.

vote: func [name] [

    enbase/base encloak head change head insert/dup copy "" " " 16 form 
    name "roty" 64
]


Please use that function, capture the output and post your vote to 
    user.r Chat


Due to encryption issues please use   'doc, 'brianh, 'henrik, for 
Nenad Rakocevic , Brian Hawley and Henrik Mikael Kristensen.

Regarding the new attached files feature: adding or deleting files 
doesn't generate any new entry in the ticket's log. As attached files 
management is done asynchronously, it doesn't require posting the 
ticket's form to commit changes. So, the policy for logging attached 
files actions is not clearly defined yet. Your feeback about this 
topic is welcome.

Additions to v0.9.11in production:
- Added the "import account" form in registering page.

Seems that's all the differences.

About direct ticket references, I'm adding short URLs to reference 
tickets in the form: http://issue.cc/r3/<ticketid>

At this point, providing the full capabilities of OpenGL to REBOL 
seems trivial, once the image! improvements are added to Extensions 
API.


Some form of callbacks would also allow us to use a different window 
manager than VID (which would make it faster, since we wouldn't need 
to convert to rebol bitmaps at each frame).

I might be a bit more detailed, and I will not mention things other 
ppl mentioned here:


The stuff that needs adressing, at least in the form that RT states, 
WHEN and possibly in what form, are those things implemented

1. Concurrency (tasking)

2. RIF - what happened to this concept, and how important it is for 
3.0 beta?

3. Codecs - is this concept of read-all-data-into-memory usefull 
at all?

4. Unicode - what about more locale support? I need to be able to 
sort using collations, or Unicode is half-way implemented for me

5. find/not - some ppl talked about it as about important feature. 
I can see only find/first on the list

be sure that the moment I get some form of host code or plan I'll 
react to it ASAP.  This is the main "holding back" of R3 right now 
IMHO.

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

Offered by:
	TomBon
Task:

 R3 - Bindings for libcurl - the multiprotocol file transfer library
	http://curl.haxx.se/libcurl/

	C - API  -> http://curl.haxx.se/libcurl/c/allfuncs.html


  libcurl is a free and easy-to-use client-side URL transfer library, 

 supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, 

 LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET 

 and TFTP. libcurl supports SSL certificates, HTTP POST, HTTP PUT, 

 FTP uploading, HTTP form based upload, proxies, cookies, user+password 

 authentication (Basic, Digest, NTLM, Negotiate, Kerberos), file transfer 
	resume, http proxy tunneling and more!


 libcurl is highly portable, it builds and works identically on numerous 
 platforms, 

 including Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, 
 AIX, Tru64, Linux, 

 UnixWare, HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, 
 OpenVMS, RISC OS, 
	Novell NetWare, DOS and more... 

Amount:
	$150
Valid until:
	01.11.2010
Terms:
	PayPal

read and write are very similar ... can we do this?

		read: func [
			port [port!]
			/write data
		] [
			either any-function? :port/awake [

    unless open? port [cause-error 'Access 'not-open port/spec/ref] 
				if port/state/state <> 'ready [http-error "Port not ready"] 
				port/state/awake: :port/awake 
				do-request port 
				port
			] [
				sync-op port either write [ data ] [[]]
			]
		] 
		write: func [
			port [port!] 
			value
		] [

   unless any [block? :value any-string? :value] [value: form :value] 

   unless block? value [value: reduce [[Content-Type: "application/x-www-form-urlencoded; 
   charset=utf-8"] value]] 
			read/write port data 
		]

spec/headers: body-of make make object! [
		Accept: "*/*" 
		Accept-Charset: "utf-8" 
		Host: either spec/port-id <> 80 [
			rejoin [form spec/host #":" spec/port-id]
		] [
			form spec/host
		] 
		User-Agent: "REBOL"
	] spec/headers 
what exactly is this code doing?

I wonder why he can't do this 

spec/headers: make spec/headers [
		Accept: "*/*" 
		Accept-Charset: "utf-8" 
		Host: either spec/port-id <> 80 [
			rejoin [form spec/host #":" spec/port-id]
		] [
			form spec/host
		] 
		User-Agent: "REBOL"
]

In make-http-request there is this

	result: rejoin [
		uppercase form method #" " 
		either file? target [next mold target] [target] 
		" HTTP/1.0" CRLF
	] 

since it is stated that http 1.1 is being supported, we should change 
this to 1.1

it appears to me that if all the properties of the header was kept 
as strings.
then we could construct back the header's response with 
>>enline form headers
(no need to make a foreach anymore)

Small optimization:


Graham, if you try to connect to a host with an ip as a string, then 
a DNS lookup is performed even if it's useless.

On the other side, if you provide an ip as a tuple, no lookup is 
performed and it's a straight connection.


So as an example, when you enter in PASV mode (ftp proto) try this 
instead.

data-address: to-tuple to-block form copy/part tmp 4

Yes, filled in their feedback form.

I drove IOS to the limit, it's using around 140MB. Would be much 
less with a DB and it's just faster if you need to slice & dice data-records 
form one or the other side.

Are modules working correctly?

>> system/version
== 2.100.96.2.5
>> import http://www.rebol.it/power-mezz/mezz/form-error.r
>> source form-error
form-error undefined


Also, are the Imports and Globals fields (as used in Gab's Power 
Mezz) supported? ... http://www.rebol.com/r3/docs/concepts/modules-defining.html#section-3

You can't have an op! call a function with a refinement. STRICT-EQUAL? 
is only there to be the prefix form of ==.

Request for help received via REBOL.org's feedback form. If you can 
help, please post here and I'll forward him the URL of the archive:

===============

Using Rebol 3.0 Alpha, 2.100.97.3.1, how can I save the value removed 
from a series when I use the remove function? See example 1 below; 
I would like to be able to save the value "red" in a variable.  Can 
a "parse" statement be used instead of the remove. How would it be 
coded?

See example 2 below. Should'nt the value be "red"

example 1
text: "redblueyellow"
== "redblueyellow"
remove/part text 3
==text: "blueyellow"

Example 2
saved-text: "redblueyellow"
== "redblueyellow"
difference saved-text text
== "d"

I tried this an hour later and got 
== "rd"
===============

Ladislav, your B-CATCH/B-THROW example is similar to what I suggested 
in an earlier comment, but in code form. Nice code :)

And the block spec of MAKE object! is free-form. It's the same with 
MAKE map! and the case-sensitive option.

Yup. But it only really affects objects, functions and closures. 
Most types aren't affected by binding issues, and the other main 
type that is - modules - can't be serialized in a restorable form 
at all.

People who need the 'self binding sometimes with a context, and don't 
need it other times with *the same context*.

 - this is the issue in a crystal clear form. As far as I am concerned, 
 I need to bind every block supplied to the Bind function to be bound 
 the same way, when the same context is given, because I need the 
 code to behave consistently. Therefore, I dislike the state, when 
 I do not know, what "the same way" is. As opposed to that, you seem 
 to prefer to bind blocks differently, even when they are bound to 
 the same context, which seems to be necessary only in case, when 
 the usual contexts have to contain, as I call it "unsolicited" 'self.

pekr,  to-integer is a helper func.  its like form, not mold.

you shouldn't be using to-integer.. for binary arithmetic.

rebol is reversible:
>> b: to integer! a
== 32000

>> b: to binary! a
== #{0000000000007D00}

>> a: to integer! b
== 32000

Andreas - thanks for reminding me we have following form: 
>> l: 2#{11111110}
== #{FE}

>> print l
#{FE}


I just wanted to ask, if it would be possible for interpreter to 
"preserve" original written format for the output purposes?

Yes, I know. And I tried to help myself with binary. Suggestion to 
use integers, and shifting, might be accurate, but I am not here 
to crash my brain with operations I can't easily understand. So I 
try to find a convenient way. And what is convenient for me? To look 
into sources and to see, what is happening:

>> a: to-binary 1022
== #{00000000000003FE}

>> b: pad-bin #{8000}
== #{0000000000008000}

>> a or b
== #{00000000000083FE}


... you see? I could imediatelly check, that OR was correct. And 
if I would be mistaken, or needed to perform shift, I can even use 
bitmap form, to see, what is happening:

>> 2#{0000001111111110}
== #{03FE}


So - no, I will not use integers. And I don't have to, if my model 
fits what I am doing right now ... I still think that it can't fail 
me, and all those "you can't know what #{8000} means" are just theory 
for me right now :-)

It's not refined in my head yet enough but i think 'IN needs of a 
redesign.

Especially this form allowed by the specs but throwing an error currently.
>> in [obj1 obj2 ...] [a b c d]
== Error!

it could be powerfull, allowing to inherit properties from a hierarchy 
of objects (think about nested gobs with their own context)
But it's not enough...
I would like that the returned block discard the unbound words.
It would be consistent with the single form.
>> in context [a: 1] 'b
== none

I don't know if i'm clear...

I think Paul is asking for a short form of :

b: either a < 10 [a] [false]


If none is an acceptable value when the condition fails, it can be 
shortened to:
b: if a < 10 [a]

Strangely enough, the R2/Forward source is already in Power Mezz 
module form :)