AltME groups: search

so my question is basically, what is the proper/expected means of 
submitting a buffer ?

hum... I think I understand something... because the call, is not 
returning a string!, but filling up a buffer, REBOL has no means 
to know that it should fix the string! and resize it to the zero 
terminator, right?

You don't pass a string as a bit of memory to be filled ...

well many C calls expect a buffer as an argument... what's the prefered 
method then?

is double word correctly specified as a string? (count). Should not 
it be an integer?

pekr:  its actually a word pointer  and  MS example look like so:
GetUserName( infoBuf, &bufCharCount )

which is why I supplied a string, so that the get user name would 
receive a pointer instead of a number.

pointer is a number

what about trying putting struct instead of buffer [char] in there? 
:-), with first element being a string? Struct itself will be represented 
as a pointer

just one question, how many bytes is a double word (in MS) supposed 
to have 4 or 8?

I think that is more a problem with the use of int and long.

string! have an internal size and an external size.  using a string 
within rebol, will always update the size, so that it returns the 
current amount of the string! which has been "filled"

now the external call dumps chars directly in the string and add 
a null termination.

there are two cases - when external function returns string and expects 
your struct for it, and second, when external function allocates 
its own buffer and provides you with a pointer

that is strange a bit then .... feels like close to cause a crash 
:-)

yep, but in a case where rebol returns the value, its smart enough 
to look it up and find the null terminator for you  :-)

I know we have to draw a line... but true and false literal string 
representations of boolean values... should be a valid representation 
of input just just like literal integer, decimal, dates, urls, files, 
issues, words, etc values .  no?


we already accept 0 and 1,  why not the string equivalent (obviously 
also support on, off)

LOAD and DO are a more flexible second level.

oh this last one is a bit dangerous IMHO.


since not using the /all refinement of mold easily create true/false 
words... (I  know you'll say use /all) but REBOL isn't always the 
data originator.

Anytime you pass a string buffer to the API, you have to pre-fill 
it. I have a little func called NULL-BUFF, that just inits a string 
filled with nulls. 

A DWORD is 32 bits. A WORD is 16.

but true and false literal string representations of boolean values... 
should be a valid representation of input just just like literal 
integer, decimal, dates, urls, files, issues, words, etc values . 
 no?


Only in the case of TO LOGIC!, not as general substitutes anywhere. 
Of course, it's easy enough to patch TO-LOGIC to do that if you want.

I think I actually did that at one point, and also did a func to 
allow FORMing logic values to their alternate words (on/off, yes/no).

I agree that its only a valid case for the TO LOGIC!

I had also done as-decimal, as-integer which had an expanded input 
format... maybe we should publish a set of functions, one for each 
datatype and submit to the community for peer review?  maybe then, 
this can find itself within R3.  if the work is all done, I don't 
see why Carl wouldn't want a consistent, and already documented set 
of functions.

the speed is secondary at this stage... what we really need is to 
layout the logic and demonstrate a consistent path to conversion 
for all datatypes.  two or three guiding principles will emerge out 
of the implementation... no need to try and define them too early 
on IMO.

Agreed, but we don't have a community effort ogranized to propose 
and submit ideas, in general, for R3. Something *else* I keep meaning 
to do. :-)

btw, this is my buffer init procedure for routines:

buffer: head insert/dup copy "" #"^@" 100

for a 100 byte buffer (99 max length C string)

I guess, you'll need a validation routine to be called after each 
entering of a number by the user, and chech with something like
if error? try [...]

I have the same problem with networking operations. programs will 
halt to console if there is a networking error. the only real solution 
is to wrap your calculation code in a function. you could call it 
'calc, and have that return a disarmed error on failure or a number 
or whatever fits to the situation.


This way calc [2 / 0] wouldn't crash to console and it's fairly clean 
to insert.

should read: The only real solution is to wrap your calculation code 
in a block and use that as a function argument. The function could 
be called 'calc.

since things are cached, only a value which changes cause any amount 
of processing...

Max, I will but this will need some test and a major rewrite of my 
app. So not for the 1.0 release.

robert, depending on your code, there may be an easier way than put 
try in every calculation; for example if you have a window and do 
the calculation when the user presses a button, you could just use 
try in  the button's action; or, you could wrap the do-events (i.e. 
view) in try, and so on. it also depends on how easy it is to recover 
from a given point (the farther you are from the location of the 
error, the harder it is to recover, usually).

