AltME groups: search

Patrick

REBOL has a LOT of words (functions).

It really is worth it to just read all of them (even quickly) it 
is a lot of fun, and realize the amazing depth of it.


When I get a new peice of software (or even hardware) I simply read 
the whole manual from front to back.  I know I might not understand 
it all that way, BUT, I then at least know what it does, and what 
it does not do.  It is sort of like walking around a new house quickly.


You might not remember where everything is, but you mind keeps working 
even afterward, helping you fill things in.

Hi all, I have a problem to figure out.


I have a special needs child that uses a talker device to speak for 
her.  It will log all of the words buttons she pushes to a file. 
 Problem is, the timestamp was not adjusted to the correct time and 
date, as a result each record with a timestamp is off by 6 years, 
3 months, 25 days, 6 hours and 17 minutes.  The format of the file 
is like this:

30th 6pm
*[YY-MM-DD=03-06-30]*
18:04:38 RECORD ON
22:55:13 CTL "Switch User Area from ..."
...
*[YY-MM-DD=03-07-01]*
06:19:12 CTL "..."
06:19:37 PAG "..."
...


As you can see, it is a simple text file that contains a header record 
for the date, and then each line has a time along with various info.

What I would like to do is this:

1.  Compute the offset time (to adjust the erroneous timestamp to 
the correct time)
2.  Go through the file record by record.

3.  When you find a date header record, "*[YY-MM-DD=" grab the erroneous 
date (pos 12-19 as yy-mm-dd), but do NOT write it out.

4.  When you find a time record (hh:mm:ss in pos 1-8), put the bad 
date and time together and then subtract the offset time from it 
to get the right date and time.

5.  If the right date has changed from the prior record, write out 
the corrected date header record.

6.  write out the corrected time record (replacing the wrong time 
with the right time)

7.  Any other records other than a date header or time trailer, just 
write out as is.

Steeve,  should the last "-" be a "=" instead?

They are not equal. The first makes a copy, the second references 
the original.

This matters more in code in a function. That function might get 
called again.

Ok, I get the if x is modified it won't change the original,

What I don't get is that and empty block [ ] is just empty.  It is 
not like a word or anything is it?

Yes, i did see the performance numbers.  that is good to see!

The empty block is a value, even if it doesn't contain other values, 
and it is a value that can be modified.

Ok just so I have this. 
x:	copy [ ]    will copy an empty block that x is refered to
y:	[ ] 	   will be a reference to an empty block


how is it possible to modify an empty block without referencing it?

 y: [ ]		<-- ref empty
== []

>> append "hi" y	<-- changes that empty block
== "hi"

>> x: [ ]			<-- X is now that same empty block
== []			But I don't see the "hi" value.  -- What am I missing?

I have a typo in my example.  Now I see

x is not the same empty block, it is a new block.

>> a: does [append copy [] 1]
>> b: does [append [] 1]
>> a
== [1]
>> a
== [1]
>> b
== [1]
>> b
== [1 1]

>> source a
a: make function! [[][append copy [] 1]]
>> source b
b: make function! [[][append [1 1] 1]]

a: does>> a: does [append copy [ ] 1]
>> b: does [append [ ] 1]

>> c: does [append x: [ ] 1]         ;<--   is this the same as b?

Ok so back to my question.

A will reference a specific memory and each time it is eval, a new 
empty block is setup.

B will reference a different memory place, and each time it is eval, 
that same memory can be modified.

C will reference a different memory place, that can also be modified 
by either using C or changing X.


But is there any significant difference to the following, if both 
reference a NEW memory location that is empty?
x:	copy [ ]
y:	[ ]

Sorry, I am really trying to understand

I think I understand now Brian,

In terms of just initializing a value, both of these are only done 
once, then they are essentially the same,

But if at any time you eval X or Y a second time, then you get different 
results!!!

Thank you for explaining it to me!

I have a question about the APPEND function.

>> loop 10 [x: "a" append x "b"]
== "abbbbbbbbbb"


I would have expected the the final result to be just "ab" (after 
the 10th iteration).


But in this example, X has been assigned to the string "a" and then 
"b" is appended to it 10 times.

If X has been "reset" to the letter "a" again in each interation, 
why doesn't the previous "b" also go away since X has been reinitialized 
to just the letter "a"?

