AltME groups: search

So the only way to construct a float32! from a literal, is by casting 
(`as float32!`) from a float64! literal.

I know. OK, maybe I need an advice. I was looking into some C code 
educatory example, which contained something like:

char multi[5][10];

decomposed to:

    multi[0] = {'0','1','2','3','4','5','6','7','8','9'}
    multi[1] = {'a','b','c','d','e','f','g','h','i','j'}
    multi[2] = {'A','B','C','D','E','F','G','H','I','J'}
    multi[3] = {'9','8','7','6','5','4','3','2','1','0'}
    multi[4] = {'J','I','H','G','F','E','D','C','B','A'}


which gets stored in a memory block of a "0123456789abcdefghijABCDEFGHIJ9876543210JIHGFEDCBA" 
value.


If I would be supposed (for any reason :-), to interface to such 
a construct, I would simply use a pointer in Red, and would be responsible 
to manually decompose/treat the value of arrays, not to break it 
for the C level code?

is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]

As I said, wrapping a binding in a context isn't enough, in the first 
place because #define's remain global. Making them context sensitive 
would help a lot, because they're currently the most primitive construct 
in Red/System

it would be strange from you to try to push us to recreate an object 
just to expand it


That is part of the basic semantics of the R2 object! datatype, it 
follows the prototype-based model. You construct new objects by copying 
existing ones, it can be just a copy (cloning the source object), 
or derivation (extending the source object with new words). Changing 
object context (adding/removing words) without creating a new one 
is not consistent anymore, so it can look like a big hack.

In other words, we need some kind of Red wrapper (or maybe dialect) 
on top of Red/System to make it easier to construct programmatically.

Ok, I see what you mean. Like in C, you can already write "thread-safe" 
code in Red/System by using only variables on stack. If you need 
concurrent access to global variables, usually, the OS are already 
providing some API for that (locks, semaphores, mutex,...). I haven't 
chosen yet how it will be implemented at Red/System level, there 
are different options. For example, it could be handled by the language 
directly using a similar construct as in Java:

    synchronize [ x: x + 1 ]


In my early design notes, I have researched only how to handle concurrency 
at Red level, I've left the underlying Red/System part as an "implementation 
detail". I plan to start working on it after I/O will be implemented.

In that case, it seems obvious to me to do nothing. That's a regular 
construct in programs

Carl, 9-Sep-2012 15:46:54: "I need to apologize all of you for the 
lack of response to your comments. This was due to a funny incident 
that happened on my ranch.


Last week, a few heffalumps burst into my basement and turned over 
the last barrel of 1999 Châtemateloo. Unfortunately, the precious 
liquid flooded telecommunication cables and I lost network connection.

You know me, this is not a reason to give up.


Using a microwave oven, amateur radio, and 4 lines of code in REBOL 
I was able to construct a modem and here I am.


Well, I read very carefully your comments (the first two lines of 
each comment) and I noticed that most of them contain the phrase 
"Hi Carl". I was hoping that I'll find out from them what further 
steps should be taken to save the future of REBOL, but it seems that 
as usual I have to come up with a solution myself.

So, here it is.

I decided to open source REBOL.


Choice of license is very difficult because there are many kinds 
of them. I examined the majority of them, and none meets my needs. 
They are overloaded and too complicated. The only thing I can do 
in this situation is to write my own license. I name it ... Rebolense.

Creating a license is not an easy task, but is necessary.

I'll be working on it soon, so stay tuned. "

Rebol2 has a pretty straight forward case construct

Well, more I read it, more it becomes obvious.

Last week, a few heffalumps burst into my basement and turned over 
the last barrel of 1999 Châtemateloo

Using a microwave oven, amateur radio, and 4 lines of code in REBOL 
I was able to construct a modem and here I am.
 
Pretty funny

'Restricting "library" to only encompass "OS libraries" is certainly 
a debatable opinion, but it's not the stance the FSF takes.' - My 
reservation is:


- everything mentioned here is just an opinion of the respective 
person, certainly not a qualified opinion of the lawyer

- the DO is not implemented in REBOL at all, is it a functionality 
implemented in C, and the DO variable is just a variable the interpreter 
"knows", certainly not some code your REBOL program is "linked to".

- also, the user of the interpreter obtains r3.exe and r3.dll, not 
some other "hypothetic library" which is just a construct you are 
creating