Is there a  way to build a rebol object with these tools?

There is a problem with attributes. What if an attribute to a tag 
has the same name as another element within the content of the tag?

A rule could be made, that attributes are placed within a block named 
"attributes" within the object. But that you can't have a tag with 
the name "attributes".

That's a solution, but it can't cope with all XML. What should you 
call the content attribute? You might call it something, that another 
attribute is called already.

It's hard (maybe impossible) to come up with a solution, that can 
handle all XML.

is there a difference between valid xml and that which is in common 
use?

I've used Graham's code a lot --especially for hefting RSS files 
into REBOL format. It works well.

There's a HUGE difference between dealing with simple, well formed, 
XML, and trying to implement the XML specification. A good deal of 
XML our there is just well formed; no namespaces, no attributes; 
easy to deal with. I did a loading (XML to blocks) that just makes 
a minor change to parse-xml; it reverses the content and attribute 
values--since attributes are often NONE--so you can use path notation 
on the resulting block.

>> test: make object! [ a: b: none  c: make object! [ d: none]]
>>
>> obj: make test [ c/d: "testing"]
>> h: make test [ a: 1 ]
>> probe h
make object! [
    a: 1
    b: none
    c: make object! [
        d: "testing"
    ]
]

how come when I create a new test object, it has the same c object 
?  Shouldn't that be a new object as well?

that's a bit painful ... guess why I never used objects much before.

Quick hack, Graham:
test: make object! [ a: b: none  c: make object! [ d: none]]
obj: make first reduce load mold test [ c/d: "testing"]

try a fresh console, I've done it successfully on mac with view 1.3.2 
and winXP with view 2.7.0

your kidding me... Could that be a problem ?

hmm... it could be that it evaluates as a path

Please do not run this in REBOL console. Instead I want you to tell 
me what you expect as a result:

unset 'a a/x: (a: 1x2 3)

I would probably expect 'a/x to be 3

...and what you expect in case:

a: 1x2 a/x: (a: [x 4] 3)

or:

    a: 1x2 a/x: (unset 'a 3)

a = [x 3]

so... what happens with a/x: (a: func ...) ?

(if a was already func that is)

My proposal is, that

f: func [/x] [print "huh"]
f/x: 1

should be an error (cannot use set-path on a function)

it's mainly a matter of wheter it is more natural for the set-path 
to be evaluated first or last.

well, there is a possibility to use the strategy to "partially evaluate" 
the set-path before evaluating the argument, but then e.g.

a: 1x2 a/x: (a: 3x4 5)

should yield a == 5x2 and

a: 1x2 a/x: (a: [x 4] 3) should yield a == [x 4]

hmm, the last example is strange, actually, I guess, that the only 
reasonable variants for a: 1x2 (a: [x 4] 3) are a == 3x2 or a == 
[x 3]

I don't see the point to the partial evaluation either. A set-path 
will always evaluate its argument, so you don't need to preevaluate 
the set-path to determine whether the argument will be evaluated 
- it will. Just evaluate the argument ahead of time. If the set-path 
fails later, so be it.

Ladislav, I would go for the fastest implementation. So double-check 
is out of the question. Then post-check must be the best and safest 
way (I guess!?).

unset 'a a/x: (a: 1x2 3)
should then make a holds 3x2.

a: 1x2 a/x: (a: [x 4] 3)
should make a be [x 3]

a: 1x2 a/x: (unset 'a 3)
should give an error.

I think, this is correct. I'm not 100%.

This is a strange corner of REBOL. And one not often explored. A 
good developer would probably not do something like:
unset 'a a/x: (a: 1x2 3)

But we can't be sure. Maybe it's a really good trick sometimes to 
write something like that.

In general it's good practise to only set internals of values, IF 
it's valid up front (, so I understand, that Gabriele would expect 
an error). But of course REBOL should be able to handle it, if someone 
wrote such tricky code. It shouldn't be undefined, what would happen. 
I feel, the post-check (that Ladislav is talking about) is the safest 
(and fastest) way to handle this, and then maybe in the documentation 
notice, that it's bad programming practise to do this.

Geomol: I agree, but to have it complete, here is a more complicated 
expression:

    a: [1 2 3 4 5 6 7 8 9]
    i: 2
    a/(i: i + 1): (i: i * 2 0)

What should i and a look like?

This leads us to the path evaluation too. What should be the result 
of:

    a: [1 2]
    a/(a: [3 4] 1)

Or to yet another crash:

    a: 1x2
    a/(a: [3 4] 1)

yes, that is a reasonable variant too

Ladislav, your example:
	a: [1 2 3 4 5 6 7 8 9]
	i: 2
	a/(i: i + 1): (i: i * 2 0)

The actual behaviour seems good to me. That is, the first paren is 
evaluated, then the path is resolved, then the second paren.

Maybe this example
	a: [1 2]
	a/(a: [3 4] 1)
is better as 
	a: [1 2]
	a/(insert clear a [3 4] 1)

how about this one?

a: 1x2 a/(a: 3x4 1): (a: 5x6 7)

Tough questions! :-) In general I'm for evaluation of what possible 
at the earliest time as possible. This way stack space should be 
kept at a minimum. This works against the post-check method mentioned 
earlier. So we have the old fight between speed and size. We want 
both! (Good speed and minimal size = reduced bloat and small foot-print.) 
Examples are good to explore this!

