Thanks all for a feedback! I really feel that i'm not alone :) > Vikenti did you check the Entreprise Pharo book because it contains > nice chapters from svn on cahracter encoding.
Thank you, i'll take a look at this chapter. And i'll look at gettext. > Did you report it? Yes, i reported it from Pharo IDE. If i need to create a ticket in some bugtracker please explain me where and how to do it. > We are slowly deprecating the old streams (because they are messy) and > replacing then with ZnStreams. > Now if you want to help this would be useful to produce a better Pharo. I'll be glad to help to make Pharo better. I think there's some basic tasks every language\platform should do. For example, starting from windows 3.1 there was a way to put resources with application and load it - strings, images, bytearrays. Delphi goes further and created the advanced system to store almost any resource in simple standard way. And so on. Now, we live in 2017 year, XXIst century has come and for me it is very strange to solve such standard tasks every time i need it. I feel like i'm back to 90's - first of all, you waste your time to create libs for all your stadard needs, then you begin to create applications. I think, Pharo is very great system, but lacks of some basic things to create commercial applications (and to involve more people!). These things (in my case) are: 1. standard way to create UI. Spec is great, though it has some bugs (i put a treeview into tabbed view and have some unpredictable bugs with drag-n-drop while alone drag-n-drop works fine if not in tabbed view). If there will be a form constructor like in Cincom VW, Dolphin Smalltalk or ... QT designer - it will significantly lower time costs on constructing lots of forms and. This is the way that make Delphi popular, and now Lazarus goes this way. + there should be documentation on creating custom components. Pharo book contains more on this topic but not all. Lots of time is wasted to look for code and understand what is going on. 2. Common way to store resources. Like in Cincom VW - "install bytearray on accessor" or via text representation. It is simple but we always waste time to create some unique mechanism to load resources. We shouldn't waste this time, just need to make few calls using single simple api. 3. I18n. The app i working on now need english\french\german + russian + chineese\japaneese + (maybe arabic) languages. It was simple to do this with Cincom VW but it is hell with Pharo. Even Delphi from yearly 2000 could do this. 4. Deployment of applications. We don't play childish games, we are not students, we make serious applications for serious tasks, and we want to sell them, so we must have a common tool to delpoy: - strip code - maybe some cryptography on loaging code or hash-sum to check if code is changed by third side. - create a number of files for simple start of application. And this tool should work on all main systems: windows, *nix, MacOS. (+ optional additional functions to check license key\generate licenses etc). These tasks are always solved in commercial - oriented solutions. And while Pharo has no standard ways to do them ... there will be less big projects despite the fact Pharo is very powerful platform. It is only my opinion. best regards, Vikenti Potapov.
