On 14/02/2016 19:40, Giulio Paci wrote: > On 13/02/2016 18:44, Tiago Tresoldi wrote: >> Hello all, >> >> first of all, I started doing some corrections to the code, mostly related >> to comparisons between size_t (unsigned) and some signed variable. I made a >> different commit for >> each file, so you can easily revert it if you want. > > Good! Thank you.
I just had a quick look at the changes. I think most of them was fine. I would avoid leaving too many comments in the code anyway, as comments require maintainance in order to be useful. So I dropped comments that were not very useful. In particular, with reference to primes.c, the comment was useful for me to accept the change without asking, but is not useful in general. BTW: did you really found a compiler that launched a warning in that case (it was a false positive)? The comments about casting are redundant because they just state what is done immediately after, so they are not useful as well. Other less obvious comments (e.g. the comment about alpha and c in met.c), such as those that explains blocks of code or that reminds something that will happen later, are very useful to the reader. With respect to commits comments, it is usually considered best practice to have them short in the first line and leave longer explanations in later lines (you can use more than one line). In this way git log can fit standard terminals width and is not hard to read. >> One questio, Giulio: in et.c, in what is now line 523, why did you add `c` >> as an unsigned long? Is there some particular reason not use size_t? > > Portability when you want to use *scanf and *printf functions. > size_t is machine dependent and related to memory management. It is large > enough to contain any memory address and should be used when referencing > memory. > So it is the right type for malloc, array indexes, elements counting and so > on. On many modern system it is 64bit and often it is defined as unsigned > long. > > unsigned long is also machine dependendant. It is granted to be at least > 32bit and, on many modern system is 64bit as well. > > In *scanf and *printf unsigned long is the largest unsigned value that can be > used portably (including C89-only compilers). And this is why I used it there. > > Anyway, we are already using C99 flags and the z modifier is available in > C99... So this is maybe a non-issue at all. > However, while I am not strict at all about this, I prefer to have > C89-compatible code if possible. > > >> > [scripting and python] >> > >> It is not much ironic in my opinion, because actually Perl fits better >> than other languages only when dealing with text processing and most of the >> programmers do not do >> that in their life, while people doing text processing mostly rely on >> other programmers and examples for programming-related stuff. >> >> >> Oh, you should have seen some crazy Perl code for tagging and parsing >> Brazilian Portuguese that people used ten/fifteen years ago. Being written >> by linguists who learned >> Perl and programming in general as they were writing the system, it was >> unreadable even by Perl's standards. :) > > I believe you. I used to say that perl is a write only language. ;-) > >> Python on the other end has a nice syntax and do a lot of magical >> automatic things that makes programs easier to write. Apparently, because >> when you write without >> overriding them you cannot be sure that your script will work on another >> computer... >> >> >> I suspect that you experience is mostly with Python 2, especially regarding >> unicode. Things did got better with Python 3, in my opinion, but now we have >> the problem of two >> somewhat incompatible systems, with libraries only available to one or the >> other version, and (even worse) with libraries behaving in a different way >> depending on the >> version of the language. Not to mention that most systems don't have >> python3, particularly in commercial solutions. Maybe there's a reason why C >> has stuck around... > > I agree, the situation is much better now that python 3 is getting used more > and more. And indeed, if python as to be used, I would suggest python 3 > should be used. > Consider that a tool containing python 2 code will not be accepted in Debian > anymore (and I still have the goal to try to have acopost in Debian as well). > >> Regarding the corpus, I did not push it, it was already there. According >> to git you added it in 2013. >> I added the test1 script the day after. Now I just converted it to >> produce TAP output and to not need autoconf anymore. >> >> >> Sorry, I should have (git) blamed me... Strangely, I don't remember writing >> that generator, and can't find it among my scripts. I'll take a look at the >> backups later. > > It would be nice to have that tool available. Especially if it can provide > deterministic output that can be used in tests. > > Bests, > Giulio > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ acopost-devel mailing list acopost-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acopost-devel
