AltME groups: search

Is there a sticky thread feature being worked on for Altme?  Would 
br really good for new group explanations etc.

Also - is there consideration being given to introducing a threading 
model for messages in altme?

I've helped a couple of organizations evaluate messaging/groupware 
in the last couple of months.

In neither case did Altme make it to the shortlist.

Why? Same reason in both cases: zero tolerance for applications that 
lose data.


(If you are on dial-up or in any way have a slightly flakey connection, 
then this can happen: you type a message; you press enter; Altme 
notices the connection has gone bad; Altme automatically reconnects; 
Altme throws your message away: no warning, just thrown away).

I agree AltME could use a better backup plan for the worlds.

Thanks. i try my best, but Altme and IOS are minority products, so 
they've got to be better than good to get to a shortlist..
Altme has at least three ways of losing data.

And having to rename the world every time there is a server crash 
doesn't make this group a useful reference site.

I do think this is a golden opportunity area, care-free backups, 
and I have some solutions in the works

We're now on REBOL3 world.....Two crashes of REBOL.net, each need 
to create a new world and abandon the old one.
Not a great advert for the x-internet.
 What needs to happen to ensure we never need a REBOL4 world?

But I can live all my lfe on just one.

Shouldn't need rocket science just to recover from a cashed server 
:-)

Rebol3 is another case as there was a filesystem crash so the altme 
Rebol2 files were broken/lost !

If you have a FS crash, Exchange will go down too !!

there's only one solution, distributing the data. once your data 
is on a dozen nodes, the probability of ALL of them breaking up becomes 
quite small. :)

DideC has the right idea with the Rebol# Worlds.  There was nothing 
stopping us from using the old worlds.  I have seen a couple of times 
now how nice AltME's system is in restoring a user's system that 
has crashed, simple reinstall AltMe and all data is resent - trouble 
for a big world or a dial-up modem.

If AltME allowed you to choose a date to start the restore from, 
and allow the search feature to retrieve previously unretrieved messages 
- it would be a very nice system.

You mean if Carl had reinstalled a 6-week old backup of  the master 
REBOL2 world, it could have recync'ed itself  by finding later messages 
from the rest of us?

(I'm guessing six weeks since the last viable backup, as that was 
the date for one of the IOS restores).

distributed means that all nodes are equal. and with the right measures, 
a few nodes failing are not enough to cause a data loss.

Gabriele -- I think I have a more relaxed definition of distributed.

it should have been possible to recreate all the public stuff (as 
Brock says) by reclaiming more recent messags from some of the more 
trsuted clients.

Private messages would be a little harder -- but stil not impossible 
with the right recovery code.

**ALL** the data still existed somewhere. Altme failed to re-collect 
it.

The present set up seems totally fragile.  Dependant on a single, 
central server. That's so 20th Century :-)

its a bussines model

Another answer is use Raid Drives, and back up once in a while (daily).

how do I make a new group again ?

That's one layer of security Reichart.

But (given that failed for whatever reason -- human laziness in doing 
backups;  tsunami; all kit stolen in break-in; whatever), what's 
the *next* layer?

Secure systems need more than one layer -- as we've discovered with 
REBOL-->REBOL2-->REBOL3.

*All* the data still existed, distributed amond the many users. But 
we threw it away and started a new world.

It's not a a good case study to write up for prospective Altme users.

Reichart: see my comment at top of this group regarding a separate 
AltME usability issue.

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

Words, contexts and bind... : Ladislav, Gabriele and BrianH articles. 
I suppose I will find those articles on rebol.org? I will look them 
up and read them. And the presentations on Dialects... although what 
I understood about that was that one could make up dialects for a 
particular use. If so, not sure it would help in the ingeneering 
of a "better" teaching/learning approach for the language.

Did you notice http://en.wikibooks.org/wiki/REBOL_Programming? My 
Bindology article is: http://www.fm.tul.cz/~ladislav/rebol/contexts.html
(I guess it may earn a title of the most unreadable article written 
on the subject :-)

