- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building Pharo on a Core 1.1
by Dale Henrichs Feb. 25, 2010

Feb. 25, 2010

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | But I get an error raised by MetacelloPackageSpec>>instVarNames:put: | | apparently some reflective operations try to access a non-existing | variable. | | I know that Pharo is meant to be built from a stable core. But I would | like to benefit from the snappy interface and the nice menu. Anyone | tried ? Odd... there's one spot where Metacello uses instVarNamed:put: and the names being used should correspond 1 to 1 with instance variables of the specs. Do you have more detail about the error? The receiver's class and the value and class of the args to instVarNamed:put: might help. Dale

2 1

[Pharo-project] [update 1.1] #11233
by StÃ©phane Ducasse Feb. 25, 2010

Feb. 25, 2010

11233 ----- - Issue 2055: Checking squeak fixes to SUnitGUI - Issue 2071: subclasses and withAllSubclasses return a array - Issue 2076: Clean Exceptions - Issue 2072: clean RealEstateAgent Stef

1 0

[Pharo-project] Building Pharo on a Core 1.1
by Torsten Bergmann Feb. 25, 2010

Feb. 25, 2010

>But I would like to benefit from the snappy interface and the nice menu. Yes - but since we changed more than just the nice menu I think the whole config and anything that gets loaded need to be revised for 1.1. Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

2 1

[Pharo-project] hex
by stephane ducasse Feb. 25, 2010

Feb. 25, 2010

in pharo #[122 43 213 7] hex = '7A2BD507' in squeak #[122 43 213 7] hex = '7a2bd507' do you think that it makes a difference? Stef

5 12

[Pharo-project] Re-licensing Squeak
by Torsten Bergmann Feb. 25, 2010

Feb. 25, 2010

FYI: http://lists.squeakfoundation.org/pipermail/news/2010-February/000215.html -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

1 0

[Pharo-project] Why a package management system
by Torsten Bergmann Feb. 24, 2010

Feb. 24, 2010

>So you are educating them.... >Frankly I stopped trying long time ago. No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion. >I think it would be much more ... "becoming" (and fruitful) if we all >could stop "trash talking" each other - especially those of us who play >a "larger role". +1 Meanwhile the Pharo community has grown with new members and many people dont care about old discussions. Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap. I therefore would really like to see a common exchange mechanism used on both sides. I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system. Bye T. "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

11 19

[Pharo-project] withAllSubclasses -> Set or OrderedCollection
by StÃ©phane Ducasse Feb. 24, 2010

Feb. 24, 2010

Nicolas I remember that we discussed this point or a related one a while ago Squeak Point withAllSubclasses an OrderedCollection(Point) Pharo Point withAllSubclasses a Set(Point) Do you remember? I forgot? Stef

2 8

[Pharo-project] Building Pharo on a Core 1.1
by Alexandre Bergel Feb. 24, 2010

Feb. 24, 2010

Hi! I tried to built a Pharo-dev from a 11229. I executed the script given in a Pharo distribution: -=-=-=-=-=-=-=-=-=-=-=-= Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0- rc2.10508') load. Gofer new squeaksource: 'ImageForDevelopers'; package: 'ImageForDevelopers-pharo'; load. (Smalltalk classNamed: #DEVImageCreator) default install. -=-=-=-=-=-=-=-=-=-=-=-= But I get an error raised by MetacelloPackageSpec>>instVarNames:put: apparently some reflective operations try to access a non-existing variable. I know that Pharo is meant to be built from a stable core. But I would like to benefit from the snappy interface and the nice menu. Anyone tried ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
by Dale Henrichs Feb. 24, 2010

Feb. 24, 2010

