Anomaly Jobs: +myjob/cc
-
A complete rewrite of the aJobs system would also be useful, but it's not likely to happen soon.
@Groth, I also mused about changing how the system determines which comments to show, so yeah, preaching and choir et al.
What I asked, tho, is what would be best. I'm guessing you're saying you think this would be the best fix, which is cool and all but I'm kind of guessing.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Thenomain said:
A complete rewrite of the aJobs system would also be useful, but it's not likely to happen soon.
How badly do you want it?
-
@Alzie
raises hand -
@Alzie said:
@Thenomain said:
A complete rewrite of the aJobs system would also be useful, but it's not likely to happen soon.
How badly do you want it?
Not that badly.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Thenomain said:
@Alzie said:
@Thenomain said:
A complete rewrite of the aJobs system would also be useful, but it's not likely to happen soon.
How badly do you want it?
Not that badly.
Heh. On a more serious note, once I'm done converting requiem to the new Character stuff and have some free time, I will look at making a more modern, simplistic jobs system.
-
@Thenomain said:
A complete rewrite of the aJobs system would also be useful, but it's not likely to happen soon.
@Groth, I also mused about changing how the system determines which comments to show, so yeah, preaching and choir et al.
What I asked, tho, is what would be best. I'm guessing you're saying you think this would be the best fix, which is cool and all but I'm kind of guessing.
Rewriting the logic that determines if a comment is shown or not does exactly what you want it to do and is very easy to implement.
If you felt like it, you could even rewrite the logic to add new types of publishing, you could write one type of publishing that hides staff comments, one that shows staff comments, one that only shows comments from members of the same IC group etc etc.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
Rewriting the logic that determines if a comment is shown or not does exactly what you want it to do and is very easy to implement.
I can't tell if you're an alien, arrogant, or just not all that experienced with aJobs. Making changes to aJobs is never very easy to do. There are so many pieces spread out over so many different objects, and odd little fiddley bits that it is very hard to determine when you change something how it is going to affect a different bit of aJob code down the line.
I guess. What I really want to say is:
Please tone back the "this is easy!" attitude. It might be easy for you, but it isn't necessarily for everyone else with an interest in changing/editing aJobs.
That said:
@Alzie: A better +job/+track/+ticket system as something I've wanted to do for years but never quite found the time/giveafuckenough to actually do it. So if you'd like someone to throw ideas around at, feel free to hit me up.
-
I'm going to re-write the conversation.
@Thenomain said:
What would be best fix? I'm guessing that you're agreeing that it's in the "what comments are published?" part of the code.
@Groth said:
Yes. I can do this.
Cool. If you feel like taking a stab at it, sure.
@Cobaltasaurus said:
Gooooooood luuuuuuuuuuuuck!
Heh, yeah.
-
I agree.
With fixing the what comments are published part of the code. Because I am such the coder.
-
The code I posted works. I didn't claim I can do this, I did this.
Anomalyjobs is very well documented compared to the code I've been trying to debug lately. I'm sure there are some parts of Anomalyjobs which are huge pains to work with, but the comment filtering is not one of those things.
-
Where is the documentation for the code? Hell, I still have problems finding information in jhelp after how many years?
Again, I don't mean to insult anyone about the code, and I know how it is, but I always feel a weight on my chest when I have to find out what aJobs is doing.
For instance, HOOK_* finds out the comment it's affecting by picking up the last comment. The comment number is not passed. Why is it not passed?! I found this by accident, mainly when I needed to add functionality.
On the other hand, the job filter system is a thing of beauty. It's entirely internal to the system and is a breeze to work where to hook external code into. Another system was easy for this too--SQL archiving, I think--once I worked out what registers did what and what is passed to which.
"Once I worked out what registers did what and what is passed" is my years-long experience with aJobs, I start with '+job/add' and stumble through from there. aJobs is the boulder I keep having to push up the hill.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Thenomain It isn't passed because [after(last(lattr(job object/COMMENT_*)),_)] is trivial. Or at least, that's what I imagine the developers of AJobs thought.
-
I've never used jhelp, I've only ever used https://code.google.com/p/anomalyjobs/w/list to find things out.
-
Possibly, and that's what I would think too, but the system is based on triggers without semaphores which risks, slightly but still possibly, timing issues. The calling code knows exactly which comment number is being created. It makes me both argle and bargle.
I really can justify a lot of what the code is doing, and does, and I will not for a second say that my code is perfect either, but I feel that I have a light need to defend myself in thinking that some of what aJobs does is silly. Because some of what aJobs does is silly. Like not passing the comment number to HOOK_*, or treating a 'cc' like a 'bcc'.
Maybe these are only my opinions, as I'm not in the code team, but a coder without opinions is a drone.
Gripe gripe gripe.
-
I imagine the reason is that for most hooks you don't actually care about the comment.
What is obvious to you may not be obvious to me and vice versa.
-
My answer is a mix of the previous two: they didn't think it was needed, and when they put it in the default install they felt it was easier to run close-enough code than find all the places it would need changed.
I've been there. Very recently.
I'm still griping about it. I hate doing it.
C.f., what @Alzie says, below. HOOK_ADD is only used for comments like MAI is, so potentially would use it. PUB likewise.
-
@Groth Take it you haven't looked at any of the hooks. Just the first one that comes to mind.
&HOOK_MAI [v(JOB_VC)]=@set %0/[last(sortby(%va/SORTBY_COMMENTS,lattr(%0/COMMENT_*)))]=no_inherit``` -
Most != All.
-
Pedantic != Helpful in many situations.
In a non trivial count, Pedantic == Argumentative.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Thenomain Wow, did you just get mad at someone for being pedantic? Damn. Groth needs some kind of award.
