AltME groups: search

I'm a guy with principles and respecting the work done by other is 
one of them. I like playing by the rules.

As I'm reviewing my old code, where I see a lot of rejoins where 
the first arg of block is always binary... what do you think about 
something like:
abin: func[block][append copy first block next block]
where the speed gain is:
>> tm 1000000 [abin [#{00} "a"]]
0:00:01.609
>> tm 1000000 [rejoin [#{00} "a"]]
0:00:02.938

maybe not such a big gain.. as I must use:
abin: func[block][append copy first block reduce next block]
which has result 0:00:02.078... but anyway.. every ms counts:)

mazbe it's strange that works:
>> make string! reduce ["a" "b"]
== "ab"
but not:
>> to binary! reduce [#{00} "a"]
** Script Error: Invalid argument: #{00}
** Near: to binary! reduce [#{00} "a"]

abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert tail copy first block: reduce block next block
]
;to be able have code like:
abin [to-binary #"^(00)" "a" "b"]

Oldes, a faster way (in R2) is this:
abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert copy #{} reduce block
]

bjoin, since it is a binary version of ajoin.

bjoin [#"^(00)" "a" "b"]

What do you see as the arguments to both have = and == in REBOL?


There are times when you care about strict equality, and times when 
you don't. And it's a balancing act between usability, strictness, 
and risk; similar to the choice of making a language case sensitive 
or not.

It's tricky, too, because sometimes you'll want to add something 
that you think will make things easier, but it really causes more 
problems in the grand scheme of things. TO-STRING versus FORM is 
a good example. I would like to see REBOL minimize the number of 
things that differ only in very subtle ways (which are often not 
explicitly documented).

Let's look at this example. I have two words, iss and str, that represent 
some value, and they're some datatype. This is charasteristics of 
them:

>> series? iss
== true
>> series? str
== true
>> first iss
== #"a"
>> first str
== #"a"
>> length? iss
== 3
>> length? str
== 3
>> pick str 2
== #"b"
>> pick iss 2
== #"b"
>> str/3
== #"c"
>> iss/3
== #"c"

They seem quite alike. Are they equal?

>> str = iss
== false

Nope! Why not?

>> str
== "abc"
>> iss
== #abc


Again, I see little point in having both equal and strict-equal, 
when there's so little difference between them. If there were more 
differences between them, it would be good arguments to me for having 
both.

But if we didn't have strict-equal then how would we know when a 
variable is a pointer?

;consider:

>> a: "123"
== "123"
>> b: a
== "123"
>> b
== "123"
>> a
== "123"
>> append a "4"
== "1234"
>> b
== "1234"
>> a == b
== true

Obviously, a and b are pointers to the same memory address that  
holds the string.

You don't check, if they point to the same mem area with strict-equal, 
you use same? (or =?) for that:

>> a: "abc"
== "abc"
>> b: "abc"
== "abc"
>> a == b
== true
>> a =? b
== false


So it's not obvious, they point to same memory address, just because 
a == check returns true.

Something funny. (We had a long discussion about this in R3-alpha.):

>> 0.3 - 0.2 - 0.1 = 0.0
== false

This is also false in e.g. the C language.

It's a floating point thing - 0.1 can't be represented exactly in 
IEE754 floats.

Or you could use fixnums: integer! and a scale.

But Python is also a bit strange, it seems. From Python prompt:

>>> 0.1 + 0.1
0.20000000000000001
>>> 0.1 + 0.1 == 0.2
True
>>> 0.1 + 0.1 + 0.1
0.30000000000000004
>>> 0.1 + 0.1 + 0.1 == 0.3
False

anyone remember where the parse demos showed a calculator dialect 
?

saves me a few mins writing my own !

I was trying to help new guy on ML, and just would like to ask - 
why is there a difference in evaluation when printing a block, and 
printing first block?

>> colors: [red green blue]
== [red green blue]
>> print colors
255.0.0 0.255.0 0.0.255
>> print first colors
red

so 'first does not reduce the value, while print itself does?

>> a: 1

== 1

>> type? a

== integer!

>> type? 'a
== word!

>> b: [a
]
== [a
]
>> type? first b

== word!

>> print a

1

>> print first b

a

>> print 'a

a

Help says print does an evaluate (presumably a reduce) if the value 
to print is a block....So it is documented behavior:
  http://www.rebol.com/docs/words/wprint.html

trouble with double caret afer forming a string from block.

print y: form [KBE RKH CSCD IDJ MNOV LCAPB CWCO ^DJA]
KBE RKH CSCD IDJ MNOV LCAPB CWCO ^^DJA

how can I avoid the double caret?

form, mold or composing the string via foreach etc. doesn't work 
here.

sorry I mean a probe... -> probe y: form  [KBE RKH CSCD IDJ MNOV 
LCAPB CWCO ^DJA]

Any time the string is displayed literally (such as at the console, 
or mold/save) will you see the double caret.  Internally it's a single 
caret.

As chris states, there is a difference between how rebol show some 
chars and how they are kept internally

But there's no way other than a rewrite to get 'probe to display 
a single caret.

same behavior with tab, newline,...
a tab is showed as "^-" but internally it's only one char!

ahh I see. I need this string to compose a url and get a error. thought 
by 'probe the second phantom caret was the failure.

looks like rebol doesn't accept the caret with a url

yes, made a string and then to-url. this helps if the caret is hex-encoded 
 %E5

So, a typo in a user input string could result in returning a wrong 
time! value without throwing an error. Looks like a bug or at least, 
a flaw IMO.

REBOL has always had a policy of "normalising" times with >59  minutes. 
Even without the to-time and string:
>> 1:111:11
== 2:51:11

I think you may have a typo........My example was 1:0:5000 (two colons). 
I see identical behavior in R2 and R3

>> blk: [a b c d e]
== [a b c d e]
>> foo: [bar 5]
== [bar 5]
>> path blk foo/bar
>> blk
== [a b c d]
>> foo/bar: 1
== 1
>> path blk foo/bar
>> blk             
== []
>> foo
== [bar 1]

The primary example use was in functions, to return the contents 
of a variable and also free the variable. eg, this:

	add-one: func [value][1 +  also value value: none]

replaces older code such as this:

	add-one: func [value][1 + first reduce [value value: none]]

Is that a good example? Why would you set value to none, if it's 
a number? It doesn't matter.

use cases: 
1/ swaping a with b
a: also b a: b
2/ in a function, returning a value after cleaning local vars
func [x /local tmp][
	tmp: a * 2
	also tmp tmp: none
]

error with swaping
a: also b b: a

Hm, a SWAP command could be a good idea, maybe. Or just do:
set [a b] reduce [b a]


About freeing local variables, why would you do that? Don't you call 
your function several times? You give garbage collector more to do 
this way. If it's often the case, that locals should be freed, then 
maybe we need a new function type, that does that?


(I'm asking all this, because I never understood the reason for having 
ALSO.)

When I think about it, much of this is based on assumption how memory 
is handled in REBOL. We don't really know, because it's not documented. 
When is it good to free a local, and when not? There may be something 
wrong, if this should be handled by the programmer (also when it's 
not documented).

If I have a simple local in a language like C, I wouldn't allocate 
and free it every time, I call my function.

A local in C is just a value stored in some memory. I guess, it's 
the same in REBOL? Again we don't really know.

REBOL must have a look-up table for the known words in the context, 
but after that it should just end up at a memory address.

I use also function a lot.

John, I haven't done a lot of performance checking but I know the 
clear-locals function is working to free memory.

it's a differrent use case when dealing with series.
even in R3 you need to clear the series

so, if I am on a M$ network, what is the best way to reach a \\blah\blah\blah\file.blah?

wow, thanks Paul.  I think I freaked momenarily.  If I have to do 
it through Windoze I figure I could do a call (as a backup plan)

A link to where Gab answered this, and yes, your example looks correct, 
http://www.rebol.org/ml-display-thread.r?m=rmlJZJQ

Is this a bug?

>> first [:a/b]
== :a/b
>> type? first [:a/b]
== path!

Shouldn't it be get-path! ?

R3 responds get-path!, so it might be a bug

I think, you are right! Just a bit confusing, what :a/b mean then. 
It doesn't give an error.

Maybe a combined get-word! and path! ?

It isn't a path either

I think it's being interpreted as a get-word! with a refinement:

>> type? :a/b
** Script Error: a has no value
** Where: halt-view
** Near: type? :a/b
>> type? :a /b
** Script Error: a has no value
** Where: halt-view
** Near: type? :a /b
>>

and inside the block, it can be interpreted as a path. basically 
get-path! is a good idea. :-)

>> as-lit-word? first [:a/b]
== false
>> as-lit-word? first [:a]
== true

Tells me if an item acts as a lit-word.

I could test the value with the as-lit-word? function to determine 
if I want to set the word to a value.

It seems that there's no specific semantic rule in R2 for a get-word! 
as first item of a path! value. So, it's just treated as word!.

>> a: [b 123]
== [b 123]
>> :a/b
== 123
>> a/b
== 123

I think it was to get rid of 'my-port. ALSO is useful when returning, 
so you don't need to assign another word for results that would otherwise 
be temporary. I use ALSO in a couple of places here.

What happens, where you call process-port? Don't you have a variable 
there?

It does really untie a small knot there and I've bumped into that 
quite often. It was discussed heavily a year ago in the r3-alpha 
world and Carl wanted it in. I remember the discussion was mostly 
what to name it. :-)

Maybe if I see a bit larger program, that use ALSO!?

I learned a program structure more than 20 years ago called "program 
95%". It's a structure, you use 95% of the time when programming 
COBOL (and probably also in most other langauges). Maybe the need 
for ALSO is related to how we structure our programs?

I'm not sure it is. For the port example above, there's no way to 
return without ALSO or assigning a temporary variable. If you are 
using it inside another function, like process-port, it will only 
reduce overhead, not create more.

What is the overhead for calling a function compared to not call 
it? And by having the close down in a function mean, it may not be 
on the same level as the open, which may be seen as bad programming 
style.

no, you may exactly _not_ have 'my-port. you may be doing a test 
on the port which does not require an extra word.

So you don't really need to copy the port? It's just for a test, 
like:

port: open ....
while [port] [
....
]
close port

Geomol: I wonder why you have a problem with 'also now. It was discussed 
on 10-Aug-2007 on r3-alpha in new-functions group - and you were 
one of the people who were in this discussion

Yes, I then said, I didn't see the need for it, but I suggested a 
good name. Now 1.5 years later, I still don't use it. I'm asking, 
if people use it, because if I see good use of it, I hope to use 
it myself.

I've used it in a couple places, almost always having to do with 
ports - it is much nicer than spanning 3 lines for the same thing

John, consider if you have a local variable in a function.  Then 
calling also can clear that local variable.  This is what I use 'ALSO 
for the most and why it is way cool.

Yes to save resources.  For example, what if I just read an MP3 file 
into a word? I want to free that word so that it no longer is allocated 
to that data.

If you want to load more MP3s, it would be a good idea to reuse the 
same memory area. An example:

>> f: func [/local blk] [blk: []]   
>> a: f
== []
>> insert a 42
== []
>> a
== [42]
>> source f
f: func [/local blk][blk: [42]]
>> clear a
== []
>> source f
f: func [/local blk][blk: []]


You see, A and BLK inside F points to the same memory. Next time 
you call F, you can put some more stuff in BLK (read another MP3).

If you want to be able to completely remove BLK, I would do that 
using an object. Build the MP3 player as an object, instead of just 
a function. Makes sense?

You still have to set the MP3 data returned from your function to 
none to release the memory (making the garbage collector to work). 
I would handle this situation either by making a refinement to my 
function or (probably better) creating the whole thing as an object.

I gotta run for a bit but will be back in about an hour or sooner.

Using ALSO returns some data. If your code look like this:

mp3-data: load-mp3-function


and that load-mp3-function ends with an ALSO, setting the local var 
to none, you still have a full copy in mp3-data. Actually you end 
up having 2 copies for some time, until the garbage collector frees 
the local version. Later in your code, you need to set mp3-data to 
none to free to memory (which the garbage collector does). Now, is 
this how you use ALSO and why you need it?

but, like before, say that happened in a function

>> f: has [q] [q: [] append q "kdfjkd" also q q: none]
>> a: f
== ["kdfjkd"]
>> a
== ["kdfjkd"]
>> source f

f: func [/local q][q: ["kdfjkd"] append q "kdfjkd" also q q: none]

Is this expected behaviour?

>> f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> a: f
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> insert a "hmm"
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "hmmblahblahblahblahblah" also q q: none]
>> a: none
== none
>> source f
f: func [/local q][q: "hmmblahblahblahblahblah" also q q: none]

Izkata, you got a point with your Pread. But it's not a secure function, 
because it may crash. Let me see, how I would make such a function...

>> a: f: has [q][q: "blahblahblahblahblah" also q q: none]
>> a
== "blahblahblahblahblah"

>> f
== "blahblahblahblahblah"
>> a: f
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "blahblahblahblahblah" also q q: none]

You can see, it doesn't this way:

>> f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> a: f
== "blahblahblahblahblah"
>> insert a "more blahblahblahblah"
== "blahblahblahblahblah"
>> source f

f: func [/local q][q: "more blahblahblahblahblahblahblahblahblah" 
also q q: none]

Look at the source of f. Notice the "more blahblah...."

a: f: has [q][q: copy "blahblahblahblahblah" also q q: none]

unfortunatly the same story...
does anybody knows why a replace on the second and third also
changes the first letter?  ^JKSE = %5E/KSE and  ^IKSE = %5E-KSE
but ^MERV = %5EMERV and therefore okay.

	probe load replace/all  mold "^MERV" #^ "%5E"
	probe load replace/all  mold "^JKSE" #^ "%5E"
	probe load replace/all  mold "^IKSE" #^ "%5E"

any advise is highly appreciated...
tom

Paul, in your last example with copy, the q memory is released, and 
the string after copy remains. So this actually is a version with 
something gained. Now I have to think, if I would do it this way.

Well, ^I is a control-i.. and in vim, that inserts a tab.  ^- is 
the tab character in Rebol

Anyway, I can now see, how you use ALSO with ports. By using a function 
approach, you choose to copy the data out to some further external 
computation. And it's up to the user of the function to free the 
data, when finished. I would take an object approach and store the 
data in the object. Then external computation can work on the data 
in the object. I feel, it's confusing using ALSO, but maybe it's 
just me.

Where I see a potential problem with ALSO, is if you in a function 
load a local var with a huge amount of data, say 1GB. And then to 
release that data ends your function with:
also copy local-data local-data: none


At that moment between the two arguments to ALSO, you have 2 GB of 
data allocated. The first 1 GB is freed, when the garbage collector 
comes to it.

Geomol: [Izkata, about the timeout. It seems here, that when the 
open/binary returns, the data is immediately available, so the timeout 
has no effect. I'm on OS X, maybe it's different under windows?]

I'm on Ubuntu  ;)  but yeah, now that I think about it, that's true. 
 Originally it was written differently, and the error appeared to 
be on the copy.  I added it when mininova was timing out on certain 
requests due to high load - it seemed to make a difference then, 
but I don't know if it was coincidence or not.

If you're thinking I'm making a torrrent client in Rebol, not yet 
 ;)

networking is not a strong point

Geomol, your last "potential problem with ALSO" is not exclusive 
to ALSO. It's a potential problem anywhere COPY is abused by a programmer 
not knowing what's going on.

The way to return the large amount of data and to release the local 
from it is of course like this:

	also local-data local-data: none

In the load-mp3-data function above, a large binary series is loaded 
and contents set to refer to it. The ALSO line returns the binary 
series and unsets CONTENTS so that it no longer refers to the binary 
series. The usage code below the function definition takes the return 
value (the binary series) and sets DATA to it.

So effectively the variable referencing the binary series has been 
switched with another one.

Which is a good thing to do, because now the function does not maintain 
a reference to the large binary series after it has been called.