AltME groups: search

Robert, Nenad's intial plan was for the Red compiler to directly 
generate machine code. So his first presentation reflects that. It 
was a few months after the launch that he decided to generate Red/System 
code from the Red compiler.

Browse the runtime: agreed, but we could ease that by adding support 
for docstrings in functions and use them to auto-generate a reference 
doc for the runtime functions. I remember Peter suggesting me that 
months ago, maybe we could also start working on it now. I think 
that some minor modifications to functions spec block parsing rules 
should suffice. For other elements like namespaces, enums, aliases, 
we could allow an optional docstring somewhere to document them too. 
I can do the required modifications on the compiler quickly if someone 
is willing to write the docstrings?

Oldes: I've changed the 'comment implementation to be more like REBOL, 
so it consumes the next expression, but does not generate code for 
it (so you're above example with 'x won't work in Red/System). Also, 
it cannot be used in functions spec blocks anymore, so we still don't 
have a true multiline comment support. Suggestions about that are 
welcome.

dynamic/shared libraries support? Ability to generate a DLL? Is it 
e.g. any prerequisite to come to Android, or just useful generally?

Ability to generate DLL, yes. It is a prerequisite for Android (and 
probably iOS/OSX) support.

How do I generate DLL? I added #export but it stills create .EXE 
file. Should I just rename it, or is there some compiler switch?

yes, generally we are now able to write low level binding using rebol 
like syntax, generate libraries for environments like Delphi, etc., 
which e.g. my friend still uses :-)

you used -dlib option, does it replace -t one? Not skilled here, 
but - can I generate e.g. ARM executable/library from Windows Red/System? 
Or is target environment needed?

can I generate e.g. ARM executable/library from Windows Red/System?


