AltME groups: search

Jaime - ok, I correct myself - to what you said by "rebol sending 
me to loopholes" and calling it a productivity issue, from that point 
you are probably more than right ...

in fact, I am one of two "right hands" (it is a saying in czech language) 
for our CTO. And the reason is, that I provide him with opinions 
not tied to any products of my liking. Our Delhi group, would do 
everything in Delphi, our Lotus Notes group, would do everything 
in Lotus Notes, the same goes for VB and SAP folks, and of course, 
jokingly, I would do everything in Rebol. But - things need some 
level of understanding of current/historical situation in the company.

maybe a 'bridge' for REBOL-Ruby.


allowing Ruby to call or access REBOL 'objects' directly and vice 
versa.

Now we know Flash and Ruby try to go outside the browser, so I wonder 
how usefull Rails will be in such a territory. I still think, that 
IOS like "platform" for app delivery, is still unmatched. Dunno what 
Altissimo is supposed to mean, but having rebol services or uniserve/beer 
whatever based framework for app distribution, like it was planned 
with Morpheus or even Altme, would be a win ....

Volker compilation of rebol is due to context free grammars. If you 
take this restriction you could probably have a bootstrap of rebol. 
But you can not compile just any rebol program. So this is a problem.

We are talking about bootstrapping. There is no need to compile every 
program. Its only needed to have a subset to build the interpreter. 
And that one must be able to generate machine-code.

Thats what forth does with meta-compilers and squeak does with slang. 
Ugly, so a pretty good motive to do most in meazzines :)

http://www.easy2remember.name/media/51/Spore-game-video.html<--- 
for gamers, this looks mightily impressive. An evolution game with 
a 100% dynamic world.

actually not just a world but an entire universe

For inspiration, Wright looked to the 

demo scene," a group of (mostly European) coders who specialized 
in doing a whole lot with a little bit of code. Their procedural 
programming methods were able to, for example, fit an entire 3D game 
in 64K, using mathematics to generate textures and music, etc. "I 
just found this incredibly exciting," Wright confesses, describing 
the kinds of work that he saw come out of the demo scene."


So here's what he did: he recruited an elite strike team of coders 
(who, if you were to believe his slideshow, dressed like ninjas) 
and put them in a 

hidden facility" to experiment with new ways of giving the user powerful 
tools and generating tons of dynamic content without armies of content 
creators. Best of all, he fired up a demo and showed his audience 
the results... "

this is almost a REBOL like way to create games :-)

Volker you are right. But I was thinking on Rebol bootstrapping itself 
and offering incremental compilation too. Just like Dylan or CL. 
Here is an excerpt from wikipedia. "Common Lisp has been designed 
to be implemented by incremental compilers. Standard declarations 
to optimize compilation (such as function inlining) are proposed 
in the language specification. Most Common Lisp implementations compile 
functions to native machine code. Others compile to bytecode, which 
reduces speed but eases binary-code portability. The misconception 
that Lisp is a purely-interpreted language is most likely due to 
the fact that Common Lisp environments provide an interactive prompt 
and that functions are compiled one-by-one, in an incremental way."

I thought about that a bit. IMHO it is not that impossible. But may 
need new core-features.
The idea is that argument-lists rarely change.

Rebol lets us inspect the last values a function used. So from the 
source i cant be sure 'append is really that global 'append. But 
after the function has run, i can look what the last append was, 
and see that it got two arguments. And then i can "insert parens" 
and process it like lisp.

Needs a profile-run, or would work really well with a jit. And the 
interpreter needs to stay in the background for very hart blocks.

Jaime - from my limited understanding - you would like to see rebol 
kind of grammar to be defined and used as a wrapper running upon 
another environment?

Henrik - imo with more media friendly features and rebol overal extensibility 
(as was promissed earlier for rebol), we could see Rebol being a 
tool for some nice demos ....

How about this, a single piece of code to handle any web form.. just 
add a new field to the html and you're all set... don't need to alter 
the DB or the serverside processing.

Terry, Rails already do that. It is called Migrations, a kind of 
versioned schema, and yes you just add a field and everything works.