There is not variables, there are just values, and symbols associated 
with the values.
 I don't buy this for 100%, because:
>> a: b: 4
== 4
>> a
== 4
>> b
== 4
>> b: 3
== 3
>> a
== 4

If it would be than I would had to use COPY to keep the value 4 for 
'a.

I can't follow your logic:

>>a: b: 4

Both symbols a and b "point" to the value 4

>> b: 3
symbol b now "points" to the value 3.

Peter, Robert, you're both wrong, an a sense. The "pointer" metaphor 
is too lowlevel and probably misleading; but, Robert's example above 
has nothing to do with "copy" semantics.

Peter, yes, but you could read (but as Gab said, pointer semantics 
isn't correct anyway)
a: b: 4

'a pointing to 'b pointing to 4


and if I know change 'b to point ot something else, 'a still points 
to 'b.

Well, I would read it like:

'b pointing to 4

'a pinting to the return value of (b: 4), which would be a direct 
pointer to 4

So you get 2 parallel pointers to 4, not 2 chained pointers.

if you use the "value slot" concept everything should be clear. blocks 
are arrays of value slots; the data in a context is an array of value 
slots too.

a: b: 4 -> 4 is evaluated -> result 4 -> 4 is copied to slot of b 
in the context of b -> result 4 -> 4 is copied to the slot of a in 
the context of a -> result 4 -> console display 4

a points always to the same slot in its context, b points always 
to the same slot in its context - the content o these slot is changed 
by copying the value 4 in them

And when you bind a, you make it point to another context with another 
slot in it.

I'll probably find this answer in one of the articles I was pointed 
to, but the question comes up: Binding creates a slot in a given 
context in terms of memory allocation? If so, when is it released? 
Is there some kind of garbage collector in the Rebol runtime? These 
questions are probably not relevant since words are not pointers 
anyway, from what u guys are saying above.

Many thanks for the slot explanantions. May i seek a little further 
understanding by asking:


Is it the result of the evaluation of  4 that is copied to the relevant 
slots?

Does this hold true for all values, even series?

Values are released when there are no more references to them (and 
the GC decides it's time to do a recycle).

A word is basically a value that can be put in a value slot. This 
value includes a pointer to a symbol and a pointer to a context.


A symbol is like a string that is only stored once. The symbol that 
is pointed to by a word is the same symbol (same chunk of data) as 
that pointed to every other word that is made up of the same characters 
as the word (case-insensitively).


A context is like a map from symbols to value slots. When you create 
a context it has the specified set of symbols associated with it 
and each one of these symbols has an associated value slot. When 
you bind a word to a context, you change the context pointer of a 
word to point to the context. If you try to bind a word to a context 
that doesn't include the word's symbol, the bind fails silently and 
the word is unchanged. With the exception of system/words, all contexts 
are of fixed length once they are created (for now).


If the word's context pointer is not set, the word is considered 
unbound. If the corresponding value slot in the context the word 
is bound to is supposedly empty, the value slot really contains the 
unset! value, and the word is considered unset.


(Current implementation) Every word you create is added to the system/words 
context, which expands to include it if it isn't already there. Currently, 
system/words has an upper limit of 8000 words. This effectively means 
that the words your script uses must not exceed 8000 unique symbols, 
including those used by the runtime.

I've made a document here that kind of explains words and values. 
It doesn't explain the same word in different contexts though.
do http://www.lexicon.net/antonr/rebol/doc/rebol-values.r

Anton, my explanation above does cover the same word in different 
contexts. Contexts don't really contain words (except as values in 
the value slots). You can think of a context as a hash full of references 
to symbols and a block (of the same length) that contains the value 
slots corresponding to those symbols. A word is just a value that 
points to a context, and another word can point to another context, 
even if both words also point to the same symbol.

Peter, series values are really a pointer to the series data and 
an offset. When you assign a series value to a word, that pointer 
and offset are copied into the value slot that is currently associated 
with that word (until it is bound to another context). The actual 
series data pointed to is unchanged, though.

An integer value like 4 is actually contained in the value slot rather 
than pointed to by it, so when you insert a 4 in a block or assign 
one to a word, it is copied into the new value slot. Value types 
like this are called immediate values.

I think that it would be good to have visual drawing - sentences 
as "symbol that is pointed to by  a word" is kind of abstract for 
newbies. And what bothers newbies? When the series is unique and 
not shared. I know cases where I better use 'copy, because I am not 
really sure, what rebol will do ...

I agree about the pictures. Too bad AltME uses variable length fonts, 
or I could do ASCII art. It's a good thing that denismx already told 
us that he is familiar with C++, so I don't have to explain what 
I mean by a pointer or a string here.

Perhaps we need to make a REBOL-in-REBOL, if only for the sake of 
teaching.

I'm starting to sort the concepts out, cross-referencing several 
explanations. I will have to tone down the explanations for my students, 
obviously. But to do so, the teacher needs to have a very good grasp 
of the language so as not to make faulty reprensentations that would 
work small scale, but not later on when some students progress further 
in the language.

I find its hard to get people to "grasp" REBOL.  in the sense that 
they we all just see a different syntax twist at first.

The document "Rebol Essentials" starts with an explanation of value, 
word and block. Seems to be a good starting point. Haven't looked 
at how it introduces the syntax of system words later on. That is 
a crucial part. I want to find a subset of the 400 Rebol words that 
sould and can be learned first, giving the beginner a useful and 
powerful subset of instructions to start programming significant 
small apps.

Actually, since Von Neuman, code is treated as data. You load it 
into memory and process is as a special kind of data.

... so it's a long time ago that this concept is around.

I remember writing a program in Pascal that modified itself either 
in memory or rewriting itself on disk with variations.

In fact, in any programming language, code is just data that is executable. 
Some languages allow that the code-data be processed as any other 
date. Rebol is not the only one. And I do not believe that this is 
it's main characteristic. The fundamental characteristic of Rebol 
is that it is a language for exchanging data over networks, be it 
information (data) or programs (code) so that is can be used and 
executed (if code is passed) on any computer connected to the network.

That is a forte of Rebol, it avoids data prickling or serialization 
which it is require in other languages.

I'm sure there is a lot of that. But then again, 256K for the core 
seems very small.

I will look into it Jaime. Tks. Although I am doubtfull my solution 
to devising a "better" way to teach Rebol is in getting a better 
mastery of functional programming, I may be wrong. So I'll follow 
your lead.

Functional programming demystifies a lot imho.

The question I am asking myself now, in my exploration of Rebol, 
is: What is the smallest subset of predefined Rebol words that will 
empower a student to build significant small applications.

If this set is small enough (400 words is way to large), say 15 to 
30 words, then this would be a good starting point for teaching purposes 
(18-20 year olds with no previous experience in programming).

That leads me to wonder if I could produce a histogram of all the 
rebol words in my codebase. But "rebol words" is kind of hard to 
define, so it would not give a precise result. I think individual 
frequency analysis of some actual rebol apps would lead to a nice 
collection of functions.

Then a genus tree, since many words are just subtle variations.

Rather than choosing a subset of words to learn first, choose the 
task instead, the required subset will then be fairly obvious.

Also it's clear to me that the importance of a function is not always 
related strongly to it's frequency of use. Take VIEW for example, 
not used that much, compared to other functions, but without it you 
cannot open a window ! (You can, actually, in other ways, but VIEW 
does a lot of work. Mmm... another way to assess importance of a 
function, the length of its source ?)

To create the above list, I just read my source script file and wrote 
each word as I came across it, manually, into a new script file. 
Then I ran the following code:

Anyway, I hope the above list can help to get a rough idea of which 
functions should be studied first.

- maybe examine multiple scripts, and count in how many a word is? 
Then 'view would count high, even if used once. Words occuring in 
every script are important.

- "choose the task instead" - good idea. Make a list of tasks and 
list required   words. could be in that 15-30-range

Also it's clear to me that the importance of a function is not always 
related strongly to it's frequency of use.

This is why you need the Genus.


View would be a root, while many string commands would be all gathered 
at the end of some branch.  This becomes really easy to see when 
you present the data that way.

then its a good test for the associative DB I am about to start working 
on.  :-)

