AltME groups: search

Example:
Let's say, our date is 6 digits YYMMDD.
>> date: "230812"
We deside, it's the year 2023:
>> insert date "20"
Now dashes are inserted to form a date understandable by REBOL:
>> insert skip date 6 "-"
>> insert skip date 4 "-"
Date now looks like this:
>> date
== "2023-08-12"
And we can control, it's a valid date with:
>> to-date date
== 12-Aug-2023

If it's not a valid date, like if the original had other characters 
than digits, we'll get an error. Errors can be caught with:
>> error? try [to-date "foobar"]
== true

Hope it helps.

How about this ?
f: func [/aref /bref /cref /local refs symbs][
	refs: copy [aref bref cref]
	symbs: copy []

 forall refs [if get refs/1 [append symbs to-char #"a" - 1 + index? 
 refs]] ; convert to #"a" #"b" #"c" ...
	switch rejoin symbs [
		"abc" [print "All of them"]
		"ac" [print "Just A and C"]
		"b" [print "Just B"]
	]
]

Using an issue (or could be a string) instead of a block:

f: func [/aref /bref /cref /local refs symbs][
	refs: copy [aref bref cref]
	symbs: copy #

 forall refs [if get refs/1 [append symbs to-char #"a" - 1 + index? 
 refs]] ; convert to #"a" #"b" #"c" ...
	switch symbs [
		#abc [print "All of them"]
		#ac [print "Just A and C"]
		#b [print "Just B"]
	]
]

Well, I have no such requirements, no commercialisation of anything 
I write (it's just for my own and my family's use) so there's no 
way I can justify coughing up much money; just looking for the bare 
minimum I can get away with

We will get things like threading, most of the stuff is going to 
be open-sourced, we will be able to extend rebol by own components, 
modules will be available too, and many other changes.

R3 should be released to public July 15. Of course there will be 
some bugs to sort out, some things to finish, etc. In the meantime, 
you can study some docs - most things will stay valid. It is not 
change in philosophy, whole architecture will just get much stronger.

active developers? Here on AltME plus ML ... we are small community, 
but you mostly get your response/help in minutes/hours ....

also - in Rebol/View, start desktop and go to rebol.com site to see 
some tools, demos. Right clicking them you can get to its source 
code ...

and of course, there is one commercial system, which was nominated 
for Webby Awards in 2002(?), along with Google - REBOL IOS.Pity it 
is not supported much, but you still can buy it. With R3, altME, 
View and IOS concepts will merge, and what we will get will be kind 
of virtual OS ;-)

I believe in Carl's vision "REBOL is perfect for lightweight distributed 
applications". Users need light-weight responsive gui clients that 
can work both online and offline. The evolution of the Web is moving 
(slowly) in this direction, with AJAX/Flash/JavaFX as examples of 
a more responsive and rich gui clients, BUT it's too complex and 
unreliable. The industry is adding kludge upon kludge to "fix" the 
problems resulting in further complexity and code bloat, but what 
is needed is a clean approach that captures the essence of what made 
the web a phenomal success in the first place - any body could set 
up/develop a web site and they did. Enterprise data centers need 
scalable, reliable, manageable (server) applications that run 24x7 
on commodity hardware ata reasonable price. The user PC's should 
require zero management for the applications, which is the primary 
(only?) attraction of the web ui. Question if the application is 
simple to manage and delivers the functionality the user wants, why 
do they need a fat complex os? As an example my kids get online to 
play games, research homework, etc. and they hate it (so do I) when 
the PC/OS gets in the way. Also, that PC/OS is a major source of 
 trouble with viruses and lack of (simple) control to what my kids 
can access.

Hi RayA and Welcome. 


I am a new to AltMe too. I think you are right about the evolution 
of the web. The Desktop OS has become an application in itself (IMHO). 
It's the focus of so much angst, controversy and complication. (Nailing 
my personal colours to post here: I declare myself a BSD UNIX type. 
I can still install the latest version in much less than 100MB of 
HD space and 32MB ram and 100Mhz CPU. In fact I run it on an old 
Toshiba laptop with that spec and get real work done)


I think, in principle, DOS was my idea of a good OS (I know, I know...) 
It was small, fast a stable. Yes - lockups were common when pushed, 
but I found it was the application that crashed rather than DOS itself. 
Ok. back in the world of the 21st Century, an OS need many many times 
the resources of DOS just to get itself booted. But basically, all 
I want from the OS is to let the applications get on with the job 
in hand.


What attracts me to Rebol is that it is clean and lightweight. Designed 
by a man who I respect as a Computer Scientist. (And, of course, 
the Rebol community, which collectively one might say is a "killer 
app" too). It's very productive and I'm building internal information 
systems with it.  I've got a few ideas to build my own apps outside 
of work, that is an exciting prospect for the future. 


I keep trying other frameworks/languges and over the last six years 
or so I've lost the "Rebol way" and strayed from the one true path! 
I do find myself coming back to Rebol as I run into more library 
conflict/dependency/blot features of some of the other languages 
I used. Maybe I'm getting impatient of complicated technology now 
I'm older. I just get tired of having to search the internet for 
the latest whatever.so.1 lib, or what have you. I'm making a general 
point here BTW - I know there are some very good language implimentations 
out there.


I don't know what the next killer app will be, but I do think there 
is a place for a machine "Powered by REBOL" which boots in a few 
seconds, lets me communicate, write view images, multimedia, code 
my own Rebol apps from a set of built in services, oh and the battery 
lasts for days - not hours!
It would have to display HTML too (legacy web :-))


So there you go, a bit of a rant from an old geezer technologist 
. Now where's me 8" floppies I need to boot that PDP-11?

