hey, i have done the changes you want forcing to push the repo.
i am used vscode whitespace settings, is there any other mistakes to fix?
Best,
Goksu
goksu.in
On Sep 25, 2023 at 7:33 PM +0300, Werner LEMBERG , wrote:
>
> > I hope my effort contribute to you. I wish to see you again.
>
> :-) You
> I hope my effort contribute to you. I wish to see you again.
:-) You are invited to continue your work even after GSoC has ended.
> Here is my last version of readme, [...]
Uh, oh, the formatting in the e-mail is completely broken...
> i will push submit my final submission regarding your
Thanks a lot :)
I hope my effort contribute to you. I wish to see you again.
Here is my last version of readme, i will push submit my final submission
regarding your feedback. (also waiting for *-demos code review, i will push
them too)
>
>
> ftbench
> ftbench is a program designed to
Hello Ahmet,
sorry for the late reply, I'm travelling right now.
> -Made documentation and comment line (will continue).
Very nice! Some minor nits, in case you have still time today:
* Please ensure that lines in the documentation are not longer than 78
characters
Hi,
I have created a new branch.
Here you can see it:
https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-2023-ahmet-final
-Made documentation and comment line (will continue).
-trailing whitespaces cleared
-more verbose commit messages
-formatted the code.
In this version of the code,
Hello Ahmet,
> -I have changed the * and the sentence
Thanks. Unfortunately, I was unclear that '*x*' in my e-mail is meant
as Markdown syntax and not to be taken verbatim. In other words, 'x'
should be typeset in italics, similar to a mathematical variable.
Sorry for that, and please fix.
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 , wrote:
> Hi Ahmet. I'll leave Werner
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
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,
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
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
>> With 'bulk test' I mean that you don't time single iterations but
>> do timings for 10 iterations in a group, say, thus avoiding
>> issues with the granularity of the OS timing functions.
>
> I already changed the working way of the timing. I only start the
> benchmark at beginning and stop
12 matches
Mail list logo