I was looking for a good and simple data set to organise.

(I have been REBOLing full time for a while and yess many things 
are moving ahead :-)

You could make trees where the grouping is by the words that follow 
or precede a word. Expressions, basically :-)

we can have each atom of information relate to any other atom based 
on rules we define... once the dataset is parsed, then you end up 
with a complex modeling of all related data which you can query and 
search trough quite quickly.

I'll give a shot at sorting out all of rebol.org once I get basic 
capabilities going and report back here, when its done.

I think just the list of natives would be a good start then use the 
source for the mezzanine functions as excersize of what can be done.

Although the "choose a task first then learn what needs to be used 
to code it" approach is fine in many circomstances, in a 45 hours 
course, the student ends up knowing how to code a few tasks (hopefully 
more than one, but not necessarily), but often has a very hard time 
transferring this knowledge to other tasks.


So I think a better "generalist" approach would be to categorize 
generic tasks, like "file manip"', "math", "iterations", "series", 
"network sharing of data", ... and identifying just a few native 
words category that are enough to solve all or most problems given 
in those categories.

Example problems I would give my students to solve would look like 
(to be adjusted according to the native word set retained):


Using iteration, draw a 19 line isoceles triangle (concepts of looping 
not obvious for beginners, but essential to grasp early)


Find all prime numbers lower than a given one, using previously found 
primes in the process to speed up the search.


