User may choose what languages are needed and reduce distro/RAM usage size. Also I suspect that many parts of ICU data are currently not referenced from Haiku code at all.
But we donât know if those parts are required by (future) apps inside the depot.
What might work is splitting up the ICU package into a few smaller packages so data for unneeded languages doesnât have to be installed by default, but can be installed after the fact if something needs it. Not sure if itâs really worth the effort, though.
1 Like
I criticized a library specifically ⌠that is WIDELY known to be bloated. And even explained WHY it is bloated. And compared it to the alternatives, ICU could DEFINITELY be replaced by about 1-2MB of libraries vs the 30MB it hogs.
Iâm not even going to give response to the rest of what you said. Go touch grass.
Your response in this instance is in my view inappropriate.
Youâve not provided any alternatives to ICU or done any discussions on it, the response here is just overly negative and does not help. Engaging constructively would be great, for instance identifying parts haiku does use ICU for, and seeing what other libraries or homegrown could could replace it, and if ICU is even bloated there in the first place.
Based on total install size iâd argue fonts consume way more âbloatâ currently than this one library.
Iâm all for cutting out useless/âbloatedâ data needed to be loaded into RAM, or shipped on CDâs, downloaded from servers etc. But unless you engage constructively there it is just perceived as âI hate this lib!â and nothing more.
Perhaps engageing in the two points pulkomandy mentioned would be a better start.
Begasus for example is working hard to cut down the ICU versions to one for haikuports. It would be nice if somebody could investigate the gcc2 problem.
Or maybe write an extension for clang so it can produce gcc2 equivalent name mangling and we can drop it alltogether and just use one compiler. : )
3 Likes
Interesting idea, create an extension that generates binary compatibility with Beos in clang 
It is necessary to examine what is essential for gcc2 to add the extension.
I think thatâs a bit of a dream. The reason the gcc2 mangling was abandoned and replaced is that it didnât work: some different C++ constructs would end up generating the same symbol name and clashing with each other. Also, thereâs probably a bit more to it than the mangling (things like exceptions, etc).
So, something like this may work, somewhat, with limitations, and it will be a lot of work. All of that just to run some 20 years old BeOS applications. Iâm not sure itâs worth the effort. (well, itâs not worth my efforts, but if someone thinks otherwise, feel free to have a try).
Yes, that is a problem now too. I expect this would only work with some compiler specific instructions telling it how to mangle stuff. In essence we would have to explicitly define which calls need beos compatibility and how that looks. perhaps this is too difficult, I donât know.
To me the current situation of having to use two compilers does not make stuff easier there. Personally I donât use and have not used any BeOS applications, if there was a 32bit compatibility layer on 64bit i might. But not like this. Anyway, I am seeing this is again too offtopic. so I am splitting this.
1 Like
I heard that ICU has an option to store data in separate non-executable files instead of shared libraries (it use mmap I suppose). What is a problem to use that?
2 Likes
Yes, it is possible to generate a .dat file separate from the executable:
It is possible to use these llvm-gcc and PDFs projects as references, links:
https://releases.llvm.org/2.9/docs/CommandGuide/html/llvmgxx.html
https://releases.llvm.org/2.9/docs/CommandGuide/html/llvmgcc.html
ICU documentation says it may not work if you use the same data for different versions of ICU. Not that they intentionally prevent it, but they donât test that case.
Since we are using a much older version to build with gcc2, and a recent one with gcc13, we may hit such a problem. But we wonât know for sure until someone tries it, maybe it will work just fine.
2 Likes
A rational compromise
dotnet guys, are using .dat files to reduce the size of executables and reduce memory consumption:
Links to consult:
Using .dat files will reduce the size of Haiku executables and memory consumption.
2 Likes
Then do so yourself instead of just amping up the drama. And yes other alternatives HAVE been mentioned in this thread, I saw no need to steal anyone elseâs thunder.
Iâll skip over the âwidelyâ part because Google doesnât seem to know no such thing.
No, you did not explain why, because the reasons you gave are not true or based on wrong assumptions.
ICU is internationalization library and it always was.
People who need to implement internationalization do, and operating systems especially need those.
If you have an app developer that needs to handle UTF-8 conversions and chooses ICU to do that, then Iâd argue itâs not an issue with the library being bloated.
5 Likes
Google can barely tell the difference between ICU c++ library and intensive care unit books these days⌠the worsening of google search is also a well known fact.
No it is not. Iâve not used google in years and have no idea what its quality is. Maybe your well known facts are not as well known as you think?
And really, it is completely irrelevant whether you think it is well-known or not, what matters if your discussion partner knows, if he doesnât it wouldnât hurt you to actually talk about it instead of assuming they must knew when they clearly donât.
They your reliance on google search in your comment is just about as far off as my STL usage in ICU then isnât it⌠see I can handle a bit of self deprecation lol.
if what I know or not is so important, perhaps actually having discussions rather than flame wars would actually happen. That would actually be beneficial you knowâŚ
My comment? Iâm not KapiX
If you complain about something at-least provide evidence, that would be the part of what you know or do not, and might provide an actuall discussion.
I was replying to you Iâm not sure why you think I wasnât.
https://www.google.com/search?client=firefox-b-1-d&q=worsening+of+google+search
Yes worsening of google really is a thing⌠Dozens at least hundreds of news articles about it in that search ironically. They inject a ton of irrelevant âcontentâ results into every search now and often youâll only get keyword results rather than results for a specific query lie you used to be able to get easily.
Anyway this has gotten a bit off topicâŚas there were quite a few interesting replies above.