World: r3wp

How can I convert an integer! value to 2-byte hex binary! value? 
Say, 

>> do-something 15
== #{000F}

Thanks.

>> to-hex 15
== #0000000F

to-binary [15]

Though that method, Petr, is awkward for values above 255:
to-binary [1234]
== #{D2}      ;; not the obvious result!
to-binary [12 34]   ;; need to separate out the bytes

== #{0C22}      ;; each octet is converted separately, so may still 
not be what was expected.

i know - that method was suggested to me by Oldes IIRC. Because in 
other way, that is one of rebol's aspects I don't like and I regard 
it being inconsitent - to-binary 15 - It is a NUMBER, not two chars 
1 and 5, so I don't understand, why it tranlates each char .... it 
should change for 3.0

so the way to go is to use to-hex, but when you need a binary e.g. 
for struct!, you have to compose it, at least I did it that way in 
the past iirc :-) But maybe I am missing something obvious. But if 
not, those things should be looked into fro 3.0 .... as so far I 
like Carl's aproach = willingness for change, if the change makes 
sense of course and improves consistency ....

I got it. The LOAD function is the magic.
 
>> load rejoin [ "#{" to-string to-hex 15 "}" ]
== #{0000000F}


I start to think that LOAD is not only for loading something, but 
also for converting a string to something.

Two bytes:

>> to-binary reduce [(i and 65280 / 256) (i and 255)]
== #{01B0}

>> debase/base to-hex 15 16
== #{0000000F}

>> s: make struct! [val [integer!]] [0]
>> s/val: 15
== 15
>> third s
== #{0F000000}

It's what "be a guru" means ;-)

struct! is byte-order sensitive (different results on PC/Macs), but 
it's the fastest way.

You can use reverse on the result if you need to.

yes - but to have the same code running on both little and big endian 
platforms, it needs some work (when to apply 'reverse)

That's easy, you just set a conversion function at the beggining 
of your app, picking a bigendian or littleendian one based on the 
platform, and then just use it like a black box. A bigger problem 
is that struct! is currently only available on /Pro, /View/Pro or 
/Command, which means that you can't run the code on Mac right now 
anyways. Making struct! available in /Core and /Base has been requested 
though.

struct! is not limited to /Pro. It's available on /View since at 
least 1.2.1 (not license needed). Absence in /Core is a problem, 
as there isn't usable alternatives for float conversion.

It has been aailable in versions of View that can be upgraded to 
View/Pro with a license, even when the Pro features are disabled 
by the lack of a license. However, the struct! type is implemented 
by the library extension, along with routine! and such. Can anyone 
confirm that struct! is available in versions of View that do not 
have the library extension at all, like View for Mac?

it's in View for mac alright...

Which version? it wasn't in View for Mac Classic...

Still, it's not in Core or Base yet. Probably will be in REBOL 3 
though.

works in the OSX version but that one is also built on 1.3

also, since this gets often overlooked:

>> get-modes system:// 'endian
== little

the debase trick is the most portable, although it's slow; still 
better than load rejoin though.

but not for /View 1.2.1 : no system:// port, and debase crashes sometimes. 
A little better than "load rejoin" : 
load join "#{" [to-hex value "}"]

Not sure the best forum to put this on (to where Carl will see it). 
Are there plans in the future for actual bit operations besides and/or/xor? 
RIght now, bit shifting, rotating, etc. are extremely painful (and 
slow compared to what they should be) to do.

rebcode supports shifting; not sure if it makes sense to have a native 
too, maybe yes.

shifting is a very basic operation. I don't understand how it couldn't 
be part of the core, native functions. The same could be said of 
AND and OR, and just make them logical operators instead of bitwise.

well, shifting is very lowlevel, and there are not many use cases 
outside of rebcode.

I disagree, but that's fine. I imagine the majority of those using 
REBOL are using it for non-low level things. I just don't happen 
to be one of them. REBOL is a great language for making domain specific 
languages, and many DSLs would benefit from a little more low-level 
control.

I have to disagree as well. I've bumped into a few examples where 
bit-operations would be very nice to have, if you want to use REBOL 
for prototyping bit-operations in another environment. Afterall we 
can create bitsets, why not allow full manipulation of them?

Well, you can write your own; if just prototyping, the speed isn't 
critical (we did 160 bit math for Maarten, using bitsets, at one 
point). That said, if you can use a version with rebcode, just wrap 
a mezzanine around the ops. 


That said, I wouldn't mind having standard SHIFT and ROTATE funcs 
that can operate on integer, or series values. Bit ops are also necessary 
for implementing certain algorithms.

Here are prototype funcs for SHIFT and ROTATE (plus a couple supporting 
funcs). Is it worth some time to come up with good ones and submit 
them for inclusion in R3?

; used in SHIFT below
    dup: func [value len [integer!] /local type] [

        type: either series? value [value] [either char? value [""] [[]]]
		head insert/only/dup make type len value len
    ]

    ; used in SHIFT below
    make-blank-value: func [type] [
        any [
            attempt [make type 0]
            attempt [make type ""]
            attempt [make type []]
            attempt [make type none]
        ]
    ]


    ; The new PAD/JUSTIFY func might be used to implement this as well.
    shift: func [
        "Shift values in a series; length doesn't change."
        series [series!]
        /left   "Shift left (the default)"
        /right  "Shift right"

        /part range [number!] "Shift this many positions"  ; TBD series! 
        support?
        /with fill "Fill vacated slots with this value"
        /local pad
    ][
        range: any [range 1]
        if any [empty? series  0 = range] [return series]
        pad: dup any [fill  make-blank-value last series] range
        either right [

            head insert head clear skip tail series negate range pad
        ][
            append remove/part series range pad
        ]
    ]

    rotate: func [
        "Rotate values in a series."
        series [series!]
        /left   "Rotate left (the default)"
        /right  "Rotate right"

        /part range [number!] "Rotate this many positions"  ; TBD series! 
        support?
        /local offset pad
    ][
        range: any [all [range  range // length? series] 1]
        if any [empty? series  zero? range] [return series]
        either right [
            offset: does [skip tail series negate range]
            pad: copy offset
            head insert head clear offset pad
        ][
            pad: copy/part series range
            append remove/part series range pad
        ]
    ]

I am trying right now to write a file to an FTP server. What I would 
like to do is:
- open the port 
- try to write the file
- if that fails, create the parent directory if necessary
- try to write the file again
- close the port

The difficult part is keeping the port open.

... and I have my head deep in FTP handler... :)

Ah... figured out how to do that :) The solution is to disable close-on-fail 
in the handler, so that a failure in open does not close the ports. 
This allows the command port to be reused for other commands, such 
as make-dir.

Now to make it nice...

Anyone know how to write to the parallel port ?

I don't know if this will help: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlGBVQ

Gregg says write %//prn .. I'll give that a go.

With image/rgb I can get all the RGB (24-bit) data. With /alpha I 
can get all the (8-bit) alpha data. Is there one to get RGBA (or 
ARGB) so the alpha data is interleaved with the RGB data (32-bit)?

Try to-binary logo.gif

So simple -- like most things with REBOL. Don't know why I didn't 
try that. Thanks.

Not everything is simple - yet...

Like bit shifting. I do appreciate Gregg's functions. However, when 
something that boils down to a single instruction in hardware requires 
6 lines of code and multiple function calls, something is wrong. 
;)

indeed why bit shifting is needed, at least as built in mezzanine 
functions

Hmm.  Does 'send have a forward option?

ie. forward an existing email?