AltME groups: search

Howevere PARSE is still not complete: REVERS is the only thing I 
miss. However, If we must judge, 95% of work on PARSE is done and 
only 5% is missing.

REVERSE, LIMIT and OF (but renamed I hope) are still on the todo 
list, and I really want all of those. My biggest pie-in-the-sky requests 
have been done though (with the exception of USE, which I have a 
workaround for).

It is triage time, my friends. We are heading to beta, so we need 
to seriously consider what it practical to do quickly, and what needs 
be put off for a bit. REBOL is going to continue to have reasonably 
frequent updates - no more waiting years for the next release - so 
you don't have to act like your favorite proposed feature will never 
arrive if it doesn't make 3.0. We need to figure out what we need 
to make a useful beta.

REBOL 2 will still be here, and despite what some people have been 
saying it hasn't been abandoned. We have been focusing on R3 lately, 
but there will be new R2 releases to come. Migrating to R3 won't 
be an all-or-nothing affair. Gradual migration and mixed projects 
may be the norm for the short term. We don't want to block our users 
from uusing the killer features of R3 just because it doesn't do 
everything R2 does yet.

BrianH: I think that everybody here understands, that we aim for 
3.0 Core release. But even that one needs to be feautre complete. 
I would really like, if Tasking for e.g. would be there, because 
it CAN influence some modules, mezzanines or even natives. This is 
fundamental feature to have imo, and some devs (Doc - Cheyenne) are 
waiting for it. Then add back console. CGI under Windows was solved, 
Netwokring protocols are going to be adressed hopefully soon too 
:-)

BSD or MIT... yes that is exactly what I proposed... it it VERY well 
coded and exceptionally small the whole putty app is in fact smaller 
than rebol.exe IIRC :-)


it has a LOT of goodies beyond a full SSH2 encryption set and EVERYTHING 
is stand-alone it relies on no external dll or libs.

Carl once admitted that is was possible but not "enabled".   AFAIK, 
he never told anyone the trick.  maybe its unstable and didn't want 
to put time on it.


theoretically, one could build an https server protocol in R2... 
the encryption algorithms are all there AFAIK in /pro licenses.  
its just knowing the handshaking protocols and all that... I look 
briefly at the RFC once and its not "obvious" to implement... at 
least not for the bg I have.

Just a question regarding GUI: We have GURUs like Henrik, Ashley, 
Cypre, Maxim. II have read that host source is being released to 
Maxim and Cypre. Why don't you build a GUI Team made of all those 
GUYs to push forward the developement ? I think they will make something 
explosive ! Also Gabriele has experiences because he build a prototype 
VID 3.4.

Giuseppe - just don't worry :-) Look at the document Carl posted 
regarding host code release - there are several phases and Cyphre 
is definitely involved. I hope we cooperate for good ...

Henrik, you and the other people mentioned have great skills but 
I see sometime that everyone is moving creating his one version of 
something.

Once the alpha stage ends and carl will define the roots of the new 
VID a group of high competent developers could cooperate and create 
the final product quickly and professionally.

i vote for GUI  team !

And don't count on me to be part of it i'm just an idiot unable to 
understand my own source codes so the source codes from others .... 
too much a challenge

but yea maxim cyphre, gabriele, steeve, and any other people than 
me would feet the task

and they have pretty good ideas in the different area i'm sure they 
will rock VID

Is this actually going to be released? And could we hope, the same 
thing would happen to R2, which is more interesting (to me at least).

Geomol - why is R2 more interesting to you? I can't somehow understand 
it :-) There is many areas R3 already surpasses R2, is more precisely 
defined and consistent. Time to move to R3 really soon imo ...

I think that initially it will be released to only handset of developers, 
and after two or three weeks (my estimate),  maybe others will be 
added too ...