You can cross-compile ARM/ELF code from Windows or MacOSX, just use 
the appropriate target (https://github.com/dockimbel/Red). Currently 
there's only two ARM targets: Linux-ARM and Android. You can cross-compile 
to these targets from any platform Red/System compiler works on.

I'll finish my new CMS first, or I should say publishing system together 
with the scripts I put on rebol.org lately. Then I will be able to 
publish code and story easier within my pages. I don't want the massive 
make-doc-pro and makedoc2 isn't my flavor. The ancient version from 
Chris Ross-Gill looks good but has some choices I dislike. So I am 
struggling with it too make it easy to use and with it I want to 
be able to generate a pdf version using Gabriele's pdf-maker script.

So 1 source and generate goodlooking webpages or pdf with it.

It adheres to REBOL convention for naming functions (starting with 
a verb) but it also serves other purposes:


- as a way to classify the compiler internal functions by category 
or compilation stages, e.g., comp-* functions do the translation 
+ code generation, fetch-* just fetch source code, check-* perform 
type or spec verifications, emit-* just generate target code, etc...


- as a way to stratify the code in compiler context. As I want to 
keep the compiler internal code in one piece (because of too many 
common dependencies). It helps me navigate quickly in the code when 
searching for a bug for example.

Although I'll be away the coming week, so I probably won't be able 
to generate them then

To put it concretely, the AVR backend needs to generate a memory 
image, without external symbols because there is no operating system, 
but with all internal addresses resolved. Can that memory image be 
constructed by appending data-buf and code-buf?

If someone writes the doc tool that Doc proposed, you could generate 
separate documentation for the bindings

Jerry: I don't have enough time for that, I am counting on the doc-strings 
and extraction tool to generate such documentation automatically. 
Peter is working on such tool.

Also, REBOL-like languages are easy to generate from a dialect. A 
translator could write data files in a dialect, which could be used 
to generate the wrapper functions and assignment statements. And 
a half-way decent optimizer could get rid of the wrappers using the 
same methods that would allow it to statically resolve refinements. 
There's no reason to support an astoundly worse method.

I have just uploaded a basic script to generate Red/System API docs 
to Github. It could do with a lot of polishing, perhaps you could 
take a look?

The cool stuff to show-off would be - bring your Red on your SD card/USB 
stick, plug-it-in, go to its dir = show "no-instal" option, show 
some GUI dialect, press a button, generate android app, and with 
one command or a dialect, push it to Google play. Then I can send 
you my friends short/long description, how long it took him to get 
his app there, downloading and installing all the JAVA crap and all 
dependencies ...

It seems that is uses some REBOL templates to generate some additional 
C code during the building process, like this one:

https://github.com/rebol/r3/blob/master/src/boot/types.r

It would have to be something that can be processed by Red but still 
able to generate stand-alone Red/System

About reflection, will there be a compile option to turn it off, 
for commercial code that should stay closed?


What I planned so far is a compile option to switch between different 
modes of bundling the functions/routines source code into the final 
executable. Main options are: 

- in form of native "build instructions" (the current behavior)
- in form of compressed text


The latter option will generate smaller executables, but will be 
slow down boot time a little, as it will require the interpreter 
to process it. The former option provides a high level of obfuscation, 
that requires a lot of work to decompile (cracking REBOL's SDK protection 
is probably an easier job).

Makedoc format allows the addition of REBOL code at the end. The 
proper way to generate the doc files is to CD to the folder, then 
run REBOL on %red-system-quick-test.txt

NickA - I share your point of view. Ppl mostly nowadays think, that 
the web rules it all. However - it is still complex. I don't care, 
if we generate HTML5 (whatever it is) in the end, as far as we can 
very easily build apps using VID like dialect. I remember those initial 
days, where we had really a small script (1.6KB) to show image from 
4 webcams ...

Actually, we could just make the compiler recognize such case and 
generate a call to the interpreter without you having to specify 
DO. The drawback would be that all subsequent values in that block 
level, would be passed to the interpreter too, as the compiler can't 
determine the expression boundaries. I'm not very fond of such option, 
but it is a possibility.

What I see as a first possible step is have a kind of Red website 
hosting where websites can be hosted using Red (cheyenne server) 
and a database behind it (MySQL or SQLite) and a possibility for 
digital payments (such a module could be additionally payed and kept 
'closed' source). This could obviously generate a modest cashflow.
There would be needed books etc.

Ok, lot of stuff there. So let me explain how I typically operate 
to make this the easiest way for me to help.  I need ONLY the relevant 
files to install, complete with same instrucitons for installation 
that produced the error.  I need to know specific versions as well. 
 Once I know I can re-create the problem, then I need sources (at 
least any programming sources you have) and any symbol files you 
may have or can generate (pdb) files preferred.

No installation is needed, but Red doesn't generate extra symbol 
files

Clearly. From a testing and coverage perspective, it would be great 
to have a matrix (and an easy way to generate it) to see how complete 
each type is, or make sure you have everything in place when building 
a new type.

Peter has already started something in Red/docs/generate-reds-api.r, 
but it might be just for extracting doc-strings.

Yes - Red/docs/generate-reds-api.r just extract docstrings ... but 
it shouldn't be hard to generate the datatype matrix.

Important thing to note: system/thrown needs to be manually reset, 
as the last thrown value will stay there if no exception occured. 
Such reset could be done before each call to a function that could 
generate an exception or after processing the thrown value.

Another note: messing up with the stack (using push/pop) in a user-function 
is fine as long as you returned the stack clean before calling a 
function that could generate an exception. Failure to do so will 
result in a crash. It might be possible to make stack-unwinding for 
exception resistant to such cases, I will investigate that.

btw - would there be any benefit with the Red's ability to create 
shared libs, for R3 guys? R3 can already use Red to generate extensions, 
right? And R3 lacks the interface for DLLs. Maybe for R2 guys?

That base should be enough for a start, the hard part now is to generate 
the resources tree with all the right entries ...far from easy.

Doc, tried to clone your examples, so that I could do some first 
tests by trying to adapt your code, I got into strange problem. I 
copied your hello.red into pekr.red and generated the pekr-lib.dll. 
Changed bridge.java to load pekr-lib.dll. And - it works. However 
- when I tried to clone bridge.java into pekr.java, or simply change 
"class bridge {" to e.g. "class fridge {", to generate differently 
named java app (fridge.class), it does not work. Is bridge class 
somehow hardcoded somewhere in the API?

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

Dynamically generate UI elements: yes, of course.

In a short - Red compiles to Red/System. Red/System is intermediate 
language, which then compiles to native platforms. Red/System can 
also generate shared libraries. It all means, that from Windows, 
you can generate OS-X, Linux etc. programs or libraries.


As for Red itself, it is not only compiled though. Doc's intention 
is to bring in a modern hybrid, which will work as compiled, jitted, 
or interpreted, upon the need of the programmer or the app. So, what 
we have also got is Red interpreter and console too. JIT has yet 
to come.


Recently Red is not complete, Doc took some side-way to bring in 
Android support. That means we had to have shared libraries available 
first, then JAVA/JNI bridge (which is done), nowadays Doc works towards 
generating first .apk. He is on vacation till 3rd of June though. 
After that is done, we will get objects, I/O and parse (IIRC Gabriele 
will write it, just waiting for object support)

So far I have mostly talked about the ability to write R3 extensions 
in Red and Red/System, because I made a specific bridge for that. 
But with Red's ability to generate shared libraries, you can also 
make generic extensions for other systems, such as R2 and World. 
You can write libraries in Red and then import them with the DLL 
interfaces in World and R2

It's part of Red/System runtime library which is undocumented so 
far. Some of the contributors have made some extraction tools to 
generate automatic docs, but none of the initiative has reached a 
usable state...

How hard would it be to have Red generate .SYS Windows drivers?

However, it's more logical to put constants last, and it can also 
generate more optimal code in Red/System

Now we can generate the random numbers using the random algorythms. 
It is still a long way to make the random function like REBOL's random: 
http://www.rebol.com/docs/words/wrandom.html

If the automation script I'm working on work, you'll be able to generate 
an APK without download the SDK and JDK! ;-)