Volker, compiling Rebol is not impossible, it is just very difficult 
exponentially difficult because " the order evaluation" for the a 
function call can change at any time. Depending on how the words 
in the body are defined. This is the CFG feature and problem.

Now you could use fix the body of a function maybe not allowing for 
function! values to change dynamically, but this will limit the language. 
I think the best approach for getting closer to the metal is REBCode. 
But I am not sure you can hav a Metacircular Rebol.

I dont think it limitsthe language. I never used that  as a feature. 
Well maybe setting 'print to none, but i can live with "print: func[value][]"

I can only imagine cases where that is a bug.

With a bit code around?

I can simulate lisp APPLY with a dialect. APPLY require variable 
number of args>

In rebol i put those args in a block.

Lisp does that too in a way, because it puts things always in parens.

Ah. But the point is not that you code in Rebol, the point is that 
if you implement a DIALECT that has different semantics and shares 
the value types! of rebol then you can compile such dialect.

And in rebol we have none when looking at sourcecode.

But actually, when a function runs, its "compilation-units" are always 
the same. Meanswhen a function is run, the lisp-parens can be inserted 
by reflection. (except of strange hacks)

Not to expensive to get a lot more speed. (interpreter would be always 
available too.)

If the parens are different thenext time, there is usually a bug.

So you will make executing slower, because now the interpreter needs 
to keep track of the whole tree to see which values changed and which 
are a violation of contract.

Or a compilable-function! , which would be a little bit slower until 
the jit kicks in.

BTW, compilabe- function shares some of the traits of closure. closure 
are a separte function in rebol because they are expensive. In Orca 
we made all funcs to behave like closures, but we decided to factor 
it out like in Rebol to keep the speed gains.

varargs are not the reason for not having a compilable language. 
Both Lisp and C support varargs, and both are compilable languages. 
The culprit is CFG.

From the poing of view of the compiler developer he can't make any 
assumption on how to compila a rebol expression, while in C and Lisp 
he knows that the forms are fixed.

Yes. In rebol too, when a function has run.

Jaime, just had a look at 'migrations' and it's not the same at all.. 
 here's the pseudo code just to change the db with rails..

    * Step 1: Create a migration with script/generate migration WhatImChanging
    * Step 2: Modify your generated migration file in db/migrate
    * Step 3: Run rake migrate

    * Step 4: Revel in the fact that your database is converted to the 
    newest schema!


With Framewerks you never alter the DB.. it's a black box where data 
goes in and out.

with Framewerks, you could copy a form from any web page, change 
the 'action' of the submit button.. and it will work perfectly.  
Rails cannot do that.

Volker, You can not forbid it. That is just a simple function. It 
will be the same than this test: does [append s v]. The body of test 
is not compilable because the block [append s v] execution depends 
on the environment.

Volker here is another example,



anyF: does [f g h
]

f: func[x][print "f third" 2 * x]

g: func[y][print "g second" y + 1
]
h: func[][print "h first" 1]


anyF ;; == f(g(h()))

;; 

now lets change 


g: does [print "g second" 5

]

anyF ;; == produces something like f(g()) h()


  anyF is compilable only if the order of evalutation 
doesn't change 
  at runtime. 

Rebol permits for the order of evalution to be determined 
  
by the context in which anyF is run, and the interpreter is 
smart 
  enough to GC the unconsumed values.


   This is a feature of Rebol because with the same expression 
you 
   can have two very different meanings, the disambiguation 
of the 
   grammar is provided by the context (or environment). 
This allow 
   Rebol to support easy Dialecting. That is each 
DSL may need specific 
   evaluation orders, aka semantics, 
while they share the same code 
   expression. In this case [f g h].



In the example above two different branches of the AST three 
were 
followed. But by just looking at [f g h] is impossible
to know which 
branch will be taken. 


  Other compilable languages enforce the order of evaluation by 
using 
  specific syntax forms to determine what is an expression. 
 Lisp 
  uses  parens, while  C semicolons and others markers.

 


So in order to make anyF compilable we need to  enforce the 
order 
of evaluation.  One possibilty  is to use Rebol parens.



