- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] why do we have XMLParser and XML in the default image?

by stepharo

In fact we just have the repositories defined. Le 11/10/15 10:41, stepharo a Ã©crit : > Hi > > why do we have XMLParser and XML in the default image? > > Stef > >

Oct. 11, 2015

why do we have XMLParser and XML in the default image?

by stepharo

Hi why do we have XMLParser and XML in the default image? Stef

Oct. 11, 2015

Re: [Pharo-dev] Yet another Athens font thread

by stepharo

Le 8/10/15 18:05, Aliaksei Syrel a Ã©crit : > Do you remember a hack with scaling? (scaleBy: 1.0001@1.0001) It makes > letters to have the same height, so no more huge ones with small > fonts. But it doesn't fix a bug when letters have wrong width so there > is a space between characters. The same effect can be achieved if we > set font size manually after setting scaled font before drawing glyphs > with cairo. It means that at some point we get wrong calculated > glyphs. So if we "fix" scaled font before glyph calculation - the > problem would be gone. In the patch I set scaled font, manually apply > font size, retrieve "fixed" scaled font and calculate glyphs based on it. > > Also after investigation I found something interesting. If we clean > real font of a logical font the problem gets fixed for some period of > time. I assume that FreeTypeFont gets broken after a while and logical > font always returns broken real font. Exactly. If you have code we applied accept it. In the pharo roadmaps on github you have a roadmap for the problems I identify. > Setting realFont to nil forces logical font to create a new working > free type font. As soon as new free type font is created cairo > produces scaled font and caches it. So actual problem lies deep in > FreeTypeFont... > > I even opened two images: one with broken fonts and one with working. > Then I compared in inspector two free type fonts - they are absolutely > the same and have identical instance variable in a whole object tree, > except of handler pointers to C structure which I can't inspect from > pharo... > > Saving image fixes fonts because of > > LogicalFont>>shutDown: quitting > self allSubInstances do: [:i | i clearRealFont]. > > > Cheers, > Alex > > On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > How did you fix it? > > Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>>: > > Hi > > It looks like I fixed that weird text rendering problem... > Just get the latest Athens-Cairo. > > Cheers, > Alex > > On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess > <nicolaihess(a)web.de> wrote: > > > > 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel > <alex.syrel(a)gmail.com>: > > Hi > > I noticed that if I force use "Source Code Pro" as > standard font for all elements in the image I never > have problems with font rendering. In case of "Source > Sans Pro" font is just not usable becasue of rendering > bugs on mac, windows and linux(?). If "Lucida Sans > Pro" is used - no bugs too. > > Because bug is reproducable on all platform - it's > platform independent bug. > Because it's reproducable only with one specific font > - maybe it's not an athens issue but bug in font > itself and if someone could change/update Source Sans > Pro to a newly version or to a similar font the > problem will be solved? > > > Did you try to use a new font version ? > I don't know exactly how embedded fonts are included. I > tried to create the font with a newer version but it did > not work ( or at least I could not see any difference). > > > Cheers, > Alex > > > >

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by serge.stinckwich＠gmail.com

Great job Marcus ! I could not the SciSmalltalk talk. This was maybe not recorded ? Regards Sent from my iPhone > On 9 oct. 2015, at 17:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On Fri, Jul 17, 2015 at 3:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> The slides from the second talk are online: >> >> http://www.slideshare.net/MarcusDenker/variables-in-pharo5 > > > Video is finally online, too: > > Video Part1: https://www.youtube.com/watch?v=hEWKV9eWAGY > Video Part2: https://www.youtube.com/watch?v=hEWKV9eWAGY >

Oct. 11, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by stepharo

