April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] changing default theme to DarkTheme

by Stephan Eggermont

On 14/04/17 09:09, Esteban Lorenzano wrote: > I wanted to let you know that we talked at the board and we want to make the DarkTheme a default for Pharo 6.0. > This is just because we want to have a visual immediate reference of changing things (yeah, marketing ;) ) No. Please revert that decision. It is too late. You can try that for 7, and then have the discussions, but not for 6. Stephan

April 15, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by nacho

Why not have a "mini-config" sort of splash screen (as Squeak now does) and let the user select? In that mini-config we can proudly announce 10 timesRepeat: [ 'Pharo 6 is out ! (and it is great)'] cheers Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/changing-default-theme-to-DarkTheme-tp4942038p4942203… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 15, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Dimitris Chloupis

Thats the illusion of people who complain , because they are so vocal , they think they are a majority when actually they are a small minority. I call this "The tyranny of noise". Its in our nature to focus on the noise and ignore the silence. I am a huge supporter of Dark Themes, they are friendlier to the health of the eye and much friendlier to the environment too. Their objective value cannot be questioned. But as always personal taste plays a role here. Whether people prefer more light to dark themes, is difficult to say. Even though most apps come with default light themes, two common patterns emerge. a) White themes are almost non existent (I cannot even recall another app besides Pharo that has a white theme) b) Dark themes are at worst the second preferred choice. I am definitely in favour of "dictatorship/oligarchy" regimes for the leading of open source projects. Democracy is the best political system but it has two huge weakness. It requires the active participation of its members and a high education, hence why it rarely works well. In any case , its a moot point to make in such a customisable environment as Pharo. I am in the middle by the way for those that wonder, I use neither Dark (but I really like it) or White (my eyes hate it with a vengeance) theme and I have made my own custom Blue theme which makes me an extremely tiny minority :D But I was raised with blue and green themes (I hate green themes) so maybe I am biased. In any case a huge thank you to Esteban for dark theme has made coding in Pharo far easier for me :) On Fri, Apr 14, 2017 at 2:55 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-14 13:46 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> But look&feel is different. You just open Pharo and have impression is it >> looks good or not. Voting can work here. >> >> >> yeah, but is impossible to satisfy everybodyâ¦ specially in non-technical >> stuff :) >> > > It is important to satisfy majority. > And it will be nice for people like me to be sure that we are special :) > Now I am sure that I am average person and most of people do not like dark > :) >

April 15, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by HernÃ¡n Morales Durand

2017-04-14 8:44 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Also I am really wondering that this decision was not publicly discussed. >> We should vote for such kind of changes. >> >> >> no, this is not how it works. >> > > yes, it is how it could work :) > > Current approach is not bad for technical choices because it is difficult > to make everybody evolved in particular technical topic. > But look&feel is different. You just open Pharo and have impression is it > looks good or not. Voting can work here. > I would forget about it. I stopped waiting for votes long time ago in this community. Also I decided to stop contributing to external projects (including reporting bugs) because who knows which tool (browser, morphic, etc) the board would like to add/remove tomorrow. I will not invest my time fixing tools who knows what's the plan on them. The best you can do is to work in the dark and adapt your stuff with each new Pharo version. Of course anyone with enough time/money could fork a new more democratic Pharo ;) HernÃ¡n

April 15, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Stephane Ducasse

tx pavel! We need a look that we can identify pharo 60 as pharo 60 :) On Fri, Apr 14, 2017 at 2:42 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-04-14 13:48 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> But to me it is too late for such change. I am sure there are UI >>> widgets/projects which looks horrible in dark. And people probably test >>> them in pharo 6 before this change. So they will be very surprised. >>> >>> >>> no, dark theme is around since 3 years and is very depurated. In fact, >>> many people already use it as they preferred theme. >>> >> >> Just open any project with Versioner. Symbolic versions are in green oval >> with white label. It is almost unreadable. >> > > Let's be constructive :-) > https://pharo.fogbugz.com/f/cases/19935/Versionner-tags- > are-unreadable-in-the-dark-theme > > >> >> Do you remember how many times Steph complains about style of current >> white theme? I am sure he not deeply look into dark. >> > >

April 14, 2017

Re: [Pharo-dev] [Vm-dev] String hash function

by Andres Valloud