you fell into the copy trap :-) x is not reset by assigning "a" to 
it.

x: copy "a" would solve that. that's why it's called the copy trap.

You mean like this:

>> loop 10 [x: copy "a" append x "b"]
== "ab"

with this, you can provide some interesting tricks to building series 
without assigning them to words:

loop 10 [append "a" "b"]
== "abbbbbbbbbb"

Effectively, you are making x the _same_ as the string "a" so when 
one changes, they "both" do. as Henrik says, you want to initialise 
x to the _value_ of the string "a" instead.

It may be clearer like this
     A: copy "a"
    loop 10 [

        x: A    ;; x is the _same_ as A ... you want [x: copy A] to get its 
        value instead 
        append x "b"
    ]

as a rule of thumb, REBOL tries to reuse series as much as it can.

use SAME? to detect whether two series are the same one:

>> a: ""
>> b: a
>> same? a b
== true

>> b: copy a
>> same? a b
== false

>> loop 10 [x: "a" append x "b"]

And yet, if I repeat the exact same comand 10 times, I do NOT get 
the same result

x: "a" append x "b"
=="ab"
x: "a" append x "b"
=="ab"

no, because every time you make a new line, you are making a new 
string. in the loop, you are reusing the same string.

If you type:

>> ""
== ""


you are making a string, but you are also immediately losing it again. 
you can't use it again.

By doing this:

>> ""
== ""
>> ""
== ""

You are therefore creating two separate strings.

Ok, so the same as the loop would be:

x: "a" append x "b"
x: "ab" append x "b"
x: "abb" append x "b"  etc    right?

This means also that doing this:

>> x: "a"
== "a"
>> x: "a"
== "a"


you are creating two separate strings, both assigned to 'x and the 
last assignment overwrites the first one.

nope. :-)

The same would be:

x: "a"
append x "b"
append x "b"
append x "b"...

or: 

    b: [x: "a" append x "b"]
    do b
    do b
    do b

I need a small function "my-compose" that takes a blocks, deep search 
tag! values and change it with the value of the word into the tag.
For example, if I have a test function like this:

x: 1
test: func [y /local z] [
	z: 3
	my-compose [ 
		print [ <x> + (<y> + <z>)]
	]
]

Calling:

test 2 

should return:

>> [print 1 + (2 + 3)]

My problem is to do the right bind in the parse:

my-compose: function [code [block!]] [elem rule pos] [
	rule: [any [

  pos: set elem tag! (change/only pos **magical-bind-here** to word! 
  to string! elem ) |		    	
		pos: any-block! :pos into rule |
		skip
	]]
	parse code rule
]

Steeve thanks, now it is much more clear.

I'll use the get-word type as you suggest. (I have to change a bit 
my dialect, but it's not a problem)

REBOL has no reserved words
 --I've seen suggestions like this several times.

There are exceptions....Some of the commonly used dialects have many 
reserved words. [Parse, View etc]. That is clearly stated in some 
of the documentation, eg:
    http://www.rebol.com/docs/view-guide.html#section-7


In addition, 'local acts as a reserved word as this code (R2 or R3) 
shows:
    >> use [local x][x: has [local][]]
    ** Script Error: Duplicate function value: local


So there is at least one real reserved word. Anyone know of any others?

i give you a true one in R3.
>> context [self: 1]
** Script error: cannot set self - it is protected

I see where you are coming from. But I explicitly used USE [LOCAL] 
to make LOCAL local to my block.

If FUNC has a problem with that, it helps establish my point that 
LOCAL is a de facto reserved word.

Good one with SELF

You made the point in your initial post Sunanda: "Some of the commonly 
used dialects have many reserved words."  Function specs are just 
a dialect. A reserved word, or keyword, is one that can't be used 
for your own purposes because the language has a fixed requirement 
for its use.

Gabriele, yes. My point, poorly stated, was that a *dialect* may 
have keywords, but REBOL itself does not, per Sunanda's original 
post.

It seems that it is not possible to use the word 'local as a word 
in the context of a function. (R3 raises a dupilcate word script 
error if you try.)  So in that sense 'local is a reserved word in 
any function.

So it would appear to be a reserved word at least.

The HELP function treats the /local refinement specially in function 
specs, but the function spec dialect doesn't: /local is just another 
refinement. Some of the mezzanine function creators treat /local 
the same way HELP does (particularly HAS, FUNCT and FUNCTION), but 
that's just a convention, not a reservation. The duplicate word error 
PeterWood got above would happen if any argument word was duplicated, 
not just 'local.