Here is an example:

cgi-obj: construct decode-cgi read-cgi

;check the input
all [
	in cgi-obj 'email
	trnEmailAddress: to-email trim form cgi-obj/email
	not empty? trnEmailAddress
] [
	;evrything seems ok

 send trnEmailAddress reform ["Thank you. Your number is" token "."]
	quit
]
print "Error!"

it's also possible to simply add a pane of faces that construct the 
text in the necessary parts. with SIZE-TEXT you can then calculate 
the necessary size of each part and write a little routine to lay 
it out. it's a bit of work, though.

Basically, you create an HTML file and put it on your webserver. 
Let's call it "form.html":


<form action="form.cgi"><input type="text" name="word"><input type="submit"></form>


Then you create a REBOL CGI matching the "action" used above, so 
"form.cgi", and also put it on your webserver:

#!/usr/local/bin/rebol278 -cs
REBOL []
cgi-values: construct decode-cgi system/options/cgi/query-string


;; Now you can access the "word" value submitted via the HTML form
;; as cgi-values/word.

;; Let's echo the value back to the user, as an example:
print rejoin [
  "Content-type: text/html" crlf
  crlf
  cgi-values/word
]

btw - do might be unsecure, e.g. with CGI code. Maybe 'construct 
would do the trick too, without evaluating the stuff?

I see what you mean. I just read the function summary for 'construct'. 
My objects are encrypted before they get saved anywhere. Thanks for 
the tip Pekr.

the most secure method is to SAVE/ALL AND CONSTRUCT.


also, btw, using MOLD/ALL can save a lot of ram because things like 
hash! and objects! do not get double allocated.  on big datasets 
like I'm  using it means saving 100MB RAM on app startup . :-)


just be carefull with save/all & mold/all   they can corrupt some 
data types just like when /ALL  isn't used.  it does allow much more, 
but it still can create some un-reloadable issues... always test 
it with your current data structures before blindly adopting it.

In this case, you keep your code and data separate because code is 
best saved with MOLD and reconstructed with DO, but data of types 
that don't have a normal literal form (but aren't affected by binding) 
are often better saved with MOLD/all and restored with LOAD. The 
main thing is that we don't have a literal syntax to declare word 
bindings; instead, we have a way to construct them with code. Same 
goes for cyclic or DAG structures that aren't strictly nested. So, 
if you need to create such things, you need to run code. And you 
need to keep your untrustworthy data that you can't safely DO separate 
from that code.

I don't agree, because 'H is defined within context of 'G and uses 
'H binding.  its both consistent and logical... because Rebol binding 
is supposed to be static.

in the above example, I'd say the construct itself does what it should, 
but the real question is should one usually do this... no.  


I understand its a trap, but its not a trap for which the language 
is responsible, the user is simply leveraging the language.

yes, you have basically two options:


1) work with string - insert db {insert into data1 ....} - you simply 
construct the DB string directly