I have a huge graphical application written in R2 (Canvas RPaint, 
close to 13'000 lines of code), that I can't get released because 
of host problems and differences in REBOL between OSs. I do much 
of my development under OS X, and I have lots of utilities and applications 
written in R2, that suffer from problems in REBOL/View, that I might 
be able to solve, if the host code was released. I have tried to 
look into the graphical part of R3, but I can't see, how I'm able 
to convert my code to R3.


(I'm sorry to say so, but R3 to me looks like a hobby project, not 
a serious business projekt.)

Geomol, last year I have written the same thing but this year a lot 
has happened.

Once alpha i finalized and VID is complete expect a boost into the 
development.

Also I suppose REBOL is short of money and programmers so they cannot 
speed up the project.

Geomol - wait half a year, and you might get even View/VID in R3. 
Core 3.0 is close.

It would be good, if you are right.


As an example of my use of R2, and where I can't use R3, look at 
this image:
http://www.fys.ku.dk/~niclasen/bachelor/dist.png


I'm working on my bachelor project in astronomy at the university. 
I'm going to make a simulation of comets at the Late Heavy Bombartment 
some 3.9 bio. years ago to test a theory, that the water on Earth 
came from those comets. A part of my work is to study earlier simulaitons 
of 10'038 comets made by others. I would like to see, how the distribution 
of their initial situation looked, so I made a little REBOL script, 
that plotted the 10'038 comets and the orbits of the planets, Jupiter, 
Saturn, Uranus and Neptun. The image is showing this. It took me 
very little time to write the script in R2, and I can use the result.

Can you see, I can't use R3 for such things?

No, you misunderstand. I hope and expect R3 to be able to do that 
some day. I just look at the facts:
The project has been gong on for 4 years since 2005.
Where it is now.

When I can expect it to be in a condition, where I would begin to 
use it for real. (I've learnt to have very small expectations.)

I said a looong time ago that we would, when R3 reaches beta, require 
a much larger number of developers to move forward. When extensions 
and host are properly released, this will still be the case.

I made a quick test to compare calc performance between R2 and R3. 
A 10'000'000 loop of some simple + * and /. It took around 17 seconds 
using R2, and 27 seconds using R3. If this is not changing, then 
I will probably continue to use R2 more than R3.

It takes 55 seconds in R2 and 64 seconds in R3 here.

But don't forget that extensions are precisely for such cases and 
R3 is way ahead of R2 here.

Yes, the say to go with heavy calculations is probably to get some 
C code written somehow, and then just use REBOL as the control program.

we can expect

 - no, I think we can expect a reasonable explanation to the slowdown 
 and possibly a fix, when we get to that point.

I don't think Carl wants to complicate R3 with fast maths that could 
be done smaller and faster as a C extension anyway.

It's interesting, that the difference is large when running under 
OS X, and just a few percent when running Windows.

I not surprised that the Windows R3 Alphas run better than the Mac 
ones. Carl seems to develop for Windows and then ports to Mac and 
Linux in between "development phases". I think the more we report 
Mac bugs and issues in CureCode the more likely we are not to end 
up with a crippled R3 on Mac.

Geomol, sometime I felt frustrated by the long time REBOL3 took to 
be developed but now I see the light out from the tunnel and it is 
not the train running against us !

REBOL3 has been rewritten from ground upp with high skills and few 
resources. This mean it needs time to be completed but it will be 
like a good wine.

Actually we are in the state where all developers should wait for 
the core to be completed. In beta stage they will be able to operate 
and cooperate to extend it.

Giuseppe: I think it would be better if more developers could test 
the R3 alphas and report bugs and issues rather than just wait.

PeterWood, I think that only a little step further is needed to have 
this. Developers want R3 to be used in REAL world scenario and do 
testing for passion; this is called "motivation". Even Carl admits 
the situation.  When CGI support, VID, and extension will be finalized 
expect an huge boost into test and debugging.

Geomol, the manual was converted from the Core 2.3 manual, and most 
of the pages still reflect that. For types where the semantics have 
changed, the manual pages usually aren't updated until the semantic 
changes are finalized. This is not the case with money! yet, so the 
page hasn't been updated.

Geomol, all the work on R3 was not about improving the runtime (host 
code)... as much as the language (the core dll).


improving the runtime is easier/faster cause decisions are either 
obvious or straightworward.  work on the core is both tedious, highly 
philosophical, and complex.  add one assembly instruction to functions 
evaluation and you've slowed functions down 50%, everything design 
Carl changes, basically cause side-effects else where, its a very 
organic process.


I see it like a closed system, where the slightest change causes 
feedback where you have to stop everything and start again, until 
the system is balanced and doesn't feedback.  then you add another 
thing to the system.

the host is a totally different beast.  once a few of us have the 
host code and start hitting it with "applied" code, 2 things will 
happen IMHO:


* The core work will start to shift from "completing" R3 (architeture) 
to "finishing" it. (bugs, optimisations, docs, etc).


* R3's theoric usability (which is what pekr keeps refering too ;-) 
will be replaced by more and more "applied" usability, what you, 
I, and many others have been actively refering as "a working" version 
of R3.

at first I did understand what you meant, I started a reply and then 
realized that you where explaining what I meant by closed... so I 
further expanded hehehe... no chance for mis-comprehension now  ;-)

I have the Reichart chat disorder...  In my case, I litterally see 
and read the word in my mind... not on the screen... so when I post, 
I often don't even realize words are missing or totally wrong... 
;-)

...I have considered moving to "!did" as in "NOT DID" to fix that 
problem.  I really hate that polar words are not MORE different. 
 

