AltME groups: search

in your case you seem to want null have a value that sorts before 
any known value which is fine for you. but in  general,  the three 
cases where a b or both are null are equalivanrt in that no comparison 
can be made and so are "vacuously true" because they cannot be proved 
false.

It's easy to do case sensitive or case insensitive tests for equality:
     >> "abc" = "ABC"
     == true
     >> "abc" == "ABC"
     == false
(Or use equal? and strict-equal?)


Anyone know a  similar shorthand way to do the same for greater/less 
than comparisons?
     >> "abc" < "ABC"
     == false
     >> "abc" > "ABC"
     == false
Right now, I'm using to-binary to get the right result:
     >> (to-binary "abc") < (to-binary "ABC")
     == false
     >> (to-binary "abc") > (to-binary "ABC")
     == true

Functions are pre-fix (name of function followed by arguments), actions 
are in-fix (argument1 action! argument2), and there are no post-fix 
words in REBOL. I'm not too familar with the language theory, REBOL 
is based on, but should it be possible to make new in-fix words? 
And what about post-fix? Or is that just too confusing?

you can build your own parsing, and your own dialects as well...depending 
on your application

True. I also actually meant op! types (operators), not action! And 
the operators in REBOL are pretty basic, so no need for new ones, 
I guess.

The infix operators in REBOL can be seen with:
>> ? op!

It's a special corner of REBOL, as I see it. And I don't feel a big 
need to be able to make my own infix operators. There is a funny 
thing with the and, or and xor operators. They have twin and~, or~ 
and xor~ actions. The actions is used like: <action> <value1> <value2>, 
but operators can be used the same way, so the action counterparts 
seem to be irrelevant. Examples:
>> 3 and 9
>> and 3 9
>> and~ 3 9

Why do we have and~, or~ and xor~ made?

One can overload 'and~ 'xor~ 'or~ but should not overload 'and 'xor 
'or.

With form~ we know they are only used in <action> <value1> <value2>, 
and are safe to change.

I think, that it is an *unsafe* and confusing practice to use infix 
operators as prefix

I have one little thing to ask for my personal knowledge and I hope 
for people to thinks together on a good way to exploit it in REBOL 
to enhance it's capability to interface with DLL or exploit files 
containing memory struct dump:

the thing is how to load or convert a C structure like this and use 
it in REBOL in a approachant way of C (I hope we could find even 
a better way to do it with rebol than in C)

//-------------------------------------------------------------
//- SMD2Header
//- Header for all Md2 files, 
struct SMD2Header
{
   int m_iMagicNum; //Always IDP2 (844121161)
   int m_iVersion;  //8
   int m_iSkinWidthPx;  
   int m_iSkinHeightPx; 
   int m_iFrameSize; 
   int m_iNumSkins; 
   int m_iNumVertices; 
   int m_iNumTexCoords; 
   int m_iNumTriangles; 
   int m_iNumGLCommands; 
   int m_iNumFrames; 
   int m_iOffsetSkins; 
   int m_iOffsetTexCoords; 
   int m_iOffsetTriangles; 
   int m_iOffsetFrames; 
   int m_iOffsetGlCommands; 
   int m_iFileSize; 
};

//-------------------------------------------------------------
//- SMD2Vert
//- Vertex structure for MD2
struct SMD2Vert
{
float m_fVert[3];
unsigned char m_ucReserved;
};


//-------------------------------------------------------------
//- SMD2Frame
//- Frame information for the model file 
struct SMD2Frame
{
float m_fScale[3];
float m_fTrans[3];
char m_caName[16];
SMD2Vert * m_pVerts;

//Cleans up after itself
SMD2Frame()
{
m_pVerts = 0;
}

~SMD2Frame()
{
if(m_pVerts)
delete [] m_pVerts;
}
};

//-------------------------------------------------------------
//- SMD2Tri
//- Triangle information for the MD2
struct SMD2Tri
{
unsigned short m_sVertIndices[3];
unsigned short m_sTexIndices[3];
};

