World: r3wp

Note: I am not sure, whether this would work with ports and gobs, 
though, since I do not know, whether SAME? behaves similarly for 
them

Ladislav, it needs to work in the case of auto-adjusting indexes 
too.

Auto-adjusting is broken in the case that Henrik mentioned. As a 
separate issue, the case Henrik mentioned has *better* behavior, 
because the whole idea of auto-adjusting is a bad one, so it not 
working is an improvement.

But because of that, the PAST? function for R2 needs to work whether 
the index auto-adjusts or not. So before you submit another version, 
test it against past-tail references with auto-adjusting indexes. 
If it works then, it works.

To get a past-tail reference that auto-adjusts, clear from the head 
of the series rather than from further along.

why didn't you try? it works

every past-tail series auto-adjusts in ceratain interpreter versions 
(in other no past-tail series auto-adjusts), no exceptions

Henrik does not know any series that does not auto-adjust, it is 
just your error

(you just need to read above)

Note: all versions work just in (auto-adjusting) R2

I am mentioning that, since there were some versions of R2 that did 
not auto-adjust

(long time ago)

But, it is possible to write a modified version, which would work 
regardless of auto-adjustment

In 2.7.7, indexes auto-adjust if you clear the series from the beginning, 
but not if you clear from later on. In the same interpreter.

Wrong, see above

You did not check Henrik's example as I did

I did, but got different results than I am getting now.

Actually, you did not, it was just an error

With the same code, no less, I am getting different resulta now.

I didn't post the the old results.

You are getting the same results you got before, it was just your 
error, resulting from the fact, that auto-adjustment adjusts past-tail 
series to tail indices, i.e. to 2 in case Henrik posted

Nevertheless, it is easy to write code that would work regardless 
of auto-adjustment

(which means, it would work in R2, old R2, and R3)

Well, I don't know why the results are different from the same code, 
but your code works now, so if it's alright with you I'll update 
R2/Forward with it.

I'll just chock up the old results to a momentary glitch until they 
recur.

E.g. this modification works regardless of auto-adjustment: (i.e. 
even in R3)

past?: func [
	"Returns TRUE if a series is past its tail."
	series [series! gob! port!]
] [
	and~ greater-or-equal? index? :series index? tail :series
	    not same? :series tail :series
]

but, pick whichever version you like

BTW, "returns true if a series index is past its tail" mixes different 
datatypes - series index is integer, while tail is a series, so, 
my opinion is, that the shorter wording is less misleading

The not same? :series skip :series 0 line works well enough, afaict. 
Do you have a case for which it doesn't work and the larger test 
is required?

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