World: r3wp

it would make sense if it was. it would make View a little smaller, 
wouldn't it?

not sure .... dunno how AGG is integrated, maybe AGG compositing 
is not used at all? Difficult to say ... but I expect radical redesign 
of View - at least we can be sure there is new event system placed 
inside, hopefully libevent .... so I expect even some compositing 
system changes and also face concept redesign ....

It would be nice if Carl would blog a bit about new View internals 
....

I hope there will be direct access to the buffer rather than going 
through SHOW. this would speed up operations immensly.

If Cyphre is in charge, I expect him to push Carl for more media 
features :-)

well, if he gets them through, it screams AmigaDE replacement, which 
can be a good thing right now

of course .... noone except few companies use AmigaDE ... AmigaDE 
(let's talk intent), has some powerfull media capabilities ...

.... but dunno, if today, being self-hosted, means an advantage - 
there is nowadays lot's of even small OSes Rebol can run on-top of. 
I prefer it being that way ....

Volker, parentese fails in this case. The 
body of f didn't change 
as matter of fac t
it runs and produces as result 6. But the
parentese 
func fail to produce an expression 
for it. 



ctx-tuneme2: context [
    
	append: func [arg1] [arg1] 
    
	add: func[][none]
   
	 f: func [] [append 7 append add 5 6]

]



ctx-tuneme2/f ";run it once" 

probe parentese second get in ctx-tuneme2 'f


  ** Script Error: get expected word argument of type: any-word object 
  none

** Where: parentese-once

** Near: arglist: first get first code

So ctx-tuneme and ctx-tuneme2 has the exact same body for F..  However 
they perform different evaluations, one compiles another not. This 
is the problem. Now you can keep tuning parentese, but I bet it is 
always possible to find a way to break it.  The larger the body of 
F, the more posibilities for evaluation exists.

No, that is a problem with an intentionally limited quick POC.
But i had to blink twice. :)

It currently expectes that all expressions start with a word. Now 
tuneme2 is  [(append 7) (append add) 5 6].
And it fails. As it should with this limited subset. 
Found it after adding a probe,
      arglist: first get probe first code 
which gave 5 on last run.

I do think  i can match rebol completely (means a rebol with small 
additions/restrictions).

Its as tricky as to compile, say 'c. There are lots of exceptions, 
but in the end it is possible.

Handling standalone values is one of the first thoughts of course. 
then there are operators and refinements. Then deciding if something 
is rebol-code or not (that needs an extension. 'do must flag it processed 
the block. So that parse-rules etc can be detected as data and the 
parens inside are detected as "run by do". Surely more small things, 
but should be doable.

Btw makes nice coverage-tests then)

http://www.cs.vu.nl/~ast/reliable-os/

volker, nice read. very easy to digest.

Yes, Tanenbaum can write:)

Fission: https://addons.mozilla.org/firefox/1951/

Puts the progression-bar below the url (at the top, where one looks). 
Interesting feedback.

below means bar is now the url-background.

Volker, I never say that compiling rebol is not possible, I said 
that is exponentially difficult.

So in practice compiling rebol is a pain in the arse.

Much more than other languages. Because there is no easy way to make 
assumptions. The moment you make an assumption you leave space for 
a compilation hole.

Now if the Rebol becomes a function first language like lisp you 
can get a bit further but still you will need some other markers.

No, exactly not. Without that "run first" yes. With it not. Or i 
miss something very stupid.

MINIX3 sounds interesting, BTW.

I'm almost tempted to try it out  .... but I'd need time for that... 
 ;-)

Thought that too. Small kernel, has X, would be a recompile.

There is a live-CD!!

it could be the basis for rebol/OS standalone appliance.

-> recompile to run rebol.

Interesting nameclash :) http://www.cs.vu.nl/orca/. Found it by 
looking for Amoeba. "We cooperate intensively with the  Globe  group 
of  Andrew Tanenbaum ([ast-:-cs-:-vu-:-nl])."

(one of Tanenbaums distributed osses).

I like the bontago here. http://www.digipen.edu/main/Award_Winning_Games

To our physics: Is it possible to build a little physics-engine for 
such things, and how about collision-detection? The 3d from the contest 
could be sufficient for a small version of this.

is http://www.minix3.orgdead?

Slashdotted? I got that link there. But when i looked it was still 
running.

I love the system requirements: 16 MB RAM and a 386.

that's pretty tough .. I don't think I'd be able to find a 386 these 
days

there's still a lot of embedded matchbox-sized hardware that use 
those

I hope www.minix3.org isn't running Minix, because that would be 
bad marketing

I hope it's not running a 386!

it's up again now

http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl&
<--- interesting link from that site.

Looks like they have a Pet emulator.

I had a gold fish once. Died after a week.

oh... THAT Pet.

a port of REBOL would double the amount of software available

the system can build itself, including the kernel, common drivers, 
and all servers (112 compilations and 11 links) in less than 6 seconds 
on a 2.2-GHz Athlon processor.
   Yeah! I'm starting to get interested.

The Problem with Threads http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html

hmm, I read some doc when I was looking into liboop and libevent 
etc., somewhere on those sites, but each of groups tasks vs threads 
had some valid points ....

I have heard RT will go with threads, because those are optimised 
on multi-cpu environments?

Pekr, the article is not so much about which concurrency model is 
good or bad. The paper contentionis  that the emphasis on developing 
general-purpose languages that support concurrency is misplaced. 
Lee believes that a better approach is to develop what he calls "coordination 
languages", which focus on arranging sequential components written 
in conventional languages into some concurrent configuration (I suppose 
that piping in a Unix shell could be considered a limited coordination 
language). For concurrent programming to become mainstream, we must 
discard threads as a programming model. Nondeterminism should be 
judiciously and carefully introduced where needed, and it should 
be explicit in programs.