Doru, That is a good idea. It might also make sense from a Pharo perspective to have a global fallback defined. I am expecting that the mechanisms that we come up with will be useful for individual projects as well as Pharo overall, so building in flexibility at load time (instead of embedded in the configuration) is a good idea. To summarize my takeaway on this issue: - A pharo backup or secondary repository is a good solution to ensure that configurations and packages are "guaranteed" to survive over long periods of time regardless of the state of the primary project repositories - The secondary repository will be maintained by running a scraper script that scans the Metacello configurations that are critical to Pharo. - The script will copy the packages referenced by the configurations into the secondary repository. The configurations will also be copied into the repository. - Whether or not the configuration copies are modified to reference the secondary repository directly or not is still undefined. - This issue will be managed as a separate collection of packages to keep the core of Metacello clean. - The initial short term goal will be to provide a mechanism to do a "one-shot" checkpoint of configurations and packages (no configuration modification) so that a Pharo 1.0 repository of all of the important build artifacts can be archived in the event that the longer term goals aren't met in time. This initial short term goal will be based upon code already in use at GemStone to perform a similar function. - The second phase will be to work out the details of using the repository in real life conditions ... and at this point there are a number of possibilities under consideration. - More details when we get this far:) If I've missed something important, I'm sure you'll let me know:) Dale ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | Hi Dale, | | I believe the original problem is that you do not know upfront about | | where the actual files will be. In this case, perhaps the easiest | solution is to provide some scripting facility to provide a repository | | mapping that should could be modified at loading time, and not be | stored in the actual configuration. | | Suppose you have something like this: | | ConfigurationOfXXX>>baselineX: spec | <version: 'X-baseline'> | spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ]. | ... | | ConfigurationOfXXX>>versionX: spec | <version: 'X' imports: #('X-baseline')> | spec package: 'SomePackage' with: 'SomePackage.tg.1'. | ... | | | Maybe a solution would be that when loading you could say: | | (ConfigurationOfXXX project version: 'X') | withRepositoryMapping: 'SOME_URL' -> 'SOME_NEW_URL'; | withRepositoryMapping: '...' -> '...'; | load | | What do you think? | | In this way, the original configuration specifies everything, and the | | URL works either as the actual URL or as an alias that can be mapped | | to something else later on when you know the actual URL. Actually, | this can already be accomplished at engine level. I believe a simple | | scripting like above would just make it practical. What do you think? | | Cheers, | Doru | | | On 23 Feb 2010, at 21:18, Dale Henrichs wrote: | | > | > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > | > | > Perhaps Gofer can be provided with a secondary repository | location | > | in the case when the primary repository fails. | > | | > | Yes, it can. You just specify multiple repositories and it will | use | > | them all. If you tell Gofer to #disableRepositoryErrors then it | will | > | silently ignore repositories that are not available. | > | > Lukas, | > | > The only thing that worries about including such repository all of | | > the time, is the cost of building the cache of repository when | > resolving repositories ... the secondary repository would get pretty | | > large over time and most of the time (only in the case of errors) | > would it need to be scanned. | > | > I suppose Metacello could handle load errors in the code that calls | | > Gofer and do a retry using the secondary repository...the secondary | | > repository _could_ be specified as part of the configuration, so | > this probably isn't a bad idea... | > | > Thanks, | > | > Dale | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | www.tudorgirba.com | | "Every thing has its own flow."

1 0

Re: [Pharo-project] HelpSystem & Class comments
by Torsten Bergmann Feb. 24, 2010

Feb. 24, 2010

Andreas wrote: >What I'm looking for is a mechanism by which the documentation can >remain in the image even when HelpSystem is absent Why? Do you have test cases subclasses in the image when SUnit is absent? No. I think you want to have support or UI stuff removed/separated (like the viewer) - but a basic model should remain. The costs for the basic help system model support is minimal. Similar to SUnit. If you have the core model (TestCase) you are able to load/process tests done in subclasses. But with a separated UI you have the freedom for an exchangable TestRunner. Same should apply here. >What I'm looking for is a mechanism by which the documentation can >remain in the image even when HelpSystem is absent. So when HelpSystem >is loaded it needs to discover available books. Is there some tag/marker >mechanism by which one can flag those pre-existing books? > >(*hand waiving*) Maybe we should return to a pragma based solution. I originally had something like this. Just load "HelpSystem-Core-tbn.4" and have a look at class HelpHowTo methods. They have a "help" pragram. The pragma processing mechanism is in HelpBuilder>>createBookFrom: Danny removed this to introduce a HelpContent class (to support different content) - which I merged into HelpPage later. >That's why I was saying, why not derive >help books from class comments? How? Would you create a class for each page and use their class comment for the contents? >the only thing I'm asking for is just a tiny bit of additional structure >in a class comment so that one can have sections etc. As I said - maybe we should reactivate some Scamper code and use a markup language. The Parser from "Network-HTML" package on SqS.com/Scamper seems to work. Although it still uses _ instead of :=. We "just" have to rebuld a clean viewer. >We could start with simple Wiki syntax which can be used in >class comments and other simple places. If people feel unsatisfied or >need more or want to use HelpSystem for other purposes, extend it as >desired. We already discussed this and decided to first start with plain text and later add different content types (markup, active bookmorphs, ...) after getting the tool integration and other capabilities done. (I already pointed to the original discussion on pharo-dev) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0