Does REBOL provide architecture documentation/guidelines and/or frameworks 
for the development of scalable, fault tolerant, manageable, with 
hot code swapping for soft real-time 24x7 applications?
 


Petr already covered the basics (Thanks for doing that Petr!), so 
I'll just chime in with opinions. 


I've been using REBOL since 2001. No tool is perfect, and REBOL is 
no exception, but there are only a few things I think it really isn't 
suited for even in its current form. It was not designed for programming 
in the large, but that's a benefit as much as a drawback, until you 
start building larger systems. IME, REBOL does require a different 
mindset if you want to get the most out of it. You can write code 
as you would in many other languages, but you won't see the big benefits 
REBOL offers if you do. It's still a good tool, even used that way.


The docs and tools you asked about don't exist in official form, 
but there are a lot of "pieces" in the community. I'm working on 
something now that has those same goals.

Rebol does require a different mindset if you want to get the most 
out of it


It's what I call the Zen of Rebol. I think it explains why it's taken 
me years to really "get it". I'm still learning of course. In a way, 
I wish I'd not had a backgound in procedural languages before Rebol.

Thanks everyone for your prompt and honest comments.


Why did I join this community? The primary reason is to be part of 
a small, smart and passionate group who think differently, which 
when combined with REBOL is a very powerful combination. Therefore 
it would seem that focusing the resources of the community on a "killer" 
application leveraging REBOL3 would increase the chance of REBOL 
becoming main stream, and as a side effect possibly allow part time 
REBOL developers to become full time REBOL developers. As an example, 
think what Ruby on Rails did for Ruby. Wouldn't it be nice to get 
paid to do what you love!


IMO/E I believe it's very important for the application vendors to 
have very close and strong ties with the platform vendor so architectures 
and features can be designed and exist at the correct layer. Also, 
if something needs to be implemented in the application but really 
belongs in the platform, it can be done in a way that enables that 
feature to be migrated in the future with minimal impact and extra 
work. This seems to fit with REBOL's history of improving based on 
experience.


I'd like to think it's possible to build great applications in 3 
months, with new releases every three months as required based on 
requirements, so I don't have the time (and maybe not even the ability) 
to spend years learning REBOL. I'd also argue that for a company 
to be successful, it needs a small team to have a number of diverse 
skills which is focused on delivering the product. I mentioned when 
I first signed on that I would be interested to meet REBOL gurus 
who are in Northern California and see what happens when interesting 
(or not) people get together. Sorry for the length of this post and 
thanks for listening.

About dialects: You may not know what it is, so I'll give a brief 
real example of what I did, when adding a dialect to my database 
system. It does 3 different database operations, the details don't 
matter, but here goes:

lock-state: db/release locker-id current-object
set [lock-state current-object] db/add-object locker-id
if all ['locked-by-me = lock-state object? current-object] [
  current-object: db/advance locker-id current-object
]


This is RPC based, which means I call specific functions in the database 
over the network, pass parameters, get stuff back in return and maintain 
database environment variables. This is how you do it traditionally.

Now with a dialect, you can say something like this:

do-database [release add advance]


As you can see, it's an incredible code reduction. Same 3 operations. 
A part of it is of course that database environment variables are 
maintained internally and are not really a part of the dialect, which 
further reduces code. But I consider it a side effect of dialecting 
and makes it easier to design a uniform way of talking to the database.

Now which method would you expose to a third party developer? :-)

Thanks for the feedback. I'm not the "best" programmer (hopefully 
I have other strengths ;-) ), but I'm looking for different and better 
ways to solve problems and build applications. Therefore, would a 
programmer with a computer science background with NON procedural 
languages like Lisp or ML be more likely to "grok" and appreciate 
REBOL? Would it make sense to "hire" a young/new programmer out of 
college and get them involved with REBOL early so they have less 
"bad habits" to unlearn? Are any schools teaching their students 
REBOL? I appreciate the help and opinions of the group.

Therefore is a persons prior background unimportant, and it's just 
more important that they are "open minded" and willing to try something 
very different and not mainstream, or dare I say it, be a risk taker? 
Also, don't some languages (and the teaching of them) encourage more 
open minded thinking? For example, ime, it's nearly impossible to 
get Java programmers to think outside their language and OO only 
mindset.


So what attracted everyone on this newsgroup to REBOL? And, in general, 
what type of applications are people trying to build?

Since REBOL requires a programmer to 

think differently", in general what type of person, skill set, and/or 
background is required for a person to be a good REBOL programmer?" 


You just have to be open minded, and I think it helps to be curious. 
You also need to understand that REBOL is high level, but not safe 
in the sense of being dumbed-down so you can't do dangerous things. 
You can do *very* dangerous things in REBOL. You don't have direct 
mem access, so the risk is mainly to your own app, but since it's 
almost infinitely flexible, you can create works of art, or hideous 
beasts.


 "what attracted everyone on this newsgroup to REBOL? And, in general, 
 what type of applications are people trying to build?"


The small size, built-in GUI, and tiney-but-powerful demos are what 
attracted me initially. To be able to download the EXE, install it, 
and run 5 or 6 GUI demos in a couple miuntes just blew people away 
in 2001 when I showed it to them. What keeps me here is that there's 
nothing else that's as much fun to work in (for me). It can be frustrating 
too, I won't lie about that, but the benefits so far outwiegh the 
negatives for me, that I hate having to use other languages now. 
I also love the community. I would count some of the people here 
as close friends now, and it's very satisfying to collaborate with 
them, even just on fun little projects.


