- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [website] small changes

by Esteban A. Maringolo

2014-05-26 4:56 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 25 May 2014, at 16:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> Marcus: >> >> Could the images be hosted in a CDN? (AWS S3 or similar) >> It is bearable to open one picture, but if you want to do a fast >> browse through the gallery it takes forever. Around 5 secs per >> picture, which is a lot for some new visitor, and will probably cause >> a very high bounce rate. > I think the reason is that the small images are actually full size > â¦ 299kb*4 is a lot. It certainly affects, but if you need to display a big image you have no choice. If you look at the timing view it spends half second connecting and waiting. This is irrelevant of the file size. Regards, Esteban A. Maringolo

May 26, 2014

Re: [Pharo-dev] NativeBoost and WKHTML

by Henrik Johansen

On 23 May 2014, at 3:46 , Torsten Bergmann <astares(a)gmx.de> wrote: > YES, COOL - it now works as the attached PDF proves. > > 1000 timesRepeat: [ Transcript show: 'Henrik thanks!!!' ;cr ] > > Henrik - you have saved me to have to return to the darker sides of computing > and digg deeper into low level again ;) > > I knew that it must have been something in the calling wrapper and > was too blind to see it. > > A little bit misleading that one can not use the original C signature > in the NB description with char* and autoconversion through NB. > > Maybe I was too used to NB's predecessor FFI where one wrote char* and > just passed the Smalltalk string. > > Stupid me, I should have RTFM of NativeBoost instead of assuming > its close to FFI in this regard! So again the problem was in front > of the computer. Really, blame char *, itâs too ambiguous. Is it raw byte(s)? Is it a string? How is its length conveyed? Whatâs the encoding supposed to be? You canât really determine the answer to those questions up front in the FFI, though the right answer is usually clear on a case-by-case basis from the context. * So the NB rationale is (I think) not to do extra overhead which would still, sometimes, leave the user stumped at some strange error when the automatic handling mismatches reality. You only get bitten by it once (or maybe twice?), though the path to enlightenment could be less bumpy :) Cheers, Henry * No corresponding length parameter? Either single element or null-terminated string, as per context. String or bytes? Should be clear from context. Encoding? Wellâ¦ usually utf8, but could also be some environment-defined code page, gotta check the library docs to be sure. Say what you want about Windows, but at least they their APIs use explicit string types with well defined encoding.

May 26, 2014

Re: [Pharo-dev] Bad naming: users

by Stephan Eggermont

That is an interesting validation error. I don't have enough context to understand what exactly goes wrong here. It is of course a correct observation, as TraitBehavior>>users doesn't exist anymore. Stephan + ./pharo Pharo-3.0-Issue-Tracker-Image.image eval Smalltalk os environment includesKey: 'JENKINS_URL' true + ./pharo Pharo-3.0-Issue-Tracker-Image.image ci slice test --html-resources=https://ci.inria.fr/pharo/view/3.0-Analysis/job/Pharo-3.0-Issue-Tracker-Image/ws/bootstrap/ --update-issue --next [32missue tracker authentification succeded[0m 'Fetching next issue...' 'Testing Slice 13274' https://pharo.fogbugz.com/f/cases/13274 [33mStarting validation of SLICE 13274 http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main/SLICE-Issue-13274-Replac… Notice: Running a CIAndRule Notice: Running a CIChangeSliceValidationRule Notice: Loading SLICE 13274 http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main/SLICE-Issue-13274-Replac… ================================================================================ Validation Report: SLICE 13274 http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main/SLICE-Issue-13274-Replac… ================================================================================ [38;5;196mValidation Errors:[0m - A critical error happened while loading SLICE 13274 http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main/SLICE-Issue-13274-Replac… - FLMethodChanged: Materialization error. Method TraitBehavior>>#users changed its bytecodes. Archiving artifacts Description set: <a href="https://pharo.fogbugz.com/f/cases/13274">https://pharo.fogbugz.com/f/cases/13274</a> Deleting project workspace... done Finished: SUCCESS

May 26, 2014

