World: r3wp

even if I'm agree that the rebol concept could or should be pushed 
further and that it was spread over too much OSes without taking 
full capabilities of the 3  or 4 main ones  ... that's not a reason 
to say it's  useless ...

man this guy is not cool in this article not only rebol is scratched 
and at the limit on the whole page the best comments are made on 
rebol lol... java2K .... lol ... poor java2K ...

poor intercal ...

rebol is not a ghost language no no no ....  well anyway i prefere 
my rebol ghost in my machine than .NET :P

my-func: func arg1 sring! arg2 intger  print rejoin arg1 to-string 
arg2  


hum i'm not sure that the [  less version of rebol would be readable 
easyly ...

but then you are obligated to indent your code to make it work like 
in python ... i hate indentation :P i love 1 liners  is that  a bad 
thing ?

i don't understand the install issue with rebol like java and .NET 
runtime ... i don't see the problem  there  or the point ... maybe 
he refers on other os like linux but even being half an idiot you 
put rebol VM in /usr/bin and you dont need to set up your path environement 
...

well, maybe this whole topic should be moved to Advocacy group ...

lol ... ok so off topic ...

Checking in.

lots of off topic stuff here. you may need to scroll a bit back, 
perhaps to Geomol's post.

Far to many messages to read them all.  Was there any conclusion 
or summary?

Wow... this message group has way too many messages. Has anyone thought 
about spliting the discussion into smaller topics?

Someone mentioned that there was a discussion here (somewhere) that 
I should comment on.

Geomol found a way to crash R2 with a C stack dump through self modifying 
code. It does not occur in R3, but it could be considered a security 
hole in R2, so the question was whether it should be made public 
in RAMBO. Since this group is already public, that's too late. But 
what would the official stance on security holes in R3 be? Should 
they unconditionally go to curecode?

On R2 bug:  a C stack dump, or a C stack execution?  Of course, either 
way, is it a security bug if it is only possible via code?  It must 
be possible via "input to code"... like a buffer overrun.


On R3: well, we know that as of this point, it's not secure yet. 
 If the bug is fundamental, e.g. in a native function or datatype, 
it should be posted to CureCode.


Once we say "ok we think it's secure now" then we can post any other 
bugs.

Someone mentioned that there was a discussion here (somewhere) that 
I should comment on.

 <- any hint of what it was? I'm looking, but can't see anything concrete. 
 There is something earlier about the R3 project plan needing to be 
 wikified, but Pekr says you already know that.

Yes, thanks... the project plan will be converted this week, before 
the progress report is posted.

Then there is also a bit more talk about ports and why there still 
are no protocols. There is no conclusion, other than people are either 
busy or lazy.

I pointed Carl here because of Concurrency topic not being addressed 
in the whole R3 lifetime. Carl said about it a few words. But yes, 
you are right Henrik - I also reminded Carl to wikify the project 
plan. It might be done as a part of bringing us October Status update 
....

2.100.86: PARSE fixes and enhancements. Major rewrite of the main 
PARSE function. Watch for any new side effects.

http://www.rebol.net/r3blogs/0259.html

And what A86 can do.

henrik or the 3rd thing ... that's don't have a beggining of a clue 
on what and how to do protocols....

see for example i have lot  of "free' time that I could spend on 
that topic but then i'm not sure the result will feet your expectations 
and i absolutly don't know how to proceed

demo gui not working any more in the new R3-a86.exe !!!!!

that would be due to the new PARSE.

** Script error: make-text-style does not allow block! for its font-parent 
argument

** Where: parse fontize do do either load-gui catch either either 
applier do try demo
** Near: parse spec [
    some [
        spot:
        set name set-w...


This error message is kinda weird. What is the content of "where" 
section? "parse spec" can be found in text-fonts.r source ...

submitted to curecode.

Pekr, the Where part is stack backtrace to help you find where the 
make-text-style function failed. This is a very nice feature. :-)

shadwolf, I'm no good at protocols either, so the only way is to 
study for example how HTTP was done in R3.

it is confusing and absolutly nothing telling to the end user

Actually this is way, way better than the output that R2 gave, but 
I wouldn't mind if "Where" was renamed "Stack" or something.

I just run trace/back on, demo, trace/back 20 ... I can't understand 
the output, yet, but interesting :-) But really - Windows console 
just sucks and downgrading my REBOL experience by tens of percents 
in comparison to R2.

sorry for alignment, but here it is:

Parse input: |
Parse match: block!
Parse input: |

1: make-text-style : function! [font-name font-parent spec /local 
proto style nam
2: to-word : function! [value]
3: name : base:
--> to-word
    1: to : action! [type spec]
    2: word! : word!
    3: :value : base:
    --> to
    <-- to == base
    <-- to-word == base

    4: parent : [      font: [          color: black          size
     **: error : Script expect-arg
     **: error : Script expect-arg
     **: error : Script expect-arg
 1: trace/back
 2: 10
    --> trace

just read the output from left to right. it shows that PARSE called 
MAKE-TEXT-STYLE, that FONTIZE called PARSE, that DO called FONTIZE, 
etc.


R2 would only point to the source location of MAKE-TEXT-STYLE, and 
then you would just have to hope that the place was unique enough 
to find it with a text editor's search function. That would be hard 
if MAKE-TEXT-STYLE existed in 20 different places in the code, and 
so you would have to proceed with several minutes of probing. No 
need for that anymore.

Here, I can immediately tell the path to the problem.

Henrik - as for protocols, dunno who, but someone here said, that 
the http protocol is done in an old-school way, and that it deserves 
new aproach. I will gladly wait for BrianH to take over this area 
...

I didn't study the trace function yet, so no comment on that one.

it's possible that HTTP needs to be rewritten. there are also still 
bugs in it.

Henrik - you should, it is a big helper, although one has to lear 
how to interpret the result. But by parsing output, I cam imagine 
visual tool being done :-) More here - http://www.rebol.com/r3/docs/functions/trace.html

Here's the fontize:

fontize: funct [
	"Define text styles (from dialect)."
	spec [block!]
][
	assert-gui parse spec [
		some [
			spot:
			set name set-word!
			set parent opt word!
			set spec block!
			(make-text-style to-word name parent spec)
		]
	]["Invalid font syntax:" spot]
]

I wonder why trace shows 3 errors instead of 1?

Dunno. The errors don't correspond to what seems to be a reason why 
script crashes. It imo crashes, because the header of make-text-style, 
actually font-parent, expects word! or none! types, whereas it seems 
to get block! (at least that is what the error message says ...)

make-text-style: funct [
	"Define a new font style (used for text face styles)."
	font-name [word!]
	font-parent [word! none!]
	spec [block! none!]
][

so fontize gets spec block, which does not parse as needed anymore.

it would seem that PARENT is a block, but I can't duplicate this 
in the test parser, I'm building here.

how can I replace inbuilt fontize by my own? Will it be rewritten(redefined) 
by the demo call?

I think I know what it is.

For BASE font style there is no parent, and we have a new rule that 
says that SET does not set a new value, if the  value shouldn't be 
set.

This could be solved with

parent: none

prior to the parse.

Previously, this would be done automatically by PARSE. It would set 
PARENT to none if there was no parent.

ah, so what is 'parent set to, then?