What *really* excites me, though, is that I think we're still only 
tapping about 5% of REBOL's potential, maybe less. If you write code 
in REBOL like other languages, there are benefits but they aren't 
earth-shattering. When we get to the point that 10% of REBOLers write 
dialects, and 90% of REBOLers use them, and use REBOL as an interchange 
format, then we'll really be taking advantage of REBOL.

If I allow infix + after each number, the result of course get worse:

>> rule: ['add set a number! opt ['+ set c number! (a: a + c)] set 
b number! opt ['+ set c number! (b: b + c)] (a + b)]
>> time [loop 1000000 [parse [add 4 5] rule]]
== 0:00:06.360697

Why did I join this community? The primary reason is to be part of 
a small, smart and passionate group who think differently


That's basically the same reason I joined this community.  Like many 
others here I found REBOL through the Amiga community.  I had access 
to an Amiga 2000 when I was in elementary school and I loved it. 
 When I decided to start programming I played with some Perl, some 
VB, some C and then I signed up to the Amiga Developers List in 2001, 
through which I found this community and I've never looked back...

Since REBOL requires a programmer to 

think differently", in general what type of person, skill set, and/or 
background is required for a person to be a good REBOL programmer?"


  I think that those most likely to really grok REBOL are those that 
  "think outside of the box."  IMHO, anyone CAN be a good REBOL programer, 
  like Gregg says, what you need most is an open mind.  Curiosity does 
  help....  A lot.  There are a number of simple IQ tests that you 
  can give people to determine their ability to "think outside the 
  box."  The way they approach the problem is as important as their 
  ability to solve the problem because this shows you how they will 
  attempt to solve problems they encounter while programming.


Therefore, would a programmer with a computer science background 
with NON procedural languages like Lisp or ML be more likely to 
grok" and appreciate REBOL?"


From what I have seen, they will pick up REBOL a lot quicker than 
those without the background in lisp or a language like Lisp, however 
this doesn't necisarrily mean that they will be able to write the 
best REBOL code...

Would it make sense to 

hire" a young/new programmer out of college and get them involved 
with REBOL early so they have less "bad habits" to unlearn? Are any 
schools teaching their students REBOL?"


There is a group here, "Rebol School", that we have been using to 
discuss the topic of learning/teaching REBOL.  One of the users here, 
DenisMX, I believe has developed, or is at least working on developing 
a REBOL curriculum.

What is the best way to get an formatted timestamp that matches IBM 
DB2 in this form: ccyy-mm-dd-hh:mm:ss.nnnnnn

I tried this, but I'm stuck on how to extract out the nanoseconds 
from Now/precise:


Timestamp: rejoin [ now/year "-" now/month "-" now/day "-" now/time 
".000000" ]


Also, if the month or day is less than 2 digits, I need a leading 
zero -- how can I do this easily?

To get the seconds:
third now/time/precise
Use first, second, to get HH MM.
Not sure it is nano-second precise!

OK -- I'm perplexed as to when does things get evaluated.

If I have a variable like Now-TS: to get the formatted time, it will 
be resolved immediately and return the time.

If later, after I wait 1 second, I want to print the new formatted 
timestamp, it returns the exact same value as before, when I know 
the time has acutally changed.  How do I get the time now to be resolved 
again?  Example code:

print now/precise		gives 17-Jul-2007/14:35:21.308-5:00 
 wait 1

 print now/precise		gives 17-Jul-2007/14:35:22.324-5:00	now/precise 
 is evaluated immediately

 Now-timestamp: 
	rejoin [
		Now/year "-" Now/month "-" Now/day "-" 
		first Now/time "." second Now/time "." third Now/time "000" ] 

 print Now-timestamp			gives	2007-7-17-14.35.22.0000	
 wait 1 

 print Now-timestamp			gives	2007-7-17-14.35.22.0000		the exact same 
 time -- not evaluated immediately


Is it this way because Now-timestamp has been assigned and already 
evaluated  -- if so, how do I have it reevaluate it again?

Later on you can either do a full evaluation of the word by stating 
it directly ( a ) or you can just retrieve its value by using a get-word 
( :a ).

Thanks for your patience with me.  I'm wrong about the evaluation. 
 It is done at the time of the assignment returing whatever value 
to the variable.  The reason Now-timestamp had identical values, 
even after waiting 1 second was that it was evaluated once, with 
a value put into it, then the wait happened, then I simply re-printed 
the same value as before, because I did not re-do the variable.  
I think I was making it harder than it really is.

I don't understand this statment:

Later on you can either do a full evaluation of the word by stating 
it directly ( a ) or you can just retrieve its value by using a get-word 
( :a )


Are you saying that I can simply type Now-timestamp to have it re-evaluated 
at that time?

a: 23 * 56   when interpreted will compute 23 * 56 then the set-word 
 a:  assigns the value 1288 to the variable a.  Because it is just 
a number  a  and  :a  are both 1288, you can't really get at the 
23 * 56 anymore, that expression has been evaluated and "forgotten", 
forgotten not really a good word, but the expression 23 * 56 is not 
around anymore, only the 1288.

btiffin -- Thank you for taking the time to explain it.  I think 
I understand it now.  I was initially confused because I tried to 
print a timestamp knowing full well that time is changing and I didn't 
understand how to get it evaluated.  I confused the assignment of 
a value with that of a function..  Good info on the date timestamp 
above.

Thank you all!

If you read the Core manual on REBOL.com, it has a pretty good explanation 
of the four word types (normal, lit, set, and get). The other thing 
to understand is when blocks, and nested blocks, are reduced (evaluated). 
That can be tricky to figure out sometimes, because funcs like PRINT 
do it automatically.


If you can get a handle on when things are evaluated--and don't stress 
when you have to add a REDUCE or COMPOSE but aren't sure why--and 
if you can grok the four word types, you 'll be in great shape.

When getting started, you can quite often treat REBOL like many other 
languages; it has a nice facade to let you get a lot done that way 
without forcing you to understand how it really works.

In short, Rebol's molding of strings can be in two different formats 
depending on the input string, and depending on where you get your 
input string from, it can be hard to guess which one it is.

I would suggest to make your own Excel/CSV-string-molding function 
to ensure you have double-quotes as expected.

Other people have come to this exact same problem before, by the 
way.

Just skimmed here, so no new advice to add, except to say that this 
is one of those cases where it's impossible for REBOL to get it "right", 
because everybody has different rules about how it should work. I 
agree that the Excel model is a good one, and I would like to see 
it support that. REBOL also treats things differently based on whether 
there are spaces adjacent to the quotes or not, making it even more 
fun.

	http://www.rebol.net/cookbook/recipes/0018.html

Let me know what the hiccups are, if you can, so we can get a solid 
version out there for people to use. Thanks.

source to-file is very simple  to-file: func [value] [ to file! :value 
]  ; which seems to apply : to a get-word! in the first case

Put another way, what is the rule for when a word must explicitly 
bear the sigil prefix of  :  ? I.e., when is a get-word! required 
and when does any word suffice?  ::word is an error but   to file! 
:myString  in a func is no different from  to file! myString   and 
how do you pur carriage-returns into this message-post box!  ;-)

