World: r3wp

Please lets not make the mistake of using C precedence for basic 
ops. It will slow rebol.

and using parens work anyways.

Petr, about custom types, probably yes, but I don't think this has 
been decided yet; In case we have them, i think that at least TO 
needs to be implemented as a multimethod; then having multimethods 
in general might make sense... but I don't think this is going to 
be very high priority (there are more important things).

Gabriele, that was very interesting insight into the action dispatch. 
Hmmm... I guess the code-breaking aspect of swapping select's arguments 
as well as the fact that the interpreter would probably be slowed 
down sways me against the idea.

(I seem to remember this very discussion some long time ago...)

Carl... your speeding in your Blog REBOL 3.0 ...Give us time to think 
through your idea's ;-)

Rebolinth - the speed of blog is ok, what I wonder though is, how 
fast rebol 3 development can go, if there is so many ideas floating 
around :-)

Any information about how L10N & I18N will be implemented in REBOL 
3. Thanks.

I18N is partially discussed in the Unicode group, I'm not sure it 
has come up on the blog other than it being a goal, as with L10N...

I don't think there is a group here specifically geared toward localization, 
though I know it's a well discussed issue...

From the Roadmap: "Greater Locality Support 

It's time for REBOL to do a better job at supporting native languages 
and character-sets. Our goal to expand support with locality and 
unicode enhancements. In addition, it is a goal to release 3.0 with 
French, Italian, and perhaps one/two other languages as part of the 
standard distribution."

Yes I thought that that was a strange move... French and Italian..I 
can understand Localisation towards French and Spanish though.. and 
perhpas Asian or Arabic..but what is so special about Italian? (Many 
rebol projects in Italy perhaps?)

Gabriele   ;-)

the fact that i can do the translation :P

i.e. it can be in earlier. others will need community support.

Gabriele - what way in will locale support be done? Will there be 
support for more things, like locale setting for floating point - 
dot or comma, money representation char, etc. ?

Pekr: this is already solved in current REBOL I think - you can use 
both comma and dot for ffloating point and you can put anything before 
the money sign so you can have Kc$24,50 and so on.

ok, but no centralised container to keep locale related values in 
one logical group ...

My current job is localisation engineer working on some big software 
and I must say that current localisation/internalisation state is 
total mess. How do I miss good old Amiga catalogs! Such a simple 
idea and still not adapted on Windows. We do patch dlls directly...terrible. 
So I hope R3 will bring something like Amiga Localisation System.

hopefully so .... and you can probably send it to feedback, Carl 
told us he is checking feedback for suggestions ...

the Amiga way is the rough plan.

Is anyone intersted in improving the library interface in R3? I have 
a lib dialect (just posted to REBOL.org), and some notes I'll post 
here. Is it worth some time to put suggestions together for RT, or 
is everyone OK with the existing system?

The current library interface is servicable, but could be improved.

For example, char arrays in C structs are a real pain to deal with,

there is redundancy if you're importing a number of routines, from 

the same library, and extra work is required to deal with pointers
to values.

The biggest issue for me seems to be that I have to use COMPOSE 

heavily to get the results I want, or there's a lot of duplication
in struct and routine defs.

--- Easier Routine Declarations

The only thing I've addressed in my lib interface dialect is
making it easier to declare routines. I posted it to REBOl.org
for discussion:


http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=lib-dialect.r

--- Pointers


This is maybe a bit of an extreme example, but I had to do it, so 
it's not purely theoretical.

    LPINT-def: [value [integer!]] none

    LPINT: make struct! LPINT-def none

