AltME groups: search

Of course even then it's only right in a context, the context of 
human programmers... a time which will likely be coming to a swift 
end.  :)

go to the box and bring me back something that's not an apple Nor 
a pear

The english language is a bit loose ... and since the incorrect way 
of saying things is so common, one assumes that what's the speaker 
meant

what's the quickest way to determine whether a series is past end 
in R2 and then handle it?

As a side note, I noticed, TAIL? and EMPTY? is the same. So you can 
also write the above as:

and series? s empty? s


Is it wise, that TAIL? and EMPTY? does the same? Maybe EMPTY? should 
return false, if the series holds elements, even if you're at the 
tail.

AND is an op, thus infix, and doesn't have shortcut evaluation. This 
means that you should use AND~ instead of AND if you want prefix, 
but it will still fail if s is a datatype that is not compatible 
with EMPTY? because EMPTY? s will still be called even if SERIES? 
s is false.

Henrik, can you post some code that will make a series reference 
that is past the end of a series? I'm having trouble making one that 
works consistently, and neither your INDEX? method or EMPTY? will 
work. REBGL keeps adjusting the index returned by INDEX?.

>> b: next a: "a"
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1  ; adjusted
>> insert a "1"
== ""
>> index? b
== 2 ; and back again

In R3 they stay consistent, and there is an action PAST? to tell 
whether an index is past the end.
>> b: next a: "a"
== ""
>> remove a
== ""
>> index? b
== 2  ; not adjusted
>> past? b
== true


In R2 I don't even see how to write this in mezzanine without temporarily 
appending something on the end of the series (a single element will 
do) and seeing if the index adjusts, then removing what you appended. 
Like this:
>> b: next next next a: "abc"
== ""
>> clear a
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b
== true  ; past end
>> b: ""
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b

== false  ; not past end, but Henrik's method, and EMPTY? will both 
return true.

Still, the temporarily appending method would be sufficient to backport 
a PAST? workaround, so I'll write one for R2/Forward.

Here's the source to the backport:
past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series!] ; gob! port!
][
	also (index? :series) < (insert tail :series "1" index? :series)
		clear back tail :series  ; Undo the modification
]

; Note: Native in R3, and non-modifying. No ports because you can't 
undo the

; insert. INDEX? doesn't stay consistent with past-tail references 
in R2.

I'm not sure I would want the series to be modified as the case where 
PAST? is true could be for an indication of the series in a debug 
UI, rather than the actual use of the series. Interesting that you 
had so much trouble producing the problem.

It was unfortunate to adjust the result of INDEX? function, since 
we actually obtain a wrong value this way. Auto-adjusting is not 
broken in the case Henrik posted.

past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series! gob! port!]
][
	(index? :series) = (index? back :series)
]

; Note: INDEX? doesn't stay consistent with past-tail references 
in R2.

correction:

past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series! gob! port!]
][
	and~ not same? head? :series :series
		(index? :series) = (index? back :series)
]

; Note: INDEX? doesn't stay consistent with past-tail references 
in R2.

Yet another variant:

past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series! gob! port!]
][
	and~ (index? :series) = (length? head :series)
		not same? tail? :series :series
]

; Note: INDEX? doesn't stay consistent with past-tail references 
in R2.

past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series! gob! port!]
][
	and~ (index? :series) = (length? head :series)
		not same? tail :series :series
]

; Note: INDEX? doesn't stay consistent with past-tail references 
in R2.

(the last is a correction of the one preceding it)

Simplification:

past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series! gob! port!]
][
	not same? :series skip :series 0
]

; Note: INDEX? doesn't stay consistent with past-tail references 
in R2.

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.

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

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

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
]

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?

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

Nevermind, I will declare it "a feature"

(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

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

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^/"

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]
]]

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

No, it's a bug

this is r3

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

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)

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.

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.

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

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

a: make class [init]

you can also make a function which call init , if its there.