Robert.  get-words are "unevaluated", so no code will execute getting 
to the value.  Most datatypes will return the same value for get 
as for evaluate.  But getting functions will return the function, 
not the result of evaluating the function.  Umm, that's probably 
not a Ladislav level answer, but it's how I think about it.

I'm not completely clued in, but I think get-words can be faster 
as well, as the lexical scanner can skip the evaluation,  In your 
case; evaluating a filename, returns a filename, (and I only assume) 
is an extra (nearly empty?)step than just getting the filename.

For instance.  a: now  gives you a date time field that won't change 
whenever you reference a or get a and it's type is date!   a: :now 
gives you an a that will be the current time whenever it is evaluated., 
but if you get-word a with :a or get 'a you get back the native, 
not the datetime, so a's type reports as native!  It's funky and 
fun.

Brian's explanation is good; it's something to play around with in 
the console, to get a feel for things.

Robert and all;  I just bumped into this one again...so I thought 
I'd mention it.


none is a weird value, in that it usually looks like none, but a 
lot of time is  'none  the word!, not the value none of type none!

My suggestion...when starting out, get used to typing  #[none]


a: [none none]   type? first a  is word!  and none? will test false.

a: [#[none] #[none]]  nice and safe...  type? first a  is none!  
and none? will test true.

Umm, get used to typing [#none] if you are putting none into a block 
that is.  a: none  does what you'd expect.

All words are seen as words, unless reduced.


>> blk: [none true :word word: 'word integer! 1 1.0 1.0.0 $1 1x1 
"string" <tag> [name-:-host] #i
ssue]

== [none true :word word: 'word integer! 1 1.0 1.0.0 $1.00 1x1 "string" 
<tag> [name-:-host] #issue]
>> head forall blk [change blk type? first blk]

== [word! word! get-word! set-word! lit-word! word! integer! decimal! 
tuple! money! pair! string! tag! email! issue!]


>> blk: reduce [none true 'word integer! 1 1.0 1.0.0 $1 1x1 "string" 
<tag> [name-:-host] #issue]

== [none true word integer! 1 1.0 1.0.0 $1.00 1x1 "string" <tag> 
[name-:-host] #issue]
>> head forall blk [change blk type? first blk]

== [none! logic! word! datatype! integer! decimal! tuple! money! 
pair! string! tag! email! issue!]

So...get RT to open DocBase and I'll start right now, oh yeah and 
R3 beta for access to format  :)  Kidding... I was going to be playing 
with PDF-MAKER today, to see if I can add print functionality to 
the Desktop Librarian...maybe I'll use this as a good way learn the 
dialect.  So unless someone else steps up...I'll take a kick at it, 
for R2 datatypes anyway.

To all...by the way, check out Gabriele's pdf-maker.r in rebol.org 
(the docs have a pointer to the new in-progress work for pdfm2). 
 Maybe we'll get printing from REBOL sooner than later.  :)

none is always a word. of course, if you reduce the word, you get 
the value. like print is always a word, but if you get it you get 
the function :-) so there is no mistery, words are just words.

re: comments in 'core' on the plague of MI ...

multiple inheritance works rather nicely in Curl since you are required 
to provide 'secondary'  constructors - I prefer prototype-based with 
an option for class hierarchies, personally ( try experimenting with 
Logtalk if you can find time ).  I am watching Io, the language, 
evolve as Rebol3 emerges: what is interesting to me is that I ask 
'But is that Oz ?' in Oz. ( which is multi-paradigm )  I used to 
hear a lot of 'getting it' about Prolog and Smalltalk.  After almost 
2 decades in both, I think many of them "didn't get it" ( class hierarchy 
obsessed, as ST purists are/were ).  Ruby is so much like Smalltalk 
that I am quite enjoying watching Groovy play catch-up with Ruby 

Most issues in Rebol have a parallel in Javascript; where ( for the 
neophyte) experiments with 
	typeof

in a console is about the only way for the average developer  to 
'get  it' given
	d1 = Date  // now you use d1 as a function d1()
	d2 = Date()   // d2 is a string that looks like a number   

 d3 = new Date() // d3 is an object but it is UTC but it is presented 
 local time but it is compared UTC .... 
or
	s1 = "string"
	s2 = String("string")
	s3 = new String('string')

 s3[1] = 6   // s3 is an object, as typeof of reveals; String 'equality' 
 in JavaScript even with === is no end of grief  and  for what convenience 
 ?
	s3["size"] = 6
or
	a1 = Array(42)
	a2 = new Array(42)

I think the latter 2 show just how rushed LiveScript was pushed/forced 
out to market as "LavaScript" before the Sun "StrongTalk" folks had 
much influence on the Netscape folks ....  Rebol3 is in better hands 
than 'ActionScrtpt'  as it drifts into classes - because it is being 
kept 'in hand''

The changes in Groovy as it complied with the JSR for Java scripting 
are interesting ( Groovy is almost neat as Rebol would be if it were 
confined to, say, living on  top of VisualBasic ;-)  Now to avoid 
'Rebol on Rails' ...

I think some people who adopted Spring to cope with Java would appreciate 
Rebol ( there, too, you have to 'get it ' )

 MySubClassObject.prototype = new MyParentClassObject()   // now go 
 mess with THAT object before it is useful ...
	// ...

 MySubClassObject.prototype.superclass = MyParentClass  // to fake 
 having a superclass other than Object
cannot be much easier to "get" than anything about Rebol
	use    ; now mostly use /local
and

 bind   ; modifies the block it is passed; use COPY refinement to 
 preclude this side-effect

Smalltalk80 was like "Rebol4" as compared to the first passes at 
an O-O language ...  someone who actually understands Smalltalk contexts/blocks 
and JavaScript should 'get it' with Rebol ( some of those people 
are using Seaside with Squeak, Dolphin and/or VisualWorks ST )

  my 2 cents:  a1 should have been an array of fixed size and only 
  a2 should be a Vector object

I meant that I don't much ask ''But is that Oz?" the way we ask "but 
is that "Rebol?" or "But would that be Rebol?"  It comes from my 
aversion to the questions/attacks of  purists who insisted that Turbo 
Prolog was not really a PROLOG.  Neither is what Prolog became (Prologia 
IV)

The Slate team for Smalltalk3 ( if you think of JavaScript as Smalltalk2 
 [heresy] ) now have Self and Strongtalk to look over with 15+ years 
of hindsight.
It appears to have slowed them down a lot.

I can't wait to get my hands on that Rebol3 beta ...

PS  if you don't think JavaScript was Smalltalk2, just look at Io, 
the language ;-)

PPS  the author of CTM was probably asking himself "But will they 
see that this is not Oz? " with every chapter (Peter Van Roy,  'Concepts, 
Techniques and Models of CP', MIT Press) - the O-O chapter is arguably 
the worst flaw in a fine MIT intro book - unless it is the flaw of 
totally ignoring JavaScript as a functional prototype-based lang. 
( and I don't recall mention of Curl or Rebol )

Another language evolving: Cecil into Diesel

;; this is neat

 mold make object! ["test"]   ;; warning: to preserve a spec block 
 be sure to use    obj: make object! copy/deep specBlk

;; copy/deep issues are rampant in Smalltalk ( if you get the impression 
that I think Smalltalkers neglect Rebol, yer rite )

>>system/console/prompt: [ reform [ now/time ">> "]]  ;; good tutorial 
candidate from 'Rebol for Dummies' by Ralph Roberts
>>to-integer #2A  ;; Hex. But what was the question?

>>big-Q: does [ rejoin [ none ". But the answer is: " to integer! 
#2A]]
>>big-Q

>>little-Q: [ rejoin [ none ". But the answer is: " to integer! #2A]]
>> do little-Q

>> do big-Q ;; now you get an error because none is the has-no-value 
word
>> type? none 
>> path? 'none/first

set  get 
this might not be obvious if you are new ( like me )
beBoundToWord: 'aWord
set :beBoundToWord 42
print aWord 
get :beBoundToWord
word? :beBoundToWord

; this also not so obvious  about index versus path
  blk: [ t' t'' t''' ]
  blk/t'
  blk/1
  blk/t': 42
  blk
  set blk/1 21
  blk
  blk/1
  :blk/1
  get blk/1
blk2:  [ a' b' c' ]  
  set blk2/a' 42
  blk2
  blk2/2
  blk2/a'
  get blk2/a'

; one thing I failed to note with the  set  and  get 
>> aWord
** Script Error: aWord has no value
** Near: aWord
>> 'aWord
== aWord
>> aWord
** Script Error: aWord has no value
** Near: aWord
>> word? aWord
** Script Error: aWord has no value
** Near: word? aWord
>> word? 'aWord
== true
>> a: 'aWord
== aWord
>> aWord
** Script Error: aWord has no value
** Near: aWord
>> word? :a
== true
>> :aWord
** Script Error: aWord has no value
** Near: :aWord
>> :a
== aWord

; this seems worth getting clear:  that a word can be a value and 
still not be used until it has a value

More and more I think that was is not obvious is no longer obvious 
once it is obvious

There is an 'active' LISP tutorial that would be a good model for 
a 'Rebol for newbies'

I would like to use the approach taken in the 2.3 "Official Guide" 
book to introduce unit testing in Rebol for TDD "from-the-get-go"

In Smaltlalk we used to count on newbies exploring in a workspace: 
we reaped a culture where people thoght the point of O-O was to write 
subclasses and create deep hierarchies like, say, Collection.  What 
was obvious was just wrong.  Messages were the point, not classes, 
let alone sub-classing.  Am I wrong to suggest to anyone new: "buy 
as used copy of "The Official Guide" " ?  For Oz, which is so much 
like Rebol, I do not hesitate to recommend Peter Van Roy's CTM from 
MIT Press.  Scheme has 'Little Schemer' and 'Simply Scheme'   The 
latter would be my model for an interactive tutorial in which you 
LEARN.  Smalltalk was supposed to be about how we model things ( 
how we learn how things interact )

I think it fair to say that it failed.  Classes were not the point. 
 Objects were not the point.  Things went wrong early on in abandoning 
the Actor Model in early 70's     I am hoping Rebol3  is getting 
it right ;-)   ( Io, the language, is quite inspiring ( www.iolanguage.com 
) but I still think Oz is a great intro to Rebol (they, too, lack 
an effective learning tool to "think in Oz " )

Robert;  By definition in REBOL the only logical false values are 
#[false] and #[none]  So for instance, integer! 0 is logcally true, 
which took me by surprise at first, but that is the way of REBOL. 
 Surprise! Usually pleasant. :)


Aside: The other words that evaluate as false; no, off (others?) 
do not have a pure lexical form so, #[off] is not a loadable value 
but the word off still evaluates to #[false].


And  to logic! get/any 'an-unset-word  will evaluate as #[true], 
as back to the defintion, only #[false] and #[none] are false.  As 
far as I understand it anyway.

the size of that depends on what you've done in the session. if you 
started the view desktop for example, you're going to get quite a 
big result ;)

; tutorials  on series and find/part

; I may be alone in thinking that without experimenting, a newbie 
will miss this ...  here is my experiment

; the docs say part will accept a 'range' but give no clear indication 
what a 'range' is in 2.x
text: {
    Tested this before.
    Then test these.
}

start: find text "this"
end: find start newline
item: find/part start "this" end
print item

index? find text "this"
index? start
length? start
index? end
length? end
head start
head end
index? item
head item

; by now you get that Ah-Hah experience or Eureka! or 'hot-damn!' 
as the case may be ...

; I did a dif between the functions in VIEW and those in CORE for 
a default install.  What I get is this ( I hope it is useful to have 
al 106  in one place )

 alert  brightness?  caret-to-offset  center-face  choose  clear-face 
  clear-fields  confine  crypt-strength?

 dbug  deflag-face  desktop  dh-compute-key  dh-generate-key  dh-make-key 
  do-events  do-face  do-face-alt  do-thru  

 draw  dsa-generate-key  dsa-make-key  dsa-make-signature  dsa-verify-signature 
  dump-face  dump-pane  edge-size?  

 editor  emailer  exists-thru?  find-key-face  find-window  flag-face 
  flag-face?  flash  focus  get-face  

 get-net-info  get-style  hide  hide-popup  hilight-all  hilight-text 
  hsv-to-rgb  in-window?  inform  

 insert-event-func  inside?  install  launch-thru  layout  link-relative-path 
  load-image  load-stock  

 load-stock-block  load-thru  local-request-file  make-face  notify 
  offset-to-caret  open-events  outside?  

 overlap?  path-thru  read-net  read-thru  remove-event-func  request 
  request-color  request-date  request-dir  

 request-download  request-file  request-list  request-pass  request-text 
  reset-face  resize-face  rgb-to-hsv  

 rsa-encrypt  rsa-generate-key  rsa-make-key  screen-offset?  scroll-drag 
  scroll-face  scroll-para  set-face  

 set-font  set-para  set-style  set-user  show  show-popup  size-text 
  span?  stylize  textinfo  unfocus  

 uninstall  unlight-text  unview  vbug  view  viewed?  win-offset? 
  within?

Robert  you can get a similar list by doing

; the error from trying
>>  n: print mold m
; natually leads to
help print
; and since this fails
p: write %tmp.txt :anything"
; with
help write

; we get to clarify binding words to values, functions, procedures 
 evaluation and returned values

; I hope to get tutorials prepared for OCaml and Scheme as well as 
Haskell and Curl, Perl, Python, Ruby and Smalltalk based on my experience 
as a newbie while I am still a newbie ...

they are all functions, as the all return a value. some return the 
value "unset!" which is treated somewhat specially by the interpreter. 
you cannot set a word to this value unless you use set/any, and you 
cannot get a word that refers to this value unless you use get/any.

unset! is mainly used to catch typos (eg. if you write pint instead 
of print you get an error), and it's used as a return value by functions 
that don't have anything useful to return.

I wil be sure to cover  get/any  and  set/any 
thanks

; using a context there is no problem traversing a path into nested 
blocks. But there is using nexted blocks alone.  Here is my first 
answer to this...
>> t1: [a "one" b "two" c "three"]
== [a "one" b "two" c "three"]
>> t2: [f t1]
== [f t1]
>> t1/b
== "two"
>> t2/f
== t1
>> t2/f/b
** Script Error: Cannot use path on word! value
** Where: halt-view
** Near: t2/f/b
>> pword: func [path 'word /local blk] [
[    return to-path reduce[path :word]]
>> do pword t2/f c
== "three"

; pword is my first pass at a function to traverse nested blocks 
which are not in an object; the alternative appears to be
blk:  get t2/f
aPathDeeper: make path! [ blk c ]
; anyone know anoth path to take?

>> p4: to-path "t1/x/f"
== t1/x/f
>> do p4
** Script Error: Invalid path value: t1/x/f
** Where: halt-view
** Near: t1/x/f
>> type? p4
== path!
>> get first p4

** Script Error: get expected word argument of type: any-word object 
none
** Where: halt-view
** Near: get first p4

; using get first or get second or get last usually is handy diagnosing 
what is reported as a path but in fact fails as a path

>> p4: to-path 't1/x/f
== t1/x/f
>> get first p4
== [a "one" b "two" c "three" x [f "for"]]

; or b) step through the path and resolve each value in turn:

resolve: func [:path [path!] /local wd val][
    wd: first path: copy path remove path val: get wd
    while [all [block? val not tail? path]]
        wd: first path remove path
        val: val/:wd
        if word? val [val: get val]
    ]
    val
]

Yes, get first path is a godsend

-1 could be treated as a default value, and you would put its associated 
code right after the branch. But I get your point.

You have to get the table-base from somewhere and add that.

Ah, get it. i thought compare takes two chars, and we have to loop. 
as a loop returning -1,0,1 it makes sense.

hmm, I would expect to go this route using libraries code, but with 
rebcode? aren't you manipulating rebol internals only? How can you 
get past the boundaries of e.g. string or binary to cause such core 
dump?

Yes, you can do this:
>> ctx: context [rcmul: rebcode [a][mul a 2 return a]]
>> myrcmul: get in ctx 'rcmul
>> rca: rebcode [a][apply x myrcmul [a] return x]
>> rca 3
== 6


But I think, Kru got a point. It would be better to be able to do 
it his way.

Here are some initial comments on the recently posted rebcode documentation 
draft:

- It has been suggested on the list that since the assembler's rewrite 
engine is a mezzanine, it might not be included in the final version, 
in favor of (to promote?) user-made rewrite engines. If not, you 
would need to change the documentation to match, especially section 
1.4.

- It needs to be made clear somewhere in the initial description 
of the rebcode dialect that rebcode is a statement-based language, 
not an expression-based language like the do dialect. Opcodes perform 
actions, but don't return anything per-se. The 2.1 or 2.3 sections 
would be a good place for this explanation to be.

- In the "Branches are always relative" note at the end of 2.6, there 
is a sentence "The branches are always relative to the current block." 
that could be removed. The whole note should probably be renamed 
to "Branches are always local" because the note doesn't really cover 
that they are also relative. Also the phrase "use a branch opcode 
to" could be replaced with "branch to" and be less awkward.

- A common mistake in specifying literal branch offsets is to miscalculate 
what location the offsets are relative to. This mistake would be 
less likely if the third paragraph of 2.8 were changed to "The argument 
to the branch opcodes is an integer value, representing how much 
of an offset you want the branch to perform. Branch offsets are always 
relative to the location after the branch statement, not the absolute 
offset within the block. Positive values branch forward; negative, 
backward. The branch target must always fall within the current code 
block." as this is the actual branch behavior (and more clear).

- The sentence in 2.8 "The brab opcode allows computed branch offsets 
to be created." isn't really true right now, at least in any practical 
way. The current behavior is more like "The brab opcode allows you 
to branch to an offset selected at runtime by an index.".

- The paragraph at the end of 2.8 "There is also a special case of 
operation. If the block argument to BRAB is an integer (created from 
a label), then the branch is made to that relative location plus 
the value of the index argument." would be a good idea to be implemented 
(I've submitted it to RAMBO), but is rather awkwardly phrased. This 
could be rephrased once the behavior is implemented, or left alone 
if you don't want most rebcode users to use this behavior.

- In section 2.9, the sentence "Result then refers to the value returned 
from the function." may be better said as "The word result is then 
assigned the value returned from the function.".

- 4.1.*: The phrasing of many of these entries is awkward. Also, 
remember that opcodes don't return anything, they modify operands.

- 4.1.1: I'm not sure "integral" means "the integer part of" as it 
is used here; the word may be more related to integrate than integer.

- 4.1.4: Lowercase the "Tail" word to be consistent. Otherwise, well 
phrased.

- 4.1.5: The descriptions of change, copy and insert don't describe 
how their amount parameter is used. You could describe change as 
"Changes part of a series at the current position to that part of 
a value (-1 for the whole value).", copy as "Set the operand to a 
partial copy of the series (-1 for all) from the current position.", 
and insert as "Inserts part of one series (-1 for all) into another 
at the current position.". Or, you could provide further explanation 
in some new 2.* section.

- 4.1.6: In the description of index?, change "Returns the" to "Set 
the operand to".

- 4.1.7: Does not reflect the renaming of the opcode get to getw 
and the addition of setw. Also, instances of "Result modified" should 
be changed to "Set result" or "Set operand to result".
- 4.3.3: The braw opcode has been removed.

As for "and you can add code snippets into code without having to 
add labels", imagine that you are generating your rebcode, or copy-paste 
coding, rather than hand-writing every line every time. Now imagine 
that there are branches in the code snippet you are putting into 
your code unchanged. If you use labels as branch targets, you may 
end up accidently reusing some label name that already exists in 
the block and the assembler will complain. To avoid that you can 
branch to offsets specified as literal numbers. You get these numbers 
by counting the instructions between the branch and the target yourself. 
This may seem like a lot of work for code that you have to write 
every time, but it is not too much work to put into a tested snippet 
of code that will be reused as is, over and over again. And if you 
have relative branches, you only need to consider how far apart instructions 
are within the snippet, rather than recalculating those offsets depending 
on what position the entire snippet has in the block you are inserting 
it into.

graph-layout: I won't have the time to get deeper into rebcode in 
the moment. So, here is a request, for something that gives a nice 
demo: I have the old graph-layout code, which uses the TouchGraph 
idea. Anyone interested to port it to rebcode and see howmany nodes 
we can handle?

An optimizer does just the opposite: It converts the literal offset 
to a kind of virtual label statement (the difference being that the 
virtual one takes no space in the code); then after code insertions 
or deletes have happened, it changes the offsets to their new values, 
just like rerunning the fixup phase of the assembler. Of course optimizations 
like this can get a little more complicated when you have branch 
targets calculated at runtime - this was probably why they added 
BRAB and removed BRAW in the recent release, replacing general branch 
calculations with a simple lookup table.

questions we need to get an answer for, especially from BrianH as 
a supplier of #3947:

how to get random number between 0 and 1?

Thanks! I just want to make sure we get permission from authors.

You can use 'third, 'get and 'set to turn objects into blocks. only 
from the rebol-side, but maybe it helps a bit.

Kru, you can use apply in or apply bind to get a word bound to the 
object field, and then use setw and getw to get at the values.

I've made a test of a voxel landscape engine in rebcode. As I did 
it on my Mac, it's written in the version of rebcode found in the 
version 1.3.50 of REBOL/View from around Oct-2005. I haven't tested 
it with the Windows version of View, but I guess, it should work 
with that same version 1.3.50. I first did a plain REBOL version 
and got a framerate of around 3-4 fps (frames pr. second). With the 
rebcode version, I get around 20 fps. The script is found here: http://home.tiscali.dk/john.niclasen/voxel/NicomVoxel.r


I've also made a snapshot here: http://home.tiscali.dk/john.niclasen/voxel/snapshot.png

I get a bug:

>> do http://home.tiscali.dk/john.niclasen/voxel/NicomVoxel.r
connecting to: home.tiscali.dk
Script: "NicomVoxel" (2-Apr-2006)
** User Error: Rebcode syntax error:
mul idx cZ
add idx cX
pickz OldY heightmap idx
** Near: make error! reform [msg copy/part mold/only where 50]

ok, I get 20 fps on a 1.2 GHz G4 Mac.

How many RHz do you get with: http://www.rebol.com/speed.r

I've done some little C processor dialect ideas as well, mainly to 
handle DEFINEs and convert structs to REBOL friendly data. I think 
those kinds of tools are useful and, for the amount of use they get, 
I prefer that approach to trying to do a complete C processor/loader. 
Ultimately, that might be good for some people, but I still want 
an interface dialect in REBOL that makes things easy to read and 
understand from a REBOL perspective. I think "dialect first, then 
tools".

so far I can see only logical additions to get into programming into 
large ...

I'm not saying parse cant do anything... its just something some 
people "get"  and some others dont.  I am of the latter kind.

modules just extend them and allow us to make SURE they don't affect 
other code and dont get affected either.

The issues you are touching on  are all easily circumvented.

If I have your *source* I can easily preprocess it before DOing or 
LOADing it to make whatever behaviour changes I like.

That makes it impossible in a source-level library to get total protection.
Binary modules, that's another issue.
Paranoia is good!

create a file and check ownership? does get-modes tell?

now tell your IT manager or CTO that you have to do all of this just 
to get the user name and that you really want to use REBOL...  ;-)

just like we just SEND a mail, READ a web site, or WRITE an ftp server. 
 if we could also LOAD/SAVE any XML technologies (XML files, DTDs, 
Schemas, etc), then R3 would immediately get appeal in the corporate 
world.  It would actually have value to them .

And R3 would have the excuse of being able to be IT friendly.. which 
it currently isn't.   AND it would benefit of having access to a 
slew of tools which actually help some people get work done integrating 
Heterogenous systems, which is something REBOL is currently incapable 
of stating.

If you get any salesman in an IT dept which has XML capabilities 
(and they are getting used, really) and in 15 minutes, LOADS their 
data structures, instances, edits them and spits them right back 
out using a simple command line interface... welll...  case closed.

you at least get a chance at having REBOL being used for some little 
tidbits, and as we all know, it will become addictive and soon will 
get used more and more.

Personally, I've never really considered the "copy problem" a problem. 
When you don't copy something it doesn't get copied. When you do 
it does. Series aren't immediate values, they are reference values. 
Same for objects. Every language design choice could be considered 
a bug or a feature - it all depends on how you use it. I've found 
more advantages to the way that REBOL functions work now.


The only real problem I've run into is functions keeping references 
to their temporary data after they return, at least until they are 
run again (a memory hole). The closure example above with the adders 
stops being a problem when you realise that FUNC is a function that 
does something when passed a  couple blocks - it's not syntax. You 
didn't copy the block, so it gets reused, go figure. You are building 
functions - is it such a stretch to build code blocks?

make-adder: func [n] [func [x] compose [x + (n)]]

and thus get tackled by the GC?

I found one bug: Your build dialect will convert lit-path! to path! 
unintentionally (as far as I can tell). Convert all word references 
to block or result in your inner function to get-words (:block and 
:result respectively).

;The changed build function would be:
build: func [
    {Build a block using given values}
    block [block! paren! path! lit-path! set-path!]
    /with
    values [block!]
    /local context inner
] [
    values: any [values [only: :encl ins: :dtto]]
    context: make object! values
    inner: func [block /local item item' pos result] [
        result: make :block length? :block
        parse block [
            any [
                pos: set item word! (

                    either all [item': in context item item <> 'self] [
                        change pos item'
                        set/any [item pos] do/next pos
                        insert tail :result get/any 'item
                    ] [insert tail :result item pos: next pos]
                ) :pos | set item get-word! (

                    either all [item': in context item item <> 'self] [
                        insert/only tail :result get/any item'
                    ] [insert tail :result item]
                ) | set item [

                    block! | paren! | path! | set-path! | lit-path!
                ] (
                    insert/only tail :result inner :item

                ) | set item skip (insert/only tail :result get/any 'item)
            ]
        ]
        :result
    ]
    inner :block
]

Still, changing them would make your build dialect compatible with 
older versions of REBOL that evaluated path and paren values when 
you referenced them with a word rather than a get-word. It all depends 
on how far you value backwards compatibility.