World: r3wp

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.

Also, to bring some positive news...one note from Carl: "So, just 
an FYI, R3 is running on ARM now." I thought most of people here 
wanted to hear such thing :)

Cyphre - very good work, and good aproach too imo ...

WTF with ARM? Unbelievable :-)

Almost missed that note :-)

great to hear about ARM support - do you have any idea if this is 
just core or inc. graphics?

Just core.

I bet it is just core because so far there is noone who would like 
to port graphics to Linux. What would you Linux guys do without Wine? 
:-)

:-) Without Wine? Just whine :-)

But as for "just core" argument - does it mean including the host 
kit part? I mean - did Carl manage just to compile Core under ARM, 
or is it runnable R3 without graphics?

Well, maybe "R3 is running on ARM" speaks for itself, that's really 
nice if at least Core works ...

hopefully then 'BEIN' will follow soon...

> What would you Linux guys do without Wine? :-)
Live happily ever after? :)

I live happily without it on my own Linux distro. Prevents a lot 
of frustration to be able to say to people that you can't run Windows 
software :-)

For the record, I do want to port R3 graphics to Linux, but that 
doesn't mean that it's possible or wise. It's not possible due to 
fulltime work on other R3 stuff, and it's not wise because the Amiga 
patches haven't been integrated yet, so the host kit is still very 
Windows oriented while more work has already been done

May sound stupid, but I agree :)

Looking into porting R3 graphics to Linux has been on my "if you 
ever come across a free week" list for a while.

I've also asked Steven Solie in public and in private to put up his 
Amiga patches somewhere, as this will definitely help everyone interested 
in doing the same for Linux.

Yeah, and you'd be spending that week redoing Steven's work in the 
current situation

Precisely.

Including porting his patces from A109 to A110

Which seems unwise to me as well.

(Redoing Steven's work, that is.)

I thought the old Amiga hands here would be delighted that all ports 
are waiting for the Amiga ;-)

I only tried to poke about the Linux port state. It's good to know 
there are at least two peopel who are willing to work on it. The 
Amiga port could behelpful but I still think you would need to write 
the majority of os specific stuff like, window + event handling, 
networking etc. from scratch.

scratch the 'networking' part...this is already in the Core :)

What we want mostly are the FreeType patches, because that's pretty 
much what everyone except Windows and Mac uses

I also think that the Amiga code would be a better example for a 
port than the Windows code, which tends to be awkward

And I think the hard part about the window/event handling stuff is 
isolating the parts of the hostkit code this affects.

The Amiga patches would be handy for that too.

Yes

And S Solie isn't putting up his patches??

He's also waiting for a new host kit with more patches integrated

So why are not Steven's changes included in the source-base?

...hard part about the window/event handling stuff is isolating the 
parts of the hostkit code this affects....


This is easy already...you have to create equivalents of the files 
in src\os\win32...the rest is non-OS specific code.

Cyphre - would it be able to fix receiving of resizing events, during 
the window border is dragged? That is kind of unpleasant effect it 
causes for the rebol apps. Next low level thing which would be nice 
is ctrl+tab for system compatible tab switching ...

...we want mostly are the FreeType patches

 - I have published the Freetype support changes in the RMA version 
 of the hostkit so you should be able to just use simple define switch 
 to use freetype in the Linux(or any other OS that have FT2 lib avilable)

Pekr, ofcourse, all this can be improved but currently I have other 
things on my hi-priority list...

Amiga code would be a better example for a port than the Windows 
code, which tends to be awkward

 - I don't think so...there is minimum of 'windows' related code...in 
 fact just couple of basic Win32 api function calls, the rest of the 
 code logic will be very simmilar if not the same.

So...if you go thru the 5 files in src\os\win32 dir and make equivalents 
for Linux you are mostly done.

I'm playing around with a dumb idea:

find/instance [a b d a c] 'a 2
== [a c] ; find only the second instance of a value

ok, you can do it with PARSE, but it requires an extra word

Or with chained finds.

Cyphre, thanks for the FreeType code. It's a while ago that I looked 
at the src/os/ files, but they seemed fairly large and complicated. 
I won't have time to start that project until at least after ReBorCon

BrianH: Find the 10th item would mean chaining 10 FINDs.

find-nth: func [series value n] [
    loop n [unless series: find series value [return none]]
    series
]

I like Gabriele's solution, especially with FIND being an action.

that's ok

Isn't this inconsistent?

>> to-word "d"
== d

>> to-word #"d"
** Script error: expected word! not char!
** Where: to to-word
** Near: to word! :value

Yup. TO doesn't support all conversions, but from chars makes sense 
to support.