i: 2
a/(i: i + 1): (i: i * 2 0)


Should evaluate the first paren right away, because it's possible. 
This way the path is reduced to: a/3

Now, a/3: might not make sense yet, depending on wheater a is defined 
or not. But we don't care, because it's a set-word, and here post-check 
rules.

a: [1 2]
a/(a: [3 4] 1)

should give 3 (I think).

a: 1x2
a/(a: [3 4] 1)

should also give 3 then.

The last one:
a: 1x2 a/(a: 3x4 1): (a: 5x6 7)
should go like this:
i) a is set to 1x2
ii) a is set  to 3x4

iii) first paren returns 1, so a/1 is about to be set (a is not desided 
yet, because it's a set-word).
iv) a is set to 5x6 and second paren returns 7.

v) a is about to be set, so it's being looked up (a holds at this 
point 5x6).
so result is, that a ends up holding 7x6.

Ladislav, looks like pairs are treated differently. (not a series, 
even though they really should be ?)

Path evaluation order once again: it looks to me, that the algorithm 
working as follows:

a: 1x2 a/(a: 3x4 1): (a: 5x6 7)
a ; == 7x2


is more than two times faster than the "more natural" one yielding 
a == 7x6. The difference lies in the fact, that the latter algorithm 
needs to rebuild the path before applying it, while the former one 
can "evaluate on the fly", without rebuilding.

Moreover, the a == 7x2 result is compatible with the way how functions 
are evalutated:

f: func [x] ["first"]
g: func [x] ["second"]
h: :f
h (h: :g 1) ; == "first"

apparently i lost it completly...;-) 


I have to following issue: I want A to be a block and B thave the 
initial values of A, but B may not change when A changes!

so i tried it all , but it always turns out that b changes with a 
i.e.

a: [ [ 987987 ] [ kljhljkh] ]
b: []
b: a
a/1/1: 'blabla  
then b changes too... ;-) 


Oke..i know this, but how do I apply a to b without b changing to 
'a everytime I change a

I need to be able to compare A with B after A changed x times... 
so B must be a block..when using 'equal? B A

I tried 'append 'insert 'foreach but it keeps changing in B too when 
changing A.. That bring me too an issue in rebol, How can I check 
if a Type is a relative of a different Type? like 'copy does..

Im unable to see if B is a copy of A, i can only check if the Type 
is the same but thats useless I cant check if B is a Relative of 
A...

Rebolinth:  you can use b: copy/deep a

Mmmmmm "/deep - Also copies series values within the block."  I cant 
say thats a realy clear eplenation ;-) never the less it works...

Icarii, you can probably use bitsets for what you want. I did some 
bitset math stuff a while back, so Maarten could do 160-bit checksums 
(IIRC).

unfortunately, it doesn't copy all series:
>> a: ["aa"]
== ["aa"]
>> b: copy/deep a
== ["aa"]
>> same? first a first b
== false

yes its strange actualy to find this function under copy... I would 
expect a name like copy/static or someting..but whats in the name 
;-)

hi, I want to call a rebol script in a separate process and pass 
parameters e.g.  launch {c:\script.r param} but does not set  system/script/args

