World: r3wp

oh, I didn't get that before, but I do now. odd.

a/ -> x/

I see the problem now. Or at least a problem: If you 'do the same 
script multiple times in the console, the system/script object depth 
increases.

another note: parent equals none the same time as the script header 
does, so to properly check whether you really don't have a parent, 
if you want to see the header, you should check parent/header, not 
just parent.

No, the script object depth only increases if the script depth increases. 
When a script ends, system/script is set to system/script/parent.

ok, now I'm wondering why the script depth would increase.

Is the script calling itself, or does it return and have an outer 
trampoline script call it again?

Or is the script creating some functiona and objects and returning 
so the caller can use them, then being reloaded by the caller to 
do this all over again? I wrote a server application in 2000 that 
acted that way, with scripts migrating the data from the previous 
incarnation still in memory.

the script calls 4 other scripts once. one of these contains an object 
that must know the name of the launched script. that's basically 
all.

Does the object need to know the name of its own script, the calling 
script, or the script that is calling the code in the object?

it needs to know the name of the launched script. there can be any 
number of levels down to the script that was used to launch the script 
containing the object. but I have solved the problem now. I was just 
wondering why the script object depth increased on each run of the 
main script.

Any maths guys here?

I need to map a pair from one coordinate system to another.

So, I have two pairs initially, specifying a top left and bottom 
right.
eg. 4x26 => 38x729, and 234x355 => 600x62

So, I need a function that works like this

remap 4x26 38x729 234x355 600x62 n1xn2
=> n3xn4


that is, it takes the 2 sets of pairs as argument, and a new pair, 
and returns the value of the new pair mapped to the new coordinates.

I guess it's just linear algebra

What I am doing is taking two sets of pairs on a PNG image, and trying 
to map to the EPS image as postscript coordinates.

Probably not something as simple as this, though, eh?

remap: func [a-ul a-br b-ul b-br pt] [
	res-x: pt/x / (a-br/x - a-ul/x) * (b-br/x - b-ul/x) + b-ul/x
	res-y: pt/y / (a-br/y - a-ul/y) * (b-br/y - b-ul/y) + b-ul/y
	as-pair res-x res-y
]

(untested)

looks close , but not right though as if i feed it one of the first 
two pairs, it should display one of the second pairs

>> remap  4x26 38x729 234x355 600x62 4x26
== 277x344
but that should be 234x355

>> remap  4x26 38x729 234x355 600x62 38x729
== 643x51
and it should be 38x729

Ah, I thought you would feed it 0x0 to get, e.g., the UL corner.

I mean 600x62

So the point is the coord in the first rect and returns the "equivalent" 
point in the second rect.

yes

but the second rectangle uses a different coordinate system.

ie. in the first, 0x0 is top left as in vid, but in the second, 0x0 
is bottom left as in postscript

Ahhhhh. I see now.

but I can't use 0x0 as the image is offset from there in both instances

so, I'm using the actual points where the top left of the image starts 
and the bottom right where the image ends ... surrounded by a little 
whitespace

; How about something like this:

remap: func [a-ul a-br b-ul b-br pt] [

 res-x: (b-br/x - b-ul/x) / (a-br/x - a-ul/x) * (pt/x - a-ul/x) + 
 b-ul/x

 res-y: (b-br/y - b-ul/y) / (a-br/y - a-ul/y) * (pt/y - a-ul/y) + 
 b-ul/y
	as-pair res-x res-y
]
remap 4x26 38x729 234x355 600x62 4x26
remap 4x26 38x729 234x355 600x62 38x729

Wow !

passes the first tests :)

I'll plug her in and see if it works ...

I think it's working :)  Thanks Gregg.

(don't forget to declare locals res-x and res-y)

Glad to hear it Graham. Thanks for catching that Anton; quick hack 
you know. :-\

I was wondering why this happens:


>> a: does [try [2 / 0]]
>> a

** Math Error: Attempt to divide by zero
** Where: a
** Near: 2 / 0
>> try a

** Math Error: Attempt to divide by zero
** Where: a
** Near: 2 / 0
>> error? a
** Math Error: Attempt to divide by zero
** Where: a
** Near: 2 / 0



Whereas when ERROR? is put inside the function, it catches the error 
properly.


>> a: does [error? try [2 / 0]]
>> a
== true



Is returning a value or an error considered an extra step that causes 
ERROR? not to catch the error in time?

sorry, couple of malformed lines in the above example. I hope you 
can read it.

'try returns "armed" error. That's why there is 'disarm function

>> a: does [try [2 / 0]]
>> disarm a

** Math Error: Attempt to divide by zero
** Where: a

** Near: 2 / 0

I'm just wondering what is happening at the moment of value return. 
There must be an extra step.

The armed error! value is very "hot". error? is the only function 
able to trap this error! value.

is it possible to embed/serialize binding information? I have a fairly 
complex object where functions in it are supposed to be bound to 
their parent context, but when loading, they are bound to 'system 
(or nothing). to solve this, I manually rebind every function, which 
seems rather clumsy. is there a more direct way?

; I'm not sure you can bind whole objects, but you can at least make 
short work of the manual process.  Here's a quickie I've used:

reconstitute: func [object [object!] /local bindings][
	append bindings: [] object
	foreach word next first object [
		switch type?/word word: get in object word [

   function! [foreach context bindings [bind second :word :context]]
			block! [foreach context bindings [bind :word :context]]
			object! [reconstitute :word]
		]
	]
	remove back tail bindings
	object
]

is there an in-memory version of save/header "" header-obj ?

save/header data: #{} "" [Title: "Data"]

probe to-string data

thanks

(still reviewing your previous answer, so I'm not just thanking you 
for that ;-))

On the previous answer, you could probably modify it to incorporate 
objects nested in blocks.  Also, it does not reconstitute some of 
the subtle uses of nested objects, such as the reusable 'feel objects 
in faces.  Sadly.