2) work with block - insert db ["initial string here, contatining 
values(?)" value] - which allows to work with rebol blocks and evaluate 
some things ...

>> blk: decode-cgi "var1=Petr"
== [var1: "Petr"]
>> type? blk
== block!
>> object: construct blk
>> object
>> object/var1
== "Petr"

so use:

values: decode-cgi read-cgi
result: construct values

insert db ["insert into data1(oneone) values(?)" result/oneone]

i am using the first one ... can i use codes which you mensioned 
in above ?  values: decode-cgi read-cgi
result: construct values

insert db ["insert into data1(oneone) values(?)" result/oneone]

Create 2 files. Call the first one e.g. cgi-test.html, and upload 
it to your server. The only thing you have to change is the link 
to your .cgi script in there:

<HTML>
<TITLE>Simple Web Form</TITLE>
<BODY>
<b>Simple Web Form</b><p>
<FORM ACTION="http://www.xidys.com/cgi-bin/cgi-test.cgi">
<INPUT TYPE="TEXT" NAME="Field" SIZE="25"><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>
</BODY>
</HTML>



Create a second file, called cgi-test.cgi (it has to align to how 
you name it in the above source file). Upload it to your cgi working 
directory. Remember to change the first line to contain the path, 
where your REBOL executable is placed:

#!/usr/local/bin/rebcmd -sqc

REBOL []

print join "Content-type: text/plain" newline
start: now/time/precise

submitted: decode-cgi read-cgi
values: construct submitted

prin "Submitted: " print mold submitted
prin "values: " print mold values
prin "values/field: " print mold values/field

print now/time/precise - start
print newline
 

Now go to your URL, and try to submit some values. You can test it 
on my site at: http://www.xidys.com/cgi-test.html

but I'll probably be using modules as the basic construct for slim 
R3, instead of objects... in my model, it might not really matter, 
I manage access/biding to/from modules actually altering and expanding 
the module when it is being loaded.


the data being sent to slim isn't executed directly, the block is 
sent to a manager, which does some binding and security stuff first.

CFOR, EVERY etc

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions -- just have to set words 
to values.

For me, the syntaxtic sugar neatness of the new proposals is outweighed 
by the simplicity of the setup for the existing method.


No real opinion on how to standardise the existing behavior other 
than to reiterate a point Brian has already made: FOR start and end 
can work on series too; all the examples I've seen of proposed change 
behavior is for numbers. We need to ensure thar series FORing works 
as expected too.

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions 

 - this looks like you never used CFOR, otherwise you would have know 
 that it does not require anything of that kind

The existing LOOP is used quite often, so any replacement for it 
won't go in R3 by default. However, the main reason LOOP is used 
is because it doesn't have the overhead that a lot of the other loops 
have, less than the other natives even. Its simplicity and definite 
form are its strengths - a loop with a more flexible form would be 
need to process that flexibility at runtime, which would add inefficiency 
that could easily be avoided by making that choice at development 
time by choosing the loop that meets your needs. And any loop construct 
that requires any kind of manual reducing of its arguments in order 
to have it take the result of an expression is a definite no-go. 
I just got rid of that in REWORD.


I like http://issue.cc/r3/884as a replacement for FOR. It keeps 
the local binding (unlike Marco's CFOR above, sorry) and is flexible 
in behavior without being flexible in form (it has a very simple 
implementation).

@BrianH, when you say "And any loop construct that requires any kind 
of manual reducing of its arguments in order to have it take the 
result of an expression is a definite no-go.", does "manual reducing" 
mean having the user do it? e.g., if I get a spec passed to my dialected 
LOOP func, and I REDUCE it or DO/NEXT internally, is that a no-go? 
If so, where should I look for the reasons and guidelines about it?

Another interesting thing I noticed:

    facets: [
        init-size: 28x28
        bg-color: 80.100.120
        border-color: 0.0.0.128

        pen-color: ; set by on-draw
        area-fill: ; set by on-draw
        material: 'chrome
        focus-color: guie/colors/focus
        draw-mode: 'normal
        materials: none
        face-width: none
    ]


Normally, in regular Rebol code, 'pen-color and 'area-fill, would 
be set to 'chrome, if I would use it to construct an object. But 
maybe it is just a spec block, so I should not care? I mean - what 
about setting them initially to 'none too, for a convenience? :-)

#[[Adrians

Among other things, how is it OK to invoke arg-adder without providing 
the one arg it expects when you have "return/redo :arg-adder?
]]AdrianS


RETURN/REDO is a construct returning (in this case) the ARG-ADDER 
function and setting up an indicator telling the interpreter that 
after obtaining the function as a result it should reevaluate it 
collecting the respective number of arguments for it (one in this 
case).

Geomol, some notest regarding alpha channel:

The alpha values seems to be left out.

I'ts not left out..that's only the way "mold" of image! datatype 
works. So I the image have "fully transparent" alphachannel it is 
just not shown by mold to make the output more readable.

But it seems, the alpha channel is separate from RGB values.

The alphachannel is always present in the image! datatype (ie. internally 
it's always 4 components = 32bit bitmap). Again it's just the way 
"molding" of the datatype displays the content.


AFAIK You can construct the image! with alphachannel in various ways 
for example:

separated alpha:

>> i: make image! [2x2 #{0102030405060708009A0B0C} #{11121314}]
== make image! [2x2 #{
0102030405060708009A0B0C
} #{
11121314
}]

same example but the RGBA compoments together:

>> i: to image! #{0102031104050612070809130A0B0C14}
== make image! [4x1 #{
0102030405060708090A0B0C
} #{
11121314
}]

>> i/size: 2x2
== 2x2

