« first day (365 days earlier)      last day (3951 days later) » 
00:00 - 19:0019:00 - 00:00

19:00
stackapps is an interesting one, because it is one of the very oldest sites.
NO OTHER BETA SITES HAVE GENERALISTS>
From what I can tell, no graduated site (that came from a proposal/beta/graduate system) ever had generalists before graduation.
2
like, we have a bunch of users that technically score the badge, but won't get it until the site graduates?
we have 12 users who qualify, but the tag status was only completed a few hours ago, and, I expect that the generalist badges are awarded by the same script that awards tag-badges like [badge:java], etc.
And that script runs about 3 hours after midnight UTC
For example, look at Stack Overflow:
all the 'first badges' were awarded at the exact same time.
Do you know the specific users, or just the count? Not that I suspect that I'm one of them.
how long have you been qualifying for it?
I have been qualifying for a while now.... probably 2 months?
19:09
that's nice, I didn't realize I was qualified for it!
You would have been helping more with the tag-cleaning if you knew.... ?
@Mat'sMug So close...
So, for three more of these tags below score 15, I need to reach a tag score of 15 or more?
That is your progress.... and, ... you got it.
19:13
I did? You said 12 users qualify, and those show a tag count over 20.
You need to have a score >15 in 20 of the top 40 tags.
You have a score >= 15 in only 17 tags
The exclamation mark in the right column means your score in that tag is not enough.
I saw that. So, I still have some work to do on that, unless it's just a matter of receiving more votes for existing answers.
Good evening everyone :)
@Morwenn Hello.
hi
19:18
hey Morwenn, Jerry, World
I was at the medieval/neo-pagan civil union of two friends these last days. It was great.
@Morwenn Definitely sounds like fun.
37 tests passing. 5 tests ignored. Implementing Hearthstone is.... complicated!
Can't you just say "I went to a cool wedding."
@SimonAndréForsberg What tests of what are failing? :o
19:20
@rolfl It wasn't a wedding. Only a lesser civil union :p
@skiwi (none, they are ignored ... ;-)
The cool wedding of other friends was two weeks ago.
did someone get generalist?
@skiwi No tests are failing. I am just ignoring some tests for now. The mechanics of this dude and this card for example.
Ah... you said ignored
19:23
@Malachi Not yet, but we're expecting them. We just get stars for now. As always.
You have legit cards already at least
@SimonAndréForsberg ok
anyway I was just checking in
and dang it, I missed a day. I hate the difference in time zones
start over
well I didn't miss that day on Superuser? how the heck is that?
@skiwi Yeah, I ignore some tests for which I am not sure on how to do the implementation yet. And there are also some things which I still haven't tested, and are not sure how to test... for example, what happens if you play "Conceal" while having this card on the battlefield? Will it lose it's Stealth ability?
saw that in the Hot Questions list, thought it was a hot meta question!
2
3
Q: Don't Understand Beta Decay

user5404Reading Wikipedia on "Beta Decay" they list the equation of Carbon-14 decaying into N-14. see equation https://en.wikipedia.org/wiki/Beta_decay I presume the 14 refers to total protons and neutrons. The 6 in C, I believe means six protons. In N, I believe the 7 refers to protons. Where did the...

Mail a support ticket to Hearthstone :p
19:29
@skiwi Or rather: Play Hearthstone against a stupid computer opponent and test the functionality. There are a couple of such things I want to test.
:)
@Mat'sMug It's probably only a matter of time until a hot meta question appears. And when it does, it'd better be here on CR.
@rolfl Unfortunately I have to disagree partly with your answer... If I would wrap Collections.synchronizedSet around a HashSet, then add, forEach and many other methods are thread safe. The only ones not thread safe are the iterator, spliterator, stream and parallelStream
1
Q: Modifying HTTP headers in a piped stream

FlambinoNote: This is the first time I've written anything whatsoever in straight C. In other words: I have no idea what I'm doing. I recently had a task that involved temporarily relaying files from one web server, through "my" server, and then on to the client. Along the way, "my" server had to add an...

