World: r3wp

I see a strange bug with the REBOL/View included in the latest SDK 
of 5-Dec-2005. The following code produce a linear gradient in earlier 
versions of View (as it should), but it gives me a radial gradient 
in the SDK View:

FillType: make object! [
	grad-mode: 'linear
	startpos: 20x20
]

img: make image! 100x100
draw img	[pen none fill-pen FillType/grad-mode FillType/startpos
		0.0 100.0
		0.0 1.0 1.0
		0.0.0 255.255.255 0.0.0 255.255.255 0.0.0
		polygon 20x20 80x20 80x80 20x80]

view layout [image img]

Funny thing is, that if
FillType/startpos
is changed to
20x20
the gradient will become linear.

Conclusion so far is, that the DRAW command only can handle one object-reference!?

Help!
(This is crusial for me to continue Canvas RPaint development.)

*crucial*

To be more precise: is it a bug?

if replacing the actual values works, i'd say it's a bug.

Is 'linear the default for gradients? i.e. are the objects being 
de-ref'd correctly at all? I haven't tried this in the new View, 
so I'm not sure how lookups are evaluated. Does it work if you use 
COMPOSE?

'radial is default (it seems). I indicate 'linear in the FillType 
object, and it does linear gradient, if that't the only value, I 
use by reference. If I have a second value by reference (FillType/startpos 
in stead of writing 20x20 directly), then gradient change to radial.

Notice! This behaviour, I describe, is ONLY with the REBOL/View included 
in the SDK of 5-Dec-2005!

I would like to use this precise View, because it has many DRAW bugs 
fixed, but make this new one.

Can you use COMPOSE? And does that work around it?

I have to test later, when on my windows PC. Thanks for the suggestion, 
Gregg. :-)

Gregg, yes, if I do a compose as in:

compose [pen none fill-pen (FillType/grad-mode) (FillType/startpos) 
...

then it work correctly. So that is a possible work around. It must 
be a bug, and I'll report it to RAMBO.

It's also worth noticing, that the bug is only there, is the 2 variables 
(grad-mode and startpos) are inside an object. If they're defined 
as stand-alone variables, it works too. So it's a problem with combinations 
of objects and DRAW.

I think that has to do with evaluation constraints then. That is, 
DRAW will get words, but not do further evaluation (kind of like 
CONSTRUCT), so it's safe.

I'm trying to use the 2.6.2 version of enface from the SDK to encap 
a Rebol script I used to encap with rebolve, but I get the following 
error:

Set-Net not provided.
** Script Error: stylize has no value
** Near: stylize [
    wmtxt: text "Test" 255.255.0 font-size 16
    wtext: text " " 640 as-is no-wrap black white
    box: box...
** Press enter to quit...

Any ideas?  It also didn't support 'insert-event-func.

you haven't included all the necessary files.

Aha!

I guess I was expecting they were all included like with rebolve.

you have to explicitly include all the necessary source files

How does one ascertain which source files contain which functions?

prot.r includes all the protocols

view.r includes all needed view stuff ( I think )

and there's another for mezz.r

you can edit these to rip out the stuff you don't need.

Thanks Graham!  I have it up and running now, but it isn't working. 
:-(

I'll have to debug now to handle whatever changed in Rebol to cause 
it to stop working.

Just curious if the sdk package located at http://www.rebol.net/builds/sdk/
requires a newer license.key file?  I already own SDK but this one 
seems to tell me to put my license file in the correct directory 
when I try to run it and I have dropped into every directory I can 
think of.

If it requires a newer one then anyone know how much it cost them 
to simply upgrade their license file?

I am concerned that REBOL would require me to buy another one shortly 
afterwards.

Paul, my license key still works.  I'd contact RT to see what's up.

You just need to put it in the directory where the executable is 
located (at least that's what I did).

Ok will do. How old is your license.key - when do you think you initially 
purchased SDK?

Jan. 14, 2002.  But I used to work at RT so I may have a different 
license key than what you purchased.

Yeah that is true.  Thanks Bo.  I got an email into Cindy currently.

I guess this would be good to post in RAMBO for the future.

My old lisense works with last SDK (license from end of 2004 IIRC)

Same here.

It was a strange problem I think.  I think I had a pro key and an 
sdk key - that is my only explaination for the problem because Cindy 
sent me a copy of my original SDK download and that key worked on 
the newer one so I think I may have been using the wrong key file.

The main problem I have with the SDK is that it makes it harder to 
find bugs. Does anyone have any idea what is causing this error message:

** Script Error: bind expected known-word argument of type: word
** Near: ctx-text: context bind ctx-text system/view
** Press enter to quit...

you can optionally output your prerebol source and run that.  then 
no question of encap being involved.

louis, my guess is that the encap version you are running is older 
than the version that code is expecting. (bind allowing objects is 
a rather new thing)

JeffM wrote in Core:

Can REBOL/SDK define functions that will be called from C and passed 
to a C function? For example:


c-logger: make routine! [ "Define the callback function for error 
tracking."

    logger: [string!] "using string! since a function ptr is just a pointer"
    return: [integer!]
] my-lib "C_Logger"

rebol-logger: func [s] [ print s ]

c-logger :rebol-logger

; Try this:

c-logger: make routine! [ "Define the callback function for error 
tracking."
    logger: [callback! [string!]] ; Here is the fix
    return: [integer!]
] my-lib "C_Logger"

rebol-logger: func [s] [ print s ]

c-logger :rebol-logger

Be careful though: The current implementation of callbacks in REBOL 
limits you to defining 16 per REBOL process. I'm not sure whether 
it is the making of the routine or the calling of the routine that 
establishes the callback though, so test to be sure. Most scripts 
I've seen use callbacks for logging, like your example, and so only 
call the routine once. Once the callback is established, there shouldn't 
be any limitation to the number of times the C code can call the 
REBOL function, in theory.

The rebol function must complete before the C function tries to call 
it again - or there will be fireworks. Even a short rebol function 
can take 40ms to complete (for example), and if the C function tries 
to call it every 20ms that will stuff up the rebol interpreter.