Strangely enough, the BIND function has a keyword that DO doesn't: 
'self.

The 'system word is predefined and protected, but not a keyword in 
any built-in dialect in R2 or R3.

Strangely enough, the BIND function has a keyword that DO doesn't: 
'self.

 - as far as I know, 'self is not a keyword for Bind in R2, but it 
 is a keyword of the object spec dialect.

...the DO dialect doesn't, except for one: The word 'rebol before 
the header

 - actually, I would say, that the word 'rebol is a keyword of the 
 script specification dialect (i.e. I would make a distinction between 
 "plain Do dialect" and "script specification dialect (s)", there 
 actually are two variants of the script spec dialect, one for "normal 
 script", one for "embedded"script"

Thanks for the various explanations and examples.


My conclusion.....At the very least. use of LOCAL as a variable should 
be flagged somewhere as a potential gotcha. 


Consider the six R3 functions below. Some print NONE, some print 
999 -- not every developer will have enough guru-fu to know which 
do what:

local: 999
 f: closure [] [print local] f
 f: does [print local] f
 f: func [][print local] f
 f: funco [][print local] f
 f: funct [][print local] f
 f: has [] [print local] f

Sunanda, more than guru-fu, people just need to use SOURCE. :-) BTW, 
we could change /local to /some_unlikely_to_be_used_word, it's just 
a mezz change.

In R2 DO of a block or string didn't require (or use) the header, 
but DO of a script does. In R3 it's the same for DO of a block, but 
strings are treated like scripts now, and the header is optional, 
unless you need information in it. So DO script has a 'rebol keyword, 
but DO block doesn't. And DO block is what we think of as being the 
DO dialect.

Sunanda, I actually use 'local in some functions as a extra temporary 
variable. It has a good name for that use.

A simple `return*: :return` should do the trick ...

It seems that I was quite wrong about local being a reserved word 
- it's all in how your write the function specification:


>> func-with-local-called-local: func [/local] [print local: "my 
local word"]

 >> func-with-local-called-local                                  
             
my local word

>> local

** Script Error: local has no value

** Near: local

Ladislav, you keeep suggesting that there will be the option of dynamically 
scoped RETURN and EXIT if we switch to definitionally scoped. There 
is no indication that this is the case, and the increased complexity 
that would add to function calls is a serious indication otherwise. 
It's probably going to be only definitional or only dynamic, not 
an option of either/or. And either way we will need a workaround 
attribute: something like [throw] for dynamic, something else for 
definitional.

you keeep suggesting that there will be the option of dynamically 
scoped RETURN and EXIT if we switch to definitionally scoped. There 
is no indication that this is the case

 - citation: "Allows return as a dynamic function to still work (when 
 return not in function spec.)" see http://www.rebol.com/r3/notes/errors.html

It makes the above sense to me, so, I do not propose a modification.

Just a note, which may as well be put here, I guess: since R2, Rebol 
"mixes" definitionally scoped and dynamic constucts, and it looks, 
that this mix will stay with us even in R3

it creates a new object, though. in R3, you can use the extend function 
to extend an existing object with one new value.

extend does not do that (though it could, just a mezz).
but this do it:
>> append obj1 body-of obj2

extend extends with a single value, where append can extend with 
any values.