anyF: does [(f) (g) (h)] ] *** see note


  The cost is evaluation speed for the interpreter, and now 
we are 
  back at using parens at each step. Which is what 
lisp uses. Should 
  we go back to 1967?


  The alternative of JIT is possible, but  it requires hinting and 
  
a sofisticated runtime environment. The translation of Rebol 
code 
  to some an  internal VM like rebcode  is simpler and maybe 
sufficient, 
  otherwise extending rebol via DLLs  is the way to 
get closer to 
  the metal. However, I don't see an easy path 
to having a Metacircular 
  Rebol. If you do, I hope you write
 a Rebol compiler and share it 
  with us ;-)

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

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

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

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.

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.

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

There is a live-CD!!

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.

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 it's not running a 386!

Looks like they have a Pet emulator.

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

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.

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.

Depends on how they guarantee the order of execution. For examplie 
in Mozart/Oz you can have a concurrency that ensures that the sequence 
of computation is maintained, just like if was sequential even though 
is executed sequentially.

A general-purpose concurrent language like Erlang or Ada has to include 
syntax for mundane operations such as arithmetic expressions, a coordination 
language need not specify anything more than coordination.

I doubt a coordination language can do without general-purpose stuff. 
Messages must be queued, counted, somewhat verified etc.

Gabriel. I agree with that statement. So vanilla threads are a problem, 
and adding concurrency to language need to be done with care. How 
is R3 going to handle tasking?

are you on-schedule for alpha at the end of May? In Unicode group 
Jaime gave some answer, which sounds a bit unsatisfactory, like it 
would not be decided yet, which way to go in that respect ...

From my early recollections, Rebol was designed for communications 
..as a scripting language.

hehe, they want internet to become OS .... and PC OSes to become 
just - commodities - non-important in its own, just a layer for internet 
networked apps :-)

this is pretty bad ... it opens up a lot of stupid cases... http://www.theregister.co.uk/2006/04/21/moderator_liable_for_comments/

Regarding multitasking and REBOL, how far is it possible to go using 
communication between tasks over the TCP protocol? I've implemented 
multi-user locking this way with a relational database in REBOL, 
and it works quite well. I haven't done stress-test, so I have no 
real measurement, how effective it is, and what the performance is 
compared to other inter-task communication methods. I'm working on 
an OpenGL implementation, where OpenGL commands are sent from a REBOL 
task to an OpenGL server task (written in C), which will execute 
the OpenGL commands, so I'm about to get more experience in this. 
Both tasks will run on the same computer, but can easily be on different 
computers, of course.


Anyone with more experience in task communication using TCP? Where 
is the limit?

hmm, I am not sure I like it ... you open a port and firewall jumps 
in

I'm developing a byte-code style for OpenGL commands, so little communication 
is needed. Only 1 byte for the command (gl, glu and glut commands 
are fewer than 256), and 4 bytes for most parameters. So many commands 
are fewer than 10 bytes of communication. It may not be fast enough 
for games, but I hope, it's fast enough to make tools and fast OpenGL 
prototyping (trying out ideas).

hum Geomol, is it possible to start a new group for this?  I'd like 
to support your endeavor with testing and I think this can become 
a big thread!

Maxim, in a few days, I hope. I'll speak up, when I have something 
concrete to show.

Maybe make benchmarks first. Blast a realistic amount of data from 
rebol to rebol. Maybe by beer or uniserve, something fast.

Pekr, good hint. But i guess to calls to send a byte are two packets 
too. And then there was some flag too IIRC. Somebody remember?

Jaime, writing to files is something for the os to handle, not the 
language. what happens if you write from rebol on a file you're writing 
from another app?

Maybe Jaime means: If you do everything that way, including the os? 
But, there would be no  such thing as a file, there would be a file-server, 
eg a third task. Which gets request and can sort them out.

what a crap - I stop buying Creative stuff. If some company can't 
innovate, they should shut-up and leave the scene. How can anyone 
with good brain condition patent such a thing as sorting based upon 
ID3 tag content?

One can even sue about using a trashcan -icon for a trashcan IIRC..

But what you wrote is similar too
either 1 = random 2[ write%file "Hello"][write %file "world"]

