02:33
sortiz joined
02:49
skids joined
04:15
geekosaur joined
07:27
RabidGravy joined
09:18
geekosaur joined
09:51
TimToady joined
|
|||
dalek | kudo/nom: fd29b24 | lizmat++ | src/core/ (16 files): Make grep a frontend of where Inspired by gist.github.com/0racle/ea0523759e2da15758d4 . Remembering my first exposure to Perl and Unix, I never understood what "grep" meant: "find" was always more natural to me, but of course that meant something else in the Unix world already. Since we already use "where" and not "grep" for subtypes, it only seems natural to use "where" instead of "grep". 868d8b4 | lizmat++ | src/core/ (16 files): Revert "Make grep a frontend of where" This reverts commit fd29b24939bcb565a88292a5456483c3393d7cea. |
11:19 | |
lizmat | the commit is github.com/rakudo/rakudo/commit/fd...939bcb565a | 11:20 | |
spectested clean, fwiw | |||
0racle++ for getting this on the road :-) | 11:21 | ||
timotimo | wait, we're getting "where"? | ||
i thought we were 100% NOPE on that suggestion? | |||
lizmat | we were ? | ||
timotimo | "we don't know something that's 100% the same as another thing", i thought | ||
psch | having both definitely seems weird | 11:22 | |
lizmat | well, let me put it this way: .grep cannot be removed until we have a looong deprecation cycle | ||
timotimo | er, not "know", "want" | 11:23 | |
lizmat | well, it wouldn't be the first commit of mine to be reverted :-) | ||
psch | i mean, i like the sentiment. grep is really just a *nix-ism that we don't need to be tied to | 11:24 | |
i just don't know if the deprecation cycle can ever finish, seeing as it's so culturally ingrained | |||
lizmat | well visually the o's in looooong have some feel of infiniity in them :-) | 11:25 | |
using .grep incurs a small overhead now :-) | |||
timotimo | i actually like that grep can be easily verbed, whereas where can't | 11:26 | |
lizmat | .oO( I whered it ) |
11:30 | |
psch | "don't you mean 'was'?" | ||
lizmat | .oO( the items wheren't there ) |
11:32 | |
masak | I'm mostly "meh" about adding `where` as a method. it makes the `where` of subtypes and parameter narrowing more confusing, since it's really a different thing. | 11:48 | |
but I think things like that, targeting the most core parts of the everyday API, shouldn't be added without enough deliberation and discussion | 11:49 | ||
masak | lizmat++ # quick turnaround :) | 11:51 | |
lizmat | :-( | 11:52 | |
masak | if I were interested in adding synonyms for "where", I would probably recommend "filter", which has a lot of prior art and which people would probably recognize for what it is | ||
"filter" is a verb | |||
lizmat | "* jnthn is glad we got something a bit shorter than filter, without having to abbreviate )" | 11:53 | |
masak | well, I'm not jnthn. :) | 11:54 | |
lizmat | and you're not pumpking :-) | 11:55 | |
[Coke] | -1 on .where for .grep from me. Yes, I also thought it was mostly nope from the core devs on that one. | ||
masak | lizmat: no, I don't claim any authority on this. | 11:56 | |
[Coke] | ... and it was reverted on the next page of scrollback. | ||
masak | I just had to search for a few minutes to re-remember what Ruby chose for this word. "select" :/ | ||
(and "reject" for negative grep, which is perhaps the only redeeming feature of that naming decision) | |||
timotimo | .keep-only-matching | 11:58 | |
lizmat | let's stop this discussion: core devs (other than me) were apparently NOPE on this | ||
I must have missed that | |||
if either jnthn or TimToady decide it was a good idea after all, there's a revert to revert | 11:59 | ||
masak | I don't see why "let's stop" would be necessary -- but I'll shut up about it now | ||
lizmat | because this is quickly devolving into bikeshedding | ||
timotimo | also, there's a possibility that discussing this further could negatively impact liz' mood, which i also wouldn't like | 12:00 | |
lizmat | I thought 0racle++ made a good point in gist.github.com/0racle/ea0523759e2da15758d4 | ||
timotimo | not saying that's what's going on, but i think it should be considered, at least in the back of your head :) | ||
lizmat | especially about the 7 year old girls part, which rang so true with my first experience with Unix and Perl | ||
my mood for today is already negatively impacted... so you don't have to worry about that | 12:01 | ||
I'll go cycling in a little while and feel better after that | |||
timotimo | p6-wig also gives you .where, which is a good step in that direction | 12:02 | |
lizmat | if you think that is a good step, why not have it in core then ? | 12:03 | |
timotimo | in my day-to-day life and conversation with like-minded friends, i already use "to grep" and "grepping" as a regular word :S | 12:04 | |
lizmat | "like-minded" sounds very echo-chambery to me | ||
timotimo | that's true | ||
having the functionality duplicated still feels "smelly" to me, but throwing out grep would, as you pointed out, require a really long deprecation cycle | |||
lizmat | cycling& | 12:05 | |
psch | #126527 is weird :/ | 12:10 | |
wrt .where, the deprecation cycle is what concerns me most as well | 12:12 | ||
and lots of long-term *nix users might just consider that another change for the sake of change, and i don't know if there'd be enough 7 year old girls to refill the potential loss in user base there | 12:13 | ||
as in, i like the change, but i think inertia is already a concern now | 12:14 | ||
awwaiid | hoelzro: are you doing any active work on the REPL? I've been playing with moving the looping, reading, and printing bits in there (into REPL.pm instead of the nqp Compiler.nqp and rakudo Compiler.nqp) and it's starting to look promising. | 12:47 | |
on this "where" discussion, ruby interestingly has select and find_all implemented identically, and are what we call grep. They additionally have 'grep' which does a === match (so typically passed a regex) and takes an additional block that works like a .map of the matching entries. | 12:58 | ||
side note: Go to ruby-doc.org/core-2.3.0/Enumerable.html and mouse-hover over a method entry like grep. You will see a "click to toggle source" button in the upper-right corner. Click that sucker to see the top-level implementation (either in C or Ruby). Works on all the ruby-doc.org stuff -- pretty sweet. | 13:01 | ||
though in ruby land ActiveRecord (and ORMs across all the lands) often use .where, though I suppose that context should in theory be pretty clear | 13:03 | ||
timotimo | i'd almost say we should call it .keep | 13:09 | |
awwaiid | ooo. nice and short | ||
timotimo | though on second thought that sounds more like a mutating method perhaps | ||
awwaiid | ah. | ||
timotimo | @foos.keep(* < 5) really does read well | ||
awwaiid | maybe this is why the Great Unixers invented a new word :) | ||
too bad 'take' is taken :) | 13:11 | ||
masak | 'keep' sounds like it'd mutate for some reason | 13:12 | |
awwaiid | 'take', 'gather', 'keep', 'choose', 'adopt', ... . Alright, me being a thesaurus is probably not helpful. Time to walk the dog and get breakfast! | 13:14 | |
timotimo | if we can use lojban spelling, we could spell "choice" as "cois" | 13:15 | |
that's the same length as "grep" and "keep" | |||
choose would be even shorter as "cus" | |||
psch | ...i don't think length is the concern | ||
timotimo | jnthn said he's happy we have something shorter than "filter" | ||
and that's just 2 additional characters compared to grep. choose is the same length as filter | 13:16 | ||
psch | jnthn also said "we don't two ways to do the exactly the same thing" | 13:18 | |
which points back at actually deprecating grep being the concern | |||
at least that's how i see it | 13:19 | ||
and i think that's just way to much fallout for far too little gain | |||
well, jnthn said it grammatically correct... :) | 13:24 | ||
btw, i find it humorous that this issue has already been described as bikeshed the day before yesterday here: | 13:25 | ||
irclog.perlgeek.de/perl6/2016-04-01#i_12270384 | |||
and just to be clear: i'd welcome an authorative decision that says we're deprecating .grep for .where | |||
m: my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it, it =:= IterationEnd | 13:52 | ||
camelia | rakudo-moar 868d8b: OUTPUTĀ«Mu|60166368 Use of Nil in string context in block at /tmp/52phNs24bW line 1ā¤ False Ā» | ||
psch | $ ./perl6-j -e'my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it, it =:= IterationEnd' | ||
Mu|679099929 Mu<679099929> False | |||
i think that's behind #125577 | |||
m: my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it.WHICH, it =:= IterationEnd # clearer | 13:54 | ||
camelia | rakudo-moar 868d8b: OUTPUTĀ«Mu|62607680 Nil False Ā» | ||
psch | now how does the Iterator API actually work... :) | ||
awwaiid | my wife suggested 'vet' and 'sift' when I was trying to describe this to her :) | 14:08 | |
timotimo | sift is a beautiful word, but is it obvious? :\ | 14:09 | |
grep isn't obvious at all, so sift probably wins that by default | |||
TimToady | I really don't think we're changing anything here; 'where' in particular has no current auto-iterative meaning, it's only used where something external is looking for a boolean smartmatch, so that would be confusing to overload | 14:18 | |
and I don't buy the etymological fallacy that just because grep used to mean something else, it means only that today | |||
and everyone is acting like they're bored :) | 14:19 | ||
timotimo | btw, if anybody cares, the "lines" version of this benchmark github.com/tbrowder/perl6-read-wri...st.pl6#L46 spends about 16% of its time all-in-all gc_mark-ing an Array object; i think we're keeping around a gigantic amount of these lines rather than going through them sequentially for some reason | 14:22 | |
we don't have a "batching" thing in place there yet perhaps? | |||
awwaiid | what does "my $*AUTOPRINTPOS := nqp::tellfh(nqp::getstdout());" mean? I'm trying to understand method autoprint in nqp/src/HLL/Compiler.nqp | 14:39 | |
mmm. I guess tellfh gets the file pos. so this snapshots it and then doesn't print if something else has been printed. | 14:40 | ||
ok, answered my own question, thanks | |||
geekosaur wonders how well that works on something without a seek position | 14:58 | ||
16:19
Ven joined
|
|||
hoelzro | awwaiid: I'm doing a bit of cleanup atm and allowing the user to select their preferred line editor | 16:25 | |
awwaiid | hoelzro: what sort of cleanup? I'm making pretty good progress I think. Well I should be able to incorporate any of your cleanup well enough | 16:27 | |
hoelzro | awwaiid: well, I moved the line editor role mixin stuff into their own functions for now, for example | ||
awwaiid | ah nice | 16:28 | |
I'm transferring functionality from nqp/src/HLL/Compiler.nqp -> src/Perl6/Compiler.nqp and then src/Perl6/Compiler.nqp -> src/core/REPL.pm, so that the main loop { read; eval; print } lives directly in REPL.pm . I think that doesn't conflict with the role mixins at all | 16:29 | ||
hoelzro | cool =) | 16:30 | |
awwaiid | I'm in the middle of some destruction at the moment, but when I get it stable again I'll push the branch | 16:31 | |
masak | TimToady is right -- surely we have something to energize us much more than a bikeshedding? | 16:34 | |
hoelzro | awwaiid: cool, let me know! | 16:36 | |
awwaiid | hoelzro: when you are devving this you just run 'make' in rakudo over and over and it takes like 1 minute each time, right? Any edit/compile/test shortcut I should be using? | 16:40 | |
hoelzro | awwaiid: I revert -n this commit while I'm working: f7d1c4b | 16:41 | |
and set PERL6LIB=src/core | |||
that way, you don't need to make to load your changes | |||
I want to add a RAKUDO_REPL_MODULE env var to add the same functionality, but I have some concerns about how to do that securely | 16:42 | ||
awwaiid | that works when you make changes to REPL.pm but not src/Perl6/Compiler.nqp, right? | ||
hoelzro | yes | ||
awwaiid | ok cool | ||
16:55
hankache joined
17:18
Ven joined
17:28
Ven joined
17:48
Skarsnik joined
17:57
pmurias joined
|
|||
pmurias | re grep/where having both seems inferior than having just grep | 17:59 | |
I'm might be biased in terms of UNIXisms as I was introduced to unix/perl at the same time and both seemed awesome | 18:01 | ||
18:34
Ven joined
18:39
hankache_ joined
|
|||
timotimo | damn, i made a mistake | 18:57 | |
the part where we spend so much time in gc_mark isn't lines, it's slurp | |||
github.com/tbrowder/perl6-read-wri...st.pl6#L63 - in this case it doesn't surprise that we'd be marking a gigantic array | 18:59 | ||
lizmat is back from cycling | 19:27 | ||
without starting up the .where discussion again, I would like to do a post-mortem as far as I'm concerned | 19:28 | ||
- I had completely missed the discussion that had led to the NOPE verdict | |||
I was under the impression that we would have this type of discussion on #p6dev rather than #perl6 | 19:29 | ||
I don't backlog #perl6 anymore: when I'm online I sort of follow it, but when I'm not, I'm not | |||
I also understand that these discussions may happen at places where we don't expect them | |||
I would therefore suggest that *if* we have such a discussion on a place other than #p6dev, someone should at least put a link to the discussion on #p6dev | 19:30 | ||
this would saved us a lot of hassle | 19:31 | ||
having missed the discussion, I thought the gist / PR had just been warnocked | |||
- the argument that this can live in module space, I think is basically void | 19:32 | ||
as far as I understand precomp, any module that does an augment, can not be used by a module that is precomped | |||
nine jnthn is that assertion correct, or am I having a brainfart here ? | |||
- this whole thing was about .where as a synonym for .grep | 19:33 | ||
as far as I was concerned, there was never a question of needing another name for grep | |||
just that, since we have where for subtypes, it seemed logical to have it as a synonym for .grep to me | 19:34 | ||
and remembering my confusion about "grep" when entering the Unix world ~22 years ago | 19:35 | ||
I thought it would make sense for non-Unix newbies | |||
and I guess there's a reason why languages as Ruby have things like "select" and "reject", instead of "grep" | 19:36 | ||
- end of post mortem | |||
19:36
skids joined
|
|||
timotimo | lizmat: i'm not happy with the way i brought up my understanding of the issue when i saw that commit message :| | 19:36 | |
moritz | if I wanted to implement TR///, how do I make it only available in v6.d? | 19:44 | |
lizmat | moritz: afaik nine has a conceptual 6.d setting sitting in a branch | 20:41 | |
nine | lizmat: I'm not sure either, but I guess things would really start to break when two precomped modules use the same class but one of them expects an augmented version and the other doesn't. | 21:15 | |
moritz: commit f6ea6553af39bf7b0a0e18bafc1ad46638b7c97e in the language_versions branch is an attempt at doing a v6.d setting | 21:16 | ||
lizmat | nine: I vaguely remember discussing this | ||
nine | +1 +1 +1 on posting important discussions on #p6dev | ||
vendethiel- | lizmat++: fwiw, I really appreciate that you're pushing terms easier to understand for non-unix-ers/unix newbies :) | 21:22 | |
it's most often confusing to me who hasn't been using that for 20 years :P | |||
(even .uniq is) | 21:25 | ||
lizmat | vendethiel- : that's why it's called unique nowadays :0) | ||
:-) rather :-) | |||
vendethiel- | yes, I remember bikeshedding to get that new name :P | 21:27 | |
it's good that we aren't locked up anyways, if someone wants to provide a module that re-verbs ours (use Ruby; :P), they can do that just fine! | 21:28 | ||
.oO( but how long will it take for these 7 years old to learn UNIX? ) *g* |
|||
MadcapJake | wrt .where: rigaux.org/language-study/syntax-ac...stKeeplmnt | 21:33 | |
lizmat | good night, #perl6! | 21:54 | |
23:06
vendethiel joined
23:44
vendethiel joined
|