June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Adding progress to SmalllintChecker

by Yuriy Tymchuk

Done https://pharo.fogbugz.com/f/cases/13348/Display-progress-when-running-lint-… On 20 Jun 2014, at 22:06, stepharo <stepharo(a)free.fr> wrote: > Yes send code. > > Stef > > On 20/6/14 13:12, Yuriy Tymchuk wrote: >> Hi, >> >> can we add the progress bar to RBSmalllintChecker so we will see how many classes have been already checked? Or also how many methods in the class (though I donât think this is reasonable). >> >> Uko >> > >

June 21, 2014

Re: [Pharo-dev] How to convert properyl an Athens Surface to a Form

by Hilaire Fernandes

The black background should be white. I use asFrom: area owner athensSurface asForm where owner is a WrapAthenMorph Hilaire Le 19/06/2014 22:16, Nicolai Hess a Ã©crit : > I use asForm and it works for me. > can you create a screenshot with the odd result > it creates. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 20, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Hilaire Fernandes

Gi Igor, For DrGeo it is not a workable option to have different fonts in Morphic widget and Athens canvas (I explained earlier why). However I found the scaling trick of draw text to work reasonably well. Not full perfect as from time to time I can see some artifact. Thanks Hilaire Le 20/06/2014 15:32, Igor Stasenko a Ã©crit : > Sure, you can do: make sure you don't render text with same font in > Morphic UI and Athens, so they don't interfere with each other. > There's no easy way to get rid of interference, because it would require > changing Freetype package and its plugin in order to establish a single > font management point and funnel all requests to freetype library > through it. > -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 20, 2014

Re: [Pharo-dev] Pharo VM crash on seom DrGeo sketch

by Hilaire Fernandes

It think the input was not well formed, error of mine with code not yet updated to Athens. Hilaire Le 20/06/2014 13:15, Igor Stasenko a Ã©crit : > it is balloon plugin.. which responsible for rendering complex shapes. > looks like for some shapes/complexity it doesn't works well? > or input is not well formed..? > -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 20, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Yuriy Tymchuk

On 20 Jun 2014, at 22:59, stepharo <stepharo(a)free.fr> wrote: > > On 19/6/14 14:08, Henrik Johansen wrote: >> On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> Hi, >>> >>> maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. >>> >>> I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. >>> >>> Uko >>> >> #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. >> >> Symbol has no #value:value: message, hence it should have no #cull:cull: either. >> >> You could argue it should implement both, with value:value: polymorphic to the block >> [:a :b | a perform: theSymbol with: b ]. >> >> but cull:cull: would then mean equivalence to: >> for #+ [:a :b | a + b] >> for #squared [:a | a self] >> >> And I donât see how thatâd be intuitive/useful enough to warrant inclusion > > +1 Iâm not telling to implement #value:value: but #cull:cull: which is equivalent to #value: so instead of [ :var | var name ] I can use just #name > > >> >> Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . >> aCollection sort: #> / aCollection inject: 0 into: #+ >> which, while might be nice, both have no use for cull:cull: in the same manner: >> aCollection inject: 0 into: #squared -> [:sub :next | sub squared] ??? >> The whole "who is the receiver, whatâs going onÂ»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel itâs better to write out the block explicitly. >> >> Cheers, >> Henry

June 20, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Sean P. DeNigris

kilon alios wrote > Pharo has zero official reference documentation Well Pharo By Example and Deep into Pharo are close. IMHO, we've chosen to pour as many of our limited resources as possible into shrinking and redesigning the system into something one person can master, rather than thoroughly document things that may soon change drastically or disappear. Real BDD (Behavior Driven Design i.e. tests from the perspective of the user of the library) would help here as the tests would provide documentation for free. But BDD doesn't seem to have caught on in the Smalltalk world, and I find many (most?) tests to be useless from a "how does this library work" perspective. Also, when the system stabilizes and we start documentation "for real", the fun part will be active essays; traditional paper-like documentation is the kind of thing Smalltalk was invented to replace. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Where-is-the-postcard-with-syntax-tp4763281p4764026.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 20, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by stepharo

On 19/6/14 14:08, Henrik Johansen wrote: > On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi, >> >> maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. >> >> I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. >> >> Uko >> > #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. > > Symbol has no #value:value: message, hence it should have no #cull:cull: either. > > You could argue it should implement both, with value:value: polymorphic to the block > [:a :b | a perform: theSymbol with: b ]. > > but cull:cull: would then mean equivalence to: > for #+ [:a :b | a + b] > for #squared [:a | a self] > > And I donât see how thatâd be intuitive/useful enough to warrant inclusion +1 > > Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . > aCollection sort: #> / aCollection inject: 0 into: #+ > which, while might be nice, both have no use for cull:cull: in the same manner: > aCollection inject: 0 into: #squared -> [:sub :next | sub squared] ??? > > The whole "who is the receiver, whatâs going onÂ»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel itâs better to write out the block explicitly. > > Cheers, > Henry

