AltME groups: search

The plan is now to do a /Core and /View, with /Core coming out first.

brianh  i know htat what i read on the blog too but i though vid 
would be integrated by default in the VM ... a module is like it's 
external and you don't have it by default

There are internal modules, and some of them will wrap natives.

Too much code, too much to keep track of. So, Carl took a break to 
start the module system and I finished it.

i want a way to handle fonts the proper way on all os's and with 
draw . i want a given font to be able to speak with me or the VM 
and draw/text to auto adapt the rendering to it. (if i have to simulate 
a fake cursor i will need to know what is the real pixel size of 
each of the chars in my line;;;)

and i want so the fonts given to be rendered the same way on any 
os

i don't care having rebol on iphone i want it to wark the same way 
in linux, win7 and macOsX that would be just enough

my idea is to offer the user an easy GUI font selector  in viva-rebol 
and having the any fonts he use not disrupts the renderng  i noticed 
really strange effect with fonts on other Os's than winXP things 
rendered  like this :

winXP:
toto: func [ 

on windows 7 was producing 
toto	:	f	u	n	c [

things like that

maxim exactly and even the linux rebol VM renderise same font from 
same font file in a different way  and the fixed font caracter is 
not kept at all all fonts become unfied like magic and some time 
along the document produce wrong spacing information

i tested even forcing rebol to use the tff file from windows XP  
and that produced the same sizing bug 

all the text motion turns around the idea you don't have much to 
care about each char size in pixel since it's always the same you 
do a size-text call on "MM" only when you change the font size (growing 
the text shrinking it) and that's all if we had to care about the 
rendering of each elements in the texts that woud be a real pain

we would have a draw/text call for with precise sizing for each and 
every char  making the draw block cliped to our area-tc/effect/draw 
a gigantic size

hello word imagine it as text 0x0 "H" text 0x10 "e" text 0x15 "l" 
text 0x17 "l" text  0x19 "o" and each time you have to retreive the 
precise size (an hash table could be done with char => real_pix_size) 
but then you need anyway a good way to retrieve that size in formation 
being sure it's not a wrong information and size-text  doesn't works 
well on char from unfixed fonts

and we are not even speaking of unicode OMG lol

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

font rendering not taking advantage of AGG i'm completly agree since 
anti aliased doesn't works properly but this should be the time on 
that particular area to see the font rendering area under a new line 
of real time text processing and their is alot  of amazing things 
to be done . 

in the end my request is simple i want my users to choose their own 
font they like on any ot the main OS brands and get the same result 
everywhere (even on online editing for example imagine the rebol.org 
integrating viva-rebol thrue rebol3 webrowser plugin  to allow the 
script sumiters and owner to share editing of a script with bunch 
of select people. That's the qualité we should aim for.)

Pekr can we still keep win32 15 years old kid as base for VID  on 
windows plateform on a middle term  (5 more years) won"t it be better 
to start right now to support winfx enhancement and use part of the 
hardware acceleration in rendering?

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

rich-text is read only spécific rendering  based on a specific markup 
language... since we are not talking about the same goal ( i want 
real time text edition (read and write) and the hability to create 
extend or change the rendering process to feet not only colorize 
text but any kind of tet rendering with high performances and simplicity 
of code writing. area-tc is just the first step in that process it's 
just  a proff to show that VID and most largely rebol concept can 
bring to that area. But there is still alot of work to do and that's 
normal initially VID and draw were not designed to handle such duties 
and the tricks we had to use to achieve that goal in R2 only showed 
us the limitation of the existing. So what we do do we evolve to 
chase that area or do we just try to redo again a limited R2  version)

then i think ritch text is based on an old idea replaced by a more 
powerfull one....  based on area-tc way to work redoing the richt-text 
area to bring in it the write cncept is not impossible to be done. 
and what better way for a user to use a markup language not knowing 
you use it (MS word and all other advanced tet editing tools does 
that constently. from RTF to PDF)

and wysiwyg interfaces are the best ones for regular users

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

maxim i already long time ago worked in the Markup document creation 
tools with ashley MDP-GUI  and one of the limitation was that you 
could not create the markup data and the at same time see the rendered 
result at same time you had to use 2 separated boxes one for rendering 
the other for "scripting the document"

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

yeah but anyway markup had another conversion stack wich would be 
better to be done directly to draw dialect. and i'm not sure the 
markup language doesn't imposible limitations that will not allow 
you to go out of the box.

as long as you can detect what word is under the cursor at a given 
 coordinate using specified scrolling, you could use the rich text 
directly.  and then output to whatever format you want... as long 
as you can predermine how all the coordinates map in both systems. 
 This last part is what just about every importing/exporting out 
there tries to get just right... but in the end, its never exact 
because coordinate systems are different, font rendering engines 
don't use the exact same algorythms, etc, etc, etc.

something that was sorely missing in R2 , and isn't readily available 
in all GUI systems. :-)

the rich text has all of the format and explicit position info... 
if you want to slide text in order to add an image inline... just 
do so.  ;-)

as I said, we need to know the offsets... if you really want to use 
another layout engine, just wait for extensions to support image! 
and go crazy  :-)