For example even better than !did would be "did" and pop" for example. 
 Where "pop" is the negative of "did".

we should all dump all languages and just learn latin... stop the 
language madness  ;-)

to me, latin is to language what math is to physics.  logic, order 
and structure... applied to chaos and randomness  :-)

I remember writing a program many years ago on my Amiga, that would 
change the input to what I choosed using a simple lookup table. I 
used it to write fast in e.g. IRC, where I would make a table with 
the 3 first letters of many english words. When I wrote 3 letters 
and pressed space, it would write the full word. Could be used to 
change things like !did to didn't. The good thing with the Amiga 
was, I connected to the console device (or what it was called), so 
the program worked everwhere with all other programs using the OS. 
Could also be used to e.g. program fast using shortcuts for command 
words.

GEomol and henrick OR YOU CAN STOP USING PAST CENTURY COMPUTERS THAT'S 
GOOD TOO !!! 


>> x: now/time a: 1. b: 2. loop 10000000 [a + b * a / b] now/time 
- x
== 0:00:03
Take that baby

Heh, my test was about R2 and R3 performance, not to test how fast 
(or slow) one of my computers are. I could have run the code on my 
multi-GHz intel box.

LLVM is a compiler, which you can control in real-time and easily 
embed.

Or you, as a dev. simply use LLVM to create REBOL executable? And 
as you have ti LLVM abstracted, you basically code to one host environment? 
I probably don't understand the model correctly ...

it would make for a powerfull extension, where we could simply run 
a rebol dialect like Rebolek's REBOL syntaxed-C and compile it in 
real time through an extension which serves as a jump vector manager.

shake, one of the most high-end visual effects software in the world, 
uses a system just like LLVM within their software and it made it 
much faster than all the competition because of it.

sure, its not for the host, but its still not huge, and makes for 
a nice feature I'd add in any of my speed-critical applications, 
if I had access to it.

Shake is not good because of LLVM-like low level imo, but because 
of properly Graph based GUI. Now allow us something like that for 
View, and you get-me-interested :-) http://www.apple.hu/hun/mac/shake/shake/shake.html

pekr... wrt shake... and what do you think the graph does ?  ;-) 
 


the graph is compiled in real-time everytime you change its structure. 
 you can create your own nodes and add them to the engine, using 
the graph itself as a visual development platform.


 as I said, I worked for those guys... I have an intricate knowledge 
 of how it works.  I also implemented a REBOL implementation of shake 
 callings its rendering engine and intepreting its (C) Header files 
 to integrate all the nodes.  :-)

yes, in R2, globs is such an engine, and it works very well.

Regarding JIT/VMs: Recently I spent some time looking into this area. 
After the short investigation I believe JIT compiler which can be 
really useful(and fast enough) for Rebol can be written in kilobytes 
of code not megabytes.

a VERY cool and somewhat, excentric, group of people hehe... nothing 
real parties at tradeshow events like siggraph... usually where the 
most sought after events...   S&M show with boobs on fire :-)  nude 
circus acts.  world-renowned dj's doing the music... ahh... those 
where the good times.

shake still today is preferred for very large effects shots... it 
can layer 500 full frame cinema images (2048p or more) using a few 
hundred megs of RAM.  other softwares need 8GB of RAM just to handle 
10. and render exponentially slower.

it took me just a few hours to have OpenGL running in an extension.... 
 which includes downloading all the OGL libs, and C compiler and 
stuff.

well, for those of you who are on devchat... you can see my (humorous) 
host-lib compilation post there, but for all others... just I just 
want to tell the world that... 

ITS ALIVE!!!! hehehahahahaha (evil grin and laugther)...


yep, I am on the short list of lucky individuals who got the host 
code, and it compiled the very first time I tried, so, mission accomplished 
and congratulations to Carl.

OK, and what compiler have you used?

so far, I really like the Device model, there's nothing like C OOP 
without the ++  

Exactly like the Amiga philosophy used to be.  :-)


I guess C++ coders will just be screaming as to why this isn't all 
classes and objects...  but its simple to code in any case

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

And there is no http server support yet.

The source from the console was generated from the scheme dialect, 
and that source was originally generated from the .rlp. What you 
see at runtime is not what gets written. You need to get on DevBase 
to see the real source.

The R3 and R2 development process uses a lot of code that generates 
code; FUNCT is one such example, but not the biggest.

Heck, 2.7.7 uses two functions that generate and run code at *runtime*: 
APPLY and MAP-EACH, both native in R3.

It's more confusing to understand the big picture than it is to actually 
develop and use the code. The code generators are quite helpful.

Plus, afaict the http spec that Gabriele wrote (the one in the doc) 
was written before most of the helper functions, so it doesn't take 
advantage of their helpfulness. It might be best to start with %mezz-ports.r 
in #26, and then %prot-http.r in #27.

