@monorail hmmmmmmm
@monorail probably should be ++i. oh well!
@monorail anyway I was nice and comfy in my bed and this made me get up to use my computer so every one of my followers better favorite this
@wallhackio @monorail Next time, consider using laptop computer while in bed
@wallhackio @monorail idx should increment by 1 which is not what either of those would do
@wallhackio @monorail no.
@wallhackio @monorail it would increment by 1, then 2, then 3…
@wallhackio @aescling if you want to increment by 1 every time, one way i like to do that is with += 1
@monorail @wallhackio damn holly how did you get so wise
@aescling @wallhackio by looking up "javascript shared prefix of multiple strings" on google and seeing a stack overflow page about it
@aescling @wallhackio oh sorry i thought this was a reply elsewhere
@aescling @wallhackio this one is a holly original wisdom
@monorail @wallhackio that is a good wisdom
@monorail @wallhackio baaaaall-eevee or not, i’m walking on air
@wallhackio @aescling @monorail Can you do something like idx++, i++?
@vaporeon_ @aescling @monorail yeah that's what i would do (actually I would do ++idx, ++i but it objectively doesn't matter)
@vaporeon_ @aescling @monorail also this thread makes me certain that "I'm not sure I would give enough of a shit in a code review because either way would look Weird" was the right answer all along
@wallhackio @vaporeon_ @aescling mr. wallhackio do you like my javascript https://git.hollymcfarland.com/monorail/DSCRTC/src/branch/main/dscrtc.user.js#bypass=true
@monorail @vaporeon_ @aescling ooooh yummy delicious iife
@wallhackio @vaporeon_ @aescling this is convention for userscripts you see
@wallhackio @vaporeon_ @aescling sometimes you have an iife that constructs a script tag and injects it into the DOM, that's also conventional (but not always necessary)
@monorail @vaporeon_ @aescling I will support iife usage even if its stupid, iifes give me life
@wallhackio @vaporeon_ @aescling it makes sense for userscripts because they like to pretend they live in their own little bubble but you absolutely can pollute the global namespace with them and cause big bad problems
@wallhackio @monorail @vaporeon_ please tell me you OiI’d that Iife
@wallhackio @monorail @vaporeon_ he didn’t :c
@aescling @wallhackio @vaporeon_ i have no idea what this means sadly
@monorail @aescling @vaporeon_ welcome to todays lucky 10000 https://www.youtube.com/watch?v=E3p_Crhi3K8
@wallhackio @aescling @vaporeon_ holy shit
sorry clodboy i’m sniping you on this one
re: sorry clodboy i’m sniping you on this one
@monorail @vaporeon_ @aescling my only note is to use matches.at(-1) instead of matches[matches.length-1] at line 53 but even so, your javascript is clod-approved
@wallhackio @vaporeon_ @aescling hooray hooray
i might fix that if i ever commit to this repo again
@wallhackio @aescling i'm less than sure about this
@wallhackio this was mine and it's good enough that i'm not going to make another commit lmao https://git.hollymcfarland.com/monorail/DSCRTC/src/commit/00e6045482dee54286893aeeb01695530251db25/dscrtc.user.js#L46-L55
@monorail @wallhackio link 404s?
@aescling @wallhackio fuuuck
@aescling @wallhackio try now
@monorail @wallhackio i would pat your head but im tiny and you’re all the way up there
@monorail I did more thinking about this while I was supposed to be playing Deltarune and am now preferring:
let idx = currentSignal.length;
while(i < matches[0].length && matches[0][idx] === matches.at(-1)[idx]) ++idx;
let i = idx - currentSignal.length;
@wallhackio @monorail Hell Of A Study Session
@wallhackio @monorail But you never define or increment i before using it in while (i<...), do you? I think this can't work, this'll throw an error
@vaporeon_ @monorail fuckin hell
@vaporeon_ @monorail I give up
@wallhackio @monorail Maybe you (Clodsire who really wants a while loop here) could do this? Since Holly said she also needs to check the length of the second list, because of longest common prefix.
let i = 0;
while (i<matches[0].length && i<matches.at(-1).length
&& matches[0][(idx = i+currentSignal.length)] === matches.at(-1)[idx]) ++i;
@wallhackio @monorail Personally I, since it isn't performance-critical, would define a function so that I can rename matches[0] and matches.at(-1) to simply a and b. Less annoying to type and to read.
Please correct me if this syntax is wrong in JavaScript, I am not a JavaScript programmer.
function longestPref(a, b, sig) {
let i;
for (i=0; i<a.length && i<b.length; i++)
if (a[i+sig.length] !== b[i+sig.length]) break;
return i;
}
/* ... */
let i = longestPref(matches[0], matches.at(-1), currentSignal);
However, this is more lines of code to produce the same result, so maybe this is bad, unless you have reasons to call longestPref multiple times from different prefixes...
What do you think?
@wallhackio @monorail Upon further thought: We actually want to find the longest common prefix of matches[0] + currentSig.length and matches.at(-1) + currentSig.length (with C array semantics for the + because I'm clueless about JavaScript), not of matches[0] and matches.at(-1), right? The i is just there to make sure that we don't exceed array bounds. At least in C, that means we could just have a normal longest prefix function:
int longestPref(char *a, int alen, char *b, int blen) {
int i = 0;
/* while loop to make @wallhackio@cat.family happy */
while (i<alen && i < blen && a[i] == b[i]) i++;
return i;
}
And then call it like this (I renamed currentSignal to sig because I'm not typing all that 4 times):
int i = longestPref(matches[0].arr+sig.len, matches[0].len-sig.len,
matches[mlen-1].arr+sig.len, matches[mlen-1].len-sig.len);
Clodsire: Can I do something similar in JavaScript?
@vaporeon_ @wallhackio i did end up giving them names in my code as well https://git.hollymcfarland.com/monorail/DSCRTC/src/commit/00e6045482dee54286893aeeb01695530251db25/dscrtc.user.js#L46-L55
@vaporeon_ @wallhackio i've discovered a forgejo bug with this link but tbf i'm on an ancient version
when you click through you may have to remove #bypass=true from the url
@vaporeon_ I haven't carefully scrutinized it but I like the approach in principle
Personally I prefer readability over concision as long as the code isn't performance critical (which is most code). So bigger code size is rarely an issue for me
@vaporeon_