IME, being smart about which characters to hash quickly runs into data sets being smarter about hiding variation in the unsampled characters. Slower hash functions aren't necessarily bad. Practical experience: 1. Investment bank end-of-day report takes 30 minutes to run. The time is spent mostly in linear search because of hash collisions. Introduced a 5x slower hash function that had a collision rate of about 2.5 instead of 20+. The report now takes 90 seconds, and hashing is nowhere to be seen in the profiler output. No need to optimize hashing further. 2. VisualWorks string / symbol hashes were also "smart". Replaced with a multiplicative hash along the lines of the Horner rule, which is slower for large enough strings. But interning all symbols into a new symbol table now takes 7x less time, and one of the k-nucleotide-related Computer Language Shootout benchmarks now runs in half the time. Regarding huge strings, surely a 1mb string has a special meaning that could be encapsulated within an object, and it is *this* object that could provide a hash function suitable for the purpose at hand. In fact, especially in those cases, the returned hash value might not even need to be based on the 1mb string at all. On 4/13/17 14:19 , ClÃ©ment Bera wrote: > > > > > Hi all, > > I am trying to investigate performance overhead in benchmarks to improve > the VM performance. In a benchmark strings are used as dictionary keys, > which seems to be an OK pattern to me that may be actually used in real > code from time to time. Something stroke me: _the hash function of a > string is actually iterating over the whole string. _ > > As a result, I get something like this: > > #( > 'String size: 0, Hash function performance: 17,817,776 per second' > 'String size: 1, Hash function performance: 15,395,388 per second' > 'String size: 3, Hash function performance: 14,853,109 per second' > 'String size: 4, Hash function performance: 15,151,954 per second' > 'String size: 5, Hash function performance: 14,139,881 per second' > 'String size: 10, Hash function performance: 11,545,749 per second' > 'String size: 65, Hash function performance: 3,431,067 per second' > 'String size: 130, Hash function performance: 1,879,047 per second' > 'String size: 520, Hash function performance: 511,934 per second' > ) > > This means that if a hash of a 1MB String is computed it takes a hell of > a time. > > I wonder why we don't compute the string hash from a small number of > inner characters taken randomly but deterministically from the String. > From example, for all strings longer than 5 characters, one could pick > only 5 characters in the String to compute its hash. The hash function > is this way decent enough and the performance does not drop for large > strings. > > One implementation could be to replace: > 1 to: stringSize do: [:pos | > by: > 1 to: stringSize by: stringSize // 5 do: [:pos | > in: > ByteString>>stringHash: aString initialHash: speciesHash > > Then we need to rehash the whole image. > > What do you think ? Is there a hash expert around that can confirm this > is a good idea ?

April 14, 2017

Re: [Pharo-dev] String hash function

by Martin McClure

On 04/13/2017 02:19 PM, ClÃ©ment Bera wrote: > I wonder why we don't compute the string hash from a small number of > inner characters taken randomly but deterministically from the String. > From example, for all strings longer than 5 characters, one could pick > only 5 characters in the String to compute its hash. The hash function > is this way decent enough and the performance does not drop for large > strings. > > One implementation could be to replace: > 1 to: stringSize do: [:pos | > by: > 1 to: stringSize by: stringSize // 5 do: [:pos | > in: > ByteString>>stringHash: aString initialHash: speciesHash > > Then we need to rehash the whole image. > > What do you think ? Is there a hash expert around that can confirm this > is a good idea ? This kind of thing has been tried before, and failed miserably. One of the biggest breaking incompatibilities, IIRC, between Java 1 and Java 2 was that they had to change their string hash function to hash all characters, because their scheme of hashing only a subset of characters had a huge number of collisions in real-world string like URLs, which have a lot of characters in common. I think it's worth the time to hash all characters. Regards, -Martin

April 14, 2017

Re: [Pharo-dev] Security in the image

by Richard Sargent

LaeMing wrote > > Stephan Eggermont wrote >> On 12/04/17 09:34, LaeMing wrote: >>> What sort of security implications might that have and are there any >>> current >>> solutions to a multi-user single-image situation? >> >> Take a look at gemstone. >> https://www.youtube.com/user/JamesGFoster/videos >> Starting at https://www.youtube.com/watch?v=U0z5TddqyQI >> James made a really good series of videos >> >> >> Stephan > Thanks, Stephan. > Gem looks rather good, but I need an OSS licensed environment. Can you elaborate on that? GemStone/S has a free, even for commercial use, license. Are you planning on modifying the VM or the base product code? -- View this message in context: http://forum.world.st/Security-in-the-image-tp4941857p4942128.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 14, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Pavel Krivanek

2017-04-14 13:48 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> But to me it is too late for such change. I am sure there are UI >> widgets/projects which looks horrible in dark. And people probably test >> them in pharo 6 before this change. So they will be very surprised. >> >> >> no, dark theme is around since 3 years and is very depurated. In fact, >> many people already use it as they preferred theme. >> > > Just open any project with Versioner. Symbolic versions are in green oval > with white label. It is almost unreadable. > Let's be constructive :-) https://pharo.fogbugz.com/f/cases/19935/Versionner-tags-are-unreadable-in-t… > > Do you remember how many times Steph complains about style of current > white theme? I am sure he not deeply look into dark. >

April 14, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Pavel Krivanek

2017-04-14 14:20 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > On Apr 14, 2017 14:13, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-04-14 12:52 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Isn't it a bit too late for such a change? Might break projects that >> expect configurations to be present. >> > > I do not think so. We do not have configurations for the system itself > (well, we have them in an external repository but they are not update since > switch to baselines). They are used only for the actively maintained > semi-external projects like GT, QA, Epicea, Zinc etc. However even in that > case they are sometimes out-of-sync with the upstream. > > Most users of such configurations are using the upstream configurations. > If some one is using wrongly the versions in Pharo, he uses reference to > the Pharo repository where the configurations will still be present. > > > For the record, I still think it's not the best idea to do this now :) > Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too. -- Pavel > > Cheers, > Andrei > > > Cheers, > -- Pavel > > >> >> Cheers, >> Andrei >> >> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> Hi, >>> >>> in Pharo 7 all configurations will be removed and replaced with the >>> baselines. The bootstrapped image itself does not load the configurations >>> at all. Most of them is now outdated and old versions of configurations in >>> the standard Pharo image can cause problems for users of newer versions >>> semi-internal packages (like Moose-Algos). >>> >>> So we, me and Cyril think that we should remove all current >>> Configurations from the image just before the Pharo 6 release. Do you see >>> any disadvantages of this step? >>> >>> Cheers, >>> -- Pavel >>> >> >> > >

April 14, 2017