so I see prot-http.r and prot-http.rlp

and I use get to fetch the files .. and don't even need %prot-http.r 
:)

So, trying to port your http patches to R3? Funny, I was doing the 
same thing this evening. Wanna work together, or should I work on 
the reorg and server support instead?

And refactoring is later. Right now we're focused on getting things 
to work.

which allows you to define where to look for words and in what order 
the dictionaries are searched

In the case of FUNCT uses in the mezzanine source, the code is run 
and then saved, so there is no FUNCT calls at startup time.

And there's this in prot-http.r

crlfbin: #{0D0A} 
crlf2bin: #{0D0A0D0A} 
crlf2: to string! crlf2bin 

This stuff should be in some reusable module too

I think that the preprocessor will actually mix in the mixins itself, 
as if they were part of the original source of the calling modules. 
That way if you want to do selective import you would split your 
module into two, one that contains the shared stuff, and another 
that contains the local stuff that references the shared module. 
It's not as hard as it sounds.

How about let's worry about the refactoring later, and focus on getting 
it to work now. We can refactor on the way.

Kaj raised the point of how much memory r2 and r3 take compared with 
the clone ...

read and write are very similar ... can we do this?

		read: func [
			port [port!]
			/write data
		] [
			either any-function? :port/awake [

    unless open? port [cause-error 'Access 'not-open port/spec/ref] 
				if port/state/state <> 'ready [http-error "Port not ready"] 
				port/state/awake: :port/awake 
				do-request port 
				port
			] [
				sync-op port either write [ data ] [[]]
			]
		] 
		write: func [
			port [port!] 
			value
		] [

   unless any [block? :value any-string? :value] [value: form :value] 

   unless block? value [value: reduce [[Content-Type: "application/x-www-form-urlencoded; 
   charset=utf-8"] value]] 
			read/write port data 
		]

heh ..Gabriele must be top down programming .. .he writes the higher 
order code first and then the supporting definitions.

He programs in the RLP and then it topologically sorts the code.

The original prot-http.r was generated from .rlp, but has since been 
revised directly. Look at the revision history with LF and DIFF.

ok,  I see this

        spec/headers: third make make object! [
in the rlp, and in the .r

	spec/headers: body-of make make object! [

so the rlp is correct?  and the .r is not ?

The .rlp version is more than 2 years old, the .r is more recent 
and works.

so spec/headers contains the standard template, and it adds these 
other members to this template?

oh ... headers is a block and not an object!

I think that the Accept, Accept-Charset and User-Agent headers are 
the defaults, and spec/headers are the user-specifiable options.

we should allow binary! as well ... and change the code to 

if content [
		if string? [ content: to binary! content ] 
		repend result ["Content-Length: " length? content CRLF]
	]

Sure. And it's going to be rewritten so that http server mode is 
supported too.

This would be where you are PUT ing a binary file and you already 
know the length, so you set it in the spec ...

Clarification: The http server mode is meant to be good enough for 
Doc to build an R3 Cheyenne on. If he feels the need to bypass it 
and go down to the tcp level, that would be a failure.

if you look at the port object! after eg. opening rebol.com, there 
is a port/scheme/actor object, and then the actor object seems to 
be duplicated in port/actor ...

Just a question about eg.

open http://www.rebol.com


Does 'open take the url, turn it into a port object, and then invokes 
the http scheme'' open on the port object?

That's useful ... I thought I molded the whole p and didn't see anything 
...

Graham: i write top-down or bottom-up depending on the case. if i 
know *very well* were i am going, i usually work bottom-up. otherwise 
top-down generally gives much better results. the R3 http scheme 
was more bottom-up than top-down. however, i always tend to present 
the code top-down, for a number of reasons. first, most people are 
only interested in the interface (how to use the scheme) - they find 
that first. after that, people maybe just want to figure out why 
something is not working or how something works, so they just need 
to go a little bit deeper, and that means just reading a bit further. 
only someone who needs to figure out the whole thing needs to read 
the whole file.

Graham: re. the headers discussion above, spec/headers is the user 
supplied headers. the ones in there are the default one (the template). 
in order for the user to be able to override the default, it is make 
template spec/headers and not make spec/headers template.

I had a look on chat and there doesn't seem to be anything there 
....

Graham: this was writteng when binary! was still any-string!. then 
the code was changed quickly to make it work with the new unicode 
build (hence the crlfbin stuff and some of the hacks in the parse 
rules).

read returns binary if it can't convert the content to string (ie. 
content-type is not text/* and charset is not UTF-8.) this was a 
quick addition after the unicode changes, and needs much more work.