Ladislav, if a: 1x2 a/(a: 3x4 1): (a: 5x6 7) resulting in 7x2 is 
more than 2 times faster than the post-check method resulting in 
7x6, then that is a very good argument to have it that way. Anyway 
your example is something, that should be avoided (if you're a good 
developer, I guess), so speed is better than a "more natural" result. 
That's my view.

if it results in 7x2, does it mean that 'a in paren! is local?

I think, that it really needs an explanation.

* The 7x2 evaluation can work as follows: 

1) the interpreter first sets its Path-start variable to 1x2 and 
its Path-variable to 'a

2) the evaluation of the paren changes the A variable, but that does 
not influence the interpreter Path-start variable, so the path will 
be evaluated as Path-start/1:

3) the argument is evaluated, which changes the A variable again, 
but not the Path-start. The argument value is 7
4) Path-start/1: 7 is evaluated, which yields Path-start = 7x2

5) The variable A is set to the new value of the Path-start variable


The same algorithm can be used for longer paths too and we do not 
have to remember the complete path - it always suffices to remember 
"where we are".


The 7x6 evaluation cannot work like that, since we never know "where 
we are" - the Path start can change anytime, so we cannot "traverse" 
the path when evaluating parens. We need to "rebuild the path" evaluating 
all parens and remembering all intermediate results. Only when done 
and when the argument is evaluated, we can start to traverse the 
rebuilt path knowing the Path start.

Joe, I can't get it to work either. It looks like LAUNCH always just 
converts its VALUE argument to a file and then tries to do it.

Anyone else ? Is this a RAMBOable offence ?

I was processing a Chinese text file using REBOL. The text file was 
in the Big5 Encoding, which is the de facto encoding we use in Taiwan. 
A Big5 character needs two bytes, so I used strings whose length 
is 2 to present Big5 characters. 


Something weird happened. After a while, I realized that REBOL treated 
two different characters as they were the same character.


Chinese-char1: to-string #{A4 68} ; Big5 Char for "Educated Person"
Chinese-char2: to-string #{A4 48} ; Big5 Char for "Human"

if Chinese-char1 = Chinese-char2 [
    print "This cannot not be happening..."
]
How would I fix my REBOL scrip? Thank you.

Not in Core ;-) and I from using Gabriele's keycode onle-line displayer 


view layout [box feel [engage: func [f a e] [switch a [up [focus 
f] key [print mold e/key]]]]]


It looks as though Rebol doesn't provide an event when Caps Lock 
is pressed or released.

as you can see it is possible to catch also KEYUP events in Windows. 
What a pity system port has a bug under View so it works only when 
console window is activated.

That's right, the /MATCH refinement causes exact matching to occur 
from the position you specify (eg. the start). I was a bit confused 
by this at first too. What you probably want is the /ANY refinement, 
which switches on wildcards. So use /ANY instead of /MATCH and you'll 
be alright.

my god... how can such a big feature pass by virtually unused...

Under Windows, you can trap pretty much any WM IIRC, but you can't 
do it from a View window, which is the big limitation. Still useful 
for some things though.

what's the fastest way to sort a directory of files chronologically?

; version 1
my-face: make face [
    my-data: none
]
make-my-face: func [ extra-data ] [
    make my-face [ 
        my-data: extra-data 
    ]
]
; end of version 1

; version 2
my-face: make face [
    my-data: none
    new: func [ extra-data ] [
        make my-face [ 
            my-data: extra-data 
        ] 
    ]
]
; end of version 2


Quesion: I have a lot of my-face objects ( 1,000,000+ ) in an appication. 
Which version is better? Will the version 2 take more memory since 
the "new" is a object method instead of a function?

It depends. Every my-face shows an Unicode character bitmap. They 
are put in a pool for saving memory. If a character is not needed, 
it won't be loaded. ... Showing a long article wich Chinese character 
in it is a nightmare. Short article is not a problem though.

why don't you simply use AGG to "stamp" each character in a bitmap? 
 using the draw command over and over (per character or per line)

this can limit your memory use a lot! especially if you do a pre 
analysis and count the recurrence of each character in the article 
(so you can keep only those that recur, saving some speed).

Right, to clarify, if your my-face object has other overhead that 
could be externalized, do that, and use blocks that contain a reference 
to the lightest-weight face you can use.

do you think such a big draw block will hold?