AltME groups: search

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.

Our main goal would be to build the official GUI for R3, which Carl 
is forming from scratch. Right now it would be a bit foolish to go 
build our own UI to immediately go into competition with VID 3.4. 
It would be double work.

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

I doubt you will see R2 source release anytime soon. R2 is monolithic 
in design, who knows how it is (or is not) internally separated. 
R3 was the answer to R2 inefficiency in that regard, so if you ask 
for R2 to have such a feature, you ask for R3 in fact :-)

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.)

R3 is Alpha! A little unfair to call it a hobby project..

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 - you are completly off. I would not expect reaction like 
yours from person like you. Calling R3 dev. effort a hobby project? 
Where do you live, man? On a different planet? Sorry for being picky, 
but R2 dev. effort, compared to what we achieved with R3, is a complete 
joke, yet you call R3 being a hobby 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 think that trying to get R2 View working properly under OSX will 
take longer than reaching the same goal for R3. I don't think there 
is much we can do in terms of speeding either R2 or R3 development 
up, so it's simply a matter of waiting until it's ready with the 
number of developers available to us. I don't want to disturb R3 
development with too much interference from R2.

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.

Henrik, you've used R3 more than I have, I think. Do you remember 
my work on FITS files in the spring from my visit to the telescopes 
at Tenerife? I made images from the 16MB FITS files using R2. It 
took 1-2 minutes to compute one file, where it takes less than a 
second if using C. How do you think, R3 perform compared to R2, when 
it comes to brute force calculations?

If it's math heavy it will probably be around the same. If you use 
graphics, the better scalability of having many GOBs will help speed 
up certain operations. DRAW is currently around the same speed. If 
you use it as a C extension, then you will of course get C speeds. 
There are a few tricks in R3 to reduce the need for copying as well 
as some functions that have gone from mezzanine to native.

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.

a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]

I didn't know there was a PPC version of R3.

Seems like there's a newer version, than what I have installed. I'll 
try the newer one...

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.

My results
R3
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]

== 0:00:05.575825

R2
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:03.590101

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

I tested mine under VMWare, so that's a third environment.

The money! datatype calculations are much slower, I guess that is 
the price of accuracy:


>> a: $1.00  b: $2.00 dt [loop 10000000 [a + b * a / b]]
== 0:00:15.957041

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.

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.

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, 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.

it seems the word "closed" is too closely coupled to souce in CS.... 
by "closed system" I do put the emphasis on "system"  as in a chaotic 
system, like a complex frequency modulation patchbay or a closed-circuit 
video system where a monitor is in the view of the camera.

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 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

Take this:


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

llvm is a compiler.  its not an OS service.

but its a compiler which can be easily embeded into any application.

mesa3D is using it in their driver engine to convert graphic calls 
to any GPU instructions... on the fly.  implementing a driver becomes 
just a question of providing LLVM instruction maps... although not 
trivial... still much simpler than having to go from HW to OS in 
a single driver  ;-D

although we could all of this ourself... LLVM is a nice framework 
to make all of that easier.

so it is not a compiler, it is a virtual machine environment, no? 
What is the advantage here? REBOL is its own VM - if we get it to 
every platform, why would we need LLVM? How big is actually LLVM?

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.

so you code in a language similar to REBOL, but end-up with compiled 
code which is linked dynamically in the host...

souce code is 7MB, but probably includes a lot of stuff we can trim 
for our specific purpose. the binaries are big wrt rebol, so it can't 
part of the host code(unless brian can build a very slim version 
of it), but it would make for a very nice extension.

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.

if some compiler adds more than 100KB to REBOL, then it is a no go 
:-)

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.

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.  :-)

They still sell Shake? I thought it was discontinued a couple of 
years ago.

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.

give me a few months  ;-)

a lot of the stuff is already coded... it just needs to be translated 
for R3.

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.

Just being able to compile the host source with a C++ compiler would 
be sufficient - having declarations still work, for instance. The 
rest could be handled with shim code, basicaly what most of the host 
code is anyways.

Guys, there's a trouble with OS-X or so it seems. Any experienced 
OS-X coder to help? Message from Carl on R3 Chat:


I must set OS X on the back burner... I've wasted far too much time 
on it.

There are three choices on it:
1. find a tool that does what 
I need
2. make a tool that does what I need
3. join all the sources 
into one large .c compile

Note that gcc -fvisibility=hidden does 
not work, nor does __private_extern__ wor
k either.

I've got to 
get on with other projects now. So, if you happen to find the soluti
on, 
let me know. (PS, yes, using GCC > 4.0.)

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.

DevBase, aka chat. Be warned though - it was generated from a literate 
programming environment, so the source isn't structured in a way 
that makes sense to humans - only the generated docs do. Fixing it 
might require a full restructuring, which I have been working on 
in my available time.

We need a new scheme specification dialect though - I have some ideas 
in that regard.

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

but that is an interesting thought ...  a bit out of my depth so 
far.

Just want to understand what is being done a little ...

I see this ...

system/intrinsic/parse-url: make object! [
	digit:       charset "0123456789"
	digits:      [1 5 digit]
	alpha-num:   charset [#"a" - #"z" #"A" - #"Z" #"0" - #"9"]
	scheme-char: insert copy alpha-num "+-."

Yes, there should be a module full of character sets, all read-only. 
If not read-only, then no.

I think that a modular rewrite of prebol is needed.

The module system was designed to allow such a thing.

how does that work?  Is it like a dictionary space in forth?

So, say we had a module containing all the charset definitions .. 
how would we include them to be accessible to us at run time?

prot-http.r is itself a reusable module.

Makes a object containing the standard http headers derived from 
the template object, also defined in a literal spec.

Something looks reversed, like spec/headers is using the specific 
headers as a template rather than the reverse. Don't know why yet.

So, it is modifying the original spec/headers by adding these new 
members to spec/headers ...  as a way of modifying the object in 
situ as it were

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

Actually, an object is created. Then it is converted to a string 
later.

Yeah .. seems a rather round about way of doing things.

There are a lot of interesting tricks you can do with objects that 
are much trickier with string-format headers. It's worth it.

make-http-request  says that content is [ any-string! none! ]
it then converts this to binary.

But if we want to send a binary file using PUT,  I think this must 
mean we need to convert that file to string first ... which seems 
wrong.

Which has only been patched a few times, not yet properly reworked.

Only if you aren't using chunked encoding. If you are, then setting 
Content-Length would be a bug.

In an event handler sort of way though - no assumptions that there 
are going to be files that are being served. You could build a new 
Cheyenne on it, but it won't compete with Cheyenne itself.

Just thinking that if you need to create signed headers eg. for Amazon 
requests, then these functions should be readily accessible rather 
than tucked inside a scheme somewhere

Just had another thought, if the headers already contain a content-length, 
then make-http-request should not set it again ...

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

All the stuff is defined in the http module - it's the only part 
if the internals that has been put in a module, so far.

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.

what I need is a function that traverses all the objects to find 
a function ....

running away from me??  Happens a lot :(

It's just a fling - I'll be back :)

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?

just a stream of consciousness like Marcel Proust

looks like 'open is a native ... no source given

HEAD / HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: www.rebol.com
User-Agent: REBOL

HTTP/1.1 200 OK
Date: Wed, 06 Jan 2010 07:28:08 GMT

Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 
mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 
OpenSSL/0.9.7a
Last-Modified: Fri, 01 Jan 2010 21:19:01 GMT
ETag: "3f44376-2667-4b3e66c5"
Accept-Ranges: bytes
Content-Type: text/html
Via: 1.1 bc1
Content-Length: 9831
Connection: close

must initiate the path var to get a response from the server:
read [ scheme: 'http path: host: "www.rebol.com" method: 'head]

** Access error: protocol error: "Server error: HTTP/1.1 400 Bad 
Request"

ok, to send stuff ... need to set a content: in the port spec.

[ content: "ehlo" scheme: 'http ..etc ]

This is a little inconsistent .. if I read www.rebol.com I get a 
binary returned

If I read http://www.compkarori.co.nz:8090 I get a string returned 
instead

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: IIRC the HTTP/1.0 was put in there as a quick fix because 
someone was complaining about bugs with HTTP/1.1... unless i'm confusing 
this with something else.