This struct shows where a nested struct is needed.

    _FAX_JOB_PARAM-def: compose/deep/only [

        SizeOfStruct    [integer!]      ; DWORD structure size, in bytes

        RecipientNumber [string!]       ; LPCTSTR   pointer to recipient's 
        fax number

        RecipientName   [string!]       ; LPCTSTR   pointer to recipient's 
        name

        Tsid            [string!]       ; LPCTSTR   pointer to transmitting 
        station identifier

        SenderName      [string!]       ; LPCTSTR   pointer to sender's name

        ;SenderName      [struct! [value [string!]]]       ; LPCTSTR   pointer 
        to sender's name

        SenderCompany   [string!]       ; LPCTSTR   pointer to sender's company

        SenderDept      [string!]       ; LPCTSTR   pointer to sender's department

        BillingCode     [string!]       ; LPCTSTR   pointer to billing code

        ScheduleAction  [integer!]      ; DWORD job scheduling action code

        ;ScheduleTime    [struct! (SYSTEMTIME-def)]        ; SYSTEMTIME  
          time to send fax
            wYear       [short]
            wMonth      [short]
            wDayOfWeek  [short]
            wDay        [short]
            wHour       [short]
            wMinute     [short]
            wSecond     [short]
            wMilliseconds [short]

        DeliveryReportType  [integer!]      ; DWORD e-mail delivery report 
        type

        DeliveryReportAddress [string!]     ; LPCTSTR   pointer to e-mail 
        address

        DocumentName        [string!]       ; LPCTSTR   pointer to document 
        name to display
        CallHandle          [integer!]      ; HCALL reserved
        ;_PTR   Reserved[3]  [integer!]      ; DWORD must be zero
        _PTR-0  [integer!]      ; DWORD must be zero
        _PTR-1  [integer!]      ; DWORD must be zero
        _PTR-2  [integer!]      ; DWORD must be zero
        _PTR-3  [integer!]      ; DWORD must be zero
    ]
    _FAX_JOB_PARAM: make struct! _FAX_JOB_PARAM-def none
    _FAX_JOB_PARAM/SizeOfStruct: length? third _FAX_JOB_PARAM

    fax-complete-job-params: make routine! compose/deep/only [

        JobParams     [struct! (LPINT-def)] ; ptr to job information struct

        CoverPageInfo [struct! (LPINT-def)] ; ptr to cover page struct
        return:       [integer!]
    ] winfax.dll "FaxCompleteJobParamsA"