Hi stefna can you describe the problem so that we can ask alain? Stef Le 10/10/15 21:13, Stephan Eggermont a Ã©crit : > On 10-10-15 20:41, stepharo wrote: >> Hi stefan >> >> could you open a bug entry and publish a merge? >> We participated to an hackaton with esteban, pablo, kevin and cyril >> and we >> are not really happy about the tools, the frameworks... >> :( > > I can fix those. How do I check for (partially?) missing source code? > > Stephan > > > >

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by stepharo

Le 11/10/15 00:40, Dale Henrichs a Ã©crit : > Christophe, > > I still don't have a lot of time to read the paper and try to > understand what you are trying to accomplish, you should read it. :) We wrote it for that and it is not boring nor long. > but I am curious how you think "package dependencies" will play with > git-based projects? > > In git-based repositories I don't think you have the same type of > dependency issues that one might have with monticello repositories --- > In a monticello repository you have a whole range of possible package > versions to pick from, but in a git-based repository the range of > package versions is fixed to those that are committed together so the > packages that are meant to work together are committed together. I think that this is only true for packages committed within the same repo. Now between porjects published in different repo you have to express them. I do not think that we all want to publish in the same repo and clone out everything. > > In the bootstrap scenario, you would only have one version per package > to choose from, so the packages that are meant to work together are > committed together .... > > I guess I don't know what you mean when you say: >> we want to decouple a released version of a package from the working >> copy of the package version description (implies the creation of a >> package repository + a web interface on top of it to promote/search >> packages). > Perhaps a description of the problem being solved would help me > understand. We want to be able to have a package market place where tools can grab dependencies without to load code and can compute the set of packages that should be loaded. When a package is released into the market: then it externalise its metadata so that a crawler can automatically build dependency graph and create specific distribution. Stef >> >> Le 6 oct. 2015 Ã 20:23, Dale Henrichs a Ã©crit : >> >>> >>> On 10/6/15 5:10 AM, stepharo wrote: >>>> >>>> Le 6/10/15 11:40, Stephan Eggermont a Ã©crit : >>>>> On 06-10-15 11:11, stepharo wrote: >>>>>> I will do a separate configuration of magritte seaside. >>>>> You need to load the correct groups. Separate configurations are a >>>>> bad practice and should be eliminated, not encouraged. >>>> I totally disagree. >>>> And groups are not supported by the configurationBrowser >>>>> The configuration has a lot of essential complexity, as many >>>>> different combinations of components are needed in different >>>>> situations. We need tools that recognize that essential complexity >>>>> and support it, not tools that try to hide it and then have no >>>>> practical usability. >>>> Well I disagree. And all the effort of christophe for the new >>>> dependencies declarations at the package level just goes in that >>>> direction. >>>> I will do a MagritteSeaside Configuration that I will maintain and >>>> I will also do a MagritteTutorial one. >>>> >>> Stef, >>> >>> I hope you and Christophe are considering cross platform >>> considerations when implementing "new dependencies declarations at >>> the package level" ... MonticelloConfigurations had "package level >>> dependencies" and the implementation was extremely rigid to the >>> point where it wasn't possible to substitute an alternate >>> (platform-speicific) package in the package graph without creating >>> new package versions of all packages in the graph ... Of course I am >>> not aware of the approach that Christophe, but be aware that "there >>> be dragons there":) >> Thanks for the warning. cross-platform packages are integrated into >> this new approach by allowing to express dependencies to virtual >> packages (idea from debian OS: >> http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg) It >> allows low-coupling and is very flexible. >> You will find more information in the paper published at IWST'14: >> https://hal.inria.fr/hal-01086083/document (by the way, you should >> already have it, I sent it to you last year but you were very busy at >> this time ;) ) >> >> To summarize in a few words, we want dependencies expressed at the >> package level (and we want more meta-data on packages), we want to >> decouple a released version of a package from the working copy of the >> package version description (implies the creation of a package >> repository + a web interface on top of it to promote/search packages). >> We also want to detect dependencies automatically as much as possible >> to avoid missing or not-used dependencies (dependency analyser tool). >> All together, it will allow to define architectural rules and layers >> in Pharo. I now experimenting all that with the Pharo bootstrap. >> >> If you have any question or remark, do not hesitate to ask or to give >> feedback. >> >> Christophe. > > >

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

