Hi. Il 12/08/2014 15:31, William Di Luigi ha scritto: > On Tue, Aug 12, 2014 at 12:14 PM, Giovanni Mascellani > <mascellani@xxxxxxxxxxxxxxxxxxxx > <mailto:mascellani@xxxxxxxxxxxxxxxxxxxx>> wrote: > > This is, as I already mentioned in my previous email, the same reason to > say that we probably don't want to do the same with tasks: the same > "task" in two different contests actually are two different tasks, not > the same task referred twice. When you modify one of that, you expect > the other not to change (except exceptional cases, but this is trivial). > > > I personally think that it's not always necessary to exactly represent > reality, I mean, if you want to clone a task (for example, because you > have a version where N <= 1000 and another version where N <= 1000000 > where you have to implement a better strategy) you can simply create two > different tasks (mytask, mytask2), but we should not /enforce/ this. > That is: even if it's apparently not realistic, we have no reason to > avoid having an identical task referred twice (the point is: I think > that reality is not a good reason). I'm not sure I understand: two objects with two different properties (like the maximum value of N above) necessarily are two different objects. The point is whether we want to allow two objects with the same properties to actually be the same object. This can happen when you are ok with the following semantics: "When I change something in one object, I ALWAYS want all the other copies to retain the same change". Instead, two identical objects have to be considered different objects although with the same properties when you want them to implement the following semantics: "There is AT LEAST ONE CASE in which I want to change one object and I want the others not to change". (there are cases in which you want to implement multiple references to the same object even if the objects behave according to the second semantics, for example in the case of copy-on-write; but this is just an optimization of the representation, which we definitely don't require) Now, my point is that when you "clone" a task, you nearly always expect the two clones to behave according to the second rule (for example because the cloned task is taken from a past contest, which you don't want to touch anymore). > This i probably unrelated but consider what Misko Hevery has to say > about the Singleton design (anti-)pattern: > http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ > tl;dr «There is nothing wrong with having a single instance of a class, > lots of reasons why you may want to do that», the problem arises when > you /enforce/ a class to have a single instance. I'm not sure I understand why you're citing this. According to me, the conclusion of the post (as the author actually points out in the third post in the series) is to avoid using static and global state as much as possible. I fully agree with this conclusion, but fail to see how this is related to supporting shared tasks. > Also, consider this /real/ use-case (actually happened before): during a > training week there was a selection, but there were some experienced > contestants and some new contestants, so they participated at the same > time in two different contests. These two contests had three tasks each, > respectively: /contest_1/ had task_A, task_B, task_C, and /contest_2/ > had task_B, task_C, task_D. These 4 tasks had the same statement.pdf, > the same limits, the same inputs, and so on. In this case, having the > tasks-contests separation would have come handy. I admit this can be a borderline case. In my opinion, the correct way to handle this kind of contests is to actually make a contests with all tasks and all contestants, tweak ScoreTypes in order not to give points to contestants solving wrong tasks and modifying a bit CWS interface in order to avoid mistakes as yours. If you decide to make two contests, then, in my view, you're implying that the two groups of people are engaging in two different competitions that have no reasons to be related. In particular, there is no hard reason why a task could be changes in one competition and not in the other. So it is better to treat the as independent. BTW, in this and in others cases there may be good reasons to have a tool to clone or merge different tasks. This is entirely reasonable. But it is different from saying that two tasks are the same task. > (Actually, when this happened, I remember that there was a single > contest with 4 tasks and they said what tasks we had to do... And it was > so confusing that I managed to waste almost 1 hour on the only task that > I didn't have to do :P) > > > * cmsReimporter disappears > > o Why reimport an entire contest when you can reimport exactly > > what you changed? (well, actually */italy_yaml/* checks if a > > task has been changed before importing it... this check would > > still be handy, to "warn" contest admins trying to reimport an > > unchanged task, but would become unnecessary). Also, in "my" > > use-case, even checking if tasks have been changed it's still > > quite annoying (we have about a hundred tasks). > > Well, to me the point of a reimported is just that of being lazy and > asking the reimported to mind about the merging details. > > > But cmsReimporter is very hack-ish, because of this merging details > (see https://github.com/cms-dev/cms/blob/v1.1/cmscontrib/Reimporter.py#L261), > correct me if I'm wrong. Well, cmsReimporter implicitly implement just one of the many merging strategies that there may be around. It is the one that was always found to be the more sensible in real environments. In case another should emerge it could be implemented and it should be selectable as a run time parameter. I don't consider the choice of a particular strategy to be a hack. The comment you're pointing to is just a work around some quirks of the PostgreSQL language, which we didn't want to properly investigate (there should be support for checking constraints at the end of the transaction). We don't have infinite time to get around every hard edge you find in development. All in all, cmsReimporter is probably not the best piece of software ever, but it does its job and it's reasonably written. But, exactly, what's the point about it? (BTW, I'm not pretending to represent all CMS developers; there are just my views) Giovanni. -- Giovanni Mascellani <giovanni.mascellani@xxxxxx> PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani
Attachment:
signature.asc
Description: OpenPGP digital signature