19:45
What?? ConcurrentHashMap is 6300 lines long
Surprised?
OK, enough Hearthstone for the moment, time to try to write my own Collector...
About 6300 lines... yes
Collector as in Java 8 Collector?
@SimonAndréForsberg Yes. In almost any other language, you'd expect it to be in the high hundreds to maybe one thousand lines or so. Therefore, managing it in less than ten thousand lines of Java is a pleasant surprise.
What's the emoticon for an evil grin again? :-> or something like that?
Good luck with that, they ain't easy to get right at compile-time with all the generics there
19:54
@skiwi Generics is my best friend!
@SimonAndréForsberg Not for long
If you're lazy you can always build on top of existing collectors, but that costs performance ;)
@JerryCoffin I actually lol'ed.
@skiwi What existing collectors can I build on top on?
sigh Can I ask about library recommendations in here? :P
@SimonAndréForsberg All of them
@hichris123 Yes, but expect either primarily opinionated spam or no answers at all :)
@skiwi And where do I find "All of them"? How exactly do you mean?
19:56
@SimonAndréForsberg heh. Don't flag me as spam!
@hichris123 Don't worry, I won't :)
Hang on @SimonAndréForsberg, gaming aswell atm
I need a library to handle large numbers, and calculations with them. Doesn't matter what language, it just needs to be quick & snappy, and reasonably precise (I'm not going to be using decimals, but I need a number to be a whole number).
@hichris123 All I can recommend is BigInteger/BigDecimal in Java, and it's not even a library. It might not live up to your speed requirements though.
How large numbers are we talking about?
Pretty large, maybe 10-20 digits.
20:02
lol, and here I was expecting a googol or a googolplex
Meh, it might be upward of 100 digits sometime, not sure yet.
Well, it would probably be best to have capability before writing code that needs a different type. :P
For my Minesweeper probability code, I work with numbers of the size 10^50 quite often, and I'm only using the primitive type double there.
@SimonAndréForsberg Huh. The only problem I have with a double is that it's floating point... can I round that to a whole number?
@hichris123 int value = (int) Math.round(doubleValue);
@hichris123 Just about any arbitrary precision integer library should handle 100 digits pretty easily. If you don't care about language though, I'd probably use a language that supports arbitrary precision in the language itself.
20:06
@SimonAndréForsberg I like the last few digits hint
@SimonAndréForsberg ... which will that always give the same answer?
double is fast, it is very accurate, it can handle values up to about 10^370, then it suddenly reaches infinity.
@hichris123 I don't see any reason why it wouldn't.
@JerryCoffin Yeah, my main concern is speed, since I'm going to be doing +-/* and possibly pow and such.
@SimonAndréForsberg I meant this with custom collectors on top of existing ones:
@hichris123 Or you could always try this "library", and then review the code while in the process :)
2
Q: What is the proper naming of classes and method when designing API for calculation library?

d-sauerI'm working on library which will provide easier writing and calculation in Java using fluent API. Library have implemented basic functionalities and now I working to improve API. I follow instruction given by this. But still I have some doubts in naming some classes, methods. So I have several...

20:07
public final class CollectorUtils {
    private CollectorUtils() {
        throw new UnsupportedOperationException();
    }