hum but  in general you do your best to select the best 3D file format 
 to go with your custom made 3D engine to get the best rendering 
real time speed and that best quality compromise.

and that's exactly what an imposed Markup dialect forbids to you 
point.

more low level instruction to make y world easyer why not ? ...  
being tied by the neck and forbid from freedom no way !

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

but there is no link between make doc and rich text.

It seems insert (and maybe even change, remove) are already implemented 
for parse? At list this is how I read between the lines of Carl's 
blog reply in Either related blog ...

And it looks like it is the ? | model I put here :)

'into does not seem to allow other types yet, we don't have multiple 
to/thru and 'use. Hopefully those get added in first iteration of 
parse rewrite ....

multiple to/thru  are near the top of the list... and Carl recognises 
their use... and probably they where the first requests, ever for 
parse.

did we ask for too much and unleashed a monster in Carl?  ;-)

I agree... then is the most readable and is pretty close to the meaning, 
and especially since then is related to if then else.

hmm, 'and reads much worse in the example at the end of parse doc, 
than STAY or HOLD would read there ...

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

It is called AND because it means that something at this position 
has to match one rule *and* another.

OK, but - what happens after the match? (at the end of the block) 
- where is the position? At the end of currently matched rules, or 
at its beginning? Because my initial understanding was, that STAY 
was supposed to match the rule (look-ahead), but, it did not advance 
the positon. And if it is true for AND, it does more, than its name 
suggests, no?

As for EITHER/+, my favorite proposed name for that is now =>. We 
absolutely have to use '| for the second part, since => is *not* 
an infix operation, it just looks like one. Since we can't use 'else, 
'then looks a little silly, as do all alphabetic words when paired 
with a symbol like '|. We need another symbol, and => implies advancement 
without making it seem that the data position is being advanced like 
'next would.

If both rules of the AND succeed, then the ending position of the 
second rule is what you end up with. It's like shortcut boolean and.

forget AT, there should be AND, it is a typo. But as I understand 
it, it returns back at initial position?

As you described AND few moments ago, it sounds logical - if all 
conditions are succesfull, then OK, otherwise return to the starting 
position right in front of AND?

Ah, but you didn't get that AND only appears to take two arguments. 
It actually only takes one argument, and the second works on its 
own.

hmm, so and is not semantically aligned with | ? I mean [a & b & 
c]?

AND has to be prefix to work, which is why it isn't called &. Algorithmically, 
it is the commplement of |, which needs to be infix to work, and 
is the only operation that *can* be infix. Implementation restrictions 
that we try to make sensible, by using visual naming tricks.

OK, but - we always think about OR vs AND as their logic counterparts. 
Now it is not true, or is it? By our definition:


AND: Purpose: A look-ahead rule: Matches the parse rule without changing 
the current position. 


I am denerved about the "without changing the current position" part. 
It is some explicit rule user will have to know. Why not to advance 
the position?

