|
Hard to say just by looking at it... probably not your random number generation, but could be your clockwise thing. Easy to test though, try iterating through your surroundingPixels from length-1 => 0 and see if it significantly changes things.
|
#
?
Sep 30, 2015 22:36
|
|
|
|
| # ? Jun 6, 2024 08:09 |
|
|
Skandranon posted:Hard to say just by looking at it... probably not your random number generation, but could be your clockwise thing. Easy to test though, try iterating through your surroundingPixels from length-1 => 0 and see if it significantly changes things. Good call... it definitely does. When I reverse the for loop the trend is down to the left instead of up to the right. Well what the heck. Guess I'll try shuffling the array...? e: Shuffling the array worked. However this is still weird to me and I wonder if anyone can shed some light on why this would happen? kedo fucked around with this message at 23:00 on Sep 30, 2015 |
|
#
?
Sep 30, 2015 22:56
|
|
|
What happens if you check for the animating class on pixel at the top of trigger and return if it's there instead of animating it again?
|
|
#
?
Sep 30, 2015 23:18
|
|
|
Munkeymon posted:What happens if you check for the animating class on pixel at the top of trigger and return if it's there instead of animating it again? I tried that as well but it wasn't the problem. For some reason the for loop was hitting all of the items in the surroundingPixels array, but only one to two of the first four (top, top right, right, bottom right) ever seemed to meet the requirements to actually animate. Very rarely one of the last four (bottom, bottom left, left, top left) would animate. They all ran through the same function, so they all theoretically had the same chance of animating (ie. a random number up to 100, if less than 30 - animate). Shuffling the array is a fine workaround, but it still seems weird to me. Why are items at the beginning of the array more likely to animate than others? I have zero clue. Here's a jsfiddle with array shuffling disabled (commented out on line 88) if anyone wants to muck around with it. If you mouse over enough pixels you'll see that some pixels on the left do animate, they're just very, very rare.
|
|
#
?
Oct 1, 2015 01:45
|
|
|
The problem is you've written for(i = 0... rather than for(var i = 0... Every invocation of your trigger function is referencing a single (global) instance of i, which in effect means that each cell can only trigger one other cell - once a neighbour cell triggers, that messes up the loop index and prevents it from triggering any other cells.
|
|
#
?
Oct 1, 2015 03:00
|
|
|
Jabor posted:The problem is you've written for(i = 0... rather than for(var i = 0... JAVASCRIPT  A good reason to use "use strict"; in your files.
|
|
#
?
Oct 1, 2015 03:39
|
|
|
use strict and JSHint are so useful that they really should just be counted as essential.
|
|
#
?
Oct 1, 2015 04:05
|
|
|
kedo posted:Here's a jsfiddle with array shuffling disabled (commented out on line 88) if anyone wants to muck around with it. If you mouse over enough pixels you'll see that some pixels on the left do animate, they're just very, very rare. That absolutely murders Chrome on this machine. The browser freezes and by the time it's done 'animating' everything the timeouts have expired, everything is back to default and I'm lucky to see anything. Now I'm going to spend all day wanting to performance tweak it until it runs well.
|
|
#
?
Oct 1, 2015 16:23
|
|
|
Jabor posted:The problem is you've written for(i = 0... rather than for(var i = 0... Well poo poo. That seems to be the case because when I swap it to for(var i I'm getting stack overflows like a mofo. Guess I need to work on this a bit so I don't endlessly trigger pixels forever. Skandranon posted:A good reason to use "use strict"; in your files. piratepilates posted:use strict and JSHint are so useful that they really should just be counted as essential. Also good points. :\ Munkeymon posted:That absolutely murders Chrome on this machine. The browser freezes and by the time it's done 'animating' everything the timeouts have expired, everything is back to default and I'm lucky to see anything. Yeah, it's just a proof of concept at this point. It works okay for me on my newish macbook but it chugs on the girlfriend's old PC. I need to do a ton of testing on it still. I'm wondering if generating a static array of random numbers and using that instead of generating one on every single trigger would help at all... kedo fucked around with this message at 16:32 on Oct 1, 2015 |
|
#
?
Oct 1, 2015 16:27
|
|
|
Not calling parseInt on the same numbers 18 times would probably help, for one  Also, IDs would be faster for lookups than data attributes.Checking for the animating class at the top of trigger prevents stack overflows, as would keeping a map of row/col values that have been visited and simply not visiting them, which would be much faster than checking for a class.
|
|
#
?
Oct 1, 2015 17:08
|
|
|
kedo posted:Well poo poo. That seems to be the case because when I swap it to for(var i I'm getting stack overflows like a mofo. Guess I need to work on this a bit so I don't endlessly trigger pixels forever. All you should really need to do is decrease the trigger chance. Before your bug fix, each triggered pixel would be expected to trigger 0.96 other ones - since that's <1, we would expect it to terminate at some point. After the fix, each pixel would be expected to trigger 2.4 other ones, meaning it probably won't ever stop. You want to get that expected value somewhere slightly below 1 if you want it to eventually terminate.
|
|
#
?
Oct 2, 2015 00:55
|
|
|
Jabor posted:All you should really need to do is decrease the trigger chance. Before your bug fix, each triggered pixel would be expected to trigger 0.96 other ones - since that's <1, we would expect it to terminate at some point. Very good point. I reduced the spread chance to 10% and it doesn't cause stack overflows. However this has me thinking that I need to change how spread chances are calculated. My goal is to have the at least half of the pixels close to the origin animate, and then maybe a quarter of their child pixels animate, and then less for the following generations. Sort of like a spray paint brush in paint. So I think I need to track what generation a pixel is from the origin and adjust its spread chance accordingly. Munkeymon posted:Not calling parseInt on the same numbers 18 times would probably help, for one  Yeah this had a huge impact. I'm going to look into creating a map as well... that's not something I've played with much before.
|
|
#
?
Oct 2, 2015 02:25
|
|
|
So for the whole MEAN stack there's a rarely-updated node thread that seems to mostly involve people who don't know much about node (or had bad experiences with earlier versions) making GBS threads on it, and then there's no thread for MongoDB, Express, or Angular. Coincidence... or conspiracy? Or possibly people not liking javascript on the backend still, in 2015. Asking because I'd like to get a MEAN stack thread going, but if those questions are already getting answered well here, there's not much reason for it.
|
|
#
?
Oct 2, 2015 04:53
|
|
|
my effigy burns posted:So for the whole MEAN stack there's a rarely-updated node thread that seems to mostly involve people who don't know much about node (or had bad experiences with earlier versions) making GBS threads on it, and then there's no thread for MongoDB, Express, or Angular. Coincidence... or conspiracy? Or possibly people not liking javascript on the backend still, in 2015. I'd be interested in that (but not enough to get off my rear end and actually make an OP).
|
|
#
?
Oct 2, 2015 05:17
|
|
|
There was a MongoDB thread but it corrupted itself during a network partition
|
|
#
?
Oct 2, 2015 14:58
|
|
|
There was an Angular thread but it got to be too slow with more than a few posts so now it's a thread about React
|
|
#
?
Oct 2, 2015 14:59
|
|
|
There was a node thread, but the title was too long for the forums to handle it.
|
|
#
?
Oct 2, 2015 17:56
|
|
|
So wasn't sure whether to put this in this thread or the Web Dev thread (which seems to be mostly JS), but... I've been trying to learn JavaScript, and I have a few thoughts. Was hoping to bounce them off you JS Gurus.
|
|
#
?
Oct 3, 2015 21:25
|
|
|
three posted:So wasn't sure whether to put this in this thread or the Web Dev thread (which seems to be mostly JS), but... I've been trying to learn JavaScript, and I have a few thoughts. Was hoping to bounce them off you JS Gurus. They aren't exactly competitors, but they provide a better way of writing front end JavaScript applications that doesn't end up in a mess of JQuery. I like Angular, but it has a lot of baggage from it's early versions. If you use TypeScript and focus on using classes similar to how is described in Angular 2.0, a lot of that can be avoided. Angular has a specific way it wants you to do things, and if it clicks with you, you'll like it. If it doesn't, and you try to use it another way, it'll just make your life hard and you'll hate it. Because JS developers don't want to learn about relational databases. Don't have anything to say about Express. Take a look at VSCode, it is based on Electron and has a lot of added features (Intellisense for TypeScript & JavaScript). Unless you are already attached to Sublime and 100 addons for it, no, you don't need to use it.
|
|
#
?
Oct 3, 2015 21:37
|
|
|
three posted:So wasn't sure whether to put this in this thread or the Web Dev thread (which seems to be mostly JS), but... I've been trying to learn JavaScript, and I have a few thoughts. Was hoping to bounce them off you JS Gurus. quote:Are Frameworks like Angular/React/Ember/Backbone competitors to jQuery? Yes and No, mostly no. jQuery is more of a wrapper around the DOM that made things less painful. Then people started adding a whole bunch of weird poo poo and plugins and started doing jQuery conferences and it's all bizarre. Ember actually still uses jQuery for manipulating DOM stuff and you'll end up using parts of jQuery if you use Ember. Angular 1.x has a dependency on a small subset of jQuery that they provide, and you can peacefully use the full jQuery too. The frameworks are more about structuring front end code, while jQuery is providing a different interface to the DOM of the webpage. quote:React's style of putting so much code together and using JSX seems really ugly to me. Seems like the lack of separation is bad. Angular seems much more visually appealing, but I've read on the forums some folks aren't a fan of it. gently caress separation, Ember separates code and templates and all you end up doing is introducing ugly template helpers to do the things you want to do in code anyway, then you need to have the helpers have their own documentation and tests and asserts and everything and it's just a pain in the rear end. Not everyone likes JSX (those fools) but it's not a bad way of doing things to have your code go right there with your template. If you really want to separate the two just think of every piece of JSX that's straight up HTML as being in a variable, and the code just using the variable instead of having the template inside the code. quote:Why so much love for MongoDB in the JS community? That sounds like a question from 2009 when everyone still loved MongoDB, the tides have turned and now everyone hates it. The only real benefit is that it stores data in a way very very similar to JSON and a bunch of early evangelists (why is this a term people like to be associated with?) promoted the MEAN stack of a bunch of JS stuff that made sense, and also MongoDB because why not. quote:All the tutorials I've seen for Express involve using it to create an API (which is awesome), but are there any other reasons for it? It's the style now that everyone is moving towards having the back-end just be a REST API and having the front-end be entirely static HTML along with a javascript front-end that just sends AJAX requests to the REST API. You can still do the traditional style server side rendering, I've definitely done it with Jade and Express out of the box but I'm not sure where the docs were and this was a major version back so you may have to look at the older docs. quote:I've been using Atom and I like it (but I'm ignorant of anything better), but I rarely see it used in videos. Should I be using Sublime or something else?
|
|
#
?
Oct 3, 2015 21:39
|
|
|
three posted:So wasn't sure whether to put this in this thread or the Web Dev thread (which seems to be mostly JS), but... I've been trying to learn JavaScript, and I have a few thoughts. Was hoping to bounce them off you JS Gurus.
|
|
#
?
Oct 3, 2015 21:47
|
|
|
Thanks dudes. I really love JavaScript so far.
|
|
#
?
Oct 3, 2015 21:50
|
|
|
three posted:Thanks dudes. I really love JavaScript so far. Try not to go too far off the deep end. It's an extremely poorly planned out language that has succeeded largely due to the friction between web browsers. But, if you want to do stuff in browsers, there isn't really another option. "If you can't be with the one you love, love the one you're with".
|
|
#
?
Oct 3, 2015 21:54
|
|
|
three posted:Thanks dudes. I really love JavaScript so far. wat
|
|
#
?
Oct 4, 2015 01:06
|
|
|
That was legitimately hilarious because of his delivery, but none of that's particularly magical if you understand how the + operator works in Javascript. Still, is it stupid that the + operator has special properties the others don't? Yes, yes it is.
|
|
#
?
Oct 4, 2015 04:46
|
|
|
One reason that people like MongoDB is that in most relational databases, schema updates in large-scale production applications are really, really expensive to do. In MySQL doing something as simple as deleting a column can take your application down for hours or days, and while Postgres handles this much better because of MVCC, you basically never see it run at large scale because of a historical attachment to really janky, bad clustering mechanisms prior to the 9.0 release. In Mongo, gently caress it, there's no schema, so there's no downtime for schema updates. Your downtime comes when, without warning, important records randomly go missing from your database instead.
|
|
#
?
Oct 4, 2015 05:15
|
|
|
Vulture Culture posted:Your downtime comes when, without warning, important records randomly go missing from your database instead. I had this happen when I was learning how to use Mongo. Was updating password/salt and a whole bunch of fields just went missing. I don't even know how it happened, but I'm very wary of using Mongo now.
|
|
#
?
Oct 4, 2015 05:38
|
|
|
Vulture Culture posted:In Mongo, gently caress it, there's no schema, so there's no downtime for schema updates. I know it's not what you meant but for anyone reading who wants to use MongoDB: there's still a schema, it's just hidden from your view and derived from your application at different stages of time.
|
|
#
?
Oct 4, 2015 08:31
|
|
|
"Doctor, doctor, it hurts when I add things together that aren't numbers or strings." "Then don't do that."
|
|
#
?
Oct 4, 2015 14:01
|
|
|
Or compare, while you're at it.
|
|
#
?
Oct 4, 2015 14:04
|
|
|
Vulture Culture posted:One reason that people like MongoDB is that in most relational databases, schema updates in large-scale production applications are really, really expensive to do. In MySQL doing something as simple as deleting a column can take your application down for hours or days, and while Postgres handles this much better because of MVCC, you basically never see it run at large scale because of a historical attachment to really janky, bad clustering mechanisms prior to the 9.0 release. In Mongo, gently caress it, there's no schema, so there's no downtime for schema updates. just use postgresql with a single primary key column and a json column 
|
|
#
?
Oct 4, 2015 18:33
|
|
|
Biowarfare posted:just use postgresql with a single primary key column and a json column
|
|
#
?
Oct 4, 2015 20:58
|
|
|
Vulture Culture posted:With the JSONB support in 9.4 and corresponding perf improvements to Generalized Inverted Indexes, this is not an altogether awful idea anymore i am doing this in production with 9.4 and jsonb like right now for a new project started a week ago
|
|
#
?
Oct 4, 2015 23:30
|
|
|
Angular question: My app has a collection, foo, which generates a variety of pages (/foo/1, /foo/2, /foo/3, etc). Foo has a "type" property that can be bar, baz, whatever. If a user is on a foo page and then navigates to a qaz page, I want qaz to know what "type" the user was looking at before they navigated. But if the user goes from foo to some non-qaz page and then on to qaz, I don't want qaz to know. My naive idea is to make some kind of fooSharedDataService with a lastFooSeen variable, have fooController set lastFooSeen when it activates, have qazController check the lastFooSeen, and have the other controllers set lastFooSeen to null. But what I really want (because mandating that every controller ever must interact with fooSharedDataService seems dumb) is some kind of global state thing which I don't know if Angular provides. Is there an Angular tool that can handle a global state thing like this, or alternately is there a better way to solve the problem?
|
|
#
?
Oct 7, 2015 01:01
|
|
|
Tao Jones posted:Angular question: Is it something you can track in $rootScope? It may or may not be the perfect place for it, but it's a start. In the old days of JS i would track this via cookies or browser cookies/session depending on the need. It might not be pretty but it worked.
|
|
#
?
Oct 7, 2015 02:07
|
|
|
geeves posted:Is it something you can track in $rootScope? It may or may not be the perfect place for it, but it's a start. In the old days of JS i would track this via cookies or browser cookies/session depending on the need. It might not be pretty but it worked. Using $rootScope is almost always a bad idea. You have the right idea, create a breadCrumbsService to track this. A service is a singleton, so in effect, it IS a single, globally accessible variable. Anyone that is concerned with knowing about where a user has last been, can inject the service. To elaborate, it's not silly, and not ALL controllers. You may have components in your app which don't care, and thus, don't need it. There is no reason you can't just create var x on the global scope, but it's not the Angular way of doing it. Also, by creating a service, you can put methods in the service which will manage the logic on how the variables get changed, so every controller just needs to call Service.SetActivePage when they get switched to, and the Service can manage the backlog. Where do you store the collection of pages? That should probably be in a Service too, and you can probably merge these things into the same service, since you are tracking the page history. Skandranon fucked around with this message at 02:15 on Oct 7, 2015 |
|
#
?
Oct 7, 2015 02:11
|
|
|
Skandranon posted:Using $rootScope is almost always a bad idea. I hate the idea of rootScope, like I said, it's not pretty. But it can be useful in the worst situations. It's the first thing that came to mind, but I should have suggested a factory. It's more natural to Java devs like me. If you're goal is you still have to track state somehow, root or or a factory object would be a good choice. I'm letting the fact that I hate the implementation of angular that a couple of devs did for my company's app. I wasn't involved in the decision (or dev) and I really wish I was. Because I would have veto'd it (or at least the way that they did it). I'm not against angular at all. I like it actually. But the web devs that we had wrapped our entire app AND javascript within controllers causing major pain and conflicts with new controllers, etc. that we've had to write. That and we still have a heavy reliance on jQuery which just adds to the mess. Those two devs are gone now (they were good, just not wise in the way they implemented angular) and I've moved all the rootscope methods to a factory where they should have been. But we have 1 module they defined and everything conficts if I want to use more than one controller on a page.  I want to hire them back so I can fire them because gently caress they put us in a bad position that I can't easily fix / refactor.
|
|
#
?
Oct 7, 2015 03:20
|
|
|
geeves posted:I hate the idea of rootScope, like I said, it's not pretty. But it can be useful in the worst situations. It's the first thing that came to mind, but I should have suggested a factory. It's more natural to Java devs like me. If you're goal is you still have to track state somehow, root or or a factory object would be a good choice. For the last month I've been working on refactoring a similarly poorly implemented Angular app. They used controllers like services, spawning up 10 of the same controller when they thought they were accessing the same one. However, it all magically worked because they ALSO created a hast table based global variable service that everything got put in, so the controllers ended up accessing the same variables from there, though I suspect this was more a coincidence. How can you not use more than 1 controller per page? Do you mean you can't nest any other controllers in it?
|
|
#
?
Oct 7, 2015 03:28
|
|
|
Skandranon posted:For the last month I've been working on refactoring a similarly poorly implemented Angular app. They used controllers like services, spawning up 10 of the same controller when they thought they were accessing the same one. However, it all magically worked because they ALSO created a hast table based global variable service that everything got put in, so the controllers ended up accessing the same variables from there, though I suspect this was more a coincidence. I don't understand it yet because I'm still figuring things out.... but they made every page its own controller. so: <body data-ng-controller="${actionName}"> (we're based in struts) wraps everything else. The controllers interfere with each other causing a major JS error (what I don't have a complete understanding of), yet. The embedded controller doesn't "fire" or "init" at all and I have no idea why. If I use directives,it works,, but it doesn't answer why the controllers don't. And perhaps that's one of the shortcomings of the 1.x branch that may be better addressed in 2.x
|
|
#
?
Oct 7, 2015 03:42
|
|
|
|
| # ? Jun 6, 2024 08:09 |
|
|
geeves posted:I don't understand it yet because I'm still figuring things out.... but they made every page its own controller. Might be because the controller is attached to the <body> element and you can't have more than 1 of those at a time. I'd just move everything to use directives, it's a much better way to break your app down into components than using ng-controller, and it's much closer to how Angular 2 does things. There should be nothing wrong with having other directives nested within those 'super controllers', and if I was trying to refactor it away, I'd break everything down into smaller parts until the 'super controller' had no actual code left in it.
|
|
#
?
Oct 7, 2015 03:49
|
|