AltME groups: search

Those full equivalences are great for someone who really needs to 
know how things work internally (such as when they need to clone 
PARSE), but you need simple examples first in docs for people who 
just want to use PARSE properly. Btw, has anyone started a set of 
full PARSE docs in DocBase? The parse project page could be raided 
for information, but it really doesn't serve as a full parse manual.

it would be prettier if the AltME server could serve the site itself.

I don't support GPL in any way, that is a bitch license. LGPL I don't 
know about. But if RT releases some parts, I hope those are BSD. 
And if Orca can serve for REBOL back, that is a strange situation 
to have ....

Geez, who is Meijeru ?

I like Meijeru, someone who makes bug reports that we can fix or 
dismiss. Even the dismissed tickets serve as documentation. Thanks 
for commenting on some of those, Steeve - you put it better than 
I could. Meijeru reminds me of Steeve, circa 3 months ago :)

We need to have the test suite and framework be public, in DevBase, 
and to support both R2 and R3 - just saying, not implying that they 
aren't already. By having one common suite of tests with the version-specific 
differences clearly marked, the tests can serve as docmentation of 
the differences between R2 and R3. This can also help point out flaws 
in R2 that we *want* to change, and determine the implications of 
fixing them.

actually, my task now is to define the desired results of such comparisons 
for R3, (which may serve as documentation too)

I thought that it would serve to do lookup on multiple different 
targets ("series" switching) ....

Max - what you are proposing - could it serve to support collation 
mechanism? Because what we still lack is to support specific collation 
sorting - unless it is implemented, I refuse to claim, that R3 supports 
Unicode ...

Gabriele, is it possible to dispatch multiple request to wiki TCP 
examples "pong" server listening on single port? It should be possible 
but for me second request is without response until the first still 
open. Your HTTP scheme is too much complicated to me as lecture reading 
:). I've tried to transform rebol.org webserver to R3, I've got response, 
but seems to me useles to serve one and one only connection at time 
when the port is asynchronous by nature. Any hint?

Well, if you have any questions that aren't covered by CureCode, 
ask them here, in R3 chat, or post them in CureCode. Keep in mind 
that a ticket being dismissed in CureCode is nothing to be taken 
personally - we like those tickets because they serve as documentation 
of design decisions, especially in their comments.

Pavel, what happens for me is that:

1. I start the server and it waits like it should

2. Then I start the client and transfer begins. At some point around 
10-20 MB in, the server just stops and the client returns to console. 
After a few seconds the server also returns to the console.

3. If I then start the server again, the read continues for another 
80000 bytes, like this:

>> do %/c/serve.r
Script: "Untitled" Version: none Date: none
subport read
len: 32000 total: 19192000 of 406258740...read
subport read
len: 32000 total: 19224000 of 406258740...read
subport read
len: 9000 total: 19233000 of 406258740...read
subport read
len: 7000 total: 19240000 of 406258740...read
subport close


And then the port closes and the server quits again, unless I start 
the client.

Can I use virtual hosts to serve multiple document roots on the same 
site without having separate domain names? I I would like to avoid 
"creeping" between multiple sites that don't share code and also 
use it as a tool to avoid the browser accessing code directories 
for the site.

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).

and I use it also on the R2 and R3 pages for GUI images, that I serve 
locally, as you have seen.

This recorded AltME discussion seems to serve as documentation - 
http://www.rebol.it/giesse/Temple.pdf

I can't get cheyenne to serve to an ajax json request.


I can get it to read the array as a local file but it does not seem 
to work through url request.


I played with content-type: application/json which I read was needed 
but I don't know if I'm on the right track.

Interesting ... I just Cheyenne for pure http and don't serve other 
web services yet

but every minute for hours?
im not getting any other messages...

and actually - theoretically - there is no browser window open showing 
anything from the site this cheyenne is supposed to serve

Re compression: after a deeper look, there is no way to support "on-the-fly" 
compression of static files without totally killing Cheyenne performances. 


If it is done in a mod, it will totally freeze Cheyenne on every 
CALL. If it is done in an handler, most of benefits from the async 
I/O main engine is lost, and Cheyenne will be limited to serve small 
files only (they will be transfered from workers to main process) 
and limited to 1 request per worker (so if 4 workers, maximum simultaneous 
request = 4, all others will be put in queue and waiting).


