Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    lylgithub2021
    @lylgithub2021
    But copy/part str find/last str "." gives "abc.txt.def", and copy/part str 13 gives "abc.txt.def.". I am confused. Why does the former have not the last dot,but the latter have?
    dsunanda
    @dsunanda
    I'd agree that's confusing - it's behavior copied over from Rebol, and it may take a deeper expert to explain why it is the best, rather than a mistake..... Might want to ask again in the Help room -- we're off topic for parse.
    lylgithub2021
    @lylgithub2021
    Many thanks again!! Then, is there a way to achieve it by parse?
    Greg T
    @gltewalt
    Because find/last returns . through the end of the string. Effectively takes it, or "chops it off"
    >> str
    == "%abc.txt.def.txt"
    >> find/last str "."
    == ".txt"
    >> copy/part str find/last str "." is telling it to copy up to ".txt"
    Greg T
    @gltewalt
    Including index? will give the latter result.
    copy/part str index? find/last str "."
    lylgithub2021
    @lylgithub2021
    index? is more readable, thanks. And I am still confused why the result of find can be used as length argument of copy/part. I don't find any explanation from help of Rebol or Red.
    Toomas Vooglaid
    @toomasv
    If you give a number, it is interpreted as offset (i.e. length to be copied), but result of find (i.e. same series with different index position) is interpreted as target position until which to copy.
    Gregg Irwin
    @greggirwin
    The doc string for /part was shortened from R2, which was "Limits the search to a given length or position." so it's confusing as it is. If we change "length" to "extent" that helps, but the R2 doc string might be best. We can also add details to the length arg, and keep the /part doc-string short. The fact that the arg is called length makes it a bit confusing too. And just reiterating the types in a doc string isn't much more informative.
    /part        => Limit the extent of the search.
        length       [number! series!] "Length or series position"
    lylgithub2021
    @lylgithub2021
    I see. Thank you @all
    lylgithub2021
    @lylgithub2021
    So, here, how to achieve it by parse?
    Boleslav Březovský
    @rebolek
    @lylgithub2021 for example:
    file: %abc.txt.def.txt
    rejoin parse file [collect some [keep to #"." ahead [skip to #"."] keep skip]]
    If you don’t want to use rejoin, collectdirectly into string!:
    out: ""
    parse file [collect into out some [keep to #"." ahead [skip to #"."] keep skip]]
    Toomas Vooglaid
    @toomasv
    Some more:
    ; Simplest
    >> first parse "%abc.txt.def.txt" [collect keep to [".txt" end]]
    == "%abc.txt.def"
    ; If you know the structure ahead
    >> first parse "%abc.txt.def.txt" [collect keep [2 thru dot to dot]]
    == "%abc.txt.def"
    ; Interesting :)
    >> first parse tail "%abc.txt.def.txt" [collect any [dot keep (copy/part head s s) fail | s: (s: back s) :s]]
    == "%abc.txt.def"
    Oldes Huhuman
    @Oldes
    file: %abc.txt.def.txt           
    ext: find/last file #"."  ;== %.txt
    copy/part file ext  ;== %abc.txt.def
    rejoin [copy/part file ext ext]  ;== %abc.txt.def.txt
    clear ext  ;== %""
    file  ;== %abc.txt.def
    @lylgithub2021 when the series is used for the part, than it is zero-based index and it makes sense. You want s: "abc" copy/part s s to be "" and not "a".
    lylgithub2021
    @lylgithub2021
    Thank you all. I'm learning them.
    Greg T
    @gltewalt
    lol
    >> reverse remove/part reverse str 4 
    == "%abc.txt.def"
    lylgithub2021
    @lylgithub2021

    Why do codes with parse fail to complie? I have a red script named "fortestparse.red" which only contains:

    Red []
    parse "abc.def.ghi.jkl" [copy aa thru "." to "."]
    probe aa

    When I compiled this script by red -r -t MSDOS fortestparse.red, it faild with wrong message: undefined word aa. Why and how to deal with it?

    Boleslav Březovský
    @rebolek
    insert a line aa: none before the parse. Compiler can't determine words from parse, they need to be initialized manually. Interpreter is smarter in this case.
    lylgithub2021
    @lylgithub2021
    Is it a bug of compiler?
    Boleslav Březovský
    @rebolek
    I won't say "bug". Maybe a missing feature?
    lylgithub2021
    @lylgithub2021
    Does that mean all word used in parse has to be preclaimed when compiling needed?
    Any help Doc mention this?
    Boleslav Březovský
    @rebolek
    Yes, you need to define all used words. There may be a list of compiler limitations in the docs, I'll take a look.
    hiiamboris
    @hiiamboris

    More targeted repost from red/red:

    Hi! If you feel like expanding mental horizons, here's an experiment I'd love feedback on.

    MORPH DSL - A dialect for efficient local series conversion

    A few teaser examples (more on that page):

    >> morph [1 2 3 4] ['x 'y ...] ['y 'x ...]
    == [2 1 4 3]
    
    >> morph/auto [1 2 3 4] ['x ? even? x | skip ...] ['x ...]
    == [2 4]
    
    >> morph/auto/into [1 2 3 4] ['x ...] ['x (not 'x | " ") ...] ""
    == "1 2 3 4"
    Boleslav Březovský
    @rebolek
    Nice :)
    Justin the Smith
    @justinthesmith

    Hey folks, I've run into a problem with unexpected case sensitivity with parse in Red 0.6.4:
    parse [a] ['A]
    This returns true in Rebol 2, Rebol 3, and older versions of Red (0.6.3). But Red 0.6.4 returns false.

    This is problematic as it's preventing construction of a case insensitive but case preservative dialect using block parsing mode. I've not enabled case-sensitive mode with the /case refinement. Any idea what's up?

    Boleslav Březovský
    @rebolek
    @justinthesmith sounds like a bug
    ne1uno
    @ne1uno
    @justinthesmith try with latest, 064 is old
    Justin the Smith
    @justinthesmith
    I get the same unexpected case-senstivity with latest, Red 0.6.4 for Windows built 13-Nov-2021/2:17:19-08:00 commit #5f09829
    Where do I file a bug report?
    Gregg Irwin
    @greggirwin
    See also: red/red#3554 and red/red#3029
    Justin the Smith
    @justinthesmith

    Thanks! Will file an issue.

    One interesting thing that's arisen looking back, is that the /case refinement in Rebol's parse doesn't seem to apply in block parsing mode. For example, this is what I would expect:

    >> parse/case [a]['A]
    == false

    This returns false in Red latest as I expected, but this is true in Rebol. Is Red's behavior here a bug? Should /case apply to word values in block parsing mode?

    hiiamboris
    @hiiamboris
    Of course it should.
    Justin the Smith
    @justinthesmith
    Thanks for the comment on the ticket, @hiiamboris . I was hoping Red could solve problem with a dialect, but I'm not sure my vision is possible with this bug.
    hiiamboris
    @hiiamboris
    Haven't I provided you with a workaround?
    I don't see how that can impair your dialect ;)
    Just produce the rules that work.
    Justin the Smith
    @justinthesmith

    The goal is to produce a dialect that's human readable, human writable, and human maintainable. "Just produce the rules that work" is easier said than done--and seems to stand in sharp contrast with the philosophy of building the the language to suit the problem.

    Consider this dialect example:

    test1: {sell 100 shares acme now}
    test2: {Sell 100 Shares Acme Now}
    test3: {Sell  100 Shares Acme  20-Nov-2021/11:45:00-08:00}
    
    rule: [
        set order ['buy | 'sell]
        set amount integer!
        opt 'shares
        set ticker word!
        ['now (set 'when now) | set when date!]
    ]
    
    parse load test1 rule
    parse load test2 rule
    parse load test3 rule

    All three tests are true in Rebol, but test2 and test3 return false in Red with the case sensitivity bug in parse.

    Rewriting the rule with your tip:

    rule: [
        set order [set w word! if (w = 'buy) | set w word! if (w = 'sell)]
        set amount integer!
        opt set w word! if (w = 'shares)
        set ticker word!
        [set w word! if (w = 'now) (set 'when now) | set when date!]
    ]

    Now all three tests are true in Red (but all are false in Rebol). But the added complexity is the problem. Going to be very difficult to scale to a more complex dialect--especially if I expect people who haven't been using parse for decades to be able to write rules as well. I can't present a solution like this to my manager, let alone others who don't know me as well.

    To me, this bug is a critical issue as it severely hinders one of the key features of the language.

    hiiamboris
    @hiiamboris
    Ah, so them others would need to modify your dialect then. I see.
    Well, you can fix the bug and PR the solution then ;)
    hiiamboris
    @hiiamboris
    And there's a better workaround for you: quote buy | qoute sell
    Justin the Smith
    @justinthesmith
    Thanks for finding that! I'll take a look
    Gregg Irwin
    @greggirwin
    Words should not be treated case sensitively by default. That's the main bug. Whether /case should apply to them is separate. It is supported elsewhere.
    Justin the Smith
    @justinthesmith

    Makes sense to me, Gregg.

    I have a few old builds saved locally prior and confirm things worked as expected prior to that commit @hiiamboris referenced. I don't have any experience with Red/system but please let me know if there's anything else I can do to help address this bug.

    Gregg Irwin
    @greggirwin
    :+1: This is probably one we want the core team to tackle.