//-------------------------------------------------------------
//- SMD2TexCoord
//- Texture coord information for the MD2
struct SMD2TexCoord
{
float m_fTex[2];
};

//-------------------------------------------------------------
//- SMD2Skin
//- Name of a single skin in the md2 file
struct SMD2Skin
{
char m_caSkin[64];//filename
CImage m_Image;//Image file ready for texturing
};

//-------------------------------------------------------------
//                        CTIMER                              -
// author: Evan Pipho ([evan-:-codershq-:-com])                     -
// date  : Jul 10, 2002                                       -
//-------------------------------------------------------------
class CMd2 : public CModel
{
public:

//Set skin to one of the files specified in the md2 files itself
void SetSkin(unsigned int uiSkin);
//Set skin to a different image
void SetSkin(CImage& skin);

//Load the file
bool Load(const char * szFilename);

//Render file at the initial position
void Render();
//Render the file at a certain frame
void Render(unsigned int uiFrame);


//Animate the md2 model (start and end frames of 0 and 0 will loop 
through the WHOLE model

void Animate(float fSpeed = 30.0f, unsigned int uiStartFrame = 0, 
unsigned int uiEndFrame = 0, bool bLoop = true);

//constructors/destructo
CMd2();
CMd2(const char * szFile);
~CMd2();

private:

CTimer m_Timer;
//file header information
SMD2Header m_Head; 
//Frame information
SMD2Frame * m_pFrames;
//Triangles
SMD2Tri * m_pTriangles;
//Texure coords
SMD2TexCoord * m_pTexCoords;
//Skin files
SMD2Skin * m_pSkins;
//Interpolated vertices
SMD2Vert * m_pVerts;
//Current skin
unsigned int m_uiSkin;
//Using a custom skin?
bool m_bIsCustomSkin;
//The custom skin
CImage * m_pCustSkin;

};

the main problem I think with this kind of hierarchical and dynamical 
size struct is to be anought performant and close to the original 
to save code writing  time and tu enhance the loading performances 
in such tasks. Actually you need to parse and readapt each data from 
the binary dump file to rebol based   things. And that's an heavy 
task


This can be usefull for all langages that allow binary dump file 
read/wirte like C, VB and many others.

the goal is to provide to REBOL the capability to do such a load 
in the simpliest and fastest way I think the posibility of using 
a vectorial data like float myvar[3];

parsing binary is a bit different than parsing ASCII...and I have 
done a bit for mp4...but I think your point of making it simple is 
a good thing.

you open in the modelviewer the hellpig.md2 file and tada you can 
playback the animation

when Josh appears, we will scratch each others heads and see if we 
can determine a way to parse this...he has done some work like this 
for his NASA project...and he is working on some crazy computer science 
parsing algorithms...I think he has been chatting with Ladislav too 
long ... ;-)

thank you ladislave for single int variable that's easy (like header) 
but for file content it's ver hard and harder I think to attribute 
to a REBOL struct based pointer the content of the file

so MD2 format encapsulate many  Frame as array and all those frames 
encapsulate many Vert that discribe for this frame each location 
of every point of my 3d Model

it is sometimes too mind expanding to write code while chatting. 
 Sometimes I think I need a few more heads, and a couple more arms 
to type and click...maybe I should draw a new model of myself.

in my 3D engine I will make a switch to change the animation that 
are into my model that supose for me to have all my 3D model to get 
the identical set of animation or to make animation switch that could 
be adapted to every 3D Model Type (that's why 3D engeneers not even 
more use this format and prefert bone animation based file format 
like MDL or MD3/MD5)

for example if I say walk is frame 0 10 for human but for aliens 
in my game I nead to have only frames 0 to 5 for the walk I need 
to make 2 animation list and 2 animation switches to handle human 
(main caracter of my game for example) and alien

If i have alien type 1 alien type 2 alien type 3 etc... and all of 
them with different set of animation it could be very heavy task 
to handle all of them using MD2 but that's not our purpose in fact 
 :)