June 20, 2014

Re: [Pharo-dev] Adding progress to SmalllintChecker

by stepharo

Yes send code. Stef On 20/6/14 13:12, Yuriy Tymchuk wrote: > Hi, > > can we add the progress bar to RBSmalllintChecker so we will see how many classes have been already checked? Or also how many methods in the class (though I donât think this is reasonable). > > Uko >

June 20, 2014

Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing

by Norbert Hartl

> Am 20.06.2014 um 17:06 schrieb Jan van de Sandt <jvdsandt(a)gmail.com>: > > And I think it's a good idea to make SHA2 hash functions part of the System-Hashing package! > +1 Norbert > >> On Fri, Jun 20, 2014 at 5:01 PM, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >> Hello, >> >> I added the SHA256 class to Cloudfork a few years ago. The class was mostly copied from the Cryptography [1] project. >> >> Cheers, >> Jan. >> >> [1] http://www.squeaksource.com/Cryptography/ >> >> >>> On Fri, Jun 20, 2014 at 10:56 AM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: >>> Max, >>> >>> Yes, it's usable as the SHA1 package already there (without HMAC so). I'm no expert in those stuff but I don't get "SHA256 base implementation". Someone with more knowledge can probably tell ;) >>> >>> Sven, >>> >>> The bare minimum to load it is: >>> >>> Gofer it >>> smalltalkhubUser: 'JanVanDeSandt' project: 'Cloudfork'; >>> package: 'Cloudfork-Common'; >>> package: 'Cloudfork-Pharo-Platform'; >>> load. >>> >>> The implementation is in Cloudfork-Pharo-Platform. >>> >>> >>> >>>> On Thu, Jun 19, 2014 at 6:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> I want to have a look, if you tell me where to look... >>>> >>>> On 19 Jun 2014, at 18:03, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> > >>>> > On 19.06.2014, at 17:59, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: >>>> > >>>> >> Does it make sense from a license point of view and practical point of view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class) in the System-Hashing package (in where there's already SHA1 and MD5) ? >>>> > >>>> > Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an SHA256 base implementation? Or does it require extra stuff? In the former case I probably wouldnât add it. In the latter case itâs open for discussion. Personally, I think it belongs into a separate package, not into System-Hashing. >>>> > >>>> > Cheers, >>>> > Max >

June 20, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Tudor Girba

Why is that? Doru On Fri, Jun 20, 2014 at 7:46 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > On Fri, Jun 20, 2014 at 7:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I do not understand. >> >> I think we are talking about two different things. Alex and I are talking >> about wrong rendering of FT fonts in Athens. A problem that looks similar >> to what we had before. Our issue has nothing to do with StrikeFont. >> >> You can (and Pharo does) use FT fonts in Morphic. I think he is asking > that the font you want to use in Athens be something different than what is > already chosen to be used in the rest of the system used in Morphic (such > as browser/workspace fonts). > -cbc > >> Cheers, >> Doru >> >> >> On Fri, Jun 20, 2014 at 3:32 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> >>> >>> On 20 June 2014 13:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> We thought so, too. But the problem manifests itself again on the >>>> latest Pharo 3.0. >>>> >>>> Thanks for checking and let us know if we can do something! >>>> >>>> >>> Sure, you can do: make sure you don't render text with same font in >>> Morphic UI and Athens, so they don't interfere with each other. >>> There's no easy way to get rid of interference, because it would require >>> changing Freetype package and its plugin in order to establish a single >>> font management point and funnel all requests to freetype library through >>> it. >>> >>> >>>> Doru >>>> >>>> >>>> On Fri, Jun 20, 2014 at 12:53 PM, Igor Stasenko <siguctua(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 20 June 2014 02:01, Alexandre Bergel <alexandre.bergel(a)me.com> >>>>> wrote: >>>>> >>>>>> Times to times, font are displayed in a very weir fashion: small and >>>>>> big letter. Width is not properly computed in addition. >>>>>> >>>>>> that should be fixed already.. i will check. >>>>> >>>>> >>>>>> Alexandre >>>>>> >>>>>> > Le 19-06-2014 Ã 18:26, Nicolai Hess <nicolaihess(a)web.de> a Ã©crit : >>>>>> > >>>>>> > >>>>>> > If I take a fresh pharo image I always have to reenable FT fonts >>>>>> before >>>>>> > doing any athens rendering with text >>>>>> > (RMOD StrikeFont(Object)>>doesNotUnderstand: #getPreciseHeight). >>>>>> > >>>>>> > Ok, I know I have to >>>>>> > open settings >>>>>> > disable then >>>>>> > enable FreeType >>>>>> > and choose a FreeType font. >>>>>> > >>>>>> > But what exactly is the problem with Athens rendering and non FT >>>>>> fonts? >>>>>> > >>>>>> > >>>>>> > Nicolai >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 20, 2014