So, the only way to support static file compression is by pre-compressing 
files and adding some config options to let Cheyenne know which files 
are compressed (file sufix alone is not enough). Pre-compressing 
means having to manage compressed versions of static files (When 
and how to compress? Where to put the files? When to delete them? 
etc...)

onetom: I think there is any easy way to implement nginx to give 
you what you want without interfering with your current Cheyenne 
setup. It is to use nginx on another port (say 8000) to serve all 
your .js files. I've found nginx easy to install and configure. The 
only change you'd need to make to your system is to update the urls 
of the javascript files in your html with the port number.

Streaming: Cheyenne is sending big files in chunks of 1KB up to ~64KB, 
depending on the connection. It can serve multiple big files, but 
the scalability might be limited by the blocking disk read accesses 
delays. Other C-based servers can use OS API for async disk read 
accesses that we can't integrate into REBOL native ports.

And maybe it's a good idea to try to serve some static JSON data 
first instead of generated data to narrow down where the problems 
are.

Cheyenne-server.org is taking a long while to serve the wiki pages.

trying 0.9.12 and getting this crash:


        URL  = /bugs/
        File = /home/henrikmk/serve/www/bugs/head.rsp

        ** Script Error : Invalid path value: locals 
        ** Where: repend 
        ** Near:  [request/config/locals/instance 
%title.inc

It's the dispatch. Right now with extensions, when you make a command! 
it makes a function that is dispatched by a function in the extension 
based on a number (which you can think of ay a key), to code that 
handles the command (the value associated with the key). In theory 
this is not that different from an object! grabbing data from one 
of its slots based on the keyword you pass it. Apparently commands 
will be able to dispatch to objects soon, and the functions assigned 
to slots of that object will handle the command code.


The DELECT dialect model was based on rebcode, mostly on its JIT 
binding. DELECT added the out-of-order, possibly optional argument 
handling to the dialect decoding phase, but the dispatch phase was 
mostly left out (I commented on this at the time). The command! type 
has the dispatch model, but uses the function call model for calling 
the commands. The overlap that Carl mentions is in the mapping of 
keys to command handlers.


If you unify the command mapping models between DELECT and command!, 
then that code can be shared. This means that the DELECT function 
could do the out-of-order dialect decoding, then dispatch the operations 
as commands. Values of the command! type would continue to be called 
like regular functions in DO code or by APPLY, and then dispatch 
using the same dispatch code as above. On the other end, commands 
would either dispatch to objects (including modules perhaps) or extensions.


By the sound of it, this might also allow the command! type to serve 
as a method pointer, but we'll have to wait to see about that :)

Keep in mind that exported words that are predefined are not overriden 
by the export process. Your export of the word 'system will not change 
the setting of the word 'system in the user context. In order to 
change that you need to assign it manually. Word precedence is first-come-first-serve, 
so even if the 'system word in the user or lib contexts is protected, 
there will still be no error triggered because the export was going 
to just silently not work anyways.

A bare-bones version would be something like:

group 1 [
	value1: field
	value2: field
	value3: field
] record [table1]


which could serve most needs. Wouldn't that be the same as tying 
fields directly to a flat table?

graham, don't know if it's useful, but I think PAD can serve as a 
filler.

Here's two examples from Mikrotik RouterOS, which migh eventually 
serve as an inspiration:

http://xidys.com/mikrotik/mikrotik-collapsable-ui.jpg
http://xidys.com/mikrotik/mikrotik-many-tabs.jpg

If you are worried about encoding issues have the web server serve 
.r3 files in binary mode. DO reads the files in binary.

Oldes  thank you for quoting me outside it's contexte to serve your 
purpose that quote is  a reply to Kaj proposition to do my own R3-GUI.

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

Hopefully this patch file will serve as an example for others who 
want to do similar patching.

I understand your take on Carl's proposal for a change in RETURN 
and EXIT scoping, but it needs some work before it can do the job. 
For one thing, if you have dynamic as an option (or a default) there 
is still the need for something like R2's [throw] attribute. And 
if definitional is an option, not the default, then I'm having a 
lot of trouble justifying that option, especially since it doesn't 
solve the [throw] issue or bug#1506. It seems to me that the main 
reason for definitional is to make a simpler default for less advanced 
developers. If it's an option that the user has to chose, it doesn't 
serve that purpose. And if it's an option that gets conflated with 
the option to specify a typespec for the return value of the function, 
then this is going to get Fork furious about making REBOL more confusing, 
and he'll be right this time.

Yes, plus it took a lot of space (it adds up). Plus the objects that 
didn't have that field behaved badly - such objects were created 
to serve as function contexts, or by functions like USE and FOREACH. 
Since all of the code that worked on objects had to skip past the 
first field ('self), if the first field wasn't 'self it was still 
skipped. Plus the 'self field was writeable, which made code injection 
attacks possible when running untrusted code - not really a concern 
for R2 with its known insecurity in such situations, but for R3 it's 
a design criterium to be able to sandbox code. It is really better 
to not have the field at all, and just make it a keyword in certain 
limited circumstances (imo).

auto-login: func [/force] [
            all [
                any [force prefs/auto-login]
                prefs/user
                prefs/pass
                attempt [login-serve prefs/user prefs/pass]
                true
            ]
        ]

Mixins in R3 often serve the purpose that #include did in PREBOL, 
but currently need to be loaded from files at runtime. We need a 
preprocessor in order to get the mixin functionality from embedded 
modules. This is what is needed to do the R3 equivalent of encapping 
(host builds).

Regarding the http://issue.cc/r3/1893


The USE-RULE/NO-REBIND variant can serve as an example of a case, 
where "early binding to function context" would make the code more 
flexible.

Ladislav, right now the best documentation of mixins is the source 
of the DO-NEEDS and MAKE-MODULE functions in DevBase. There are also 
the CureCode tickets related to them. But there aren't that many 
docs for them, and the behavior might be yet be tweaked. If you have 
any questions ask here, and I will answer as I can. But I'm going 
to be busy this month, so patience would serve you well here.

Gregg - right, I forgot that one - 'call, and very bad console, which 
did not serve initial purpose - being usable via ssh etc connection 
anyway ...

Tonight's Moment of REBOL Zen:


The /local refinement in functions is just like any other refinement. 
This again mean, any refinement can be used for local variables, 
like in this example:

exp2: func [
	"2 raised to exponent"
	exponent [number!]
	/il-locale number [number!]
][
	if not il-locale [number: 2]
	number ** exponent
]

>> exp2 3
== 8.0
>> exp2/il-locale 3 3
== 27.0


But HELP will search for the /local refinement, when producing its 
output. But as any word, HELP can just be redefined to serve ones 
needs. HELP is even a function, so its source can be looked at, if 
someone wants to produce ones own HELP function.

The long wording is for precision, and because these tickets serve 
as documentation of the issues for future reference.

Andreas: that's the idea. All Red/System features are here to serve 
either the interfacing with OS and third-party libs (mostly C libs) 
or to serve the upper layer (Red) needs.

BTW, the "manual" is supposed to be a (more or less formal) specification 
of the language, but as I didn't have time to write a separate user 
manual, it now tends to serve for both uses.

Steeve: certainly, but as you might have noticed, Red/System current 
implementation is a bootstrap for the Red/System future version written 
in Red. So all the current Red/System code written in REBOL, will 
be trashed once Red will be mature enough. Adding heavy optimizations 
at this point would be just a waste of time and energy that would 
serve no purpose.

pekr, in this case, wrap another dll around it, a.k.a. "thin layer" 
dll.


use a C++ compiler, but use the functions within a C sourced dll 
project.  this dll will then serve as your translation from the C++ 
libs to Red/Rebol whatever.    If the C++ use requires special steps 
on function entry/exit, the compiler will add these for you (when 
it compiles) and from outside the C function you'll be back into 
"normal land". 


 I've even read that some C++ compilers can't even properly use libs 
 from a different C++ compiler.

When I was trying to replicate the R3 word syntax, it was partly 
to document R3, partly to serve as the basis of a more flexible TRANSCODE 
that would allow people to handle more sloppy syntax without removing 
the valuable errors from the regular TRANSCODE, but mostly it served 
to generate new CC tickets for syntax bugs that we weren't aware 
of because the syntax wasn't well enough documented, and they hadn't 
come up in practice yet.