So, the API call returns pointers to structs containing the 
data we want; to get it we need to dereference the pointers
after the call.

    complete-job-params: func [
        /local
            params-ptr cover-ptr    ; API return pointers

            params cover            ; REBOL structs with data from API
    ][
        ; allocate return pointer structs for API call
        params-ptr: make-LPINT
        cover-ptr: make-LPINT

        ; make the API call

        reduce either 0 <> fax-complete-job-params params-ptr cover-ptr [

            ; get data from pointers returned by the API

            params: get-dereferenced-data params-ptr _FAX_JOB_PARAM-def

            cover:  get-dereferenced-data cover-ptr  _FAX_COVERPAGE_INFO-def
        ...



Getting the de-ref'd data is the real pain, and seems like it might
be unsafe in the way I did it, though it worked.

    get-dereferenced-data: func [

        {Given a pointer to memory, copy the target data into a REBOL struct.}

        pointer [struct!]   "LPINT structure whose /value is the data pointer"

        struct-def [block!] "The struct you want returned with data"
        /local struct data orig-pointer result
    ] [

        struct: make struct! compose/deep/only [ ; make wrapper struct
            sub [struct! (struct-def)]
        ] none

        orig-pointer: third struct              ; store original inner pointer

        change third struct third pointer       ; change inner pointer to 
        ref'd data

        data: copy third struct/sub             ; copy data from the inner 
        struct

        change third struct orig-pointer        ; restore inner pointer

        result: make struct! struct-def none    ; make result struct

        change third result data                ; change data in result struct
        struct: data: orig-pointer: none
        result
    ]


--- char arrays in structs, or as routine parameters

You can't just declare a fixed size block or string to do this, 
you have to (AFAIK), have individual elements for each item.
That's a huge pain if you have a 128 element array, so I end
up generating them dynamically. I think that was Cyphre's idea
originally, but I don't have notes on it.

    make-elements: func [name count type /local result][
        if not word? type [type: type?/word type]
        result: copy "^/"
        repeat i count [
            append result join name [i " [" type "]" newline]
        ]
        to block! result
    ]

    GUID: make struct! GUID-def: compose [
        Data1   [integer!]  ; unsigned long
        Data2   [short]     ; unsigned short
        Data3   [short]     ; unsigned short
        (make-elements 'Data4 8 #"@")  ; unsigned char
    ] none


--- MAKE-ing structs

How do other people make structs from prototypes? 

    make-struct: func [prototype /copy /with data] [
        make struct! prototype either copy
            [second prototype]
            [either with [reduce [data]][none]]
    ]


--- BSTR type

I've only needed it for one project, but it might be worth 
finding out if it would be worth adding BSTR support for
Windows, as a routine datatype.

in the best of worlds I'd prefer it if we could read all the info 
from a .h file and convert it into a rebol file ready to load the 
dll...
Gregg, Do you think this is possible?

Max, you want a C pre-processor. Lots of work. I think something 
like swig will be easier.

I did a .h file parser a long way back... it was able to find and 
extract function names... but did not tackle the structs....

swig?

couldn't we just base a preprocessor based on something already on 
the net?  arent' there some grammar-based C pre-processor a PARSE 
guru could convert into a dialect?

Well it sort of works. SWIG is what a lot of languages use.

Problems that arise with preprocessors is the expansion of #define 
and three traversals.

I think extracting the API of .h is the easy part, but sometimes 
the API use macros and these are the hard part. They can be nested 
macros.

When i onceneeded header-fields, i wrote a little program to output 
themand run it.
  print("%i",(&p.selector - &p));

Is there a particular reason why the left hand corner in draw is 
0x0, and not the bottom left corner?

It's the point with the first address. Traditional bitmaps on screen 
are addressed from top-left to bottom-right.

CRT beams from the top..to bottom..

so, fairly arbitrary.  It would be good if that could be user selectable.

is there a reason why we want to start the origin elsewhere?


From most daily activities, origin for drawing , writing, reading, 
tends to start from top-left.

for postscript compatibility :)

for graph drawing.

Gregg - in RT QA channel Gabriele once put answer from RT, that there 
is definitely big plan for library interfacing improvements, plus 
much more .... well, we just don't know yet, what Carl has in mind 
....

I made a .h header file parser, which handled function names, typedefs, 
structs, and enums. It was made specifically for FMOD and FMOD EX 
libraries, but it is pretty general, able to be tuned for other libraries 
"fairly" easily.  Swig is probably the ultimate way, though it's 
not as easy as it sounds on the cover, and you might lose associtated 
documentation found in comments next to functions, struct elements 
etc.

I think with Swig you still need to be prepared to dive in pretty 
deep and swim around tying things together for a while.

I've done some little C processor dialect ideas as well, mainly to 
handle DEFINEs and convert structs to REBOL friendly data. I think 
those kinds of tools are useful and, for the amount of use they get, 
I prefer that approach to trying to do a complete C processor/loader. 
Ultimately, that might be good for some people, but I still want 
an interface dialect in REBOL that makes things easy to read and 
understand from a REBOL perspective. I think "dialect first, then 
tools".

I'm also willing to accept tradeoffs. I'd rather have a tool that 
can handle 80% of common C files, than to say it can't be done because 
of the other 20%.

For anyone who has written these kinds of tools, should we collect 
them all and see if we can come up with a spec we like, that is better 
than what we have today (e.g. that addresses the things that are 
painful today)? Does anyone want to be in charge?

I'll probably be getting back into C interfacing again soonish, so 
I'll probably have more to say after I refresh my memory on that.

About mezzanines in REBOL 3.

Instead of having hundreds (or thousands) of mezzanine functions, 
will it be a good idea to put those in includes? Problem with lots 
of mezzanine functions is, that programmers might have their own 
similar words, that then redefine the default ones.
(The same can be said with natives, of course.)

Or to look at it in another way:

It might be a good idea to keep the default REBOL vocabulary at a 
minimum and put extra functions (that people want for certain functionality) 
in includes.

Hopefully this will be solved by using dictionaries or namespaces

I too think that modules (namespaces) will solve it ....

Redefining system words:  It's an annoying problem. Geomol, and none 
of us is immune.

(I once debugged a CGI written by Carl. He'd used the info? mezzanine, 
but accidentally redefined the query word that it depends on. The 
results were wierd).
Namespaces should help.

I try to *not* clash with any words by always encapsulating code 
into objects -- so it's not 'query as global word, it's 'utilities/query
Meanwhile; the best we have is protect system.