Hi Ahmet. I'll leave Werner to say something definitive, but in my opinion, given the project will be put aside and/or merge with some incomplete area soon, for some possibly long period before you or somebody else revisit the tasks/goals, it is particularly important to document things clearly. Not just in terms of formal documentations in the various readme's, but also adding "TODO", "Known limitations" in the code. Like "notes and reminders to future self" if you need to come back to it and continue after 5 years :-).
As for meson and cmake - if you do add/change something at this stage, be sure to write a bit more about what state it is in, in the commit message. It will be quite annoying for somebody else, or you yourself for that matter, to look at some large chunk of code in a year or two, and think: "what state this was in, did this work at all? Has this gotten broken recently, or never did work?". I think one example might be qt6 support for ftinspect - there are some work/code going towards it, but it would be nice to see a comment where it matters - around where one might switch from qt5 to qt6 - that it doesn't quite work yet. There are always going to be incomplete/work-in-progress areas, so the general direction would be write down things clearly so you or someone else can revisit later and continue with as much help and information as you can give now.
On Sunday, 17 September 2023 at 12:35:08 BST, Ahmet Göksu <ahmet@goksu.in> wrote:
Thanks Hin-Tak,
I am developing on a Mac.
Also,
While there are less than 10 days for final evaluation, there are points that are not completed:
*meson
*cmake
*documentation
because of our focus a bit changed, didnt worked on them much. Should I complete them all? Is there a priority?
On 17 Sep 2023 02:31 +0300, Hin-Tak Leung <htl10@users.sourceforge.net>, wrote:
I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.
https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime
So unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it.
On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu <ahmet@goksu.in> wrote:
Hello,
-I have changed the * and the sentence
-changed the links to relative
I already changed the working way of the timing. I only start the
benchmark at beginning and stop at the end.
i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test.
BTW, I suggest that you add another sentence, explaining *why* there
are two values at all.
actually, i didnt get the reason well but it may differ even with same flags. i need help in this case.
as i said before, i run the benchmark in mac. it uses this if clause.
return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC;
the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine?
On 12 Sep 2023 18:17 +0300, Werner LEMBERG <wl@gnu.org>, wrote:
If a value in the 'Iterations' column is given as '*x* | *y*',
values *x* and *y* give the number of iterations in the baseline and
the benchmark test, respectively.