You need to change a few things in the build script to generate x86 
apk.

In order to be able to generate x86 target, do the following:

- copy %build.r into %build-x86.r


- change make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86

- change "-t Android" => "-t Android-x86"


- change "rejoin [%../red/bridges/android/ bin-dir/lib/armeabi" => 
"rejoin [%../red/bridges/android/ bin-dir/lib/x86"


- run %build-x86.r - generates an apk and if you ran arm version 
previously, will pack both versions into one .apk

Can the RED compiler generate PDB files?

Difference between Github's web UI and Fossil's web UI is that Github 
can generate stable download URLs for the "latest" version. That's 
a huge difference even from an efficiency standpoint.

Most systems seem to generate 31 random bits

Cool. The host backends for R3 are quite firmly in its C source, 
though, so it wouldn't be much use to use my Red/System code: you'd 
need to write the port in C to integrate it in R3. Perhaps a part 
of it could be split off in the R3 devices architecture for hosts, 
but that's incomplete, and you would have to handle a host implementation 
in an extra Red/System shared library, because the Red/System compiler 
doesn't generate object files or static libraries yet to link into 
the R3 executable

parse-int-values: func [

    "Parses and returns integer values, each <n> chars long in a string."
    input [any-string!]

    spec [block!] "Dialected block of commands: <n>, skip <n>, done, 
    char, or string"
    /local
        gen'd-rules ; generated rules
        result      ; what we return to the caller

        emit emit-data-rule emit-skip-rule emit-literal-rule emit-data
        digit= n= literal=
        int-rule= skip-rule= literal-rule= done= build-rule=
        data-rule skip-rule
][

    ; This is where we put the rules we build; our gernated parse rules.
    gen'd-rules: copy []
    ; This is where we put the integer results
    result: copy []

    ; helper functions

    emit: func [rule n] [append gen'd-rules replace copy rule 'n n]
    emit-data-rule: func [n] [emit data-rule n]
    emit-skip-rule: func [n] [emit skip-rule n]
    emit-literal-rule: func [value] [append gen'd-rules value]
    emit-data: does [append result to integer! =chars]

    ; Rule templates; used to generate rules

    ;data-rule: [copy =chars n digit= (append result to integer! =chars)]
    data-rule: [copy =chars n digit= (emit-data)]
    skip-rule: [n skip]

    ; helper parse rules
	digit=: charset [#"0" - #"9"]
    n=: [set n integer!]
    literal=: [set lit-val [char! | any-string!]]

    ; Rule generation helper parse rules
    int-rule=: [n= (emit-data-rule n)]
    skip-rule=: ['skip n= (emit-skip-rule n)]
    literal-rule=: [literal= (emit-literal-rule lit-val)]
    done=: ['done (append gen'd-rules [to end])]

    ; This generates the parse rules used against the input

    build-rule=: [some [skip-rule= | int-rule= | literal-rule=] opt done=]


    ; We parse the spec they give us, and use that to generate the

    ; parse rules used against the actual input. If the spec parse

    ; fails, we return none (maybe we should throw an error though);

    ; if the data parse fails, we return false; otherwise they get
    ; back a block of integers. Have to decide what to do if they
    ; give us negative numbers as well.
    either parse spec build-rule= [
        either parse input gen'd-rules [result] [false]
    ] [none]
]

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

I hope it is not rude to leave a question here as opposed to be here 
for the disucssion live, ala IRC. Please forgive me if so, and if 
so I will ask again when others are present. I will break down my 
script into smaller part questions as time goes on. First thing, 
I am under the impression that if I can generate a random number 
between 1 and 1 billion and assign this result to an aribtray variable 
word like so

token: random/secure 1000000000


I want to email my newly generated random number to someone. So I 
thought of this:

send [person-:-example-:-com] "Thank you. Your number is token."


One second later I realized that will just the send the actial word 
token, not the number the variabkle word token represents.

Is the above a correct way to generate a random number?


How do I insert that random number into the body of the text of an 
email to send someone? (send [person-:-example-:-com] "Thank you. Your 
number is [token]" maybe?)


 Thanks for your help in advance, apologies for any breach of rules 
 or etiquette. 
etiquetteetiquette

You need to seed the random generator first eg. with the datestamp 
or something, and then generate your random number.  But a better 
way is to create a UUID if you want something guaranteed to be unique.

The library has code for windows http://www.rebol.org/view-script.r?script=guid.r

Just using random, something like this should work

random/seed form now/precise


send [person-:-example-:-com] rejoin [ "Thank you. Your number is " random/secure 
1000000  "." ]

Sunanda: Thanks again for issuing the World invitation. Everyone 
thanks for the continuing help.


I have read the cited document, but it just leaves me with more questions.

Is the following literal?

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


 That is to say should I type exactly that? Or is cgi-string for example 
 a theoretical variable assignment that I could call anything? Are 
 they all proper commands, or is any part of that just for example 
 purposes?  I am thinking I should copy and paste it verbatium. I 
 am also thinking I mispelt verbatum.


 I am stuck with GET. Does this mean I can leave out some code that 
 makes up for  not knowing if the original data is POST vs GET? These 
 are hypothetical questions for better long term learning. I for now 
 will go with the idea that everything is as straight fowarrd as it 
 seems. I know that my GET stream will have "trnEmailAddress" in it 
 which is a field that will contains an email address.


 So will the following  generate a random number, extract the address 
 and email the same random number to that email address?

token: random/seed now/percise

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


send trnEmailAddress rejoin [ "Thank you. Your number is" token "." 
]


 Graham: Thank you for the extra info on GUID, but Windows is not 
 involved here. I realize that random number generating really isn't 
 unless you have a monkey throwing darts at a numbered board. Regardless 
 extra effort to 
make a number unique is useful and your advice appreciated. 


 I do not think the corner cases will come up and the people who control 
 the original form assured me that web page issues warnings if the 
 form is not filled out correct which should help. I do realize that 
 people are idiots, systems are not fool proof, etc. What I am saying 
 is my basic needs are basic and I should be OK so I am not fretting 
 over those examples. It is great though to know the solutions are 
 out there when I need them.

 Tahnks.

John you have to seed the generator first and then generate your 
number
And you can dispense with the cgi-string by 

cg-block: make object! decode-cgi read-cgi

Graham: Sorry I was not clear. I was refering to you stating that 
I have to seed the generator first then generate my number.

Hi Bas, no didn't know that one, maybe there should be an universalopensubtitleday 
to generate more attention to it :)

I meant system. exec didn't work. I still prefer system above passthru. 
I have integrated my first REBOL module within my website. I needed 
to add a cookie section to obey the new cookie law anyway. I even 
used a REBOL script to generate all cookie pictures to the same size 
and png format.

sunanda, actually, I just realized that if I switched the order in 
the all, I can fix the issue :-)

and you are right, I should generate a temp object...  but if you 
put the above in a function it would be like so:

equivalent?: func [ o1  o2 ][

 all [   (words-of   o1) =  (words-of   o2)    o2: make o1 o2     
 (values-of  o1) = ( values-of  (make o1 o2))  ] 	
]

On the form validation issue. I managed to get things working as 
I initially intented. Using a Javascript function to change the text 
of the field: 
var changer = document.getElementById('fieldid');
changer.value = fieldvalue;
Where fieldvalue was filled from the cgi data block cgi/fieldname

It was really fun to get this right with all the needed double-quotes 
and curly braces that alle represent comments in rebol as you know 
and generate this from within the well-known function emit: func 
[code] [ repend html code]
I had to add an id tag to all the form fields.

Endo, when you are using set-words with MAP-EACH and R3's FOREACH, 
be sure to include at least one regular word, or it won't advance 
and you'll get an endless loop. We made that possible in order to 
support the foreach [x:] data [... take x ...] code pattern. It's 
the type of thing that would generate a warning in other languages, 
but REBOL is inherently incompatible with warnings.

I made a program that embeds a dll to generate a cellular automaton 
image. Could someone test it for me?     http://pastebin.com/raw.php?i=67KtcSK3

So I have a question about RSA encryption. When I run the following 
code:

  rsa-key: rsa-make-key
  rsa-generate-key rsa-key 1024 3

  crypt-key: copy/part checksum/secure mold now/precise 16
  print crypt-key

  crypt-key: rsa-encrypt rsa-key crypt-key
  print crypt-key

  crypt-key: rsa-encrypt/private/decrypt rsa-key crypt-key
  print crypt-key


it runs perfectly, encrypts the crypt-key and then decrypts it sucessfully.


As you probably know, the purpose of the RSA algorithm is to allow 
someone else to encrypt data that only you can decrypt using your 
private key. I tried this with a different public key using the following 
code:

  rsa-key1: rsa-make-key
  rsa-generate-key rsa-key1 1024 3

  rsa-key2: rsa-make-key
  rsa-key2/n: rsa-key1/n

  crypt-key: copy/part checksum/secure mold now/precise 16
  print crypt-key

  crypt-key: rsa-encrypt rsa-key2 crypt-key
  print crypt-key

  crypt-key: rsa-encrypt/private/decrypt rsa-key2 crypt-key
  print crypt-key


So I put the public key from rsa-key1 into another object, rsa-key2 
and tried using it to encrypt the data and get the following error.

	#{DD44AC1810E9A7020FAD72A7CFA54100}
	Segmentation fault


How do I get the public key from the first object into the second 
object so that it can be used to encrypt data?

;key1 - contains public and private keys
rsa-key1: rsa-make-key
rsa-generate-key rsa-key1 1024 3

;key2 - contains only public key
rsa-key2: rsa-make-key
rsa-key2/e: 3
rsa-key2/n: rsa-key1/n

;data to ecrypt encrypt 
data: copy/part checksum/secure mold now/precise 16

;encrypt data using the key2 (with pub key only)
crypt-key: rsa-encrypt rsa-key2 data


;decrypt data(that have been encrypted using key2) using the key1(needs 
to contain private key)
data2: rsa-encrypt/private/decrypt rsa-key1 crypt-key

either equal? data data2 [
	print "decrypted data match the original - decription passed"
][

 print "decrypted data differs from the original - decryption failed"
]

Nick -- sounds like you want an algorithm that, say, returns the 
next 50 -- that way you can work with a window rather than have to 
generate all perms in one gulp. Some of the offered solutions should 
be easily adaptable in that way.

Hey all, I'm having such a good time learning again!


I've got some code to generate a print ruler, but I think it could 
be cleaned up a lot more.   

If some of you have a quick moment, could you take a quick look and 
advise me on how to shorten this code.

ruler1: copy ruler2: ""
idx: 0
loop 110 [
	idx: idx + 1
	append ruler1 "_"
	append ruler2 last-digit: last to-string idx
	if last-digit = #"5" [
		clear back tail ruler1
		append ruler1 "+"
		]	
	if last-digit = #"0" [
		either idx < 99 [clear back back tail ruler1]
			[clear back back back tail ruler1]
		append ruler1 to-string idx
		]
	]
