@Adám In this particular case, 1 and 3 should both return 1, right? The visual pun with 1 is kind of nice, though 1⍨ is arguably more semantically clear, since the intent is to just "tally" the members.

Probably don't need to worry about performance, right?

@B.Wilson No, 1 gives you the number of code points in the grapheme, and 3 gives you 0.

@B.Wilson I'd expect not :-)

@Adám Oh, 3 ⎕IO-independent.

Oh. Yeah 1 is a lot more interesting. Not sure what I was thinking!

Actually, to get agreement with ≢, I think we need to be in document mode: ≢('\X'⎕S{1}⍠('UCP'1)('Mode' 'D'))

Sure, if you have multiple lines. Note that \X counts CRLF as a single grapheme.

Ah, okay. That's interesting. Guess ('EOL' 'LF')('NEOL'1) might be desirable, depending on semantic intent.

Testing on ~1200 grapheme lorem ipsum, however, I'm getting different results between the ascii and the zalgo versions. Really hard to visually count Zalgo text though :P

I should stop getting distracted by this :P Just got sniped by the "More information can be found in the PCRE documentation" comment in the UCP explanation.

@Adám What are you up to today?

Right now, putting the finishing touches on a new APL Show episode.

Oh, nice. Seems like you dedicate massive TLC to APL pedagogy and evangelism!

:-) Once that's rendered and published, it is time to record an APL Quest video or two…

Later, we have a pre-launch meeting for the '23 competition.

Thank you for all the time you put in. In addition to the contents produced, it's also just really nice knowing I can always throw things in this chat and get high-quality feedback/answers.

@Adám Apart from the above, do you have your head in any deep, technical problems as well?

Adám does a lot of work on the user commands/tools side of things, he's also the top source for language design. He has his fingers in a lot of pies

@B.Wilson Not at the moment. I'm finishing up the array notation proposal/spec but it isn't really technical at this point. Later, I'll get involved more in the intricacies of Link and associated startup procedures which can get really hairy. And then I'll be looking at RIDE issues and what we can do to improve RIDE (feedback is always welcome). I can paste my official objectives for 2023 if you're interested.

There are also a bunch of smaller issues with various pieces of APL code. I currently have 98 internal and 17 external issues assigned to me…

115 pies! That's indeed a lot. Definitely looking forward to the Link and startup stuff.

Pretty trivial startup thing, but I was wondering why the -script flag exists at all. The first two bytes of workspace files are always 0xaa03, right?

It looks like dyalogscript's entire role is to add some extra options and then insert -script in the right place before handing the args off to dyalog.

@B.Wilson Separate executable, no? dyalogscript calls dyascript, not dyalog iirc.

Iirc, there were some intricacies in the implementation that made it easier to set up the stage before going into the interpreter, maybe something to do with the various platforms we ship on.

I gathered some opinionated RIDE wants here: github.com/Dyalog/ride/issues/940

@Adám Ah, is that Windows? On Linux dyalogscript calls dyalog.

So some platforms need a sort of double trampoline for scripts? Interesting...

@Adám We should have a meeting about RIDE soon

Indeed.

Speaking of debugging, let's say I start debugging some intricate function with ctrl-enter, and spend some time stepping through, executing expressions deeper in the stack. I find my issue, drop out, fix my function and then I want to start again.

Now I have to shift-ctrl-backspace through a gazillion expressions I typed whilst deeper in the stack to get back to my original expression I started debugging in the first instance.

@xpqz Your --link already exists as LOAD=

@Adám ...from the shell, on the mac?

The dyalog executable can handle it, but that doesn't start RIDE, so I agree there should be a RIDE shell command that just passes args to the interpreter.

@xpqz You mean in the interactive session? Are you suggesting that things you type while you have a stack should not be added to the session log, or maybe to a separate sub-log?

Yes, exactly. I'd like the session to be stack-frame aware in some way.

Unless there is already some secret way to say 'debug my function again, just like last time'

Interesting. Not really a RIDE issue as much as a Dyalog session issue. (Remember: RIDE is dumb.)

Another useful thing would be having separate sessions for separate threads.

The fact that RIDE is dumb is an implementational issue :) -- I'm speaking as a user not privy to how things hang together under the hood.

VS Code is perhaps overly clear...

Hitting the blue button debugs my code the same way as last time.

@xpqz You might be able to step out to the top level, and then continue execution from line 0. By never clearing the stack entirely, you don't even need to re-trace-into.

Here's what I mean: youtu.be/vyCgCGAqSes

I tried to count the steps, 60+ I think

Right, I get it, but you lost the state because you did )sic

Sure, but otherwise I'd have to sit and click the close button for every stack frame.

That could possibly have worked in this case, but with a more recursive example, that's a lot of clicking.

You also asked for a )sic button. I don't use the mouse much. Esc does the trick!

Esc does not )sic (I think?)

If it did, that would be great, combined with a different way to walk the stack frames.

Maybe I just haven't discovered it.

But I don't know how to jump to the first frame whilst at the 15th.

Esc cuts one stack frame.

Yeah, and that's only of limited use if the stack is deep.

So "hard-quit from depth, restart from top, like last time"

If you know how deep the stack is, you can do )sic n where n is one less than the levels.

Is there a )command to list the stack frames?

Ooh, I just discovered an undocumented feature: )sic ¯1 gets you to the very top, i.e. clearing all but 1 frame.

Ok, lets make that something that one can hang off a keystroke!

But will this work if I've changed the function?

@xpqz )si

@xpqz Not if you've changed it while it wasn't at the top of the stack. I.e. it'll use the version that's already on the stack.

@xpqz Edit>Preferences>Shortcuts>PF3 (or whatever): )sic ¯1<ER> and assign any keystroke you want to that.

A video/webinar masterclass on debugging would be a handy resource, I think.

Most of the features I'd like seem to be there, just hard to discover.

@xpqz I would also love to see something on this

@Adám This is useful.

Eek. Ð is a valid name character, but Đ isn't. How do these look in your fonts?

I guess general Unicode punning issues would be expected to pop up.

@B.Wilson ÐƉĐ look the same in uppercase, but all different in lowercase ðɖđ which isn't so unusual. Only the first are in Latin-1, which is basically what Dyalog allows for names.

Nifty. So Latin-1 is the rhyme to this reason. Cheers.

@B.Wilson Basically:

      a←⎕UCS⍸¯1≠⎕NC⍪⎕UCS⍳255
      u←'\PL'⎕R''⍠'Mode' 'D'⎕UCS⍳255
      (a~u)(u~a)
 _  ªµºÞýÿ

Allowing _ makes sense, but excluding uppercase Þ when þ is allowed and excluding the two accented y's doesn't make so much sense.

Hm, maybe ÿ is excluded because its uppercase isn't in Latin-1?

But allowing Ý while disallowing ý just seems like an oversight, like þ vs Þ.

Huh. I see your point: ⎕UCS(⊢⊢⍤/⍨255≥⊢)⎕UCS'.'⎕R'\u&'⊢u~a.

      L←'.'⎕R'\l&' ⋄ U←'.'⎕R'\u&'
      (U a)~U a~U a
_Ýß
      (L a)~L a~L a
_ßþ

@B.Wilson You don't know about ⎕C?

I just read about nifty PCRE Unicode features, so everything is a nail. Stop ruining my fun :P

btw, ⎕R/⎕S has some additional fancy features that no other non-codegolf language has.

Such as?

multiple parallel patterns, the substitution patterns, and easy access to callback per match, the latter with persistent state across matches.