metaeducation / rebol-issues

6 stars 1 forks source link

Weird native bug in SOURCE mezzanine #1501

Open rebolbot opened 14 years ago

rebolbot commented 14 years ago

Submitted by: BrianH

There's no apparent bug in the source of SOURCE, but there seems to be an obscure output bug that (so far) only affects the source of the REPLACE function. See the code, and note the difference in the line with the do-break.

>> print mold :replace
make function! [[
    {Replaces the search value with the replace value within the target series.}
    target [series!] "Series that is being modified"
    search "Value to be replaced"
    replace {Value to replace with (will be called each time if a function)}
    /all "Replace all occurrences"
    /case "Case-sensitive replacement"
    /tail "Return target after the last replacement position"
    /local save-target len value pos do-break
][
    save-target: target
    len: system/contexts/exports/case [
        bitset? :search 1
        any-string? target [
            if any [not any-string? :search tag? :search] [search: form :search]
            length? :search
        ]
        any-block? :search [length? :search]
        true 1
    ]
    do-break: unless all [:break]
    while pick [
        [pos: find target :search]
        [pos: find/case target :search]
    ] not case [
        (value: replace pos)
        target: change/part pos :value len
        do-break
    ]
    either tail [target] [save-target]
]]

>> source replace
replace: make function! [[
    {Replaces the search value with the replace value within the target series.}
    target [series!] "Series that is being modified"
    search "Value to be replaced"
    replace {Value to replace with (will be called each time if a function)}
    /all "Replace all occurrences"
    /case "Case-sensitive replacement"
    /tail "Return target after the last replacement position"
    /local save-target len value pos do-break
][
    save-target: target
    len: system/contexts/exports/case [
        bitset? :search 1
        any-string? target [
            if any [not any-string? :search tag? :search] [search: form :search]
            length? :search
        ]
        any-block? :search [length? :search]
        true 1
    ]
    do-break: unless all [:break]
    while pick [
        [pos: find target :search]
        [pos: find/case target :search]
    ] not case [
        (value: replace pos)
        target: change/part pos :value len
    ]   do-break
    either tail [target] [save-target]
]]

CC - Data [ Version: alpha 97 Type: Bug Platform: All Category: Native Reproduce: Always Fixed-in:alpha 98 ]

rebolbot commented 14 years ago

Submitted by: meijeru

The error occurs in this line from SOURCE: print head insert mold get word reduce [word ": "] So if we do:

>> word: 'replace
>> print head insert mold get word reduce [word ": "]
the error occurs.

But I found out by accident (by making a typing mistake) that if we do

>> print head insert mold get word reduce [word ":"] ; leave out the space after ":"
the error is gone!
rebolbot commented 14 years ago

Submitted by: meijeru

Furthermore, if the reduced block does not contain the exact word REPLACE but any other word, the error does not occur. It looks like the REPLACE function is invoked somehow ?!?

rebolbot commented 14 years ago

Submitted by: BrianH

Naw, the REPLACE function isn't being invoked, it's something else. The newline at the particular line (index 999) is being printed out like a CR instead of a CRLF. I would be surprised if this problem wasn't Windows-specific. Given the closeness of that index to 1000, it might be a buffer issue in PRINT.

rebolbot commented 14 years ago

Submitted by: meijeru

I have tried to provoke that Windows-specific error by printing out a string with a newline at index 999, but wasn't successful.

rebolbot commented 14 years ago

Submitted by: BrianH

Same here. It's something about that specific string, though the characters after the index of the printing error don't affect it.

rebolbot commented 14 years ago

Submitted by: Carl

BrianH: "Bug of the week." The bug is in console printing. It's related to UTF-8 encoding at a buffer split precisely on CR insertion at an LF. Classic. Fixed it.