Just for fun (it's a slow sunday today) I've wrote a rebol version 
of the code used as benchmark in this page http://tinyurl.com/5nezt9

here's the code:

REBOL []

person: make object! [
	_count: none
	_prev: none
	_next: none
	
	_construct: func [n] [_count: n]
	get-prev: does [_prev]
	set-prev: func [pr] [_prev: pr]
	get-next: does [_next]
	set-next: func [nxt] [_next: nxt]
	shout: func [shout nth /local aux] [
		if shout < nth [
			return shout + 1
		]
		aux: get-prev aux/set-next get-next
		aux: get-next aux/set-prev get-prev
		1		
	]
]

chain: make object! [
	
	_first: none
	_last: none
	
	_construct: func [size /local current] [
		repeat i size [
			current: make person []
			current/_construct i
			if none? _first [_first: current]
			if not none? _last [
				_last/set-next current
				current/set-prev _last 
			]
			_last: current
		]
		_first/set-prev _last
		_last/set-next _first
	]
	
	kill: func [nth /local current shout] [
		current: _first
		shout: 1
		while [not equal? current current/get-next] [
			shout: current/shout shout nth
			current: current/get-next
		]
		_first: current		
	]	
]

start: now/precise
iter: 100000
loop iter [
	current-chain: make chain []
	current-chain/_construct 40
	current-chain/kill 3
]

print ["Time per iteration =" (difference now/precise start) / iter 
]
halt

which give me:
Time per iteration = 0:00:00.00080234

802 microsecond that is the slower time of the benchmark, 

but not SO slow, php is near with 593 microsecond, jython 632 ... 
.(the test system is pretty like mine so i can compare the result)

There's a way to improve the performance?

a bit better:
Time per iteration = 0:00:00.00077844

java is in the class of c++ in performance AFAIK

I remember the in 1998 there was a mame - java applet that could 
run phoenix at 100% of the velocity with no skipframe (I had a pentium 
100 Mhz at that time)

a bit OT: yesterday I've discovered that compiled VB6 run as fast 
as tcc in number crunching :-)

Java is faster than REBOL at Java-style code, because REBOL is optimized 
for a different code style. If you are writing code in REBOL style 
then it can be faster than Java in some cases, or at least less slower 
in other cases. In this case what is slowing down REBOL is all of 
the unnecessary accessor code: OO overhead that Java can optimize 
away, but it REBOL you just don't write in the first place.

I know that rebol appeared to be the slowest language on debian language 
shootout , but then cheyenne is *much* faster webserver than any 
of the ones made in dynamic languages I tried (even lua). so speed 
is a relative thing it seems (like Brian says)

also when using dialects, there is often a huge speed gain, but you 
can't really code like that in most other languages.

Is there a way to pass a refinement further? so I don't have to do 
something like
do-some: func [ /ref ] [ either ref [ do-more/ref ] [ do-more ] ]

that is an oldie. In R3 as well as in R2+Rebcode you can use a native 
APPLY

I will use normal argument .. I don't want to further complicate 
codebase to make it a little nicer

janko, when I have chained calls which use options, I do this:

func [/opta /optb /options oblk][ 
	oblk: any [oblk copy [ ] ]
	if opta [append oblk 'opta]
	if optb [append oblk 'optb]

	; then use the block exclusively using find.
	if find oblk 'opta [print "option A supplied"
	if find oblk 'optb [print "option B supplied"

	; this way you can easily chain options 
	do-something/options oblk
]

I've done the same thing as Max, and if there is just one refinement, 
I'll still use EITHER. If you have a scenario where there's an entry 
point that delegates work and requires multiple options, consider 
making it a dialected func.

The APPLY mezzanine in 2.7.7 has a minor, obscure bug that is fixed 
in a later R2/Forward release, and later R2 mezzanine source. But 
aside from that it works fine, and I have used it in production code 
with no errors (the bug was so obscure that it never came up in practice 
or testing).

Without APPLY or something like it, you end up having to do some 
tricky stuff sometimes. See this REMOLD backport for instance:

remold: func [
	"Reduces and converts a value to a REBOL-readable string."
	value [any-type!] "The value to reduce and mold"
	/only "For a block value, mold only its contents, no outer []"
	/all "Mold in serialized format"
	/flat "No indentation"
][ ; Nasty, but the best you can do without native APPLY
	do pick pick pick [[[
		[mold reduce :value]
		[mold/flat reduce :value]
	] [
		[mold/all reduce :value]
		[mold/all/flat reduce :value]
	]] [[
		[mold/only reduce :value]
		[mold/only/flat reduce :value]
	] [
		[mold/only/all reduce :value]
		[mold/only/all/flat reduce :value]
	]]] not only not all not flat
]
; Note: Uses APPLY in R3.

We did a *lot* to make R3 easier and more powerful :)

Nevermind, I think the [any-type!] in R3's REMOLD is the error, not 
the :value in the backport. I'll fix it now and put in a ticket.

works well here, try a probe
Are you trying with R2 ?
It's not working with R3

remoldx: func [x /all /flat /only][
	do probe head clear change change change next 'mold/?
		pick [[] all] not all
		pick [[] flat] not flat
		pick [[] only] not only
		reduce x
]

probe remoldx/all [next 'a/a 2] 
probe remoldx/all/flat [next 'a/a 2]
probe remoldx [next 'a/a 2]
probe remoldx/only/all/flat [next 'a/a 2]

>>

mold/all
[#[path![a a]2] 2]
mold/all/flat
[#[path![a a]2] 2]
mold
[a 2]
mold/all/flat/only
#[path![a a]2] 2

The APPLY mezzanine uses a similar method (building a path), but 
creates a new path every time to be recursion-safe.

Nice. In R3 you'll need a temporary variable for the copied path 
because REMOVE-EACH returns the count removed instead of the value.

Is there a faster way to replace the first two charcters in the given 
string by the fifth and sixth character of the same string?
 
>> s: "123456789"
== "123456789"

>> change s copy/part at s 5 2
== "3456789"

>> s
== "563456789"

Well, I once thought, that there was a way how to circumvent the 
copy, but it looks to me now, that I was wrong

yes, but it does not look to me like a viable way to replace a CHANGE 
X COPY/PART Y by a cycle of that kind, although I did not measure 
the speed difference, yet

it apparently tries to do user.r, where I have set-net as a first 
function call. Other SDK kernels don't have such problems ...

is there a difference .. I haven't ever yet user user.r .. I will 
try.

nevertheless, to all that think, that copying/collecting is slower 
than moving a character at a time, my result is, that the change 
x copy/part y z expression is about 2.8 times faster on my example 
x y z, than a cycle moving a character at a time.

Yes, the internal native loop inside CHANGE is faster than a loop 
run in mezzanine code, even if the loop function is itself a native.

Just a question: is there a way to let external fuctions (outside 
REBOL) be associated to a rebol word ? Could this fuction access 
REBOL values via some API ?

How do you create a face with VID that has a transparent backdrop?

Give it a color of NONE. (assuming what you need is that simple)

I' m probably doing something wrong, when I use a color of none I 
get a gray backdrop not a transparent one. I'm trying to answer one 
of RebolTutorials questions. 

Here's the code:

I' m probably doing something wrong, when I use a color of none I 
get a gray backdrop not a transparent one. I'm trying to answer one 
of RebolTutorials questions. 

Here's the code:

>> b-t: layout [
[    backdrop [color: none]
[    text "line 1" red
[    text "line 2" blue
[    ]
>> y-b: layout [
[    b-b: box white 728x90 effect [gradient 0x1 sky]
[    ]
>> b-t/offset: 0x0
== 0x0
>> b-b/pane: b-t
>> view y-b

IIRC, backdrop is a style, so it creates a sub-pane in the layout.

Thanks for pointing that out Anton. I a real beginner when it comes 
to view.


When I added with I didn't get a transparent face but I did when 
I triued Steeve's suggestion to set the color of the face to none.

Near the top of the source of LAYOUT you can see that the face (which 
is typically to become a window face) is created from VID-FACE (the 
very same one at system/view/vid/vid-face).

Any good example of using "range"? I cannot find a single example. 
For instance, the copy function can take a range [number port series 
pair]. I don't know how to specify the range. In the Core tutorial, 
to copy a range, we need to move to the particular position first 
and then do the copy. Fine. What is this 'range' about and how do 
we say it? The following don't work: 3-5, [35], 35, 3:5, 3x5. Thanks.

a: [a b c d]

copy/part a 2
== [a b]

copy/part next a 2
== [b c]

That was quick! Yet still don't get the 'range' part. I do understand 
the copy/part a 2, and the second copy/part next a 2. Maybe I don't 
understand how to interpret the API docs?

can you post a URL to what you're reading?

I think I get it. I find this a misnomer. It is not a range, it should 
be "ending position". It is a range because the starting position 
is implied. (?).

yes, range is always from the current index of a series to the specified 
index

start positions are usually the current position in a series, when 
using series functions in REBOL.

Correct, and this is why I now understand. As a new comer to rebol, 
I just find that the Word Browser should not use the term 'range' 
but something else, like 'position' in its definition. Anyways, you 
answered my question that unlocks the rest of the docs for me in 
this regards.

A trick that you won't see from the word browser:

here: [a b c d]
there: at here 3

copy/part here there
== [a b]

I think I saw it differently with a file example:

Oh, my the rebol echosystem has a lot of little things work unexpected.