Given a list of adresses, get the files and identify which ones have 
a given information on them (elementary parsing)


... Things like that. Diversified enough to give a good feel of what 
programming can solve while gaining basic skills (data stores, interation, 
maybe recursivity, various control structures - not necessarily all 
of them, operators, native functions and user defined functions, 
input and output, ...)

The pdf manual "Rebol Essentials" comes close to that. It seems to 
be a good starting point.

Another idea someone proposed in this thread which is very interesting 
if it is possible, is tracing a hierarchy of all the native Rebol 
word. If such a structure really undelies the whole or part of the 
400 word list, then this would be a powerful conceptual tool to aid 
in building learning "environments" for the language.

I think it depends a lot on your audience. You said they had no previous 
experience in programming, but are they computer science students 
or humanities, or engineering?


Their are many things to teach at once; computer science concepts, 
Rebol concepts, how to program, etc. I guess you would also have 
to settle on a single programming paradigm to start with. If your 
audience are hunamities students then the not so simple concepts 
such a "programming language" and "program" (leading to "syntax", 
"semantic", "type") are very important to understand properly first. 
Then you have "expression", "evaluation", "subprogram"" etc. (leading 
to "values", "binding", "function"). I think all this can be done 
through meaningfull practical example built russian doll style.

There are about 270 in View but the op! are duplicates of some natives, 
and some natives are for efficiency and can be rewritten using the 
other native words. I guess I like looking at Rebol as a Forth language 
with very good and standard I/O support.

Jean-François: one of the courses I teach is an introduction to programming 
to science students. Some of which will follow two more courses in 
programming, in the same language. Over the years, I've done this 
in Fortran, Pascal and now C++. At one time the first two courses 
were given in Python and the last (which I was giving), in C++. We 
decided that it was better to give all 3 in the same language. I 
didn't think Python was a good choice.

I'm now giving the first course (and maybe all 3). I'm exploring 
the possibility of opting at some time for Rebol, if I can break 
down the language into subsets that are "easily" learned and that 
offer useful tools for some large category of problems. I did'nt 
find any tutorial that seems to be quite there yet. 

Of course, the language is not the only thing taught. Basic programming 
and computer science concepts are also taught. But these can be taught 
independently from the choice of the language, for a large part. 