>> i
== make image! [2x2 #{
0102030405060708090A0B0C
} #{
11121314
}]

>>

Same way you can get the values in different form:

>> i/rgb
== #{0102030405060708090A0B0C}

>> i/alpha
== #{11121314}

>> to binary! i
== #{0102031104050612070809130A0B0C14}


For more I'd suggest you read the image! datatype docs here: http://www.rebol.com/docs/image.html

AFAIK The docs were written for R2 but should hold pretty much also 
for R3.

Has anyone used UML in real-life. Or even more precise - is UML worth 
studying? I want to construct some system, which will have some object 
model, inheritance, classes, but dunno if UML is worth studying as 
reference. I have read few chapters - seems like cool thing, but 
a bit difficult to swallow - too many terms etc. ....

BTW. Pekr we have some graphical tools that let you construct this 
type of instructions very easily. My objective has been that anyone 
should be able to manage a unit. But I am getting ahead the game 
here this is coming in our next releases. I think is going to blow 
the eyes of some of our competitors.

How safe is catch?
	

I have some rebol applications serving message communication (around 
1000 to 2000 messages per day mostly) running for more than half 
a year on Windows2000 Server without interruption since the last 
update of the OS for security reasons.

Recently I had to add some message splitting:
one-message -->  [message-part-1 message-part-2 message-part-3]

I used a construct similar to this

forever [
	until [new-messages-available]
	foreach message new-messages [
		catch [
			if not important [throw]

   do-some-heavy-message-processing-and data-completion-using-odbc
			if some-tests [throw]
			message-parts: split-messages message
			until [
				catch [
					message: first message-parts
					do-more-conversions
					if other-tests [throw]
					deliver message
					emtpy? message-parts: next message-parts
				]
			]
		]
	]
]

Now I saw two crashes in one day.
I was somehow able to reproduce the crash 
Invalid data type during recycle
 

by playing again the history of one to two weeks. But the crash happened 
always processing another message.

#3463 : still crash with 1.2.104 - the problem is not construct/with, 
it's using an object containing a recursive block as prototype :
b: copy [] append/only b b 
an-object: make object! [a: b]
make an-object [] ; crash

Don't know when, but old. IIRC older than 'construct. in a way its 
the predecessor of construct/with . And as such, with only data, 
there is no problem anyway. but can be used to merge objects too, 
kind of multiple inheritance. i thought.. ;)

I used it primarily for data, to add default fields. 
 item: make context[ defaults ] load %item.r

there are no functions, so no problem. now thats construct/with, 
even no binding nowhere :)
But lately i did something obscure and it drove me made..

have some faster way how to construct those binary! data from Rebol

I need to construct what is called a "triplet".  The triplet in greylisting 
parlance is a unique set of three facts about an email.
These are IP-address+smtp envelope from+smtp envelope to

The idea is that you construct a database of triplets from smtp clients. 
 If you have never seen such a triplet before, you send a smtp delay 
back to the client.  Most well constructed MTA's honor the delay 
and try again.  You set a block period .. from 10 seconds to 1 hour 
during which you do not accept any mail from that triplet.  Spamming 
engines generally ignore this delay, and just give up.  It's too 
expensive for them to log such delays and retry again.

construct head remove remove find third a to-set-word 'b

then how construct local words?

closure, associative arrays, construct with deep copy, load on values 
that don't exist in system object, others. Some of the bugs that 
have been fixed are due to our need for more power, stable and predictable 
interpreter.

Yes, we can patch rebol and fixed ourselves, but we should remove 
some "surprises" like making CONSTRUCT safe.

Perhaps that should be concise -- the expressive I guess is the ability 
to set the condition after the action, in a way that is easier for 
our brains to parse.  Of course, the core of Rebol's expressiveness 
is that the language is built on top of a consistent, robust vocubulary 
(datatypes), though it can take time to learn how to construct the 
most expressive statements.  Ruby is not instinctively reflective 
(is this the right term)?  Now I'm rambling...

until [capture-image camera/memory-full?] -- is an awkward construct.

Yes, but with dialects, you can be as free form as you wish ... well, 
mostly ... But of course that is different - you have to construct 
your grammar ...

In relation to Roberts post:

>> load mold reduce [ does [ join "Rebol" "3"]]
== [func [] [join "Rebol" "3"]]
>> load mold/all reduce [ does [ join "Rebol" "3"]]
** Syntax Error: Invalid construct -- #[
** Near: (line 1) [#[function! [][join "Rebol" "3"]]]

What!? :-)

I realized there was this traversal option using a lit-path! treated 
as a series! but it did not seem to if what I already had was a path! 
 held by a word and I wanted to 'extend' that value with a word.

This arises when the embedded word becomes bound to a different block. 
 In that case an OBJECT! looks to be the only option but then the 
WORDSs in the PATH come already bound to values and so are not 'functors' 
as are 'a 'd and 'e in your example.

I  want to construct a resultant valid path! from a valid path! + 
a lit-word where that word has no value but serves only as functor.

I had hoped that the func to-lit-path would be the answer, but I 
see now that the default Rebol DO path! evaluation precludes this 
kind of 'append'.

I should be able to use a modified version of your eval-path func 
to take as args a valid path! and a word!

My path idea is more like a 'tilde' than our '/' such that I can 
have
        ; blk/key~wrd1~wrd2~wrd3 ... ~wrd-n     ; e.g.,  
    path~wrd1~wrd-i~wrd-j ~wrd-k    ; becomes
; ...
    path2~wrd-m~wrd-n  ;  i.e.,
        ; blk/key/putative-confirmed-key~wrd-m~wrd-n   
