January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

2015-01-12 19:19 GMT+01:00 stepharo <stepharo(a)free.fr>: > Igor once explained to me that FreeType has the possibility to degrade > fonts when the family does not provide it. > Cairo does not have this possibility. > Esteban I'm sure that the same code is used. FreeType is much more > advanced than Cairo when it is about fonts. > There is a setting for the freetype plugin: Monitor type LCD/CRT. If I change this to CRT, the freetypelugin font rendering looks more like the cairo on, no colored antialiasing. (freetype plugin ones still look a little bit better, a bit more "bold"). > > Stef > > Le 11/1/15 22:43, Nicolai Hess a Ã©crit : > > Anyone knows, why the text rendering with athens (cairo) looks slightly >> different than the freetypeplugin one? >> >> attached is a screenshot, left side athen right side (morphic) >> freetypeplugin. >> >> It "looks" like the cairo freetype fontrendering uses >> CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. >> But the font options do define antialiase subpixel and a subpixel >> ordering RGB. >> >> This is on windows 7 with the latest vm, does it look different on other >> Systems? >> >> >> nicolai >> >> >> >

Jan. 12, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Marcus Denker

> > > I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var. > Yes! Marcus

Jan. 12, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Marcus Denker

> On 09 Jan 2015, at 16:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > After some searching for a solutionâ¦ that does not break backward-compatibility, I found a way to save classes that use > slots. > > - if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) > - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the > monticello model. > - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. > - the code path for non-Slot classes stays largely untouched. > > This is not beautiful but backward compatibleâ¦ you can even load classes with Slots in Pharo3, it then creates invalid > ivar names, which of course means the code does not run but it is readable. > > e.g. create a class like > > Object subclass: #A > slots: { #iv => TestSlot } > classVariables: { } > category: 'Playgroundâ > > (TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which > means all instances share the state. Just a small example) > > Limitations > -> no support for class variables yet > -> class instance variables not yet done, either Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720 - With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots next: Class Variables: add Monticello loading support for class variable definitions. Marcus

Jan. 12, 2015

Re: [Pharo-dev] GTInspector does not refresh printString

by Tudor Girba

Hi Stef, On Mon, Jan 12, 2015 at 7:15 PM, stepharo <stepharo(a)free.fr> wrote: > Hi andrei > > The inspector does not automatically update the string representation > for now (as it does not automatically refresh-- the same discussion as the > state view). > It should however update the representation if you change printOn: and > manually refresh/ inspect the object again. Just checked it and it works > for me. If it doesn't work for you then there is a bug. > What did you do? > > > I was doing a lecture and this is really sad to get all features gone. > I think this is not so fair :). > So I had to reinspect again. > Yes. As Andrei said, it is a bug that will be fixed. > In addition GTInspector bubble is a pain because sometimes you really want > to keep the result and not inpect it. > Did you see my request to get that enter put the bubble contents into the > text pane? > Did you see the reply? :) > I'm sorry but I cannot use GT as it is now. > That's a pity. And I'm working on the new version of Pharo by example and it would be good > to > have something full working. > Besides these two problems, do you have others? Cheers, Doru > Stef > > > Cheers, > Andrei > > On Mon, Jan 12, 2015 at 12:14 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> GTInspector does not change the printString representation when we change >> the printOn:. >> Am I the only one to see this behavior? >> >> Stef >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 12, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Eliot Miranda

