Hello once more.
Thanks for the single answer I got asking to take part. But I need one more booth supporter, preferred are team members. You have time till today evening to answer, otherwise I am not sure if I should blindly reply with the yes aka we will take part in CLT the team behind it is waiting for. In the end I reply and no one shows up. It is up to you. I got my holidays accepted last year already for being able to take part. What about the rest of the team who did not reply with a good reason not to take part already?
Greetings
Daniel
Daniel Reimer <daniel.reimer(a)reactos.org> schrieb am Sa, 03.02.2018 14:54:
> Hey guys,
>
> as every year, I need volunteers for the booth on Chemnitzer Linux Tage
> (https://chemnitzer.linux-tage.de/2018/en).
>
> This year it's on March 10-11. Anyone who has some spare time for it? I
> need at least two ppl for these days, otherwise I have to cancel it.
>
> Greetings
>
> Daniel
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Hello,
I'd like to propose a change for the 'Size' field:
Currently this is a localized, pre-formatted field.
By changing this to the actual size in bytes:
- We can use StrFormatByteSizeW to format it locale dependent (without
the need to manually translate it)
- We can use this value to display the progress bar, in case the
download itself does not provide this value (for example, web.archive
does not provide this).
For backwards compatibility we should probably add this as another
field, so that the 'old' rapps can still read the 'Size' field.
Regards,
Mark
Hey guys,
as every year, I need volunteers for the booth on Chemnitzer Linux Tage
(https://chemnitzer.linux-tage.de/2018/en).
This year it's on March 10-11. Anyone who has some spare time for it? I
need at least two ppl for these days, otherwise I have to cancel it.
Greetings
Daniel
Hey Amine,
seeing https://jira.reactos.org/browse/CORE-14288 just prompted me to
look into static vs dynamic 3rd party libraries, zlib and libxml2 in
particular. We use zlib in a bunch of modules these days, and libxml2 is
large and used in two, so I'm thinking we should make them dynamic.
I just did the experiment for libxml2 and it resulted in at least 0.5MB
binary size reduction and 2MB build folder size reduction, so clearly
seems worth it.[1] I'll do the test for zlib as well to make sure that's
also an improvement.
However I was thinking there might be a reason why we build those
statically right now. Do you (or anyone else) recall anything that makes
switching to dynamic a bad idea?
Thanks!
-Thomas
[1] Raw results:
Static libxml2 (MSVC debug with RTC):
msxml3.dll - 1887 KB
libxslt.dll - 1142 KB
libxml2.lib - 4953 KB (build dir only)
Dynamic libxml2 (MSVC debug with RTC):
msxml3.dll - 799 KB
libxslt.dll - 259 KB
libxml2.dll - 1592 KB
libxml2.lib - 371 KB (build dir only)
Static libxml2 (GCC debug with -O1):
msxml3.dll - 3856 KB
libxslt.dll - 2776 KB
liblibxml2.a - 48 KB (build dir only)
Dynamic libxml2 (GCC debug with -O1):
msxml3.dll - 1505 KB
libxslt.dll - 429 KB
libxml2.dll - 2553 KB