PARSE is likely part of the answer if I go that TILDE route.
Once I have a lit-path! your eval-path is the traversal.
A blk of args to a func such as

  construct_dpath: func  [ dpath [lit-path!]  functor-words-blk  [block! 
  ]  /local v1 v2] [ 

should model my case OK and that dpath can be constructed by modified 
versions of your eval-path.  Thanks

Steve - but even with VID2 you could pre-construct your styles by 
'stylize and instantiate it by directing VID to your style, or you 
could stylize it even inline within VID, so that you don't need to 
override specific parts of your button each time ...

Hi, 
Pekr,

I appreciate that the concept for parsing is different to the use 
of regular expressions, but there are some things that do map from 
one to the other & I wondered if any table of those things existed. 
 As a noob sometimes the hardest questions to get answered are the 
ones where the answer is that there is no concept such as that sought 
by the noob. e.g. how do you grow strawberries in the sea?
 

The first match must be at the begining of the line. If it was the 
first line in the set then it would not be after a new line, but 
other cases it would be.


I will use parse/all from now, I like the extra control you describe.


here a few lines of a test input, the script I am hoping to develop 
is to parse the config files from Cisco devices in order to extract 
the layer 2 & 3 information together with the interface names & descriptions.

lines: {interface FastEthernet0
 description The connection to the printer
!
interface FastEthernet1
!
interface Vlan1
 description User vlan (only 1 vlan allowed)
 no ip address
!
interface Dialer0
 description Outside
 ip address negotiated
!
interface BVI1
 description Inside
 ip address 192.168.0.1 255.255.255.0
!
ip sla 3
 icmp-echo 217.0.0.1 source-interface Dialer0

ip route 0.0.0.0 0.0.0.0 Dialer0

interface ATM0.1 point-to-point
 no ip redirects
 no snmp trap link-status
 pvc 0/38
  pppoe-client dial-pool-number 1
 !
}


; sqlab, your change to use "thru newline" does what I wanted in 
this case which is good.

; my next step is to try & understand the "or" construct properly 
as the code below dosn't quite cut it.

wanted: copy []
interface: ["interface" [to #"^/" | to "point-to-point"]]

parse lines [any [[copy temp interface (insert tail wanted temp)] 
| thru newline ]]
foreach line  wanted [print line]

; thanks very much for your help, /\/\

AH, this is a bit of a revelation..  Now I know where to find all 
those values.
And I can use this sort of construct
view layout [b: button "Hello!" [b/text: "goodbye"]]
Thank you thank you  thank you very much.

the example from Pekr was to show me how to backtrack in order to 
make the ["b" | "y"] construct work in way that is non-greedy, that 
is to say so it finds the first occurance of either.

but - I would definitely vote for =include command - both for code 
and another text file, so you would be able to construct more complex 
docs from smaller parts ....

In any case, I'd probably just do plain queries and construct the 
JSON from the resultset.

It is amazing how we Open Source can divide people. There is gray 
all over the place and this is not a black and white issue. I think 
this is not about the armies of developers, or the quality, but about 
the ability to move fwd and construct on the disclosure of code. 
For as much bad applications there are in Open Source, there are 
good ones, OpenBSD, GCC, Postgress, and the one Rebol incorporated 
AGG.

no overhead, very lean and fast - another fine construct is ubuntu-xen 
with jeos guest and webmin for admin tasks

2) decode-cgi builds the data itself AFAIK. does not use load. so 
all data should be strings. i am not sure about words, i guess they 
are bound. when you only fetch the words and turn them immediate 
in a string, that should be ok. the usual way is 
 construct decode-cgi
that result is save, because all words are bound to that context.

Petr: <<I mean - above block in 'join statement is reduced - is it 
secure?>>

That should be okay.  You could just do a construct/with to create 
an object.

If you are intending to create an object, then pre-process the block 
from decode-cgi to ensure that the word "self" is not used as a keyword 
(tip courtesy of Chris RG, if I remember rightly).

you can use CONSTRUCT, it does not evaluate. or just a block of word, 
value pairs.

rebmail 4.7.14 & associated helptext has been released (31/12/2004) 
...

Changes Since 4.7.11
Enhancement - re-work locale format (for security purposes)
Bug Fix - Correct Fetch All Error
Enhancement - Use load/all & Construct to load locale from file


rebmail.r can be found at .... http://www.upnaway.com/~philb/philip/pbmail/readmail.r

reabmail is also the following formats 

rip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.rip

zip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.zip


the archive containing rebmail.r & rebamail.html (rip = compressed 
self extracting rebol archive)
 
Any problems let me know.

rebmail 4.7.14 & associated helptext has been released (10/01/2004) 
...

Changes Since 4.7.11

4.7.12 - Enhancement - re-work locale format (for security purposes)
4.7.13 - Bug Fix - Correct Fetch All Error

4.7.14 - Enhancement - Use load/all & Construct to load locale from 
file


rebmail.r can be found at .... http://www.upnaway.com/~philb/philip/pbmail/readmail.r

reabmail is also the following formats 

rip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.rip

zip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.zip


the archive containing rebmail.r & rebamail.html (rip = compressed 
self extracting rebol archive)
 
Any problems let me know.

what is the interest to try to construct something which has no sense 
in Rebol

hmm, so construct an object, righ?

well, one of carl's original issues looks just as bad with this search 
engine: http://129.33.196.33/search/?query=construct

I can't find Carl's desired http://www.rebol.com/r3/docs/functions/construct.html
at all in above results :)

I looked at the html source and it should clearly float to the top. 
 strange... 

its got everything needed to be scored high (title, H1, and many 
counts of construct in the page).

Andreas, you're right... same with using a title search with construct. 
 it returns nothing.

if this construct page can't be found by any of the search engines 
... is there a no robots directive ?

Looking for construct now brings up http://www.rebol.com/r3/docs/functions/construct.html
as the top item

NicomDoc 2.1.0: http://home.tiscali.dk/john.niclasen/nicomdoc/

Added an alternate way to construct tables. Instead of the need for 
=row and =cell commands, a table can just be lines (each line is 
a row) and on each line, cells are separated by one or more tabs. 
Docs with lots of tables will shrink considerable in number of lines 
needed. The Math specification (http://www.fys.ku.dk/~niclasen/nicomdoc/math.txt) 
went from 3000 to just below 700 lines this way.

REMARK HAS NOW FINALLY BEEN RELEASED ON THE STEEL WEB SITE


REMARK is a robust web site building tool which allows you to construct 
your own custom tags using rebol values and dialecting.

The main difference of remark with other tools of its kind, is that 
the web pages do not contain code, they contain data or parameters 
to your custom tags.  Remark also persistently reparses tags until 
no more custom tags exist in the dialected tags you create. this 
means you can actually build up your pages with custom which use 
custom tags themselves... talk about leverage! 


at version 1.3.5 it support multiple site configs, ftp dumping, site 
specific configuration, and the very flexible remark engine itself. 


Creating tags is trivial and for simple templating, you don't even 
need to know how to code in rebol... just html content within stored 
files can be nested within your site's pages and will be included, 
by simply adding a tag which is called like the stored html.


Using differently named source file extensions you can even decide 
to parse the content differently, so that you can create different 
page templates or one can even decide to create a make-doc handler 
for example (its not included by default, just possible if you need 
it).


you can check-out the FULL documentation, including tutorial, example 
site, reference page and guides on adding new tags and templates. 


here: http://www.pointillistic.com/open-REBOL/moa/steel/retools/index.html

Question: the SDK license require to not let the program interpret 
Rebol code !

If the program load a config file (with 'construct) does it go against 
the license or not ?

'construct is ok. user can only insert data, not code.

Volker means that CONSTRUCT will not evaluate the spec block, so 
there will be no explosions :)   (make object! spec-blk   does evaluate 
the contents.)

yep, CONSTRUCT is ok.

I think that has to do with evaluation constraints then. That is, 
DRAW will get words, but not do further evaluation (kind of like 
CONSTRUCT), so it's safe.

Latest build available at: http://www.dobeash.com/files/RebGUI-019.zip

Highlights include:


 - Integrated language localization (see http://www.dobeash.com/it/rebgui/locale.html)
	- New arrow widget (run %arrow.r to see it in action)
	- Use of as-pair
	- Minor updates to pwd-field
	- title-group simplified

Known issues


 - radio-group fails under 1.2.1 and rebface 1.2.10 (but not view 
 oddly enough). Comment / uncomment radio-group block under %tour.r 
 to see.
	- Need a "safe" implementation of 'construct for 1.2.1

'construct for 1.2.1 :

construct: func [
    block [block!] /with object [object!]
/local nb spec values name value
][
    if not with [object: object!]
    spec: copy []
    values: copy []
    parse/all :block [
        any [
            to set-word! (nb: 0) some [
                set name set-word! (nb: nb + 1 append spec :name)
            ]
            set value skip (

                insert tail values nb insert/only tail values :value
            )
        ]
    ]
    append spec none
    object: make object spec
    foreach [nb value] values [
        loop nb [
            set in object (to-word first spec) 

                either find [true false none on off] :value [do value][:value]
            spec: next spec
        ]
    ]
    object
]

config: construct/with load config-file standard-config

I use 'construct for security reason, but it's most understandable 
with 'make :

DideC -- your method is similar to Henrik's, and has the same limitation: 
sub-objects fields do not propagate as you'd expect.....No f2-2 field 
in 'config here:


     standard-config: make object! [f1: 1 f2: make object! [f2-1: 21 f2-2: 
     22] f3: 3]

     config-file: make object! [f1: 88 f2: make object! [f2-1: 99]]

     probe config: construct/with  third config-file standard-config

I was using rebelxml to construct xml ... but I came across some 
bugs.  So this way of doing it looks easier ....

What are people using to construct large XML documents ... of 100s 
of lines?

Anyway this is looking promising.  I can take an xml message, construct 
a rebol object from it ... rearrange bits to create a new object 
and then create a reply xml message.

Wouldn't it make a lot more sense to use a C based XML parser, construct 
a Rebol data-structure/string and return that to Rebol?

Services are small. They do one single thing and they do that one 
thing very well. OSX has them and they've been there for ages, but 
the system only relies on them for manipulating things in apps, not 
to construct ad hoc apps themselves. How often have you not wanted 
a cool feature from program X in program Y and vice versa? This would 
do the trick.

Gabriele, Even though there Scheme uses two stages the line between 
compile time and runtime is not the same as in C. You can write macros 
during runtime that get compile on the fly and avaialbe without ever 
stopping a program. So in this sense the two phase is just process 
is not really important. The feature that macros brings is syntactic 
abstraction. Also in Rebol you can not do low level control structures. 
That is you can not add foreach without having a looping construct 
already in place. So the mezzanine is slow. Compare to delimited 
continuations of Scheme where is  only control structure and recursion 
and optimized goto. You construct other control syntaxes on top of 
that.

Gabriele, "brainfuck is turing complete, but don't tell me it's the 
same as scheme".  Well it depends on what you mean by sameness. I 
am using Turing Complete as the base of the definition. Because if 
the language is Turing Complete you can construct an emulator of 
any other language. After all that is needed is bits, memory and 
register to carry out any computation. It maybe hard to make a Rebol 
interpreter in brainfuck but it is certainly possible.

Graham - it seems to me, that ppl sometimes construct their problems 
to prove somethings which actually is not happening. Did I got some 
crash with FF3? Yes, more than with FF2, especially with stupid quick-time 
format. But - did I got some tab locks? No, never ....

The final [untested] solution is about as efficient as you can get. 
Adding JOIN support to RebDB so it can break the query down into 
similar steps is not a simple task. In all but the most trivial of 
cases you'd be better off coding it yourself.


What might be a good idea is to add something that lets you more 
easily specify the most common JOIN operation - master/detail with 
optional LOV (List Of Values) lookup(s). Your query is a classic 
example of this construct and it accounts for a surprisingly large 
number of queries.


The function would accept two queries, a master query (the orders 
table in your case) and a details query (the order-items table) and 
an optional block of column/LOV-table pairs (that perform substitutions 
such as company-name). The skeleton would look like:


 sql-join [master-query [block!] detail-query [block!] /order /lov 
 [block!] ]  [
		buffer: copy []
		...
		buffer
	]

and would be used as such:

	sql-join/order/lov [

  select [company-id order-id date amount total] from orders where 
  [amount > 2000]
	] [
		select * from order-items where %ID%
	] [8 1 5] [company-id companies]

Would this make things a tad easier?

Thanks guys, I've had a good look at both implementations and I've 
got ideas from both for a future full JOIN implementation; but at 
the moment my master/detail code has come along nicely. I've now 
enhanced the db-select function to accept statements in these additional 
forms:


 select * from master joins [select * from details where &id] on id

 select * from master joins [select * from details where [all [master-id 
 = &id master-date = &date]] on [id date]


which works exactly like a normal join with the following differences:

	a) It can only join one table to another

 b) Detail columns are always joined to the right of master columns

 c) Table.column prefixes are not supported so all columns in the 
 join must be uniquely named


Apart from that you get all the benefits of db-select (can replace 
* with specific column combinations, order and group by on the final 
result set, etc) *and* it's significantly faster than even the raw 
REBOL code example I gave before (as the SQL is parsed once within 
db-select and all loop sub-selects are done in-line).

I've also implemented “lookups” with the following form:

	select * from table replaces id with name
	select * from table replaces [id-1 id-2] with [table-1 table-2]


which performs a highly optimized db-lookup for each replaced value, 
but has the following restrictions:


 a) The lookup expects lookup tables in the form [id label other-column(s)]
	b) Only single-key lookups are supported
	c) A lookup that fails will replace the column value with none!