so or we allways ue struct! to typify our variables (wich can't be 
reuse). In C if I make SDM2Header *a, *b; a content and b content 
(physical memory localtion) will not be the same

in rebol a: SMD2Header and b: SMD2Header will point to the same memory 
chunk ...

and that normal becaus in C to initialise data I will use a malloc 
call witch will attrubute to a and b on the same based type different 
memory location

//-------------------------------------------------------------
//- Load
//- Loads an MD2 model from file
//-------------------------------------------------------------
bool CMd2::Load(const char * szFilename)
{
	unsigned char * ucpBuffer = 0;
	unsigned char * ucpPtr = 0;
	unsigned char * ucpTmpPtr = 0; 
	int iFileSize = 0;
	FILE * f;
	
	if(!(f = fopen(szFilename, "rb")))
	{
		APP->Log(COLOR_RED, "Could not open MD2 file %s", szFilename);
		return false;
	}

	//check file size and read it all into the buffer
	int iStart = ftell(f);
	fseek(f, 0, SEEK_END);
	int iEnd = ftell(f);
	fseek(f, 0, SEEK_SET);
	iFileSize = iEnd - iStart;

	//Allocate memory for whole file
	ucpBuffer = new unsigned char[iFileSize];
	ucpPtr = ucpBuffer;

	if(!ucpBuffer)
	{

  APP->Log(COLOR_RED, "Could not allocate memory for %s", szFilename);
		return false;
	}

	//Load file into buffer
	if(fread(ucpBuffer, 1, iFileSize, f) != (unsigned)iFileSize)
	{
		APP->Log(COLOR_RED, "Could not read from %s", szFilename);
		delete [] ucpBuffer;
		return false;
	}

	//close the file, we don't need it anymore
	fclose(f);

	//get the header
	memcpy(&m_Head, ucpPtr, sizeof(SMD2Header));

	//make sure it is a valid MD2 file before we get going
	if(m_Head.m_iMagicNum != 844121161 || m_Head.m_iVersion != 8)
	{
		APP->Log(COLOR_RED, "%s is not a valid MD2 file", szFilename);
		delete [] ucpBuffer;
		return false;
	}
	
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetFrames;

	//read the frames
	m_pFrames = new SMD2Frame[m_Head.m_iNumFrames];
	
	for(int i = 0; i < m_Head.m_iNumFrames; i++)
	{
		float fScale[3];
		float fTrans[3];
		m_pFrames[i].m_pVerts = new SMD2Vert[m_Head.m_iNumVertices];
		//expand the verices
		memcpy(fScale, ucpTmpPtr, 12);
		memcpy(fTrans, ucpTmpPtr + 12, 12);
		memcpy(m_pFrames[i].m_caName, ucpTmpPtr + 24, 16);
		ucpTmpPtr += 40;
		for(int j = 0; j < m_Head.m_iNumVertices; j++)
		{

   //swap y and z coords to convert to the proper orientation on screen

   m_pFrames[i].m_pVerts[j].m_fVert[0] = ucpTmpPtr[0] * fScale[0] + 
   fTrans[0];

   m_pFrames[i].m_pVerts[j].m_fVert[1] = ucpTmpPtr[2] * fScale[2] + 
   fTrans[2];

   m_pFrames[i].m_pVerts[j].m_fVert[2] = ucpTmpPtr[1] * fScale[1] + 
   fTrans[1];
			m_pFrames[i].m_pVerts[j].m_ucReserved = ucpTmpPtr[3];
			ucpTmpPtr += 4;
		}
		
	}

	//Read in the triangles
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetTriangles;
	m_pTriangles = new SMD2Tri[m_Head.m_iNumTriangles];
	memcpy(m_pTriangles, ucpTmpPtr, 12 * m_Head.m_iNumTriangles);

	//Read the U/V texture coords
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetTexCoords;
	m_pTexCoords = new SMD2TexCoord[m_Head.m_iNumTexCoords];
	
	short * sTexCoords = new short[m_Head.m_iNumTexCoords * 2];
	memcpy(sTexCoords, ucpTmpPtr, 4 * m_Head.m_iNumTexCoords);

	for(i = 0; i < m_Head.m_iNumTexCoords; i++)
	{

  m_pTexCoords[i].m_fTex[0] = (float)sTexCoords[2*i] / m_Head.m_iSkinWidthPx;

  m_pTexCoords[i].m_fTex[1] = (float)sTexCoords[2*i+1] / m_Head.m_iSkinHeightPx;
	}
	
	delete [] sTexCoords;

	//Read the skin filenames
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetSkins;
	m_pSkins = new SMD2Skin[m_Head.m_iNumSkins];
	
	//Load textures
	for(i = 0; i < m_Head.m_iNumSkins; i++)
	{
		memcpy(m_pSkins[i].m_caSkin, ucpTmpPtr, 64);
		//hack off the leading parts and just get the filename
		char * szEnd = strrchr(m_pSkins[i].m_caSkin, '/');
		
		if(szEnd)
		{
			szEnd++;
			strcpy(m_pSkins[i].m_caSkin, szEnd);
		}

		m_pSkins[i].m_Image.Load(m_pSkins[i].m_caSkin);
		ucpTmpPtr += 64;
	}
		
	delete [] ucpBuffer;
	return true;
}

