Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
March 2010
- 96 participants
- 1770 messages
Re: [Pharo-project] SmalltalkImage or SystemDictionary
by Nicolas Cellier
2010/3/20 Stéphane Ducasse <stephane.ducasse(a)inria.fr>:
> hasSpecialSelector: ifTrueSetByte:
>
> is heavily used by SystemNavigation but either invoked via Smalltak or self environment or classEnviroment
>
> I would tend to think that this is something that should be part of SmalltalkImage but this is not that clear.
> What do you think?
>
I just don't know. Since it is an information shared by the VM, maybe
it's better letting it here.
Just for curiousity, I checked how these special selectors where
shared in Encoder... Huh, not straightforward !
Nicolas
> Stef
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
March 20, 2010
Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs
Miguel,
I should emphasize that conditional load/compile in Metacello is a pragmatic feature. I don't disagree that the combinatorials can quickly spiral out of control, but for the short term there is no alternative. I won't argue that conditionals _should_ be included in the package management layer, either.
As with all other problems there are several ways to "skin the cat". I _could_ have extended Monticello to have platform-specific code components. I _could_ have added conditional compilation to the Smalltalk compiler. In many ways those solutions are uglier than putting conditional loading into Metacello:)
In the end I added the minimum set of features to Metacello that solved the problems that I was facing on a daily basis and conditional load/compile was high on my list.
With that said, I encourage and support any effort aimed at avoided the use of conditionals:)
Dale
----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote:
| Miguel,
|
| Keep in mind that the conditional load code in Metacello is the moral
| equivalent of #ifdef in C. The debian package universe has the
| advantage of pushing the conditional compilaton of _source code_ down
| a level.
|
| With Metacello, I purposely use the version attribute for conditional
| loading of code (as close to a conditional compile as you can get). In
| Metacello we do the load and the compile...
|
| Where common code can be written it should be, but as versions and
| platforms diverge in their API, something has to give ... If you can
| afford to seal off the source code for an older version then that's
| fine, but in a project that is under active development and is
| _expected_ to run on multiple versions of multiple platforms one must
| resort to "conditional loading" - conditional loading is what makes
| Grease work, BTW.
|
| When you look at the universe of #ifdef in C, you see that some of the
| ifdefs are adhoc and some of the ifdefs are based upon platform
| constants ... and that is what the metacello attributes give you ...
| Right now, you can create project-specific attributes and there are a
| handful of pre-defined attributes ... As I said, I am purposefully
| avoiding adding new pre-defined attributes willy nilly, but anticipate
| that some will be needed (GemStone3.0 and GemStone2.4 and even
| GemStone2.3 need to have difference code compiled/loaded for projects
| that are in active developement and expect to be run on all three
| versions of GemStone the low-level apis are different and different
| code has to be written for each different version).
|
| Having the conditional compile/load component in Metacello isn't
| necessarily an elegant feature, but given that no other part of the
| Smalltalk system currently provides a conditional compile/load, I
| added it to Metacello. Since I am maintaining common software on three
| different versions of gemstone, I consider it a requirement.
|
| If and when an elegant conditional compile/load solution becomes
| available, then this particular feature of Metacello can be allowed to
| die in peace.
|
| I will agree that the MYSQL maintainers don't worry whether their
| executables load on Ubuntu or Fedora, but I can almost guarantee you
| that they have conditional code that makes sure that there their code
| will compile/build on the different OSes.
|
| The ifdef world is as ugly as it comes, but it does exists for a
| pretty good reason.
|
|
| Dale
| ----- "Miguel Enrique Cobá Martinez" <miguel.coba(a)gmail.com> wrote:
|
| | El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
| | > Thanks for the explanation, Dale!
| | >
| | > May be it's obvious and I'm asking stupid questions but then I
| | don't
| | > understand how can I specify in my configuration the differences
| | > between the versions of the target platform?
| | >
| | > 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>:
| | > > George,
| | > >
| | > > The mcz files containing the Metacello configurations _are_
| | copied, but the configuration itself is not modified in the scheme.
| | > >
| | > > The idea of using different repositories is to indicate which of
| | the many different projects are _expected_ or _known_ to work in
| | Pharo1.1 or Pharo1.0.
| | > >
| | > > For GemStone, I have createed a GemSource MetacelloRepository
| and
| | I have copied the metacello configurations that I know have been
| | ported to GemStone. I've done this so that folks can know what is
| | supported. I make sure that all of the tests run green and that all
| of
| | the configs in the GemSource MetacelloRepository can be loaded.
| | > >
| | > > It does not stop someone from loading a configuration into
| | GemStone that isn't in the GemSource MetacelloRepository, but if you
| | do and run into trouble, my answer will probably be that it hasn't
| | been ported yet.
| | > >
| | > > The same thing can apply to Squeak, but someone would have to
| step
| | up to testing/approving metacello configurations that run with the
| | various versions.
| | > >
| | > > Without this extra step of approval/testing, it's difficult for
| | someone that doesn't have their finger on the pulse of the latest
| and
| | greatest happenings to know what to expect ...
| | > >
| | > > Dale
| |
| | The problem is, you are thinking in upstream development, and the
| | idea
| | of universes is that each package has maintainer for each platform
| | involved. This maintainer can be the same person that the upstream
| | developer, but it can also be someone else that make sure that a
| | given
| | package load correctly in *a give* fork.
| |
| | Making an analogy, what you are saying is that the maintainers of
| | MySQL
| | deb package in Debian should be worried about the package not
| loading
| | in
| | Ubuntu or Fedora. That is not the case. The upstream code can run in
| | all
| | of three distros, but the packages specific to each one (.deb in
| | debian
| | and ubuntu and .rpm in fedora) *must* be build and tested for their
| | own
| | maintainers. The upstream developers can rightfully don't give a
| dime
| | about where is package is being used and maybe they only release
| | a .tar.gz and know nothing (but also they don't stop efforts) about
| | external package for specific distros.
| |
| | So, returning to your question, maybe sometime in the future Squeak
| | (if
| | interested) will have to build its own repositories with its own
| | universes and put there the configurations that are proved to work
| in
| | Squeak.
| |
| | Right now as Pharo and Squeak are very similar the configurations
| | (and
| | the #common you mention) works, but this isn't going to scale for
| | different Smalltalks in the long term.
| |
| | Cheers
| | >
| | > _______________________________________________
| | > Pharo-project mailing list
| | > Pharo-project(a)lists.gforge.inria.fr
| | >
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| |
| | --
| | Miguel Cobá
| | http://miguel.leugim.com.mx
|
| _______________________________________________
| Pharo-project mailing list
| Pharo-project(a)lists.gforge.inria.fr
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
March 20, 2010
[Pharo-project] SmalltalkImage or SystemDictionary
by Stéphane Ducasse
hasSpecialSelector: ifTrueSetByte:
is heavily used by SystemNavigation but either invoked via Smalltak or self environment or classEnviroment
I would tend to think that this is something that should be part of SmalltalkImage but this is not that clear.
What do you think?
Stef
March 20, 2010
Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs
Miguel,
Keep in mind that the conditional load code in Metacello is the moral equivalent of #ifdef in C. The debian package universe has the advantage of pushing the conditional compilaton of _source code_ down a level.
With Metacello, I purposely use the version attribute for conditional loading of code (as close to a conditional compile as you can get). In Metacello we do the load and the compile...
Where common code can be written it should be, but as versions and platforms diverge in their API, something has to give ... If you can afford to seal off the source code for an older version then that's fine, but in a project that is under active development and is _expected_ to run on multiple versions of multiple platforms one must resort to "conditional loading" - conditional loading is what makes Grease work, BTW.
When you look at the universe of #ifdef in C, you see that some of the ifdefs are adhoc and some of the ifdefs are based upon platform constants ... and that is what the metacello attributes give you ... Right now, you can create project-specific attributes and there are a handful of pre-defined attributes ... As I said, I am purposefully avoiding adding new pre-defined attributes willy nilly, but anticipate that some will be needed (GemStone3.0 and GemStone2.4 and even GemStone2.3 need to have difference code compiled/loaded for projects that are in active developement and expect to be run on all three versions of GemStone the low-level apis are different and different code has to be written for each different version).
Having the conditional compile/load component in Metacello isn't necessarily an elegant feature, but given that no other part of the Smalltalk system currently provides a conditional compile/load, I added it to Metacello. Since I am maintaining common software on three different versions of gemstone, I consider it a requirement.
If and when an elegant conditional compile/load solution becomes available, then this particular feature of Metacello can be allowed to die in peace.
I will agree that the MYSQL maintainers don't worry whether their executables load on Ubuntu or Fedora, but I can almost guarantee you that they have conditional code that makes sure that there their code will compile/build on the different OSes.
The ifdef world is as ugly as it comes, but it does exists for a pretty good reason.
Dale
----- "Miguel Enrique Cobá Martinez" <miguel.coba(a)gmail.com> wrote:
| El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
| > Thanks for the explanation, Dale!
| >
| > May be it's obvious and I'm asking stupid questions but then I
| don't
| > understand how can I specify in my configuration the differences
| > between the versions of the target platform?
| >
| > 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>:
| > > George,
| > >
| > > The mcz files containing the Metacello configurations _are_
| copied, but the configuration itself is not modified in the scheme.
| > >
| > > The idea of using different repositories is to indicate which of
| the many different projects are _expected_ or _known_ to work in
| Pharo1.1 or Pharo1.0.
| > >
| > > For GemStone, I have createed a GemSource MetacelloRepository and
| I have copied the metacello configurations that I know have been
| ported to GemStone. I've done this so that folks can know what is
| supported. I make sure that all of the tests run green and that all of
| the configs in the GemSource MetacelloRepository can be loaded.
| > >
| > > It does not stop someone from loading a configuration into
| GemStone that isn't in the GemSource MetacelloRepository, but if you
| do and run into trouble, my answer will probably be that it hasn't
| been ported yet.
| > >
| > > The same thing can apply to Squeak, but someone would have to step
| up to testing/approving metacello configurations that run with the
| various versions.
| > >
| > > Without this extra step of approval/testing, it's difficult for
| someone that doesn't have their finger on the pulse of the latest and
| greatest happenings to know what to expect ...
| > >
| > > Dale
|
| The problem is, you are thinking in upstream development, and the
| idea
| of universes is that each package has maintainer for each platform
| involved. This maintainer can be the same person that the upstream
| developer, but it can also be someone else that make sure that a
| given
| package load correctly in *a give* fork.
|
| Making an analogy, what you are saying is that the maintainers of
| MySQL
| deb package in Debian should be worried about the package not loading
| in
| Ubuntu or Fedora. That is not the case. The upstream code can run in
| all
| of three distros, but the packages specific to each one (.deb in
| debian
| and ubuntu and .rpm in fedora) *must* be build and tested for their
| own
| maintainers. The upstream developers can rightfully don't give a dime
| about where is package is being used and maybe they only release
| a .tar.gz and know nothing (but also they don't stop efforts) about
| external package for specific distros.
|
| So, returning to your question, maybe sometime in the future Squeak
| (if
| interested) will have to build its own repositories with its own
| universes and put there the configurations that are proved to work in
| Squeak.
|
| Right now as Pharo and Squeak are very similar the configurations
| (and
| the #common you mention) works, but this isn't going to scale for
| different Smalltalks in the long term.
|
| Cheers
| >
| > _______________________________________________
| > Pharo-project mailing list
| > Pharo-project(a)lists.gforge.inria.fr
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| --
| Miguel Cobá
| http://miguel.leugim.com.mx
March 20, 2010
Re: [Pharo-project] Graphics fixes?
by Stéphane Ducasse
On Mar 20, 2010, at 9:06 PM, Nicolas Cellier wrote:
> 2010/3/20 Stéphane Ducasse <stephane.ducasse(a)inria.fr>:
>> Hi nicolas
>>
>> last week you pushed some squeak rendering fixes to pharo and I was wondering if the recent ones on squeak should be considered.
>>
>> Stef
>>
>>
>
> Yes.
> I just analyzed the diffs between CharacterScanner & subclasses with
> MultiCharacterScanner family and fixed the diffs.
did you publish something I should integrate?
> It would be far better to have Test Cases !!!
Yes I plan to invest on that.
> Last change is a just a clean-up, Writing the whileFalse depending on
> true exit condition rather than an infinite loop with exit returns
> seems cleaner to me.
>
> Nicolas
>
>>
>> commits(a)source.squeak.org
>>
>> to squeak-dev, packages
>> show details 6:44 PM (15 hours ago)
>> Nicolas Cellier uploaded a new version of Graphics to project The Trunk:
>> http://source.squeak.org/trunk/Graphics-nice.121.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Graphics-nice.121
>> Author: nice
>> Time: 19 March 2010, 6:44:28.896 pm
>> UUID: 62e03b94-65c3-614f-b0f0-76c0476055e7
>> Ancestors: Graphics-ar.120
>>
>> 1) Add some missing pendingKernX reset.
>> 2) explicit a loop dependency on stopCondition
>>
>> =============== Diff against Graphics-ar.120 ===============
>>
>> Item was changed:
>> ----- Method: CharacterScanner>>plainTab (in category 'scanning') -----
>> plainTab
>> "This is the basic method of adjusting destX for a tab."
>> destX := (alignment = Justified and: [self leadingTab not])
>> ifTrue: "embedded tabs in justified text are weird"
>> [destX + (textStyle tabWidth - (line justifiedTabDeltaFor: spaceCount)) max: destX]
>> ifFalse:
>> [textStyle nextTabXFrom: destX
>> leftMargin: leftMargin
>> + rightMargin: rightMargin].
>> + pendingKernX := 0.!
>> - rightMargin: rightMargin]!
>>
>> Item was changed:
>> ----- Method: DisplayScanner>>paddedSpace (in category 'stop conditions') -----
>> paddedSpace
>> "Each space is a stop condition when the alignment is right justified.
>> Padding must be added to the base width of the space according to
>> which space in the line this space is and according to the amount of
>> space that remained at the end of the line when it was composed."
>>
>> spaceCount := spaceCount + 1.
>> destX := destX + spaceWidth + (line justifiedPadFor: spaceCount font: font).
>> lastIndex := lastIndex + 1.
>> + pendingKernX := 0.
>> ^ false!
>>
>> Item was changed:
>> ----- Method: CharacterBlockScanner>>characterBlockAtPoint:index:in: (in category 'scanning') -----
>> characterBlockAtPoint: aPoint index: index in: textLine
>> "This method is the Morphic characterBlock finder. It combines
>> MVC's characterBlockAtPoint:, -ForIndex:, and buildCharcterBlock:in:"
>> + | runLength lineStop stopCondition |
>> - | runLength lineStop done stopCondition |
>> line := textLine.
>> rightMargin := line rightMargin.
>> lastIndex := line first.
>> self setStopConditions. "also sets font"
>> characterIndex := index. " == nil means scanning for point"
>> characterPoint := aPoint.
>> (characterPoint isNil or: [characterPoint y > line bottom])
>> ifTrue: [characterPoint := line bottomRight].
>> (text isEmpty or: [(characterPoint y < line top or: [characterPoint x < line left])
>> or: [characterIndex notNil and: [characterIndex < line first]]])
>> ifTrue: [^ (CharacterBlock new stringIndex: line first text: text
>> topLeft: line leftMargin@line top extent: 0 @ textStyle lineGrid)
>> textLine: line].
>> destX := leftMargin := line leftMarginForAlignment: alignment.
>> destY := line top.
>> runLength := text runLengthFor: line first.
>> characterIndex
>> ifNotNil: [lineStop := characterIndex "scanning for index"]
>> ifNil: [lineStop := line last "scanning for point"].
>> runStopIndex := lastIndex + (runLength - 1) min: lineStop.
>> lastCharacterExtent := 0 @ line lineHeight.
>> spaceCount := 0.
>>
>> + [
>> + stopCondition := self scanCharactersFrom: lastIndex to: runStopIndex
>> - done := false.
>> - [done] whileFalse:
>> - [stopCondition := self scanCharactersFrom: lastIndex to: runStopIndex
>> in: text string rightX: characterPoint x
>> stopConditions: stopConditions kern: kern.
>> + "see setStopConditions for stopping conditions for character block operations."
>> - "see setStopConditions for stopping conditions for character block operations."
>> self lastCharacterExtentSetX: (specialWidth
>> ifNil: [font widthOf: (text at: lastIndex)]
>> ifNotNil: [specialWidth]).
>> + self perform: stopCondition
>> + ] whileFalse.
>> + characterIndex
>> + ifNil: [
>> + "Result for characterBlockAtPoint: "
>> + (stopCondition ~~ #cr and: [ lastIndex == line last
>> + and: [ aPoint x > ((characterPoint x) + (lastCharacterExtent x / 2)) ]])
>> + ifTrue: [ "Correct for right half of last character in line"
>> + ^ (CharacterBlock new stringIndex: lastIndex + 1
>> + text: text
>> + topLeft: characterPoint + (lastCharacterExtent x @ 0) + (font descentKern @ 0)
>> + extent: 0 @ lastCharacterExtent y)
>> + textLine: line ].
>> + ^ (CharacterBlock new
>> + stringIndex: lastIndex
>> + text: text topLeft: characterPoint + (font descentKern @ 0)
>> + extent: lastCharacterExtent - (font baseKern @ 0))
>> + textLine: line]
>> + ifNotNil: ["Result for characterBlockForIndex: "
>> + ^ (CharacterBlock new
>> + stringIndex: characterIndex
>> + text: text topLeft: characterPoint + ((font descentKern) - kern @ 0)
>> + extent: lastCharacterExtent)
>> + textLine: line]!
>> - (self perform: stopCondition) ifTrue:
>> - [characterIndex
>> - ifNil: [
>> - "Result for characterBlockAtPoint: "
>> - (stopCondition ~~ #cr and: [ lastIndex == line last
>> - and: [ aPoint x > ((characterPoint x) + (lastCharacterExtent x / 2)) ]])
>> - ifTrue: [ "Correct for right half of last character in line"
>> - ^ (CharacterBlock new stringIndex: lastIndex + 1
>> - text: text
>> - topLeft: characterPoint + (lastCharacterExtent x @ 0) + (font descentKern @ 0)
>> - extent: 0 @ lastCharacterExtent y)
>> - textLine: line ].
>> - ^ (CharacterBlock new stringIndex: lastIndex
>> - text: text topLeft: characterPoint + (font descentKern @ 0)
>> - extent: lastCharacterExtent - (font baseKern @ 0))
>> - textLine: line]
>> - ifNotNil: ["Result for characterBlockForIndex: "
>> - ^ (CharacterBlock new stringIndex: characterIndex
>> - text: text topLeft: characterPoint + ((font descentKern) - kern @ 0)
>> - extent: lastCharacterExtent)
>> - textLine: line]]]!
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
March 20, 2010
Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by Stéphane Ducasse
Sorry but this is certainly not a show stopper so this bug will not be integrated.
Stef
> I just think the issue #1155 should also be addressed before we could claim 1.0 "done".
>
>
>
> Em 20/03/2010 16:40, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu:
> Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0.
>
> This image is based in PharoCore-1.0-10515rc3. The image also contain lot of fixes and improvements of external packages:
>
> These, are the fixed issues of the external tools:
>
> OB: Issues 1891, 1748, 1670, 1667, 1705, 1667
>
> O2: issues 1887, 1312, 1429, 1886, 2073
>
> New Inspector: issues 1783, 1499
>
> Refactoring Browser: issue 2108
>
> The link is: https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.…
>
> Cheers
>
> Mariano
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
March 20, 2010
Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by Stéphane Ducasse
thanks a lot mariano.
this is cool to have somebody like you helping and pushing pharo that way.
Stef
On Mar 20, 2010, at 8:40 PM, Mariano Martinez Peck wrote:
> Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0.
>
> This image is based in PharoCore-1.0-10515rc3. The image also contain lot of fixes and improvements of external packages:
>
> These, are the fixed issues of the external tools:
>
> OB: Issues 1891, 1748, 1670, 1667, 1705, 1667
>
> O2: issues 1887, 1312, 1429, 1886, 2073
>
> New Inspector: issues 1783, 1499
>
> Refactoring Browser: issue 2108
>
> The link is: https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.…
>
> Cheers
>
> Mariano
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
March 20, 2010
Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by csrabak@bol.com.br
I just think the issue #1155 should also be addressed before we could claim 1.0 "done".
Em 20/03/2010 16:40, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu:
Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0.
This image is based in PharoCore-1.0-10515rc3. The image also contain lot of fixes and improvements of external packages:
These, are the fixed issues of the external tools:
OB:Â Issues 1891, 1748, 1670, 1667, 1705, 1667
O2: issues 1887, 1312, 1429, 1886, 2073
New Inspector:Â issues 1783, 1499
Refactoring Browser:Â issue 2108
The link is: https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.…
Cheers
Mariano
March 20, 2010
Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Miguel Enrique Cobá Martinez
El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
> Thanks for the explanation, Dale!
>
> May be it's obvious and I'm asking stupid questions but then I don't
> understand how can I specify in my configuration the differences
> between the versions of the target platform?
>
> 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>:
> > George,
> >
> > The mcz files containing the Metacello configurations _are_ copied, but the configuration itself is not modified in the scheme.
> >
> > The idea of using different repositories is to indicate which of the many different projects are _expected_ or _known_ to work in Pharo1.1 or Pharo1.0.
> >
> > For GemStone, I have createed a GemSource MetacelloRepository and I have copied the metacello configurations that I know have been ported to GemStone. I've done this so that folks can know what is supported. I make sure that all of the tests run green and that all of the configs in the GemSource MetacelloRepository can be loaded.
> >
> > It does not stop someone from loading a configuration into GemStone that isn't in the GemSource MetacelloRepository, but if you do and run into trouble, my answer will probably be that it hasn't been ported yet.
> >
> > The same thing can apply to Squeak, but someone would have to step up to testing/approving metacello configurations that run with the various versions.
> >
> > Without this extra step of approval/testing, it's difficult for someone that doesn't have their finger on the pulse of the latest and greatest happenings to know what to expect ...
> >
> > Dale
The problem is, you are thinking in upstream development, and the idea
of universes is that each package has maintainer for each platform
involved. This maintainer can be the same person that the upstream
developer, but it can also be someone else that make sure that a given
package load correctly in *a give* fork.
Making an analogy, what you are saying is that the maintainers of MySQL
deb package in Debian should be worried about the package not loading in
Ubuntu or Fedora. That is not the case. The upstream code can run in all
of three distros, but the packages specific to each one (.deb in debian
and ubuntu and .rpm in fedora) *must* be build and tested for their own
maintainers. The upstream developers can rightfully don't give a dime
about where is package is being used and maybe they only release
a .tar.gz and know nothing (but also they don't stop efforts) about
external package for specific distros.
So, returning to your question, maybe sometime in the future Squeak (if
interested) will have to build its own repositories with its own
universes and put there the configurations that are proved to work in
Squeak.
Right now as Pharo and Squeak are very similar the configurations (and
the #common you mention) works, but this isn't going to scale for
different Smalltalks in the long term.
Cheers
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Miguel Cobá
http://miguel.leugim.com.mx
March 20, 2010
Re: [Pharo-project] Graphics fixes?
by Nicolas Cellier
2010/3/20 Stéphane Ducasse <stephane.ducasse(a)inria.fr>:
> Hi nicolas
>
> last week you pushed some squeak rendering fixes to pharo and I was wondering if the recent ones on squeak should be considered.
>
> Stef
>
>
Yes.
I just analyzed the diffs between CharacterScanner & subclasses with
MultiCharacterScanner family and fixed the diffs.
It would be far better to have Test Cases !!!
Last change is a just a clean-up, Writing the whileFalse depending on
true exit condition rather than an infinite loop with exit returns
seems cleaner to me.
Nicolas
>
> commits(a)source.squeak.org
>
> Â to squeak-dev, packages
> show details 6:44 PM (15 hours ago)
> Nicolas Cellier uploaded a new version of Graphics to project The Trunk:
> http://source.squeak.org/trunk/Graphics-nice.121.mcz
>
> ==================== Summary ====================
>
> Name: Graphics-nice.121
> Author: nice
> Time: 19 March 2010, 6:44:28.896 pm
> UUID: 62e03b94-65c3-614f-b0f0-76c0476055e7
> Ancestors: Graphics-ar.120
>
> 1) Add some missing pendingKernX reset.
> 2) explicit a loop dependency on stopCondition
>
> =============== Diff against Graphics-ar.120 ===============
>
> Item was changed:
> Â ----- Method: CharacterScanner>>plainTab (in category 'scanning') -----
> Â plainTab
> Â Â Â "This is the basic method of adjusting destX for a tab."
> Â Â Â destX := (alignment = Justified and: [self leadingTab not])
> Â Â Â Â Â Â Â ifTrue: Â Â Â Â "embedded tabs in justified text are weird"
> Â Â Â Â Â Â Â Â Â Â Â [destX + (textStyle tabWidth - (line justifiedTabDeltaFor: spaceCount)) max: destX]
> Â Â Â Â Â Â Â ifFalse:
> Â Â Â Â Â Â Â Â Â Â Â [textStyle nextTabXFrom: destX
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â leftMargin: leftMargin
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rightMargin: rightMargin].
> + Â Â Â pendingKernX := 0.!
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rightMargin: rightMargin]!
>
> Item was changed:
> Â ----- Method: DisplayScanner>>paddedSpace (in category 'stop conditions') -----
> Â paddedSpace
> Â Â Â "Each space is a stop condition when the alignment is right justified.
> Â Â Â Padding must be added to the base width of the space according to
> Â Â Â which space in the line this space is and according to the amount of
> Â Â Â space that remained at the end of the line when it was composed."
>
> Â Â Â spaceCount := spaceCount + 1.
> Â Â Â destX := destX + spaceWidth + (line justifiedPadFor: spaceCount font: font).
> Â Â Â lastIndex := lastIndex + 1.
> + Â Â Â pendingKernX := 0.
> Â Â Â ^ false!
>
> Item was changed:
> Â ----- Method: CharacterBlockScanner>>characterBlockAtPoint:index:in: (in category 'scanning') -----
> Â characterBlockAtPoint: aPoint index: index in: textLine
> Â Â Â "This method is the Morphic characterBlock finder. Â It combines
> Â Â Â MVC's characterBlockAtPoint:, -ForIndex:, and buildCharcterBlock:in:"
> + Â Â Â | runLength lineStop stopCondition |
> - Â Â Â | runLength lineStop done stopCondition |
> Â Â Â line := textLine.
> Â Â Â rightMargin := line rightMargin.
> Â Â Â lastIndex := line first.
> Â Â Â self setStopConditions. Â Â Â Â "also sets font"
> Â Â Â characterIndex := index. Â " == nil means scanning for point"
> Â Â Â characterPoint := aPoint.
> Â Â Â (characterPoint isNil or: [characterPoint y > line bottom])
> Â Â Â Â Â Â Â ifTrue: [characterPoint := line bottomRight].
> Â Â Â (text isEmpty or: [(characterPoint y < line top or: [characterPoint x < line left])
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [characterIndex notNil and: [characterIndex < line first]]])
> Â Â Â Â Â Â Â ifTrue: [^ (CharacterBlock new stringIndex: line first text: text
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â topLeft: line leftMargin@line top extent: 0 @ textStyle lineGrid)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line].
> Â Â Â destX := leftMargin := line leftMarginForAlignment: alignment.
> Â Â Â destY := line top.
> Â Â Â runLength := text runLengthFor: line first.
> Â Â Â characterIndex
>        ifNotNil:    [lineStop := characterIndex  "scanning for index"]
>        ifNil:  [lineStop := line last  "scanning for point"].
> Â Â Â runStopIndex := lastIndex + (runLength - 1) min: lineStop.
> Â Â Â lastCharacterExtent := 0 @ line lineHeight.
> Â Â Â spaceCount := 0.
>
> + Â Â Â [
> + Â Â Â Â Â Â Â stopCondition := self scanCharactersFrom: lastIndex to: runStopIndex
> -    done  := false.
> - Â Â Â [done] whileFalse:
> - Â Â Â Â Â Â Â [stopCondition := self scanCharactersFrom: lastIndex to: runStopIndex
> Â Â Â Â Â Â Â Â Â Â Â in: text string rightX: characterPoint x
> Â Â Â Â Â Â Â Â Â Â Â stopConditions: stopConditions kern: kern.
> + Â Â Â Â Â Â Â "see setStopConditions for stopping conditions for character block operations."
> -        "see setStopConditions for stopping conditions for character block    operations."
> Â Â Â Â Â Â Â self lastCharacterExtentSetX: (specialWidth
> Â Â Â Â Â Â Â Â Â Â Â ifNil: [font widthOf: (text at: lastIndex)]
> Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [specialWidth]).
> + Â Â Â Â Â Â Â self perform: stopCondition
> + Â Â Â ] whileFalse.
> + Â Â Â characterIndex
> + Â Â Â Â Â Â Â ifNil: [
> + Â Â Â Â Â Â Â Â Â Â Â "Result for characterBlockAtPoint: "
> + Â Â Â Â Â Â Â Â Â Â Â (stopCondition ~~ #cr and: [ lastIndex == line last
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â and: [ aPoint x > ((characterPoint x) + (lastCharacterExtent x / 2)) ]])
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ "Correct for right half of last character in line"
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new stringIndex: lastIndex + 1
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â topLeft: characterPoint + (lastCharacterExtent x @ 0) + (font descentKern @ 0)
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: Â 0 @ lastCharacterExtent y)
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line ].
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â stringIndex: lastIndex
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text topLeft: characterPoint + (font descentKern @ 0)
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: lastCharacterExtent - (font baseKern @ 0))
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line]
> + Â Â Â Â Â Â Â ifNotNil: ["Result for characterBlockForIndex: "
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â stringIndex: characterIndex
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text topLeft: characterPoint + ((font descentKern) - kern @ 0)
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: lastCharacterExtent)
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line]!
> - Â Â Â Â Â Â Â (self perform: stopCondition) ifTrue:
> - Â Â Â Â Â Â Â Â Â Â Â [characterIndex
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNil: [
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Result for characterBlockAtPoint: "
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (stopCondition ~~ #cr and: [ lastIndex == line last
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â and: [ aPoint x > ((characterPoint x) + (lastCharacterExtent x / 2)) ]])
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ "Correct for right half of last character in line"
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new stringIndex: lastIndex + 1
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â topLeft: characterPoint + (lastCharacterExtent x @ 0) + (font descentKern @ 0)
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: Â 0 @ lastCharacterExtent y)
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line ].
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new stringIndex: lastIndex
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text topLeft: characterPoint + (font descentKern @ 0)
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: lastCharacterExtent - (font baseKern @ 0))
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line]
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: ["Result for characterBlockForIndex: "
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ (CharacterBlock new stringIndex: characterIndex
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â text: text topLeft: characterPoint + ((font descentKern) - kern @ 0)
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â extent: lastCharacterExtent)
> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â textLine: line]]]!
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
March 20, 2010