I'm now in the process of benchmarking these changes against sqlite 
to see where the bottlenecks (if any) are. Feedback on the design 
decisions is welcome.


While I was doing this, I was once again reminded how cumbersome 
it is to construct SQL statements (not just for RebDB, same goes 
for the other SQL protocols), as the heavy use of 'compose, 'rejoin, 
etc adds noise that reduces legibility. The design goal is to provide 
alternatives to:


 sql compose/deep [select * from table where [all [col1 = (val1) col2 
 = (val2)]]]


so for a start the 'sql function should probably accept a string, 
to allow:

	sql join “select * from “ table


type constructs; but this doesn't make the first example easier. 
So how about the 'sql function accept a block containing a string 
statement followed by a number of substitution variables, as in:


 sql reduce [“select * from table where [all [col1 = &1 col2 = &2]]” 
 val1 val2]


which makes things a bit more readable (and shortens the expression 
if longer word names are used multiple times). So the two questions 
here are:

	a) Is this a good idea?

 b) If so, what substitution character (& % $ @ other) will cause 
 the least conflict with REBOL and/or SQL?

You construct your sql statement and test it.

such a construct would make certain loops much simpler

So, we construct an ideogram around that.

Hi Doc,

I was referring to something like this 
   construct/with
                cgi-block
                   make object! [a: 111 b: 222 c: 3]


from http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-display-article.r?article=x60w#toc-20



It could be added by all users to the results of validate but then 
it would be not be a standard cheyenne solution. It makes sense to 
me it is ''validate.

This is not really about Cheyenne .. but what is the better approach. 
 Using RSP to completely build your page and display it from your 
datasources, or to dynamically construct the page with javascript 
and then feed the data in Ajax like ?

but its doable.  every game out there is an implementation of this 
concept... with preset rules, preset AI, and loaded graphics.  basically, 
all that is needed (like in the matrix) is to define the construct 
(laws of physics and rule set which can be exposed and perceived 
by the agents).