Christophe, I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, but I am curious how you think "package dependencies" will play with git-based projects? In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... I guess I don't know what you mean when you say: > we want to decouple a released version of a package from the working > copy of the package version description (implies the creation of a > package repository + a web interface on top of it to promote/search > packages). Perhaps a description of the problem being solved would help me understand. Dale On 10/6/15 11:47 PM, Christophe Demarey wrote: > Hi Dale, > > Le 6 oct. 2015 Ã 20:23, Dale Henrichs a Ã©crit : > >> >> On 10/6/15 5:10 AM, stepharo wrote: >>> >>> Le 6/10/15 11:40, Stephan Eggermont a Ã©crit : >>>> On 06-10-15 11:11, stepharo wrote: >>>>> I will do a separate configuration of magritte seaside. >>>> You need to load the correct groups. Separate configurations are a bad practice and should be eliminated, not encouraged. >>> I totally disagree. >>> And groups are not supported by the configurationBrowser >>>> The configuration has a lot of essential complexity, as many different combinations of components are needed in different situations. We need tools that recognize that essential complexity and support it, not tools that try to hide it and then have no practical usability. >>> Well I disagree. And all the effort of christophe for the new dependencies declarations at the package level just goes in that direction. >>> I will do a MagritteSeaside Configuration that I will maintain and I will also do a MagritteTutorial one. >>> >> Stef, >> >> I hope you and Christophe are considering cross platform considerations when implementing "new dependencies declarations at the package level" ... MonticelloConfigurations had "package level dependencies" and the implementation was extremely rigid to the point where it wasn't possible to substitute an alternate (platform-speicific) package in the package graph without creating new package versions of all packages in the graph ... Of course I am not aware of the approach that Christophe, but be aware that "there be dragons there":) > Thanks for the warning. cross-platform packages are integrated into this new approach by allowing to express dependencies to virtual packages (idea from debian OS: http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg) It allows low-coupling and is very flexible. > You will find more information in the paper published at IWST'14: https://hal.inria.fr/hal-01086083/document (by the way, you should already have it, I sent it to you last year but you were very busy at this time ;) ) > > To summarize in a few words, we want dependencies expressed at the package level (and we want more meta-data on packages), we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). > We also want to detect dependencies automatically as much as possible to avoid missing or not-used dependencies (dependency analyser tool). All together, it will allow to define architectural rules and layers in Pharo. I now experimenting all that with the Pharo bootstrap. > > If you have any question or remark, do not hesitate to ask or to give feedback. > > Christophe.

Oct. 10, 2015

Missing mcz versions?

by Stephan Eggermont

Projects that load packages using Metacello, tend not to look in Pharo50 and Pharo50Inbox for new versions of those packages. I noticed the Rubric version in Moose 6 to be significantly behind the one in Pharo 5... Can we automatically copy back the inbox/integrator version to its repo? Stephan

Oct. 10, 2015

Re: [Pharo-dev] Problems with a large block

by Nicolai Hess

2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the >> AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan >> this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure >> creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it >> depens on the number of local temps, if this is > 3 we don't hit the right >> one. >> > > That's very strange. Can you construct a synthetic example of two simple > blocks, one with three temps and and one with four temps and show me the > difference in the byte code? > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" Bytecode 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <10> pushTemp: 0 21 <81 43> storeIntoTemp: 3 23 <81 42> storeIntoTemp: 2 25 <81 41> storeIntoTemp: 1 27 <7D> blockReturn 28 <7C> returnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" Bytecode 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <73> pushConstant: nil 21 <10> pushTemp: 0 22 <81 44> storeIntoTemp: 4 24 <81 43> storeIntoTemp: 3 26 <81 42> storeIntoTemp: 2 28 <81 41> storeIntoTemp: 1 30 <7D> blockReturn 31 <7C> returnTop As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: [ :x | | a b c | a:=b:=c:=x ] "bytecodeOffset -> IR" 19->pushClosureCopyCopiedValues: #() args: #(#x) 28->returnTop 20->pushTemp: #x 22->storeTemp: #c 24->storeTemp: #b 26->storeTemp: #a 27->blockReturnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "bytecodeOffset -> IR" 20->pushClosureCopyCopiedValues: #() args: #(#x) 31->returnTop 21->pushTemp: #x 23->storeTemp: #d 25->storeTemp: #c 27->storeTemp: #b 29->storeTemp: #a 30->blockReturnTop Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) For the first block, this works bytecodeOffset 19 = 16 - (-3) For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the second block this is one greater. > And my interpretation was, the IRPushClosureCopy node has the wrong >> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for >> whatever this is used) and we are just using it wrong for in this situation. >> > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, > it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the > BlockCreationBytecode. So if the byte code offset is somehow the span of > the "any number of pushConstant: nil's (0 to N)" then there's a bug in the > IR somewhere when the number of temps is > 3. But if that's not what it > means then, well, I don't know what the problem is. > >

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by Stephan Eggermont

On 10-10-15 20:41, stepharo wrote: > Hi stefan > > could you open a bug entry and publish a merge? > We participated to an hackaton with esteban, pablo, kevin and cyril and we > are not really happy about the tools, the frameworks... > :( I can fix those. How do I check for (partially?) missing source code? Stephan

Oct. 10, 2015