new: func[class spec /local obj][obj: make class spec if function? 
get in obj 'init [obj/init]]

if you keep the prototype as a block you don't need to do so
>> context proto

How is it again that one decodes a url? Sometimes I forget the simple 
things.

Is there something like "unmold"? I find myself needing to return 
a molded block back to a block all the time.

Yes, it's a pity MOLD isn't the one which is the least "lossy" (vs 
MOLD/ALL) when it comes to serialising.
What can be done about it at this stage, though?

thing is load isn't the counterpart to mold.  'DO is.   and even 
then, even MOLD/ALL isn't a real serialization because shared objects, 
or series aren't shared anymore.


although they go a long way, and I have been using them extensively 
in many tools, MOLD & MOLD/ALL are just helpers, destined for advanced 
users who have very special requirements.

we need to build a REAL serialization dialect, one which rebuilds 
the data sharing, even in nested and co-occuring references to series 
and objects.

but we should not be forced to use a binary dataset for such things. 
 it can be expressed in source format.

just added an (very succinct) extended serialization example which 
would allow us to basically fix all the MOLD issues on LOAD directly. 
 it could be the basis for rebin, which could just be a compressed 
version of the source version to keep it (very) small.

I have done some work on this to support reloading of shared & nested 
objects specifically and its easy enough to do (for me ;-), but it 
requires some deeper understanding of REBOL.


I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language. 


IMHO, The current implementation isn't a "bug" but rather an annoying 
limitation which has been known and put off as a "to do" for years, 
by everyone which is capable of solving it.

(cause its a very tedious and "not fun" thing to do)

also, there are nasty binding issues on serialization...  things 
like:

---------------------------------
a: "data"
f: does [print a]
o: context [
	a: "other data"
	f: does [print a]
]
set in o 'f :f
---------------------------------


how is this treated in MOLDing ?  these are hard cases to choose 
from a variety of paths, if we serialize only the o  object, then 
its f method is pretty much broken in current REBOLs.   

how would we handle this?  there are a lot of ways to play with the 
above, but no single method will ever cover all possibilites.  


so in the end, the serialization will never be "perfect", unless 
all data items are signed with a unique key which is retrievable 
at run-time and reusable at each interpretation (pretty much impossible).


IMHO all we can do is properly document  what can and cannot be serialized 
without risk of data corruption.  Currently, official & explicit 
documentation on this is vague at best.

Max, I had a specific issue in mind: (pre)processing of REBOL scripts. 
In that case, you we not need to worry about such issues as binding, 
shared objects, etc. I am quite comfotable with MOLD, since it does 
not look like a gotcha to me (not that I want to repeat that "MOLD 
is not a counterpart to LOAD" mantra), but SAVE clearly *is* a gotcha, 
since nobody sane would expect it to "distort" REBOL script when 
saving REBOL code obtained as a result of LOAD.

in R3, there is save/all which stores in serialized format, which 
might solve that particular case (saving a whole script)

Yes, that is not a problem, problem is, that almost everyone would 
expect SAVE to be adequate.

#[true]

 is a normal REBOL syntax, since REBOL is a language, and LOAD as 
 well as Lad recognize it.

if you had a pre-processor which converted all none to #[none]... 
first thing I'd do is stop using your tool   ;-p

mechanical

? - it is the only syntax allowing me to write a logic! type value 
in using the Data exchange dialect. There is no other way how to 
do it.

In the DED (Data exchange dialect) none is a word, nobody wants to 
transform it to a value of a different type, and it actually never 
happens

but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur. 

this is a big detail, which most REBOLers do not grasp.


the litteral notation allows you to load items AS data, not as DO 
dialect source code.


I guess what could be done is to remove the /ALL refinement and add 
a new refinement which forces the non /serialized format.  but that 
makes SAVE work opposite of other serialization handling ... which 
is why I'm not sure that is such a good thing.

for data exchange, I really think that a deeper serialization is 
required.   even MOLD/ALL is inadequate for any serious project. 
 I've been bitten many times.  things like recursive object molding 
or breaking can occur.  ex:

>> a: context [b: none]
>> b: context [a: none]
>> b/a: a
>> a/b: b
>> mold/all a
{#[object! [
    b: #[object! [
        a: #[object! [...]
    ]]
]]}

but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur.
 - this looks like a confused statement to me. Example:

mold/all load "true" ; == "true"
mold/all load "#[true]"; == "#[true]"

There is no rocket science involved.

in your first line... the loaded value is a word, not a #[true] value... 
but people don't get this.

even more of a reason why non-/all save needs to be abolished