class CMd2 : public CModel
{
public:

	//Set skin to one of the files specified in the md2 files itself
	void SetSkin(unsigned int uiSkin);
	//Set skin to a different image
	void SetSkin(CImage& skin);

	//Load the file
	bool Load(const char * szFilename);
	
	//Render file at the initial position
	void Render();
	//Render the file at a certain frame
	void Render(unsigned int uiFrame);


 //Animate the md2 model (start and end frames of 0 and 0 will loop 
 through the WHOLE model

 void Animate(float fSpeed = 30.0f, unsigned int uiStartFrame = 0, 
 unsigned int uiEndFrame = 0, bool bLoop = true);

	//constructors/destructo
	CMd2();
	CMd2(const char * szFile);
	~CMd2();

private:
	
	CTimer m_Timer;
	//file header information
	SMD2Header m_Head; 
	//Frame information
	SMD2Frame * m_pFrames;
	//Triangles
	SMD2Tri * m_pTriangles;
	//Texure coords
	SMD2TexCoord * m_pTexCoords;
	//Skin files
	SMD2Skin * m_pSkins;
	//Interpolated vertices
	SMD2Vert * m_pVerts;
	//Current skin
	unsigned int m_uiSkin;
	//Using a custom skin?
	bool m_bIsCustomSkin;
	//The custom skin
	CImage * m_pCustSkin;

};

Shadwolf: "in rebol a: SMD2Header and b: SMD2Header will point to 
the same memory chunk ..."


yes, but you should do it as follows: a: make struct! SMD2Header 
b: make struct! SMD2Header

in rebol you will need to load 3 files to declare SDM2Header_f1 SMD2Header_f3 
and SMD2Header_f3 with for both the stricly identical content tso 
your recoding 3 times or X times the same thing ...

I'm not an expert on struct! far of that (wel in C yes but in REBOL 
no and I think it's because I'm not using load/library capability 
until now) but that's a good discution to point to difficulties on 
this kind of task and I hope help rebol Core to have a bettre handling 
of that

you can create an empty struct using NONE and fill it using the read 
data

the dangerous thing is that with rebal I can over pass easly the 
25 limitation and write every where in the countigous memeryy area 
;)

the main purpose I purchase is to enhance and simplify the rebol 
interaction with external lib and C/C++/VB structure binary file 
based

and that's why I can here to expose the difficulties I see on that 
issue and try with you to get infos or solutions to propose to Carl

It takes a guru level REBOLer who is also profishant in C to write 
an interface to a DLL, although there are becoming more and simple 
examples...but maybe shadwolf wants to make it a graphical process?

