Thanks Hin-Tak, I will create a README and enhance the comments inside of the codes and Makefile being guided by docguide and ftrandom (another function inside of the src/tools) documentation.
Best, Goksu goksu.in On 17 Sep 2023 22:23 +0300, Hin-Tak Leung <ht...@users.sourceforge.net>, wrote: > 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, > Goksu > goksu.in > On 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, > > Goksu > > goksu.in > > On 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.
