World: r3wp

gcc 4.4.2, as cross-compiler

how can I get a specific version of gcc?  AFAIK mingw's online systems 
allow only an old 3.xxx version or the latest 4.5 which doesn't compile 
rebol at all or crashes it.

what os?

linux, via wine

ok, your compile also crashes  on my system... strange!


we need others to test this.... please, if you have a running r3 
A107 try it out so I make as precise a ticket as I can.


if it doesn't crash, download the file and try to add a few (or many) 
draw commands to it so see if it fails at some point.

I reported the LOAD issue mentioned above as bug#1651: 

http://www.curecode.org/rebol3/ticket.rsp?id=1651

Maxim, I get a crash too if I comment the first load and uncomment 
the second. This is with a107 compiled with the MS compiler.

Windows 7 64 bit

What's the point of SYSTEM/CATALOG/ERRORS/:CATEGORY/CODE , how is 
supposed to be used and what are it's limits? 

I've noticed that you can't extend SYSTEM/CATALOG/ERRORS with your 
own error category if that is defined with an code of 997 and above 
in R3:


>> odbc: make object! [code: 996 type: "odbc error" no-handle: [""] 
cannot-connect: ["Cannot connect to" :arg1 "because" :arg2]]     
 ; define my own error category

>> extend system/catalog/errors 'odbc odbc   ; extend standard errors 

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]

** odbc error: Cannot connect to "CACHWEB Samples" because "no such 
DSN"

>> system/catalog/errors/odbc/code: 997   ; too high an error code

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]
** Script error: invalid argument: [
    type: err-type
    id: err-id
    arg1: first args
    arg2: second args
    arg3: third args
]
** Where: make cause-error
>> system/catalog/errors/odbc/code: 996

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]   ; back to normal

** odbc error: Cannot connect to "CACHWEB Samples" because "no such 
DSN"


R2 seems to not pay attention to the error code, at least it doesn't 
choke on values of 997 and above. That limit in R3 seems to be somewhat 
arbitrary?

TL;DR: You can't create error categories of error codes above 996, 
is there a reasoning for that?

Slow progress on your ODBC protocol?

It isn't a protocol yet but rather has a module/function API. ODBC 
database access is working for me as a Windows only host kit extension, 
with UTF8 strings and bound parameters. I'm in code cleaning stage 
and I'm about to support SQLTables and SQLColumns catalogue API functions. 
Sadly, it won't be possible to use it with DATE! values for long 
(see curecode). And, yes, I'm thinking on supporting some ODBC errors 
in their own error category. There are no best practices known to 
me on how to do that, though.

Any example of how rebol can talk to MS Outlook?

Write an email to it? :)

At least that. Close.

If Outlook as a COM interface, you can use that

it does and works using Aton's com lib

Thanks. Found this: http://anton.wildit.net.au/rebol/os/windows/COMLib/

If you need it to be robust, and talk to mtuliple versions of Outlook 
(e.g. used by others who may have a different version), consider 
using Redemption. It is robust and well worth the money IMO.

The above lib fails. Next, Redemption.

I know that a companny has built a full integration to outlook supporting 
more than a single version of outlook... AFAIK they used Anton's 
com lib .

florin, it might just be a config issue.   did you get the comlib 
to do anything within excel?  IIRC Anton's comlib has a few examples 
for excel and word.  getting that to work first will make outlook 
attempts a bit easier.

actually the integration was for an exchange server, but it goes 
through outlook IIRC.

(Did they really? -- Gosh...)

Would COMLib allow me to mess with internet explora...for example: 
insert urls into the address bar to change the website viewed without 
having to open another tab or window?

in theory yes.

Dumb question: How is it that I solve this?

>> set to-word "a" 2
** Script error: a word is not bound to a context
** Where: set
** Near: set to-word "a" 2

There's probably some easier way than this, I hope:

>> x: 1
== 1
>> set bind to word! "a" 'x 2
== 2
>> a
== 2

ok, thanks

wow rebol has become perharps a bit too picking about binding?

did someone forget that REBOL is supposed to be "simple" ?

picking = picky

LOAD loads and binds strings except being told otherwise with /UNBOUND:

>> set load "a" 2
== 2
>> set load/unbound "a" 2
** Script error: a word is not bound to a context
** Where: set
** Near: set load/unbound "a" 6

I don't think it's especially picky the way this is.

I understand how it is... its just that in R2 to-word bound things 
to "global" context by default.

because we now have unbind and generally much more control over the 
binding, I would have thought that auto-binding to user context wouldn't 
be such a big issue.

it used to be an issue because we could not unbind.

May I withdraw my suggestion? Don't use is in tight loops:

>> dt [loop 100000 [set load "a" 2]]
== 0:00:02.017813

>> dt [loop 100000 [set bind to word! "a" 's 2]]
== 0:00:00.079424

hehe

;-)

well, then there has to be a better way to do that. some kind of 
default-bind.

I just discoverd this func...    

utf?

in some fonts the u looks like a w... hehehe

set bind/new to word! "a" self 2
or
set bind/new to word! "a" system/contexts/user 2

Max, it's a dialect: 'ut th' fu'?

Though perhaps we could have a WTF? error-related func.

A refinement for SET might be very handy for the unbound scenario, 
and BrianH may chime in with the design logic to help clarify.

yes.... wtf? as a small undocumented easter egg could be a nice little 
rebol detail   :-D   

basically it could be an alias for why?

Maybe combined with a stack dump? That is, when you say WTF? you 
need all the help you can get. And the refinement for even more info 
would be /!. ;-)

we should find refinements for:

WTF?/$/!/@/*/

;-)

hmm... refinements are case sensitive?

>> txt
== [Errors: 0 Warnings: 0 Outputs: 1 Skipped: 0]

txt/errors
== 0

txt/Errors
== none

That is very strange and makes me wonder why I haven't been tripped 
by this BTW, you're talking path notation here not refinements. With 
function refinements it seems to work as expected.

>> test: func [/a] [all [a 'a]]
>> test/a
== a

>> test/A
== a

>> test: [a 1 A 2]
== [a 1 A 2]

>> test/a
== 1

>> test/A
== none


This is dowright unexpected, I'd consider it a bug, what do you think? 
You'd better curecode this, I guess.