Rebol is my preoccupation. Some languages need a very lot of reading/learning 
before you can start to use it for solving problems with them. Maybe 
this is the case for Rebol. But I'm not sure yet. My hypothesis is 
that nearly everyone has learned Rebol by reading the Core manual 
and looking at examples in tutorials. It's ok to do it this way if 
one chooses so. But the teacher is expected to devise smoother paths 
for the learning process.

If I can engineer such a learning path, even if we never switch to 
Rebol for our classes, I'm sure that it would help enlarge the Rebol 
community. So I'm getting more interested in this project as I'm 
going along. It is not an obvious endeavor.

Denis : You should maybe contact Gerard Cote on the mailing list. 
I believe he has been using Rebol in teaching introductory programming 
for a while now. He might have interesting pointers.


Also I would be curious to know if you have ever considered using 
Scheme for your courses. There are great ressources such as PLT Scheme 
and their book "How to design Programs" or "Simply Scheme" by Harvey 
and Wright. I think the content could be adapted to a curiculum based 
on Rebol

A few ideas were collected here as well 3 years ago http://www.compkarori.com/vanilla/display/Rebol+School

tks for the link Graham. And there is a mention of Gerard Cote in 
there too, Jean-François.

Actually, I'm not trying to figure out how to introduce programming 
concepts, or computer science in general. I already have a lot of 
stuff on that since I have been teaching this for 20 years now. And 
I'm not looking tor a "better" language to teach, even though I have 
given a look to Scheme.

What I want to develop is a "better" approach to learning Rebol, 
for non-programmers mostly. I'm really focusing on Rebol, and not 
what should be learned before, nor what could be a better option.

The "Rebol Essentials" is a good start. But I think I can break the 
approach down to still simpler steps. The difficulty I face is not 
having the broad, overall picture for Rebol. I am very conscious 
this limits my ability to make the best choices for the moment.

Here is what I figure would be a good starting point, at the present 
level of my knowledge:

First concepts: values, words (at a basic level), blocks (later on 
: functions)

Then reading data somewhere and some simple parsing techniques: find 
a string, extract from one point to a second and saving the data.

I have the feeling that would be a very good starting point. I'm 
a little hazy on what is offered for parsing in Rebol at the moment. 
I'll look into that next. I think that once you have read a file 
into memory, it is in block form and you can use natives like "first", 
"next", "find" and so on on it. If so, then I would be going that 
way for sure.

Strings and blocks are both series, so first, next find etc work 
on both, but when you load you get a block and the units are values. 
When you read, you have a string and the units are characters.

When you load, the file has to be LOADable by rebol, which means 
everything in it must be parseable into rebol values.

When you read, the file can be absolutely anything. I usually have 
to read web pages and parse a string, for instance.

How about that old way of starting with a text-adventure? Write a 
framework and let the learner add some special item?

for example, in parsing a sentence, foreach could make you very easily 
traverse the whole string like so:
foreach letter sentence [print letter]

also remember that find, does not copy the series, it returns the 
serie at a different index.

I've talked to one of my colleagues about Rebol and he's checked 
into it. He's interested also. So it is becoming more probable we 
will switch to Rebol to introduce basic programming concepts as well 
as to empower them with a programming tool to build very small applications 
to complement the scientific software at their disposal.

My colleagues suggest that we use the View GUI. He feels that it 
is simple enough to code a graphic interface with this. I admit I 
have not looked into View much. My preconception is that adding the 
graphical layer complicates things too much (like Windows/C++). Maybe 
I'm wrong as Rebol is concerned?

RebGUI, something new to me. In fact, we probabably just need an 
interface to enter data and start some process and show the results. 
Maybe draw a graph with the results - that would be great. Will look 
into it. Tks.

You may want to take a look at Matt  Licholai's quick plot dialect 
for your students to use to plot results. The details are at http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlQBZK

Scroll down the thread to find the location of the source.


There is an updated version of his ez-plot example in the script 
library at http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ez-plot.r