World: r3wp

seems to be missing by a day here...

oh, well. I'll see what the customer says :-) many thanks!

Send me test cases that fail and I'll try to make it right.

I will. Perhaps you should add it to the code snippet check list?

Feel free.

done

Thanks.

Is there a loader for Targa images (.tga)? Does it require a license 
to support the Targa format? Does anybody know?

I need a REBOL->C converter. I spend hours programming in C to do 
something, it'll take minutes to do in REBOL.

R3 runs as a DLL......Car showed his basic development C script at 
DevCon.

It was abouy 12 lines of C, the heart of it being a call to REBOL, 
passing a string to be DOne.
That may be all you need to run REBOL from C with R3.

It's not actually that, I'm after. In this project I need all the 
speed, I can get, so I do it in C, but it's a lot of time spent. 
I was thinking about a dialect in REBOL, that can be converted to 
C and compiled. That way it should be possible to produce C source 
a lot faster, than I do now.

Something like:
[img: load-image/tga %gfx/image.tga]

The converter should then convert that to a lot of C source, that 
I can compile with gcc.

I wrote a dialect that is converted to C and compilable. It just 
covers basic math operations though, as that was all I needed. No 
pointers stuff and so on. But if you're interested to expand it, 
I can publish it somewhere (not sure how ugly the code is, didn't 
touch that in year or so).

Rebolek, thanks for the offer, but I haven't got the time right now. 
Maybe it'll be a good idea to take this idea up, when R3 is released 
with rebcode. Then it'll be the right time to check the possibilities 
regarding performance.

geomol, if you don't have much time, try D, or Scheme, or any other 
high level compiled language. they're still better than C :) otherwise... 
you'll probably have to code it yourself.

D is a good language.

See http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=view-html.r
for
a little blurb on D.  It is a good language...

Is there a way to change the format of to-date?  In oracle you can 
specify to-date(field, 'MM-DD-YYYY') and I need to read in a lot 
of dates that are in MM/DD/YYYY, but to-date assumes it's DD/MM/YYYY. 
 I also have dates that are Month DD, YYYY.

This will cover mm-dd-yyyy format, but you'll need to add another 
support func for the last format you posted:

parse-simple-date: func [
	"Parse a string containing a date value; return a date! value."
    date [any-string!]

    /def-day def-d [integer! word!] "Default day for mm/yyyy format. 
    Number or 'last."
    /local dig sep d m y set-def-day tmp-dt
][
    dig: charset [#"0" - #"9"]
    sep: charset " -/."
    set [d m y] none
    set-def-day: does [
        d: any [
            all [integer? def-d  def-d]
            all [
                'last = def-d
                foreach fld [d m y] [set fld to integer! get fld]
                tmp-dt: subtract make date! reduce [1 m + 1 y] 1
                tmp-dt/day
            ]
            1
        ]
    ]
    ; assuming mm/dd/yy or mm/yy format
    ; Do we really want to use PARSE/ALL here?
    either parse/all date [

        [copy m 1 2 dig  sep  copy d 1 2 dig  sep  copy y 1 4 dig]
        | [copy m 1 2 dig  sep  copy y 1 4 dig  (set-def-day)]
    ][
        foreach fld [d m y] [set fld to integer! get fld]
        ; add century if necessary; window from 1926-2025
        if y < 100 [y: add y pick [1900 2000] y > 25]
        ; swap day and month if it makes sense
        if all [m > 12  d <= 12] [set [m d] reduce [d m]]
        make date! reduce [d m y]
    ][none]
]


set 'date-val func [
	"Do everything possible to convert a value to a date."
    date

    /def-day d [integer! word!] "Default day for mm/yyyy format. Number 
    or 'last"
    /local res
] [
    if any-string? date [trim date]
    any [
        all [date? date  date]
        parse-simple-date/def-day date any [d 1]
        attempt [to date! date]
    ]
]

Thanks!

D seems to have garbage collection. Then it isn't for this project, 
I'm doing. I can't have the computer having hiccups, because the 
garbage collector does some cleanup.

I'm ok with C for now. I was just pointing out, that REBOL dialects 
producing C source could be very useful for some kinds of programming 
problems. When I got the time ... ;-)

Geomol;  You can use std.gc.disable() for smooth runtime, and std.gc.enable() 
when 
and or if you want to turn the garbage collector back on.

See http://www.digitalmars.com/d/memory.html#realtime

They've thought about it! :-) Neat.

Yeah, my exposure to D is less than a month old, but I'm becoming 
quite a fan of
Walter.

How widely spread is it? Compiler for OS X, handhelds, alternative 
OSs? Does it speak with OpenGL and GLUT? What support of sound?

Umm, my exposure is still cursory.  But it's been working great under 
GNU/Linux.

Samples are sparse, but building.  iirc, the first release was January 
2007.
OS X support with through a gcc front/back end

Supports standard C lib conventions.  Links to all libs if I read 
that part correctly.  There

may be some import sequences to work out if it hasn't been done already.

Can someone explain why this function returns none?

foo: func[a[integer!]][switch[a][ 1["one"] 2["two"]]]  If you change 
it to switch[2] it will always return "two", so why doesn't the switch 
work when using a parameter?

switch value [ val1 [ ] val2 [ ] ]
and not switch [ value ]

anyone got any timestamp routines ?  digits only - no alpha - eg 
seconds since a partciular time?

ah... just use 'difference

you mean... difference now (wait 0:0:1 now) ?

just need to create sequential unique ids

btw... this is my favourite example of non compilable Rebol code: 
 b: [a b c] b/(print length? read http://rebol.comrandom 3)

b: ["yes" "no"] b/(exists? http://rebol.com)

but maybe it is compilationable

b: pick [[print "he"] [print "ho]] random 2
; ...
f: does b
; ...
f

now try to change the meaning of PRINT after the f: does b line, 
or maybe change DOES so that b is interpreted as a dialect...

see, for how smart the compiler would be, it would still be "interpreting" 
(or compiling and using the compilation result just once - which 
is the same) most of the times.

it's much easier to just have a compilable dialect that is used in 
tight loops and so on.

a simple not-compilable code example :  a/b

with 'a defined at runtime, could be object!, function!, string!, 
block!, etc...

Compilation doesn't necessarily mean ahead-of-time - it could be 
at runtime or function creation time. Type inference could handle 
a/b.

well, but the meaning (and so the datatype) of 'a and 'b can change 
during runtime, even a JIT can have a hard-time tracking those changes, 
don't you think so ?

it seems current JIT technology has become quite agile, as per Jaime's 
claim previously...

JIT inspects stuff prior to compilation, so I guess it will just 
remember to identify stuff and just make sure double infering is 
handled properly.