replace/all ruler2 "0" "_"
print ruler1
print ruler2



____+___10____+___20____+___30____+___40____+___50____+___60____+___70____+___80____+___90____+__100____+__110

123456789_123456789_123456789_123456789_123456789_ 123456789_123456789_ 
123456789_123456789_ 123456789_123456789_

parse-int-values: func [

    "Parses and returns integer values, each <n> chars long in a string."
    input [any-string!]

    spec [block!] "Dialected block of commands: <n>, skip <n>, done, 
    char, or string"
    /local
        gen'd-rules ; generated rules
        result      ; what we return to the caller

        emit emit-data-rule emit-skip-rule emit-literal-rule emit-data
        digit= n= literal=
        int-rule= skip-rule= literal-rule= done= build-rule=
        data-rule skip-rule
][

    ; This is where we put the rules we build; our gernated parse rules.
    gen'd-rules: copy []
    ; This is where we put the integer results
    result: copy []

    ; helper functions

    emit: func [rule n] [append gen'd-rules replace copy rule 'n n]
    emit-data-rule: func [n] [emit data-rule n]
    emit-skip-rule: func [n] [emit skip-rule n]
    emit-literal-rule: func [value] [append gen'd-rules value]
    emit-data: does [append result to integer! =chars]

    ; Rule templates; used to generate rules

    ;data-rule: [copy =chars n digit= (append result to integer! =chars)]
    data-rule: [copy =chars n digit= (emit-data)]
    skip-rule: [n skip]

    ; helper parse rules
	digit=: charset [#"0" - #"9"]
    n=: [set n integer!]
    literal=: [set lit-val [char! | any-string!]]

    ; Rule generation helper parse rules
    int-rule=: [n= (emit-data-rule n)]
    skip-rule=: ['skip n= (emit-skip-rule n)]
    literal-rule=: [literal= (emit-literal-rule lit-val)]
    done=: ['done (append gen'd-rules [to end])]

    ; This generates the parse rules used against the input

    build-rule=: [some [skip-rule= | int-rule= | literal-rule=] opt done=]


    ; We parse the spec they give us, and use that to generate the

    ; parse rules used against the actual input. If the spec parse

    ; fails, we return none (maybe we should throw an error though);

    ; if the data parse fails, we return false; otherwise they get
    ; back a block of integers. Have to decide what to do if they
    ; give us negative numbers as well.
    either parse spec build-rule= [
        either parse input gen'd-rules [result] [false]
    ] [none]
]

Back in 2001 I created an intranet site for a local celebrity by 
making the database tables, then having R2 use the 'columns command 
to generate column lists that were used to autogenerate the server-side 
pages for the intranet. All it took was one function call per table 
to generate the whole site. Restyling the site just meant editing 
the HTML template in the function (this was before CSS was practical).

If you build a query dynamically with rejoin or something, the query 
is put together client side and then the server has to generate a 
new query plan for each distinct set of parameter values. This takes 
time and blows the query plan cache, which slows down the whole query 
process.

Not sure exactly what you mean Robert. I've written tools to generate 
Apache configs, if that's along the lines of what you're doing.

This group is for the discussion of Red documentation. I think it's 
important enough, and will generate enough chat, that it deserves 
its own group. See #Red for previous doc chat.

So storing the docs in source format in a DVCS repo would allow us 
to generate static web pages for the docs, avoiding   (potentially 
painful) tweaking and maintainance of a PHP-based wiki engine.

GitHub Pages also serves up static html/css/js. Still, if you couldn't 
use any server-side scripting, you'd need to pre-generate the html 
and I guess you wouldn't want to do that.

So the Red docs are not makedoc(2) specific. You only want to be 
sure that they are in a format that can be handled using scripts 
like makedoc123 and generate all kinds of documenttypes, like webpages, 
pdf, (epub?) etc. If I understand correct.

If you have TO_OS=TO_LINUX, then you need to generate a Win32 makefile 
first.

Graham, HTTP GET is supposed to be repeatable without side effects, 
and thus safe to cache. HTTP POST is supposed to generate side effects, 
and thus not be safe to cache.

I would prefer MOLD/all -0.0 to generate "-0.0". As for MOLD, I'm 
on the fence: If the difference between 0.0 and -0.0 is significant 
enough semantically, but not too confusing to the regular programmers 
that MOLD is targeted at, then why not? We definitely don't want 
MOLD and MOLD/all to be the same though, because there are too many 
developers that want to keep the illusion that 0.1 exists. Having 
a display setting to have the interactive console print values with 
MOLD/all instead of MOLD makes sense though.

Right, because they print approximate values. If your proposal is 
to change MOLD to generate the smallest value that, while not actually 
being the value in memory, would generate that value in memory as 
a result of the loader trying to approximate what you wrote, then 
I might be OK with that if it can be done efficiently. If it can't 
be done efficiently, I'm OK with doing what all of the other non-scientific 
languages do and just use 15 digits.

Gregg: I'm all for constraints if there is a significant "win" component. 
 If it doesn't, don't constrain it.  Apple, but especially Microsoft, 
are really good at artificially constraining software.  Frustrates 
me to death.  Most of the time, it just seems like a poor design 
decision.  Other times, I can see how the constraint is being used 
to generate revenue.

We are giving developers more control by saying that some stuff is 
under their control (i.e. the code blocks). We are providing some 
safety by saying that some stuff is presumed to be not under their 
control and thus possibly suspect (i.e. immediate-evaluation parameters 
to functions that they didn't write). We do screening of some stuff 
because that cuts down on the screening they have to do themselves. 
That way dvelopers can use functions and assume that they are safe 
to use by default.


For instance, one advantage of #1993 FOR would be that they would 
have to go out of their way to make it do an infinite loop, since 
no combination of start, end and bump would generate one. That means 
that they wouldn't have to wrap calls to FOR in expensive conditional 
code, they can just pass in any values of those parameters and trust 
FOR to never go infinite without them expecting it. Your CFOR would 
not have that advantage, but since it takes code blocks for all parameters 
it is assumed that you are more careful about those code blocks, 
as you should be as a general rule in R3.


It's about providing a balance. Complete consistency in how all parameters 
are treated regardless of their nature would not allow us to help 
developers where they need it. However, having a consistent policy 
that code must be treated more carefully by developers than non-code 
allows developers some flexibility while still allowing them to be 
careful. That is why code that developers provide explicitly is considered 
to be what they want to do, at least from the outside of functions. 
And you can make the distinction between code and non-code using 
simple type tests, which is why we have APPLY and ASSERT/type.

if you supply none, you generate an "empty" struct

There's already an optional "see also" header, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ascii-chart.r

And there's no reason why that can't generate a footnote in the same 
way that the "replaced-by" header does, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=calc-engine.r


All we need now is a volunteer to go through 600+ scripts and group 
them together.

Hey, fun stuff -- REBOL.org just got attacked by some sort of spambot 
trying to generate hundreds of fake signup accounts.
It managed to create 10 before our bot detection kicked in.
They must think we're stupid.

Yep, we have our  own sort of flood detection running. I call it 
RID (rampaging intruder detection)


Problem with a captcha tyope solution is that we may need View to 
generate the random images. But our CGIs currently can only run under 
Core. Plus it disadvantages the visually disabled.

Each time I see an attack like this, it gives some more ideas for 
tightening up. Most of the time (like tis time) were one step ahead 
of the vandals.

I  auto generate the  words so when a new rebol comes out I can notice 
if a word I happen to use already has a builtin purpose

Anyone know the answer to this one? 

I have a cgi script that sends an email out. The problem is that 
I want to send to an address that has the same domain name as the 
website but whose mail server is not located there (It's an Exchange 
Server). Any other address works fine as expected. I think it has 
to do with the mx records but, the weird thing is that if I generate 
an email via php, it goes through. Therefore I'm thinking Rebol can 
do it too. 

I've used set-net  for the smtp server and have set it a different 
server completely but still no go.
And I'm in the process of having the MX records changed.

The generating part will be asking you a few questions and the generate 
matchhing config files and binaries that you can copy to an empty 
Linux box with only lighttpd installed (or enginx)

hmm, it is long time ago I looked at Temple sources, but it seemed 
to me, that first phase generates block of blocks ... then you use 
some functions, e.g. find-by-id, etc., which does lookup in rebol 
block structure and then it replaces/adds data to it. Now once you 
generate html content, how does it know about its original formatting? 
You would have to store pointers to certain sections of original 
template to fill-in releavant data, but maybe I just was looking 
wrong into it ...

hmm, dunno of how to explain it. It simply parses XML, creates block 
of blocks structure. Then you have those functions like find-by-id, 
find-by-name, etc., which you can use to manipulate values ... then, 
once done, you generate XML. What I did not like is, that ti builds 
the structure from the scratch, so e.g. with html page, you loose 
nice formatting, comments etc. But others said, you could have pointers 
from such nodes to original doc and rebuild the doc properly ...

And of course the dialect is not for making animations! Use drawing 
programs to make animations. The dialect is for example to do things 
like to generate games for the tiles game: http://box.lebeda.ws/~hmm/rebol/swf-tiles.r
--- I'm sure you would not like to do it in Macromedia authoring 
tool:)

Oldes, making some progress thanks to your help. There is one example 
with soem embedded rebol code (the arc example). Is there a way to 
have rebol do some processing then expose what it does to flash? 
I want to write a function in rebol to take a string and create a 
block of characters which I then want to pass to flash. 

For example, I can hardcode a_block: ["h" "e" "l" "l" "o"] but I 
would rather send the string "hello" to a function and have it generate 
that block then pass it to flash. It seems that what I do within 
a "rebol [ ]" block is hidden from flash.

Displaying is probably the most difficult, specially for indonesia 
language. Conversion should be that hard. I guess you are receiving 
your data in unicode format. So you will need a parser to scan the 
bytes in the unicode buffer (a simple string!) and maybe generate 
the display by using the glyphs that encode each char.

yes i've to change all that in the examples, it will take some time 
... :(  and it will generate some erros im shure

If you know the names of the drugs in the system can't you just generate 
the html/get?


http://www.drugdigest.org/DD/Interaction/InteractionResults?drug=&drugList=551938&cD=6355&cD=551938&dN=%2220%2F20+Tears%22+%223-beta%2C5-alpha-stigmastan-3-ol%22+&CheckFDA=1

As long as the virtual sandbox can't be used to generate data files 
that can fill the hard drive (or even be written to it), it should 
be fine.

The encapping procedure is special for Cheyenne, it needs to be run 
in normal mode first before encapping to preprocess the source and 
generate the .cache.efs file.

hahaha, I don't expect to change the world... just that my announce 
didn't even generate one sign or having been read... so I wonder 
sometimes, if most of you use the custom dividers or are like me 
and just the "all groups" master didivers and clear them as they 
 are filled.

hehe I read about it.. I think you could generate your app within 
mine.