Re: [Pharo-dev] Bad naming: users

by Stephan Eggermont

Oops, bad commit message, the actual selector is traitUsers

May 26, 2014

Re: [Pharo-dev] Bad naming: users

by Stephan Eggermont

Name: SLICE-Issue-13274-Replace-users-by-traitUsers-StephanEggermont.1 Author: StephanEggermont Time: 26 May 2014, 10:07:23.002975 am UUID: 79d336dd-b556-4d20-849c-2b7d11d91ed8 Ancestors: Dependencies: Kernel-StephanEggermont.1750, Nautilus-StephanEggermont.737, Ring-Core-Kernel-StephanEggermont.163, Ring-Tests-Kernel-StephanEggermont.64, SUnit-Tests-StephanEggermont.38, SlotTests-StephanEggermont.90, System-FilePackage-StephanEggermont.117, Tests-StephanEggermont.682, Tools-StephanEggermont.1425, Traits-StephanEggermont.642 Be more specific: traitsUsers instead of users (:)

May 26, 2014

Re: [Pharo-dev] String >> #=

by Philippe Marschall

On 26.05.14 11:08, ClÃ©ment Bera wrote: > Hello, > > for this use case people typically use Symbols (much faster). I don't see how that helps because #asSymbol does a look up into a dictionary with a String key as well. Cheers Philippe

May 26, 2014

Re: [Pharo-dev] String >> #=

by ClÃ©ment Bera

Hello, for this use case people typically use Symbols (much faster). Now you are right we may add a shortcut in string comparison. 2014-05-26 9:51 GMT+02:00 Philippe Marschall < philippe.marschall(a)netcetera.ch>: > Hi > > I have been investigating why Dictionary look up performance with String > keys is not as good as I would expected. Something I noted is that String > >> #= is implemented in terms of #compare:with:collated:. There is no short > circuit if Strings are not the same size. In my case some Strings have the > same prefix but a different length eg 'Content-Type' and 'Content-Length'. > In that case a #compare:with:collated: is performed even though we know in > advance the answer will be false because they have different sizes. > > Cheers > Philippe > > >

May 26, 2014

A proposal for the Documentation Section of the new web site

by kilon alios

I propose to add links to the pdfs and hmtls ouputs of both Pharo for the Enterprise and Updated Pharo By Example. I know that both are work in progress , especially UPBE , but it shows that we are an active community that prioritizes documentation for newcomers. Especially PFTE clearly shows that there are loads of useful libraries for Pharo. In case of UPBE it looks like I will finish it by the end of this year and then work on updating for Pharo 4 though its obvious that the work for Pharo 4 will be a tiny fraction of the work I am doing right now. I am also willing to update "Why Pharo" if people want a better presentation. Other than that, the website looks awesome congratulation to people behind it for putting the hard work.

May 26, 2014

Re: [Pharo-dev] [website] small changes

by Marcus Denker

On 25 May 2014, at 16:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Marcus: > > Could the images be hosted in a CDN? (AWS S3 or similar) > It is bearable to open one picture, but if you want to do a fast > browse through the gallery it takes forever. Around 5 secs per > picture, which is a lot for some new visitor, and will probably cause > a very high bounce rate. > > I don't have the fastest connection (10Mbit/sec) but I don't > experience this with other sites (see attached basecamp screenshot as > comparison). On a mobile device (on which Pharo's site gets > appropriate layout), the image size and speed gets even worst given > the multiple requests (with an added redirect for each one). > I think the reason is that the small images are actually full size â¦ 299kb*4 is a lot. Marcus

May 26, 2014

String >> #=

by Philippe Marschall

Hi I have been investigating why Dictionary look up performance with String keys is not as good as I would expected. Something I noted is that String >> #= is implemented in terms of #compare:with:collated:. There is no short circuit if Strings are not the same size. In my case some Strings have the same prefix but a different length eg 'Content-Type' and 'Content-Length'. In that case a #compare:with:collated: is performed even though we know in advance the answer will be false because they have different sizes. Cheers Philippe

May 26, 2014