I personnally NEVER use SAVE/ALL in any manner.   I always use WRITE 
so I can't even give you a valid case for SAVE/ALL  ;-)


but I've used SAVE a few times to log data.  Even when doing script 
pre-processing, SAVE/ALL broke too often for me to afford the hassle.


I'll usually use MOLD/ALL process the data as a string with real 
control then use WRITE

Ladislav, if you try to DO a script saved with SAVE/all or MOLD/all, 
it will fail if it contains functions or objects. And it definitely 
*won't* be "as close to original as possible". So /all can't be the 
default for SAVE.

Andreas, that isn't a function, it is a description of a function.

It's a script, you said scripts

and that's the whole point. if you load a script and then save it, 
the original script should be affected as little as possible

Yes, and that's the strawman. Those literal objects will only be 
written from a script if it contained them in the first place.

{And it definitely *won't* be "as close to original as possible".} 
- this is a Goebbels' truth, would there be any example?

Yet another example of a Goebbels' truth:

>> do mold quote (1 + 2)
== 3

Max, you did not give any example, that would not deserve the "strawman 
prize", your DATA surely is not a DED

BTW, my above DO example demonstrates quite pregnantly, that DO isn't 
a "counterpart" of MOLD

maxim, you have a good point regardign serialising circular datastructures 
and similar stuff

the objects could be within a block of data that you are trying to 
serialize... it would still fail.

but it is a different issue than what we are discussing here

You built a strawman, since your example does not relate to the subject 
at all. The subject is: SAVE is not good to process DED.

There is nothing that can be used to process non-DED and I agree 
with that, but that is a completely different subject

{but SAVE is not only for DED, THAT is my point.} - that is not a 
point, that is a falsehood. SAVE is not even for DED (SAVE/ALL is), 
less so for non-DED data

When SAVE is being used to generate source that is meant to be run 
by DO, that source should be semantically equivalent to DO code (active 
values in an evaluation context won't be preserved without QUOTE, 
nor will constructed values in a non-evaluating context). When the 
generated source is intended to be LOADed, it should stick to the 
semantics that can be directly LOADed without DO (no multi-level 
"nested scopes" or other binding tricks, no inline modules, no natives). 
And when you are going to combine them, stick to string source.

ok read the complete definition of DED and its missing A LOT of valid 
rebol datatypes.


well, the object! is part of "compound" values.  there is a litteral 
notation for objects, so yes, it is part of the DED.


also the text uses composite values, but its like refers to scalars, 
which is wrong.

1.0 doesn't exist in any IEEE using software, but a value can be 
constructed FROM it  ;-)

can not. The not got dropped in a freeze.

Standard REBOL terms - I like those, is there a definition, what 
is meant by "serialized syntax"?

At least the REBOL standard. We have a lot of inappropriate standard 
terms (I'm looking at you, "context"). :(

Ok, so decimal! is obviously something in a third category. It can 
not be written literally without using special syntax, but it is 
not using serialized syntax according to Brian's definition.

LOAD accepts a lot of stuff that doesn't match this or that dialect's 
semantic model.

It is purely of syntactical nature, a tree of blocks (and parens) 
and scalar values.

Andreas, decimal is a special case in that the regular syntax which 
can specify every value representable in memory, also can specify 
values which aren't representable, which have to be approximated. 
And since those approximated values include much of what developers 
actually use, the aproximation is undone when the value is saved 
in the form which is supposed to result in ordinary source code.

Yes, that looks as a reasonable explanation, but, as I said, it transforms 
the script:

rebol [] same? 0.10000000000000001 0.10000000000000002

yielding #[false] into:

rebol [] same? 0.1 0.1

yielding #[true]


If I had to use a script preprocessor doing this, I would rather 
jump under a moving magnetophone tape, as a friend of mine told once

the approximation is undone

 is an euphemism. more precisly a transformation is applied which 
 also transforms values that are perfectly reprensetable in memory

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

Brian: would you mind describing a single _semantic_ aspect of the 
the DED's model?

So what we need is a function that does a better job of serializing 
the in-memory data model, and probably a new syntax to represent 
it.

 - actually not, as I have no problem to demonstrate, since the goal 
 of script preprocessing (which is the subject of this discussion) 
 can be reasonably achieved using the LOAD and SAVE/ALL pair.