World: r4wp

If they accept pull requests, they might have a shot of being an 
aggregator of development, like Linux maintainer repositories.

Anyone happens to know who we have as admins of the R3 project CureCode?

Or in a related question: what's the intended meaning of the "reviewed" 
status for R3 CC tickets?

We are (going to) accept pull-requests for our R3. IMO we need to 
move forward in those times where Carl isn't active.

Will you try to "sync" your changes with the "official" source in 
the future or let the sources diverge?

That's up to Carl. We will do pull-requests for our changes. But 
we are not going to wait.

Brian: Carl stated to me that QUERY was meant to return port state, 
not perform an action. But, I've never seen a final document that 
explains how R3 ports are supposed to work.

Gab, any idea of what the error is that corrupts the scheme after 
a forbidden read?

I'd have to review the code, the main problem with errors is that, 
again, port behavior is really not defined explicitly for that, and 
Carl never answered.

http://www.curecode.org/rebol3/ticket.rsp?id=1918&cursor=17

I have a PDF with the state diagram for HTTP, that may help you figure 
out the error problem. It's also possible that it was intentional 
in the sense that it is safer to initiate a new connection in case 
of error (though, some errors should be exceptions to this).

It corrupts the very next new connection

so possibly something in the http scheme object ?

very likely, the port needs to be reset after the error. perhaps 
a QUERY does it. I don't remember.

I posted the diagram in the files here.

Hmm.  The port is anonymous

Yes, those diagrams look the same I think as on the rebol.net wiki

ah, you're right, then there must be something that is global and 
should not be.

which is why I was thinking the scheme object

because it reports the same error

maybe i'm using a block or object somewhere without clearing / reallocating 
it

Oh well, if you have some spare cycles

i'll keep this in mind, but this month is very busy here.

Anyone happens to know who we have as admins of the R3 project CureCode?
 Carl, BrianH and me.

Who decides an issue is closed?

Who can re-open issues?

what's the intended meaning of the 

reviewed" status for R3 CC tickets?" It means that the ticket has 
been acknowledged/accepted and will be processed. At least, that 
was the initial meaning, maybe Carl and Brian used it differently 
afterward.

Who decides an issue is closed?

 Depends on the convention set for R3 project. I usually consider 
 that it should be closed by the developer processing it, once the 
 issue is fixed. It could also be closed by the one that opened it 
 if he's satisfied by the provided answer or the fix.

Who can re-open issues?

 Admin can, Developer should too. Currently in addition to admins, 
 there are 3 people with Developer roles/rights: Henrik, Cyphre and 
 Gabriele.

Looks like we need more people with developer status

Is there any prototype of FTP scheme for R3? IIRC Graham did something 
in the past?

Pekr, my schemes are still available on github.  They are all async 
and need to be rewritten as sync.
to get them to work you need to make the following changes:

1. In the header, change from 

module: 'name 

to 

type: 'module
name: 'name

make-scheme => sys/make-scheme


There's also some odd about contexts inside modules.  You need to 
declare your variables inside /local as you can get a context error 
if they are used but not so defined.

That's pretty much all the change I had to make to the prot-smtp.r

then 

s: open smtp://smtp.host.com
read s

will send the preconstructed email.

Going to change that to

write smtp://smtp.host.com [ 
			esmtp-user: 
			esmtp-pass: 
			from:
			name:
			to: 
			subject:
			message: 
		]

once I figure out al these context issues

Robert, do you guys have other schemes written so we don't duplicate 
?

rebol [
	type: 'module
	name: 'test
	version: 0.0.1
	notes: {
		to illustrate a a context issue.

  free variables defined inside a module are supposed to be "global" 
  to the module only.
		See http://www.rebol.net/r3blogs/0048.html
	}
]

do test: func [ ][
	set 'new-word none
]

>> do %test-module.r
Module: "Untitled" Version: 0.0.1 Date: none
** Script error: new-word word is not bound to a context

** Where: set function! do -apply- make catch either either -apply- 
do
** Near: set 'new-word none

this works though

do test: func [ /local new-word ][
	set 'new-word none
]

this also fails

do test: funct [ ][
	set 'new-word none
]

Thanks Graham, that seems to be the correct behavior. We should adapt 
those for the test suite.

The design of the module system has changed since that blog. In order 
for free variables to be defined at the module level, they need to 
be set at the top level with set-words like an object. Also, FUNCT 
only collects set-words, so it's correct that in your last example 
it doesn't treat iot as a local.

An isolated module acts like the blog suggests though.

I think we'll really need coherent documentation for the intended 
status quo of the module system soon.

This is a trifle frustrating that the docs are not being updated

Yes. Actually, there's a pull request that represents the current 
intended design of the module system ( https://github.com/rebol/r3/pull/40
). And I'm working on a set of tests that should help document it 
as well.

Docs not being updated? The user-level docs were never written. I 
still need to update the guru docs. It's worse that you thought.

that -> than

That pull request unfortunately only covers a teensy tiny bit.

Nope, it just fixes the last non-working part.

But without it you don't have the intended behavior.

For one aspect.