Hi Marcus, On Jan 12, 2015, at 6:59 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 11 Jan 2015, at 18:50, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> It has been a while since I read the paper, but my memory is that >> Slots lets you define features and/or constraints on inst-var's. For >> example, assigning default values or restricting the set of valid >> values. >> >> This would probably be appealing for folks coming from languages like >> Java or C++, because they're used to all of their "slots" being >> statically typed. It does seem ironic that where those static >> languages have been trying to move toward being more dynamic, Pharo >> newbies would find themselves arrived at a language which is trying to >> make something that was purely dynamic into something more static. > > It is *possible* to implement a kind of TypedSlot, but I do not think that > this is what people will use Slots for. And for sure there will be no TypeSlot > by default in Pharo. > > For Slots there are two levels > > 1) having objects that describe variables instead of strings. This is very powerful > already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily > > This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper > slot a way to transparently hook into variable access. This will be very powerful. > > 2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this > change is about > > This is what we use Slots for are three directions: > > 1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. > (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak > very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks. > > 2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a > whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. > With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots > of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely > encoded in a way that they take no space. > > 3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it > is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots. > > 4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments > to be done fast and easy so we can explore many ideas easily. > These experiments will often be just that: experiments. But some of them will be so good that they will > turn out to be useful. I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var. > >> My understanding is that specifying a certain Slot-type can save the >> need to write, i.e., initializing or validating methods. In exchange, >> the number of concepts inherent in the language that must be learned >> and remembered is increased. Standard Smalltalk is only about 2 or 3 >> concepts -- sending messages and assigning pointers. Period. There's >> something exciting about that because even Grandma can grok 2 or 3 >> concepts. No other language is so simple. > Slots do not really increase the concepts: they just are meta objects that have the > definition of the behaviour of assignment, turning assignment into message sends. > >> By introducing the implicit behaviors of slots, the number of >> different conceptual interactions between code and the slots it >> references increases exponentially with the number of slot-types. I >> fear trying to explain them to Grandma will have her eyes starting to >> glazeâ¦ > I do not see now an active slot is harder to understand than e.g. a ValueHolder. > or a BooleanSlot should be easier to understand than doing all that explicitely? > > > Marcus >

Jan. 12, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Alain Rastoul

Le 12/01/2015 18:56, Sven Van Caekenberghe a Ã©crit : > >> On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> >> hi all, >> >> Googling a bit for a logging framework in Pharo, I found sl4j, which sounds familiar to me. >> http://ss3.gemstone.com/ss/Log4s.html/Wiki >> >> I suppose the API is the same as the java package, as claimed by the project page. >> I wonder if anybody is using it , or has tried it and have an advice on that package ? >> (I saw there was no test and no comments ... :( ) >> >> I think it could be great for Pharo to have a standard package like that, a logging facility is mandatory for most -if not all- applications >> >> Any advice or pointers ? > > Object logging instead of String logging is the way to go. SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past discussions. found your video on ZnLogEvent on youtube +1 for logging objects ... :) > >> TIA >> -- >> Regards, >> >> Alain >> >> > > > -- Regards, Alain

Jan. 12, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Alain Rastoul

Le 12/01/2015 19:30, stepharo a Ã©crit : > If you need the pdf just ask we should put back the ci crushing pillar > and producing pdf the text is readable even with tags, and figures in png and pdf, so it's ok for me, thanks anyway. may be time for me to try using pillar, I saw the doc of Damien Cassou and delayed trying it but and it looks cool. > Le 12/1/15 19:25, Alain Rastoul a Ã©crit : >> Le 12/01/2015 19:11, stepharo a Ã©crit : >>> >>> Le 12/1/15 18:56, Sven Van Caekenberghe a Ã©crit : >>>>> On 12 Jan 2015, at 18:27, Alain Rastoul >>>>> <alf.mmm.cat(a)gmail.com> wrote: >>>>> >>>>> hi all, >>>>> >>>>> Googling a bit for a logging framework in Pharo, I found sl4j, which >>>>> sounds familiar to me. >>>>> http://ss3.gemstone.com/ss/Log4s.html/Wiki >>>>> >>>>> I suppose the API is the same as the java package, as claimed by the >>>>> project page. >>>>> I wonder if anybody is using it , or has tried it and have an advice >>>>> on that package ? >>>>> (I saw there was no test and no comments ... :( ) >>>>> >>>>> I think it could be great for Pharo to have a standard package like >>>>> that, a logging facility is mandatory for most -if not all- >>>>> applications >>>>> >>>>> Any advice or pointers ? >>>> Object logging instead of String logging is the way to go. >>>> SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the >>>> mailing list for past discussions. >>> >>> we will merge SystemLogger and Beacon. Now there is a full documentation >>> about SystemLogger at >>> https://github.com/SquareBracketAssociates/PharoReadyForReviews >> Cool chapters. >> And I found the projects on smalltalk hub. >> thank you Stef >> >>> >>>> >>>>> TIA >>>>> -- >>>>> Regards, >>>>> >>>>> Alain >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > -- Regards, Alain

Jan. 12, 2015

Re: [Pharo-dev] GTInspector does not refresh printString

by Andrei Chis

Hi Stef, On Mon, Jan 12, 2015 at 7:15 PM, stepharo <stepharo(a)free.fr> wrote: > Hi andrei > > The inspector does not automatically update the string representation > for now (as it does not automatically refresh-- the same discussion as the > state view). > It should however update the representation if you change printOn: and > manually refresh/ inspect the object again. Just checked it and it works > for me. If it doesn't work for you then there is a bug. > What did you do? > > > I was doing a lecture and this is really sad to get all features gone. > So I had to reinspect again. > The fact that the inspector does not refresh automatically is a bug and it will be fixed. Now we were waiting to see if if we cannot use the new reflectivity for that. Maybe we can try an intermediary solution until then where at least the Raw presentation is updated at each step or using a timer. > > In addition GTInspector bubble is a pain because sometimes you really want > to keep the result and not inpect it. > Did you see my request to get that enter put the bubble contents into the > text pane? > This will also be fixed really soon. But is this really such a common use case for you? For me let's say that around 10% of the time I need to copy/keep the printed text around. > > I'm sorry but I cannot use GT as it is now. And I'm working on the new > version of Pharo by example and it would be good to > have something full working. > A little bit more optimist would't harm :). All the issues that you mentioned will be fixed but there is never enough time. Cheers, Andrei > Stef > > > > > Cheers, > Andrei > > On Mon, Jan 12, 2015 at 12:14 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> GTInspector does not change the printString representation when we change >> the printOn:. >> Am I the only one to see this behavior? >> >> Stef >> >> > >

Jan. 12, 2015

[pharo-project/pharo-core] 3c2c4a: 40440

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3c2c4a69ecc39d713a04840130e53fbe548df6ca https://github.com/pharo-project/pharo-core/commit/3c2c4a69ecc39d713a048401… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-12 (Mon, 12 Jan 2015) Changed paths: M Monticello.package/MCClassDefinition.class/instance/installing/createClass.st M Monticello.package/MCClassDefinition.class/instance/installing/load.st M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineCase.st M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineIfNil.st M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineTimesRepeat.st M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineToDo.st M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineWhile.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script440.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40440.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40440 14716 Remove all #notify: from inline checking https://pharo.fogbugz.com/f/cases/14716 14718 Move class instance variable def from #load to #createClass in MCClassDefinition https://pharo.fogbugz.com/f/cases/14718 http://files.pharo.org/image/40/40440.zip

Jan. 12, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40440 Home: https://github.com/pharo-project/pharo-core

Jan. 12, 2015