an ez-dll.r which takes in a .h and a .dll and lets you play, experiment, 
and try to controll any .dll might be a fun project.

Cyphre not at all and that's why I came here first to expose the 
problems then to seek solutions with you

eFishAnt your right !!! in a C# ressource explorer motion (wich you 
can see in Shardevolp IDE for example ) could be an amazing thing 
and even more if the same code all you to do so on evry OS rebol 
stands in

If I take Cal Dixon's libopengl.r software for example we clearly 
notice that it only use the multi float functions in opengl and not 
the vectorial float functions that leads me to think  glColor3fv( 
my_colors[ 0.3, 0.5, 0.0 ]) kind of function are un explotable as 
is in rebol and many are the external libray that deal with array 
of data for arguments instead of fractionnal multi datas

If I'm the conseptor of the external C lib i can do ma best for preprepare 
the data to be use to be teh easier to deal for rebol but I want 
to use a yet existant lib I will have to work pretty hard to be allowed 
to inteerface rebol code and this library

I'm agree with you char * can feet every thing but this will need 
you on C side to make the spliting of the char content user << and 
&& maks to be able to retrieve your initial data passthue by rebol 
;)

and if y have twenty array sized and typed  different kind for my 
external lib I will need to wirte and handle as many function to 
play with binary content

Cyphre you comming to my main point ;) giving to carl a premaid function 
that allow us to deal easyly with array (int, float, char what ever 
type) but for struct based array that's a challenge too and an horrible 
task to do

in the current way to handle you need to be very sharp to can interact 
with it from rebol and that why Cyphre you have all my admiration 
for your quick made AGG external exploitation script ...

bye and thank you cyphre for your contribution to thi discution.

and kwoledge

well now i know better how to handle REBOL -> C and C-> REBOL the 
idéal thing could be a convert-reb-to-c multi type, multi size native! 
function in Command and in REbol/view Pro (I think it will be added 
to core any way than accessible if you have the licence.key file)

maybe idela convertion function could be c_convert/int ma_var  with 
ma_var : [ 1 4 5 10 ] if c_convert  workon a REBOL array then no 
need to specify manually the length we retrieve the info using lenght? 
type could be treat as rafinement and a switch could branch into 
c_convert function the adapted tranlation algorithm

Has anything changed with core regarding loading?  I'm trying to 
load a function using a URL, and it comes back as a block?

I'm trying to build a string with rebol content inside (also strings). 
And I get into trouble. I think, it's a bug. Try this:
>> s: "^"abc^/def^}ghi^""
== {"abc
def^}ghi"}
>> to-block s
** Syntax Error: Invalid string -- "abc
** Near: (line 1) "abc

Probably because the caret can be used even in strings and used for 
line termination formatting etc..

Can you give an example of your input and final desired output ?

