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 <ah...@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?
Best,Goksugoksu.inOn 17 Sep 2023 02:31 +0300, Hin-Tak Leung
<ht...@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 <ah...@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?
Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG <w...@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.
