KARMA! posted:

Why would a toString on a function even work?

Internet Janitor posted:

eithedog: The readme does address this. A line continuation using \ will not insert newlines automatically when you continue the string on another line. You'd need \n\.

KARMA! posted:

Why would a toString on a function even work?

eithedog posted:

Oh, sorry, didn't read the comments, I've read the code you posted. Are there any situations when manipulating HTML actually needs \n?

Subjunctive posted:

I think prototype and jQuery also used decompilation, one of them in order to recompile in the context of another frame.

Internet Janitor posted:

Isn't this the sort of situation bind() is meant for, or am I misunderstanding the issue?

Jabor posted:

"Different frame" as in, an iframe or whatever.

In terms of memory use, it's a pointer and a length per function-statement (not per function instance), which you can stick out of the critical path (e.g. off in the AST which is only looked at if you need line numbers for a stack-trace or need to recompile because your optimistic optimizations were invalidated) to use the function declaration as it's written in the source. This seems way easier than decompiling your AST into semantically equivalent code every time.

fritz posted:

The guy I have to work with broke the CI server (as in, like, totally hosed and now it won't run on any branch at all) and all he had to say was, almost literally, 'it works on my machine'.

Cheekio posted:

I keep thinking that projects written in Javascript is a fad that will go away, and then I see something like this: http://breach.cc/

Subjunctive posted:

Yeah, there's basically a call and response if someone blocks deploy:

"aw man, it worked on my dev server"
"np, we'll just route all the users to your dev server"

Subjunctive posted:

Yeah, there's basically a call and response if someone blocks deploy:

"aw man, it worked on my dev server"
"np, we'll just route all the users to your dev server"

substitute posted:

Designers are the worst.

code:

body.derp ol {list-style:disc; margin-left:15px;}

...10 lines later...

body.derp_derp ol {list-style:disc; margin-left:15px;}

YES, it's perfectly logical to make an ordered list look like an unordered list, and to do it multiple times throughout your CSS.

Subjunctive posted:

How much of a PITA is it for them to change the markup that's emitted for just those cases?

Lumpy posted:

They're already doing all that work to add the derp class to the body. You want the to do more? You monster.

Dicky B posted:

What does the Qt VS plugin do? I've used Qt for years and can't imagine needing any kind of IDE plugin to "cope" with the signal/slot syntax. I'm all for trying it if it makes my life easier somehow though.

substitute posted:

Designers are the worst.

code:

body.derp ol {list-style:disc; margin-left:15px;}

...10 lines later...

body.derp_derp ol {list-style:disc; margin-left:15px;}

YES, it's perfectly logical to make an ordered list look like an unordered list, and to do it multiple times throughout your CSS.

Hammerite posted:

I thought the choice of ordered vs. unordered list just indicated whether the order of the items matters. As in, if it's an unordered list then the list items' order can be changed and it doesn't matter. I see no reason why you shouldn't use bullets but still care about the order of the list items.

baka kaba posted:

Me again, with the unit tests (in Java specifically).

This is really a general approach question that I haven't really got the hang of - what do y'all usually do when testing a method relies on another one working? The simplest example is a getter and setter pair - testing the setter involves testing the getter too (unless the variable being set is exposed, or you can expose it through a stub). You can't actually test one method call in isolation, because you need to call another to get your results.

Are there any general approaches for this? Do you just compromise and test 'setting and getting', and then use them for setting up and checking your test cases? It just seems to break the whole idea of not having tests rely on other tests, if you break something in your set/get code it'll cause failures all over the place. And making private variables public (or protected so you can make some stub methods) seems like a compromise.

Generally I'm tempted to go the protected/stub route, it works well when the visibility already allows it, but I'd like to hear some other suggestions if anyone has any

HardDisk posted:

Then you should use ul instead of hacking css to do it with ol, but worse.

Hammerite posted:

I'll try this again. ul is an unordered list. Therefore if you care about the order of the items, isn't it appropriate to use ol (ordered list) even if you want to display the list items with bullets?

I mean, I think I was pretty clear in my post before. If you think I'm wrong, then fine, say so, but it seems like what I was saying went straight over your head.

Ithaqua posted:

Don't test get/set methods unless they actually have some sort of logic in them; it's wasted effort if they don't. That said, I'd write test cases for the get/set methods as one cohesive unit. Your only concern is that if you put value X in, you get value Y out. It doesn't matter if it's mutating as part of the get operation or the set operation. Other parts of your application might care about that distinction, but you'll write other tests that will cover that aspect.

Don't go crazy with mocks. Purists will tell you to mock out every single thing that goes into every single class, but there are going to be times when that's impractical or silly. Apply common sense liberally. Java actually has an easier time with mocks since everything is virtual by default, so you don't need to sprinkle virtual keywords everywhere or rely heavily on single-implementation interfaces like you would in C#.

HardDisk posted:

Then you should use ul instead of hacking css to do it with ol, but worse.

Internet Janitor posted:

Since Qt uses its own magic preprocessor to add features to C++ you could almost argue that it is a distinct language from C++.

fritz posted:

The guy I have to work with broke the CI server (as in, like, totally hosed and now it won't run on any branch at all) and all he had to say was, almost literally, 'it works on my machine'.

baka kaba posted:

Cheers, I posted that in completely the wrong thread so uh thanks for the genuine reply! I've just been trying to get into the 'don't have tests relying on other tests' mentality, and this feels like it completely violates that idea. It seems mostly harmless when your methods are simple, but when they're not (or if they get more complex later) it could introduce problems where the cause isn't immediately obvious. That's what I'm worried about really. But yeah, wrong thread!

hobbesmaster posted:

Theres no magic preprocessor, signals/slots is standard preprocessor stuff which is also used by boost::signals. The declarations like Q_OBJECT are also expanded by the standard preprocessor. moc automatically generates C++ code for classes containing Q_OBJECT and other macros in scanned headers - you're free to create the C++ metaobject functions yourself if you hate maintainability.

Hammerite posted:

vOv posted:

Subjunctive posted:

Subjunctive posted:

I thought it was choking on the "slots: " pieces in the C++ files, but as has become eminently clear I may in fact be the Qt PEBKAC hazard. Tool ergonomics are still lovely, though.

HardDisk posted:

I see now. I still think there's something wrong when you want to present something with an order and not order it somehow (not accounting for the positioning in the page, which is a type of order in itself).

hobbesmaster posted:

Just use Qt creator, the visual studio plugin has always seemed a bit broken. Its supposed to read in qmake .pro files and manage qt versions and such but seems to be more trouble than its worth to me.