What a task does depends upon what a task gets. I imagine a task 
in erlang as a little engine, which gets things of various kinds, 
wires them together when it has one of each kind and passes them 
further. And that "further" can not be deterministic with real hardware. 
Think of an out-of-order-cpu, a little delay in a memory-fetch and 
the command is processed by another pipeline. And that is without 
routing around crashed things. I prefer to have a full featured language 
to calculate the new route, not something restricted.

Jaime, I just don't think rebol should manage files. but, you can 
do coordination, just using message ports. and you can write a dialect 
over that.

if a thread has to wait for another, then you're just wasting time 
and creating problems with threads.

locking is painful, a server like you propose is much better.

i need to read that paper jaime posted; anyway if it's just linda 
style, it's trivial to do with a server handling the tuple space.

volker: basically a block of blocks :)

you cannot address the block; you can only get the blocks matching 
a pattern, and publish other blocks.

having a defined set of operations, you end up with a system that 
does not have the usual problems of parallel processing.

Maybe determinism means here: Some things must happen in order, for 
example writing to a log? So that different runs produce the same 
result?

if you want to log events a and b, and they can happen with watever 
order, you want to log them in whatever order. if they can only happen 
in a given order, there is no parallelism.

But a parralel processed image looks the same all the time, or the 
processing of a big matrix. Still deterministic. Whatever happens 
inside the box.

Volker, I was ilustrating that just using the function TASK is not 
enough. You need a way to prune non-determinism. The example I posted 
ilustrate the problem. Your example has the same problem than mine, 
because TASK it doesn't introduce an order of execution. The fact 
that your example is coded sequentially doesn't mean that the computation 
will be carried in that order and produce the same result always. 
Your example only introduces notatation to pass messages between 
tasks.

Your example looked like locking to me, i saw two threads accessing 
a shared resource. Semms i missed the point.

So i think a coordination language needs more features, so its similar 
to a general purpose language. While you said above " a coordination 
language need not specify anything more than coordination."

Coordination can help prune non-determinism, coordination is different 
than communication between threads, lazy evaluation and continuations 
couuld help here, using a declarative approach to the whole computation 
can help get rid off non-determinism. The basic ideas are found in 
the CTM book.

Jaime, not yet, but most likely each task will have a message port.

Volker, Do you really mean this "Complete determinism makes no sense 
with parallel IMHO", the idea of paralellism is to  be able to perform 
any computation  done by a sequential machine faster, a random paralell 
machine may have some uses, but none of the mainstraem ;-)

that sounds a little ineffective?

I am thinking the data would be in a layer above the graphic form. 
Click in the right spots, fill in the right data, print out the completed 
form, then save the data with the form  for later use. Something 
real simpe anyone can use.

openoffice 2.0 has a free XForms implementation. it can save PDF's 
like this so you can edit them like a real form. I haven't worked 
with it deeply, but I think you can save data from them in a database.

edit them like a real form
 => edit them like a real form in adobe reader

An image can be used as a backdrop to a layout.  Stick some fields 
on top and you're done.

No, i want my program to have s much determinism as needed. I call 
"perfect determinism" when i know "this stuff is done on cpu3, then 
the other thing a bit later on cpu4". That is perfectly repeatable. 
But that is not what i need. "this stuff is done on the next free 
cpu" is enough. But to do that, i need a language which can determine 
what this next free cpu is. And for that i need a general purpose 
language (counting cpus, acountig used time, priorities etc). While 
you said general purpose is not needed for a coordination language. 
But maybe i miss simething, maybe coordination means something different?

I never said that you need or not a general purpose language. As 
matter of fact, I don't think being general purpose has anything 
to do with concurrency. What I understand is than any new features 
that add concurrency  to  a language should do so in a manner that 
avoid non-deterministic results. Some languages have already accomplished 
 this goal, usually avoiding  threads. Threads operate more at  the 
OS level than the language one. So I hope R3 bring us good concurrency 
features, that ensure that our programs are deterministic, otherwise 
we could be shipping programs that at first glancelook correct and 
 will work, but could  fail later in production as the paper points 
out.