Input: "^"^/{^""

That's a string with 4 bytes: A ", then a newline, a { and another 
".
Operation: to-block
Desired output: ["^/{"]

That's a block with a string, that consists of 2 bytes: a newline 
and a {.

If this can be solved, then I can solve my other problems, I think. 
(Same goes with } btw.)

I guess as soon as you have a newline in your string you should start 
the string with { and not with "

I would initially think, that {"^/^{"} would be a valid string with 
4 chars inside. 2 ", 1 newline and one {, but it isn't.

I have seen different behaviour from typing in the console and loading 
from a file

for example
>> func: [;  []]
** Syntax Error: Missing ] at end-of-script
** Near: (line 1) func: [;  []]
>>

Not really. I start with a string:
output: make string! 10000

then I go into a parse, where I build REBOL content within my output 
string. Sometimes I have to append a string (as a string) to output, 
and it fails, when I have newlines and { like characters.

I can't start with a block, because I can't append the start of a 
block to a block. I have to append a whole block to a block, and 
I don't know the full content of the block. So I start with a string.

I have to check in a script I did short before and I thought I did 
something similar

Oki doki! :-)

I then just save my result to disk (because I can't use it directly, 
as those [ and ] are words (and not a real block). After reload of 
the result from disk, it should be real REBOL, right? Would be great, 
if I could build in a block and not a string.

@sqlab I've now implemented the block method instead of the string 
method, when I'm building REBOL syntax, and it works very well. Now 
I should be able to finish the first pass of my document format very 
soon, so I'm happy! :-)

Yes, I'm aware of that REBOL trick. :-) It's because, what I'm parsing 
might be blocks within blocks in a recursive way.

XML is an example of such a structure. If I see a start-tag, I insert 
the beginning of a block in my result, then parse further in the 
document finding content and other start-tags and so on. The best 
way is to produce the output in a seriel manner from beginning to 
end, like I parse the input.

You can use another block as a stack of  blocks references :

- When you meet a new tag, push the current block reference on the 
stack (insert tail) and make current ref to a new block.

- When you meet a close tag, pop the last reference from the stack 
in the current ref  (pick last, and remove back tail)

A document format should build on the hierarchical datamodel. That 
can lead to problems, when sections are defined with "tags" like 
\in and /in (to make something indent) and \note and /note (to make 
a note).

This is valid:
\in

\note A note

example

/note

/in

I think that make-doc needs some design work. What I liked about 
md-pro was, that it allowed to include source code. The need for 
source code to be intended is terrible. Dunno how you, but I tend 
to write my code from the beginning of line (column 1) and intending 
it by hand in the case of longer script is time consuming .... (and 
I don't want to use another script to preformat script for the purpose 
of its inclusion ....)

@Pekr: I use the vi editor (now mostly vim) to write code, and it 
allow me to set auto-indent, so when I start something indented, 
it'll stay indented, when I go to next line. Further indenting is 
done by inserting a <tab>, and going back is done with <backspace>. 
So it's no big problem for me to write code indented as makedoc require.

I have one...I think it was makespec.txt and on the world wide Reb...(through 
View Desktop) methinks.

I think, it's crucial to stick with the hierarchical datamodel, when 
making document formats.

Let's take bold and italic as an example:

This is bold and italic.

If we use the HTML tags and NOT sticking with the hierarchical datamodel, 
those examples could be done as:

<b>This text is bold.<i>This is bold and italic.</b>This is just 
italic.</i>

Back to the bold'n'italic example. It should be done this way:

<b>This text is bold.<i>This is bold and italic.</i></b><i>This is 
just italic.</i>

So if we stick with the hierarchical datamodel, it's a bad idea to 
use start- and end-tags, because it's then possible to do it wrong, 
and not sticking with the standard.

A better way is:

\b [This text is bold. \i [This is bold and italic.]] \i [This is 
just italic.]


When using a block, it's not possible to end something in the wrong 
place.

If I tried and wrote:

\b [This text is bold. \i [This is bold and italic.] This is just 
italic.]


The result would be, that the first and last text is bold, the middle 
is bold and italic. So "This is just italic." would actually be bold.

I maybe wouldn't get the result, that I wanted, so I had to change 
my text, but my text would be fully understood by the parser. This 
having start- and end-tags is a big problem with HTML, because people 
produce incorrect HTML code all the time, because it's possible. 
If HTML used some kind of a block structure in stead, a lot of incorrect 
code wouldn't exist, and it would be easier to make a browser.

RTF (Rich Text Format) seem to use the hierarchical datamodel too, 
but RTF solve the problem in an interesting way. My above example 
would in RTF be something like:


{\i0\b This text is bold. {\i This is bold and italic. {\b0 This 
is  just italic.}}}


\i0 means setting italic off, \i set it on. \b0 set bold off, \b 
set it on. A problem here seems to be, that you have to tell the 
condition of bold and italic for all text, and I don't like that.

One of the goals with the MakeDoc format is, that it's possible to 
easily read with a normal text window, and some people may want to 
edit it with a normal text editor and write the formatting chars 
themselves. XML is not suited for that. XML also has the same start- 
and end-tag problem (that I mentioned above) as HTML.

not the whole thing, just the parser ... but I have stuck it together 
various ways in Developer/IOS for experimentation and testing.

Do you use tags like \note, /note, \table and /table?

that is not a good thing, to have several incompatible variants imo 
... that is why there is make-doc project, which should produce make-doc3, 
open enough, allowing still the same level of easy of use, why otoh 
providing nicely formatted output ... I like what Chris did at Ross-gill.com, 
you can see output using two different .css files. Well, delete them 
and it will still work, even without .css!

I like the things Chris and Robert have done to extend make-doc...and 
enabling different outputs from the same content is a very good thing. 
 no disagreement from me. (and make-doc2 is open source and very 
small, not so hard to work with.

A note criss-crossed with a table; what should the outcome be? That's 
exactly the problem! A hierarchical standard based on start- and 
end-tags allow you to type it that way producing a problem. A hierarchical 
standard based on some type of container (block) makes sure, that 
you can't type something giving you a problem like that.

Container blocks aren't pretty though, and don't give any hint at 
the end what they are closing.  The crossover you mention could be 
circumvented by a smarter outputter...

but we don't want to have to put that extra stuff into the simple 
text file (only what is absolutely necessary...and I agree with what 
Chris says.

Yes, it's possible! :-) It might also be possible without the group:

\note A note

\table

some text

/table

more text

/note

###


But my point is, that making the standard this way won't prevent 
the writer to type:

\note A note

\group

\table

some text

/note

more text

/group

/table

###


making an upredictable output. And that's the problem. It's not an 
optimal standard in my view.

A way to go may be to make a deep analyse of, what a document is 
- what it consist of. There are basic elements like letters, dividers 
(<br/>), ... Then there are bigger elements (containers) like notes, 
tables, ... And we can talk about change of state like bold-on, bold-off, 
italic-on, italic-off, font change, etc. The containers should be 
strictly hierarchical. The basic elements and the containers will 
be represented in a sequence. The inside of a container is maybe 
also a sequence. Decisions should be made, if change of state can 
happen anywhere, or if going to one state and back is a container 
too. (I'm thinking loud here, you may notice.)

I don't see a difference between [ [] [[]] ] type nesting and what 
is currently used...I see that what you call "containers" are what 
the /  \  tags are doing.  Are you saying you prefer the scanner 
to die if the input is "illegal" than trying to proceed with it anyway?

I'm trying to do somthing that allows you with a bunch of clicks 
to and some little tipping to make your full doc verry quickly with 
a lot of usefull functionnality like in true texte editors (I dont 
support yet direct texte rendering or color syntaxe) but there is 
some trully good advantages

on makedoc2.r   I can use * ** and *** bullets without trouble, but 
I don't yet understand the 3 levels of enum  should it be #>> or 
>>#  so far neither seem to work.

in the make-spec, there were things like ! and * for numbering ...

in front of vi of windows notepad for example it's oriented  Make 
doc Pro (Robert Version) and the look and feel is not has nice that 
if I could include in it the whole widget AGG based set of Cyphre

(I was just perusing the source...the parse of enum2 and enum3 show 
">" and ">>"

being able to rearange lines (more fluid than cut and paste.

it's not a click click rad but it's a step further than simple vi 
/ notepad lol ;)
and it's done in pure rebol

but I hope when the official 1.3 that stabilize the whole new stuff 
is out we can merge our experience and release a bunch of new things 
 ;)

gen-html knows enum and convert it to html flag but it doesn't knows 
enum2 and enul3

so the problem you notice is due surely to a forgot implementation 
to enum2 and enum3

so need to add there the corresponding html flags for enum2 and enum3

code: My current make-doc-pro version supports including code with 
=include code <filename> and source-code will automatically indented 
to become example code.

there seems to be some things missing (how to make bold and italic?) 
and I can't properly process multiple documents using makedoc2. the 
<html>, <body> and CSS code is only included in the first one, but 
not subsequent ones, if I 'load-only makedoc2 and follow the example 
shown in the source code.