hmm, actually I wonder, how can I match one input stream by multiple 
rules (the real logical AND), this is not probably even possible 
:-)

The whole point of AND is to *not* advance the position. It allows 
you to check more than one thing about the same data.

AND block! into rule - does mean - check if the next match is being 
a block, but don't advance. And if so, go into rule? If so, then 
AND is totally weird name ...

I need following to work in terms of parse dialect :-)

keep: :and

Not a weird name, it is the closest equivalent to a logical and that 
you can get in a backtracking system. The only weird part is that 
it is prefix instead of infix. However, if you remember that *all* 
parse operations are prefix (except | ) then it won't seem so weird.

=> needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all:

- The a is matched first, and if it fails it backtracks and advances 
to the next alternate (aka, past the next | )
- If a succeeds then the next rule is processed.

- The next rule is =>, which matches its argument rule and then skips 
the next alternate, whether the rule succeeds or fails
- b is the argument rule of =>
- | c is what => skips

Does AND, in our parse situation, have anything in common with math/logic 
AND? I am not able to see so deep, but I know that parse is in fact 
some deep math ...

AND is like the shortcut boolean logic and. | is like the shortcut 
boolean logic or.

And can I explain, by such math layer, why it moves, or not? All 
I am trying to find out is, if we can explain to the user, why "AND 
block! into rule" does not consume block! position :-)

Because that is how you can check that the current value is a block! 
AND matches into rule.

re: => needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all ... I thought, that underlying C level can decide, if 
something can be prefix or infix = match a and look if next keyword 
is =>. But then it would mean, that we would slow down parse engine? 
Because then we would have to perform such check for each rule applied, 
to check if eventually => follows?

Because that is how you can check that the current value is a block! 
AND matches into rule.

 - remember that one for the docs. There will be many stupid users 
 like me, trying to understand, what the heck AND is doing and why 
 it is doing so = we want to have description theory why it is the 
 way it is :-)

I like => more and more (especially as I suggested it :-), but Henrik 
suggests, it has different meaning in Math. Is that true? I do remember 
that I often use ==> to express "then", so I just shortened it to 
=>

I was also inspired by one script, and now I dont remember which 
one, which used something like ---> in combination with some indentation, 
but maybe it was just a debug output ...

/into is a new refinement for most series. It makes it possible to 
store the result directly in a series without copying. I've been 
watching BrianH jump up and down over this feature a few months ago. 
:-)

Maybe TOO is too similar to TO,  but it's meaning is appropriate 
for this AND or  &

for new parse rewrite, there is going to be default /all mode, and 
/ignore mode and even maybe /case, so dunno, if delimiters will be 
provided as with R2 parse ...

I have a small CSV parse and CSV generator library that we could 
start from.

SPLIT has too much useless options and use other mezzanines (COLLECT) 
in his code, it why it's not a good mezznine to my mind.

On example here -- the specific problem is the same in R2 and R3:
   http://www.curecode.org/rebol3/ticket.rsp?id=1042&cursor=2

Brian - it seems that Ladislav does not agree to your conclusions 
towards parse internals ... and Carl is all but silent :-)

It reminds me of old ML discussions of gurus, trying to find internal 
REBOL representation, and differing in opinion of how things are 
done under the hood.

Back in 2000 I was one of those gurus on the mailing list, and my 
argument with Gabriele was the initial documentation for R2's context 
model and behavior. I was glad when Ladislav later fleshed out that 
discovery with more detail in his Bindology papers.

Sounds good ... and won't hurt

I think that Cyphre can't work on View engine because of C code alignment. 
We have to wait, untill Carl isolates kernel and host, and releases 
the code. But then - even few small changes might make some difference 
in the end. I think that View engine deserves few weeks of additional 
developments ...

My preferences:

- Get it done
- Make it easy to use

- Use R3's existing timer system for long delays, and then multimedia 
timers for the last precise bit

- Get smart graphics people to help with the little details, but 
smart systems people for the overall design

- Make it so easy to use that I, as a non-graphics-person, can write 
GUI apps

