World: r3wp

aha, it looks, that it works even in R3...

Case for which it does not work... - only in ancient versions of 
R2

nevertheless, I see it as a bug, that it works even in R3

That is actually an auto-adjustment test, and I thought, that no 
auto-adjustment was taking place in R3

Nevermind, I will declare it "a feature"

Well, in R3 PAST? is built-in. And auto-adjustment was taken away 
in R3 on purpose, at the same time that PAST? was added.

Yes, but skip :series 0 auto-adjusts still, but, as I said, I do 
not mind

How about the help text? The longer one (currently used in R3) looks 
misleading.

(comparing series index - an integer, to series tail - a series)

It's not misleading without the auto--adjustment. With the auto-adjustment 
a past-tail index will auto-adjust, which should be mentioned somehow.

OK, nevermind, I do not want the text to be longer, a "series is 
past its tail" looks better to me, than any reference to series index

, and it relates to the problem better, since in the case below:

>> b
== ** Script Error: Out of range or past end


what is past tail is just the series not any "series index", which 
should be an integer value, and as such it cannot be "past tail"

I adjusted the http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Series
article to mention the past-tail series and to explain differences 
between series with fast indexed access and series with fast insert/remove 
operations.

Is there a way to find out types of drives present in windows from 
rebol ?

I managed to get list of all drives using read %/.

I would like to know which of those are flash drives or memory cards...

I suppose you need to dig into the registry for that.

This is _a_ way in windows (but you need to be running in admin mode 
.... so not so usefu):
    capture-call: copy ""
    call/output/info "fsutil fsinfo drivetype e:" capture-call
    print capture-call
    == "e: - CD-ROM Drive^/"

FSUTIL or APIs, with the caveat that Sunanda noted.

REBOL []

do %../library-dialect/lib-dialect.r

make-routines [
    lib %kernel32.dll
    def-rtn-type long
    ; returns available drive flags as a bitset (in a long)
    get-logical-drives "GetLogicalDrives"
    get-logical-drive-strings "GetLogicalDriveStringsA" [
        buff-len [integer!]
        buffer   [string!]
    ]
    get-drive-type [drive [string!]] "GetDriveTypeA"
]


drive-types: [
    Unknown     ; 0 We don't know what kind of drive it is
    NoRootDir   ; 1 Probably not a valid drive if there's no
                ;   root directory
    Removable   ; 2 It's a removable drive
    Fixed       ; 3 It's a fixed disk
    Remote      ; 4 It's out there on the network somewhere
    CDROM       ; 5 It's a CD ROM drive
    RAMDisk     ; 6 It's not a real drive, but a RAM drive.
]

drive-type?: func [drive /word /local res] [
    res: get-drive-type join first trim/with form drive "/" ":"
    either word [pick drive-types add res 1] [res]
]

get-drive-strings: func [
    /trim "Return only the drive letters, no extra chars"
    /local len buff res
][

    ; Call it once, with 0, to find out how much space we need in our 
    buffer
    len: get-logical-drive-strings 0 "^@"
    ; Init our buffer to the required length
    buff: head insert/dup copy "" #"^@" len
    ; Make the call for real, to get the data
    len: get-logical-drive-strings length? buff buff
    res: parse/all copy/part buff len "^@"
    if trim [foreach item res [clear at item 2]]
    res
]

;print enbase/base to binary! get-logical-drives 2
foreach id [a b "C" 'c "D" d: %E %F %/F] [
    print [mold :id tab drive-type? :id tab drive-type?/word :id]
]
print mold get-drive-strings
print mold get-drive-strings/trim
print read %/

Is this a bug?

>> o: construct [ a: true b: yes c: yes ]
>> probe o
make object! [
    a: true
    b: 'yes
    c: 'yes
]


http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=47&archiveflag=new

>> o: construct [ a: true b: yes c: on ]
>> probe o
make object! [
    a: true
    b: 'yes
    c: true
]

replied there...

I usually mold/all for such things...
    
o: construct [ a: true b: yes c: on ]
    
>> print mold/all o
#[object! [
     a: #[true]
     b: yes
     c: #[true]
]]

construct should not evaluate .. but it is

true values are a specific special case... they are not evaluated.

construct exiplictely looks for the words none, true, false, yes, 
no   and replaces them with their value equivalents.

So, why is yes not evaluated but true and and on are?

sorry... that would be on, off (not yes no)

probably because Carl forgot to include yes/no into the construct 
special case... its possible he did it on purpose.

No, it's a bug

note, they are not evaluated, even if you replace them with functions 
which have the same word.

works correctly in R3 but not in R2

this is r3

>> a: construct [ a: true b: on c: yes ]
== make object! [
    a: true
    b: true
    c: true
]

Where are r2 bugs posted these days??

still rambo.

Just downloaded 2.7.7 to be sure that the bug is still there and 
it is

yep, it is still there, I use 2.7.7.
I use this function to test:
f: func ['w] [type? get in construct compose [t: (:w)] 't]
>> f yes
== word!
>> f off
== logic!

forum topic is "Careful when Construct an object" on http://rebolforum.com, 
above link goes another topic. (a bug on forum, topic numbers changing)

I posted the bug report

Thanks Gregg!!! It works just the way I need it to work :)

The yes and no keywords of R3's CONSTRUCT were added at my request. 
We'll have to see whether the enhanced function can be backported 
to R2 safely. There are other changes as well, mostly safety changes, 
and a CONSTRUCT/only option that turns all of the tricks off.

Bug#651 details the changes - yes and no keywords, and unset-to-none 
translation - and bug#687 explains CONSTRUCT/only.

We'll have to see if there is any R2 code that will be broken by 
the change; if so, it won't happen. As a rule, backwards-incompatible 
changes are only made to R2 when they can be proven to not harm legacy 
code. There have been a few exceptions, and at least one mistake 
that predated (and inspired) the rule, but the exceptions have all 
been added functionality that doesn't change old functionality that 
is relied on in code. If nothing relies on yes and no not being keywords, 
or unset! values not being translated to none, then we're cool. As 
a counter-example, CONSTRUCT/only could be backported without question 
because it's a new option.

One caveat to new options: Once APPLY is backported (planned for 
2.7.8) then new options will need to be added to the end of the options 
list of functions, not in the middle. APPLY is positional when it 
comes to options.

This is already a concern for those using the R2/Forward backport 
of APPLY.

What is the easiest way to prevent sub-object sharing? I have very 
simple but nested XML structure, and I want to put records into objects. 
But I have one subobject. I want to have prototype object (class) 
and create instances filled with data, but I want to avoid subobject 
sharing ....

simply put: proto: context [name: none address: context [street: 
none]], and now I want to make instances, but those should not share 
address subobject ...

You're going to have to clone the subobjects, eg.
	instance1: make proto [
		address: make address []  ; Clone object to avoid sharing.
	]

Just define your own constructor, that is all

Ah, thank you very much ... I thought I could somehow avoid that, 
but that's ok ....

I put an init function in the class, and do any stuff there, then 
its much easier to manage.

a: make class [init]