    public static <E, R, X extends RuntimeException> Collector<E, ?, R> listAndThenCollector(final Predicate<List<E>> listPredicate, final Function<List<E>, R> listFunction, final Supplier<X> exceptionSupplier) {
        Objects.requireNonNull(listPredicate);
        Objects.requireNonNull(listFunction);
        Objects.requireNonNull(exceptionSupplier);
        return Collectors.collectingAndThen(Collectors.toList(), list -> {
@skiwi But then, if you did that, you would be blocking the entire HashSet for a much longer duration, and restrict your concurrency
@SimonAndréForsberg rofl
... that's a good way to get people involved in the site! :P
@hichris123 You can, but it only supports limited precision. Double supports up to 10^308, but it uses denormalization to reach that, so at 10^308 you have only about one significant digit left.
Even at smaller values, it still has only around 15 digits of precision.
@rolfl How do you mean?about what code are you talking exactly? (which method of your proposal in your answer)
@JerryCoffin All I need is a whole number, so it should work.
20:10
Based on your other posts on SO, it appears that the synchronized Set from Collections will lock the Set for the duration of the foreach... right?
correct
OK, so then the longest running operation is your foreach on the set.
That foreach will mean, for the whole duration, that no other thrad can access the set.
The solution I proposed takes a very quick, defensive copy of the data, and, only for that time is the set locked.
Then the foreach does not need any synchronization at all.
I see where you are heading
The solution I proposed has better overall concurrency, while still keeping consistent data access, etc.
@hichris123 If your main concern is speed, I'd consider gmp. It's ugly, painful, and generally a horrible design--but it is fast. Closely related is mpir, which is basically gmp ported to work with a few compilers other than gcc (mostly MSVC). If you want to compile for Windows, the latter is probably somewhat easier to deal with.
20:13
maybe going to sound crazy, but what about the following?
Your solution leaks the locks to parts of code that are outside the mechanism.
in fact, I would call it a serious bug: You are doing eventHandler -> eventHandler.invoke(event) inside a locked foreach....
Which is not good at all
and there is no telling what other locks the invoke will have.
@JerryCoffin ok, any tutorials that you know of to get started with gmp/mpir?
@hichris123 Keep in mind that it means 15 digits total, so for a 100 digit number, only the 15 most significant mean anything. The other 85 are basically just filled with zeros--and (for example) adding a number to it that's less than 10^85 will have no effect on the result at all.
20:15
@JerryCoffin Oh, then that wouldn't work.
@skiwi - this, by the way, is a good example of why there is no 'quick way' to introduce people to concurrency/thread-safe locking.
I'm not sure about that statement there, surely there isn't a quick way to learn it, but it is a relatively quick way to introduce
I homebrew the following:
    @Override
    public void executeEvent(final Object event) {
        if (eventClassConstraint.isAssignableFrom(event.getClass())) {
            Arrays.stream((EventHandler[])eventMapping.getOrDefault(event.getClass(), EMPTY_SET).toArray())
                    .forEach(eventHandler -> eventHandler.invoke(event));
        }
    }
But I don't know if this i sgood practice, as I need the cast to EventHandler[] here
One of the lessons I have learned is to centralize lock-signifant operations in to their own methods. This minimizes the places where you have to look for bugs.
Also, the toArray is ugly, and technically wrong.
it is an an array of Object[] and casting it to EventHandler[] can cause problems.
nothing
Not if I 100% know it consists of EventHandler
@hichris123 No, not right off. I should add: I rarely find that last bit of speed really necessary. Roughly 99% of the time, I use NTL instead. It has better documentation, works with most compilers, is much easier to use, and performance is perfectly adequate for most purposes.
20:20
that's true, it was just for iterating, but probably better to move it out
You should use the toArray(new EventHandler[...]));
What about still leaving it in a Collections.synchronizedSet, such that you have the thread safety benefits of synchronization while doing add, remove and toArray (and size), but using the custom approach for iterating?
ie. make a defensive copy that is not under synchronization
You are getting hung up on Collections.synchronizedSet .... Almost always, it is the wrong solution to things. Why do you think it is better than synchronized(set){ .... do stuff ... } ?
like your in includeEventHandler:
synchronized (existing) {
    existing.add(handler);
}
yes.
20:22
That is exactly the same as calling existing.add on a set wrapped in collections.synchronizedSet?
With NTL a tutorial is rarely needed. You include the header, and define your objects to be of the right type, and from there you can just manipulate them like normal ints or whatever -- a = b + c * d; and it "just works".
It may be, but, as you have discovered, synchronization almost always needs locking in a scope that is broader than the simple activity in the set.
@JerryCoffin Huh, okay. Thanks!
You should use just one locking mechanism on ay object... mixing them is bound to end in bugs.
The lesson you should learn, is that thread-safe work is 99% discipline.
I don't see a need to use synchronized() { } if the library provides other ways
20:26
Yes, that is perhaps true, but are they the best ways?
@JerryCoffin That's nice. :D
I think so if they don't impact performance
When I get this working, who knows, I might post it for a code review. :P
I noticed that the method I proposed: private final EventHandler[] getEventHandlers(final Class<?> clazz) { does not need the synchronized block, if the handlers is synchronized, but, there's no way to compile-time ensure that.
This code should be both thread safe and performant:
20:27
(weak argument though).
@Override
public void executeEvent(final Object event) {
    if (eventClassConstraint.isAssignableFrom(event.getClass())) {
        Set<EventHandler> eventHandlerSet = eventMapping.getOrDefault(event.getClass(), EMPTY_SET);
        EventHandler[] eventHandlerArray = eventHandlerSet.toArray(new EventHandler[eventHandlerSet.size()]);
        Arrays.stream(eventHandlerArray).forEach(eventHandler -> eventHandler.invoke(event));
    }
}
I get data from the ConcurrentHashMap, I make a defensive array copy under synchronization of the SynchronizedSet, then I process the defensive copy
That looks OK, but, why do you need to do all that work if the getOrDefault is null?
And, once you have done that.... why not use the code I proposed?
@Override
public void executeEvent(final Object event) {
    if (classConstraint.isAssignableFrom(event.getClass())) {
        Arrays.stream(getEventHandlers(event.getClass())).forEach(eventHandler -> eventHandler.invoke(event));
    }
}
Would it be safe to say that I expect this code to never even go into the default branch in a correctly designed system?
I mean it is for sending messages, so I expect someone to be listening too
We're quibbling over crumbs here.....
And you are correct, your code with extra abstraction may be used aswell and yours is definately at least as correct
no denial in that
20:31
The solution you propose (for this method), is OK, and I would accept it as being thread-safe.
(but i would have to think a bit harder about "why"?
you have a point with the performance though
If you have a threaded situation, it is my (very strong) preference that the locking and control mechanisms are very obvious
2
But in the case of a HashMap you wouldn't want to do it yourself
I often do....
well... ok
20:33
It has the same problems that the Synchronized set would have
ConcurrenHashMap does not magically make things threadsafe.
It means the data in the map is always consistent ... it does not mean your code is good.
or safe
@rolfl If I might add, I think it's also worth emphasizing something you said earlier: obvious and localized. Should all happen in places that are closely and obviously related, not be spread all over everywhere.
2
I agree with that too.
That would depend on what kind of objects you store in it and what you do with them
Concurrency is one of the hardest things to get right, and it is harder to get high performance too. It is especially hard to communicate the details about, and almost impossible to test. It is one of those places where the value of a good Code Review is most obvious.
So getOrDefault is also kind of evil in threaded situations performance-wise I suppose
20:37
getOrDefault is not wrong, but you have to understand why it is useful, and use it in a way where it makes sense.
a lot of the work in ConcurrentHashMap is so that you can do atomic operations on the map.
getOrDefault is one of those operations
I don't know lots of places where it would when working with concurrency
hmm so theoretically this code would be as performant as the one you suggested, but (debatably) it would be harder to read:
@rolfl It's what (if memory serves) prompted Dijkstra's famous comment about testing never showing only the presence of bugs, not their absence.
@Override
public void executeEvent(final Object event) {
    if (eventClassConstraint.isAssignableFrom(event.getClass())) {
        Set<EventHandler> eventHandlerSet = eventMapping.getOrDefault(event.getClass(), Collections.synchronizedSet(EMPTY_SET));
        EventHandler[] eventHandlerArray = eventHandlerSet.toArray(new EventHandler[eventHandlerSet.size()]);
        Arrays.stream(eventHandlerArray).forEach(eventHandler -> eventHandler.invoke(event));
    }
}
Here nowhere I waste time in a lock
eventHandlerSet.toArray(new EventHandler[eventHandlerSet.size()]) is in a lock, but not wasted time.
The source of the synchronization is complicated, because you don't know whether you have a Collections.synchronizedSet(EMPTY_SET)) or some other set.
(or whether that other set is synchronized at all).
@rolfl Is there ever any way to ensure anything with synchronization and concurrency in compile-time?
20:41
Other than because you have access to other parts of the code.
@SimonAndréForsberg Yes... I never 'abstract' Concurrent* classes ... so, ConcurrentHashMap<A,B> is never Map<A,b>, etc.
@SimonAndréForsberg The compiler would need to be able to do concurrency validity checks, but how are you going to check it between your code and some other library?
All the synchronization is obvious in the code.
actually, the bytecode may be good enough, so you have a point there
if everyone would use that same compiler, then clients of code using concurrency intermangled with existing library code, would trigger warnings from the compiler
@rolfl That's a guarantee the implemented class needs to be provide
@skiwi My only real criticism for that code is the unnecessary work being done when the data does not exist. The code i proposed in my answer to your question, does the unnecessary work too, so I can't complain too loud.
@rolfl What unnecessary work would there be done, do you think? (When the data does not exist)
20:45
@skiwi Yes, I agree, but you have to look in other parts of the code to check/confirm
@rolfl SEDE time!
@rolfl What about ConcurrentMap then? Wouldn't that suffice, rather than Concurrent*Hash*Map?
Sure, ^^^^ OK, fair point. But habits die hard ;-)
@skiwi - edited answer with less work option....
2
A: My EventBus system

rolflThe synchronization in the code is in some places overly broad, and in others, it is absent where it is needed. synchronizing on eventMapping in your registerListenersOfObject method means that only one thread can be accessing the eventMapping instance at any one time. This defeats using the Con...

I have another solution that has no null-checks and same performance ;) Yes... I may have something in principal about null checks
Thanks Santa!
20:50
It's also less lines of code
readability is more important than LoC
It's also still readable
And null can be valuable information.
    private Stream<EventHandler> getEventHandlers(final Class<?> eventClass) {
        Set<EventHandler> eventHandlers = eventMapping.get(Objects.requireNonNull(eventClass));
        if (eventHandlers == null) {
            return Stream.empty();
        }
        return Arrays.stream(eventHandlers.toArray(new EventHandler[eventHandlers.size()]));
    }

    @Override
    public void executeEvent(final Object event) {
        if (eventClassConstraint.isAssignableFrom(event.getClass())) {
            getEventHandlers(event.getClass()).forEach(eventHandler -> eventHandler.invoke(event));
And eventHandlers is a synchronized Set?
20:53
yes
I can accept that.... it is OK.
The synchronization is not obvious... but, it is there.
Nested.
Leads me to question why they didn't make the SynchronizedXXX interfaces public
Out of interest, there is a potential bug....
A null pointer exception on eventHandler -> eventHandler.invoke(event)
If you'd manage to get null eventhandlers in the class
hehe ... yup, your code is buggy.
20:55
Would it be a bug though?
it is not that hard.
What would be the bug though?
The line of code:
 eventHandlers.toArray(new EventHandler[eventHandlers.size()])
I don't expect to work with nulled EventHandlers, so if I encounter one, either I or someone using the library has made an error by inputting a null element?
^^^That line of code could introduce the null.
Here's the process....
Thread1 calls `executeEvent.... which, in turn calls the getEventHandlers().
It gets to the line eventHandlers.toArray(new EventHandler[eventHandlers.size()])
This happens in two steps. Step 1 is:
eventHandlers.size()
Which, for example, returns 10.
Then, Thread 2 gets a lock on the set, and removes an element.....
Now, when step 2 in thread 1 happens, the call is eventHandlers.toArray(new EventHandler[10])
But there are only 9 members in the set.
So, the code leaves position 10 as null.
20:59
eventHandlers.size() will lock the entire set, so thread 2 cannot obtain a lock
Yes, but, it then releases the lock, before toArray is called.
(which locks it again).
that's just plain evil
Yes.... whch is why concurrency is hard.
Bugs like this are prolific, but so intermittent, that they seldom happen.
When they do, it is impossible to diagnose.
(or nearly impossible).
I don't know
Which brings me back to the code I proposed......
21:02
Can't I just have a loop running for a minute or so, that just continiously tries all structural changes?
(as a test)
synchronized(handlers) {
    return handlers.toArray(new EventHandler[handlers.size()]);
}
^^^ no bug.
@skiwi
34
Q: How to run concurrency unit test?

janetsmithHow to use junit to run concurrency test? Let's say I have a class public class MessageBoard { public synchronized void postMessage(String message) { .... } public void updateMessage(Long id, String message) { .... } } I wan to test multiple access to ...

I see
I gotta call it a day though, tomorrow finalizing the 'new concept' then and posting a follow-up I presume
Want to share this: quickmeme.com/p/3vw0y7
2
@skiwi You can try--and it might catch the bug. Then again, it might not. Back when having multiple physical processors was fairly new, I saw quite a bit of multi-threaded code that had run for years without any problem suddenly start breaking, quite frequently in a few cases.
@skiwi cheers... sleep well.
21:04
@rolfl And when wrapped inside a synchronizedSet, you are lacking performance because of double locks
@skiwi Good night.
But... I still have one other thought
private Stream<EventHandler> getEventHandlers(final Class<?> eventClass) {
    Set<EventHandler> eventHandlers = eventMapping.get(Objects.requireNonNull(eventClass));
    return (eventHandlers == null)
            ? Stream.empty()
            : Arrays.stream(eventHandlers.toArray(new EventHandler[0]));
}
This will not give any concurrency issues
Double-locks in and of themselves are not really a performance problem, just make a complicted thing, more complicated
toArray is required to return a new array (calling size() within the lock of toArray)
@skiwi Not that I know of.
21:07
Why would I even ever specify the array-size if I do not want to replace the elements in an existing array?
Because, .... performance
What gain is there?
The return types of toArray() and toArray(Something[...]) are different
Both calls need to query the size, and both calls create a new array
I'm not talking about toArray() though
Yes, but toArray(new Something[0]) needs to create two arrays
and with reflection involved.
21:11
@rolfl no, the new EventHandler[0] is just a cached new Object[0] that is typecast at runtime
No, it is not.
Arrays have a Type.
every empty array in the universe is the same, not?
No.
Arrays have a type.
T[] r = a.length >= size ? a :
          (T[])java.lang.reflect.Array
          .newInstance(a.getClass().getComponentType(), size);
21:13
So then it would be determining the cost of the reflection
got to go though, will continue tomorrow
And, you have to supply an array, which gets discareded.
The performance hit is small,and often negligible.
0
Q: How much code is considered too much?

eruano57I am posting this code up for review and debug. This source code is for java, and is meant to give you the exact day of the week, from a date entered. Review This program seem to have 2 case statements, would it have made sense to use an enum variable to eliminate the second case statement? ...

@skiwi - and there ends the shattering of the concurrency safety that Java provides
When you read JCIP, it will be even worse.
On the up side, Java concurrency is many times better than other languages. ;-)
Thanks again, Santa!
@rolfl What have I done now?
21:41
SEDE one-more-vote ;-)
21:51
Right, I have manually checked all sites.
There are no betas that have generalists.
5 sites never went through the beta process SO, SU, SF, meta, StackApps
4 of those sites have generalists.... stackApps still does not.
17 graduated sites have generalists. (and none of these had generalists before graduation).
21 graduated sites do not.
Apart from Code Review, no beta sites have generalists.
Then we shall be the first!
2
In other words, Code Review is more established (using this measure) than all other betas, and more than half graduated sites
Dinner time.
22:15
I love java.time in Java 8:
1
A: Output day of the week from given date

Simon André ForsbergFormatting Your intentation is a a bit off. Please improve that. Use your IDE's automatic indentation keyboard shortcut for an easy fix (Ctrl + I in Eclipse). In Java, braces go on the same line, for example public class DateCalc { becomes public class DateCalc { Your questions This ...

0
Q: For loop in javascript

Michal StefanowWhether it is Java, C#, C++ syntax for the for loop looks like that: for (int i = 1; i <= 5; i++) { // something } http://www.cplusplus.com/doc/tutorial/control/ http://msdn.microsoft.com/en-us/library/ch45axte.aspx http://docs.oracle.com/javase/tutorial/java/nutsandbolts...

 
1 hour later…
0
Q: Traffic Light VBA code

RockstarheroCan someone review this code for me, i'm not completely sure I did this correctly. I also would like help creating the code for the "walk" "don't walk" lights. In the vba I needed to create a traffic intersection. Each traffic light has a cycle of 31 seconds red, followed by 26 seconds green, fo...

00:00 - 19:0019:00 - 00:00

« first day (365 days earlier)      last day (3951 days later) »