brianH yeah ... i always said new VID have to be as easy to write 
as previous vid for non specialist and  it serves even a greater 
purpose the GUI designers area. With easy made gob or panels (windows 
where you arange the gob to be displayed on screen ... ) the the 
designer output source produced with those tools remains easy to 
read.

I came with something existing, and said: Now, how can i do this 
more rebolish...

parse/case opcode [
	any [
		start: 
		| "nn" end: (change/part start get-byte end)
		| "+d" end: (change/part start get-d end)
		| "e" end: (change/part start get-e end)
		| skip
	]
]

Forget CHANGE for the moment. Even with INSERT and REMOVE commands, 
i see things i don't like.

What i should able to write is that:

parse/case opcode [
    any [
          remove "nn" insert get-word
        | remove #"n" insert get-byte
        | remove "+d" insert get-d
        | remove #"e" insert get-e 
        | skip
    ]
]

Wich means:

- Remove "nn" if  "nn" is matched and insert the result of the function 
get-word.
or  Remove "n" ..
or  remove "+d" ...
or remove "e" ..

- Remove should use any rule as argument and not an obfuscated relative 
counter, because we don't have to calculate that. 

We know what matching rule must be deleted, we don't have to calculate 
is length more over.


- Insert should accept calculated values, it's obvious. If not it's 
useless.

First of all, Steeve, what you are suggesting is the original INSERT, 
CHANGE and REMOVE proposals. Which Carl said were infeasible to implement, 
which is why we have the new ones. Besides that, your example code 
is still too awkward. Try this:

parse/case opcode [
    any [ start:
          "nn" remove start insert (get-word)
        | #"n" remove start insert (form get-byte)
        | "+d" remove start insert (get-d)
        | #"e" remove start insert (get-e)
        | skip
    ]
]


If you are worried about change not working yet, don't be. It is 
still planned.

The planned treatment of the value argument for insert and change 
is to be the same as that of quote.

BrianH: how do you know => is going to be added? Any new info from 
Carl? Because I noticed his reply stating => is problematic, and 
no indication that ? might be changed to =>

And as for the insert/remove changes, I was saying that the originally 
proposed way was infeasible because of private discussions Carl and 
I had about the subject. Carl's version is more powerful anyways, 
if you include the integer version.

and if we free ?, will we use it for if/check?

It would be a loss of functionality, slower, and more memory-hungry, 
but I would be OK with it either way.

I think, that everybody is waiting for your go. I think that most 
ppl here prefer you working on Core. Most of devs here will prefer 
complete Core, along with parse, extensions, host code released, 
networking protocols, cgi, console and especially some FIRST words 
on concurrency ...

Actually - ppl still think, that before the host code is released 
(and hence host using Extension api (I think)), we are still dependant 
on you doing all the work ....

First, it's easier to get a Core completed, so that those of us (and 
I include myself) can start using R3 for our servers and other such 
tasks.

So, we must then look at it: what critical things are missing from 
Core?  And...

there is - projects-plan.html. We should vote on features, update 
the projects-plan, and go for it.

Noone can help, if Host is not released, and host is not released, 
as it does not use Extensions. Extensions might require few requested 
features, etc. I think those things are obvious ...

BrianH is your second brain and RT should put him under the contract 
:-)

BrianH and I work together well, but the two of us alone are not 
enough!

The victory would be in speed and the fact that your replacement 
code was missing a :here, but your suggestion is nicer I suppose.

My summary for what defines the beta is in my 3 posts here: http://www.rebol.com/cgi-bin/blog.r?view=0424#comments
... and even Concurrency is missing ...

2. "Networking/Schemes" - I spent a lot of time on the Scheme model, 
to purify and simplify it compared to R2.  So, I'm not sure what 
BrianH is proposing yet.

Carl - protocols/networking is the stuff community can work on. I 
suggest you concentrate on low-level stuff:

- finish parse changes

- back to Extensions and closer to Host interface, prepare for release 
and first porting efforts

- please let's at least outline, what the concurrency model is going 
to be. Without it, Doc will not waste his time trying to port Cheyenne 
to R3, if R3 concurrency model is not at least defined?