- Pharo-dev - lists.pharo.org

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

[Pharo-project] Pharo won't make a VM in linux
by Javier PimÃ¡s Feb. 24, 2010

Feb. 24, 2010

This is a spin-off of the Alien's building thread, I think it deserved it's own thread. I first faced this while trying to build alien, but then I noticed it's unrelated. The VM is not building in linux, and I think it's not caused by my machine's configuration. I'm using 1.0RC2, with VMMaker loaded yesterday using configurationOfVMMaker. I also applied ObjectMemory initializeWithBytesToWord: Smalltalk wordSize. as told in the other thread to fix some issues. Plugins are: - internal: B3DAcceleratorPlugin, BaloonEnginePlugin, BitBltSimulation, FilePlugin, SocketPlugin. - By the way, I'm also having to include some dummy plugin as external. If I don't, cmake will make some weird stuff like creating a = directory and then fail. I use ADPCMCodecPlugin. The errors are these: ... Linking C executable squeakvm B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): In function `glRenderVertexBuffer': /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: undefined reference to `glColorMaterial' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: undefined reference to `glGetError' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: undefined reference to `glEnable' /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: undefined reference to `glGetError' ... /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: undefined reference to `glLightModelfv' /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: undefined reference to `glGetError' collect2: ld returned 1 exit status make[2]: *** [squeakvm] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2 Maybe it should be linking to opengl lib but it isn't, what do you think? Regards, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

4 5

[Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
by StÃ©phane Ducasse Feb. 24, 2010

Feb. 24, 2010

After the lengthly discussion about the fact that Smalltalk implementation is a balkan region (cf "what Pharo/squeak do not parse 16rFF) > Authorize - at any position in binary selectors (like VW 7.7) > See http://bugs.squeak.org/view.php?id=3616 > Address the problem of compiling 1@-2 with following strategy: > > If compiler is non interactive, then compile with backward compatibility 1 @ (-2). > If compiler is interactive, propose a menu to disambiguate and insert a proper space. > 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 > 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 > > Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... > I didn't do anything to support this vicious Squeakism, and by now the semantics are change. I was wondering what do we do with that kind of changes. Is it useful? what is the end user case? what are the binary operators that we could invent with -~- -| -@ nicolas do you have a case in mind? what VW people use it for? Now do we want this in pharo? What is the cost? Impact / broken code? > Stef

4 12

[Pharo-project] [update 1.1] #11232
by Marcus Denker Feb. 24, 2010

Feb. 24, 2010

11232 ----- Issue 2064: Tests for Cull: Issue 2044: fix cycles Issue 1797: Object>>initialExtent (again) Issue 2070: hierarchy button DNU in the Browser Issue 1972: clean ResourceCollector, ResourceManager and ResouceLocator -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 2070: hierarchy button DNU in the Browser
by Pavel Krivanek Feb. 24, 2010

Feb. 24, 2010

see http://code.google.com/p/pharo/issues/detail?id=2070 fix included -- Pavel

1 0

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

Feb. 24, 2010

Crosspost squeak-dev/pharo-dev Andreas Raab wrote: >a) Currently a book depends on the presence of HelpSystem (i.e., via >subclassing). No, you are not forced to be in the "CustomHelp" hierarchy. You can define an own hierarchy, directly as subclass of Object, whatever (athough I would recommond CustomHelp as common superclass similar to TestCase in SUnit) The standard builder ("HelpBuilder") is able to use a different root. See HelpBuilder class>>buildFromRoot: and HelpBuilder>>defaultRoot. With HelpSystem-Core-tbn.16 I even allow to provide own builders. To get the latest you can just load the baseline: (ConfigurationOfHelpSystem project version: '1.0-baseline') load b) Typing in '' quotes is pretty insane when you quote text. I know, but this is annoying since you currently write it manually using the browser and by adding methods yourself. Storing the contents in method is just the vehicle - additional authoring capabilities would help here in the future (an additional HelpEditor beside the HelpViewer). Again you judged too early. I would also like to see some reactivation of Scamper code for a more capable viewer/editor - since with a basic support for simple markup we could catch two flies by providing in-image and web-help with the same contents/source. >I'm not saying that comments are the only way by which HelpBooks should >be created but I think that this should be one of the ways that >HelpSystem directly supports. That's already there - Danny already added this for the help classes. Just open the book "Help on Help" -> "HelpSystem API Documentation" and subnodes after loading the latest baseline. If you click on a class node you will see the class comment displayed in the help (currently as ASCII). We may add a book "Reference" where you open two subbooks: "By categories" and "By hierarchy" - displaying the classes using categories or in their usual class hierarchy for browsing. However: the main question to me is the kind of format we should use: a) Wiki Style or similar + easy to write + easy to transform - mostly non-standard With Maven the APT format is often used [1], Eclipse for instance provides even editors, see [2] for screenshots) But we also have Tiny wiki syntax somewhere on SqueakSource which may be similar. b) real markup like HTML + easy to put onto the web without tranformation - we need to have more markup support -/+ embedding of Smalltalk has to be done the W3C way, similar to javascript <a href="smalltalk:..." c) specific format like Squeaks Text representation with textDoits, ... - very Squeak specific and may not work in Pharo - hard to put on the web I would like to see b) with a cleaned up Scamper code since a general markup editor/viewer would be helpfull anyway and it would be easy to publish stuff on the web. But looks like more work. There is also another HTML browser with markup and CSS now available open source as MIT (WithStyle), see [3] and [4] for more info. Maybe someone has a minute ;) Bye T. [1] http://maven.apache.org/doxia/references/apt-format.html [2] http://sourceforge.net/project/screenshots.php?group_id=193560 [3] http://n4.nabble.com/ANN-HelpSystem-was-ProfStef-td1554685.html [4] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&… -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

2 1

[Pharo-project] Issue 1972 clean ResourceCollector, ResourceManager and ResouceLocator reopened
by Pavel Krivanek Feb. 24, 2010

Feb. 24, 2010

Hi, I reopened the issue 1972 because it caused an obsolete class instance in Project current instVarNamed: #resourceManager Cheers, -- Pavel

2 1

[Pharo-project] Issue 1797 Object>>initialExtent reopened
by Pavel Krivanek Feb. 24, 2010

Feb. 24, 2010

Hi, I reopened the issue 1797 because it caused the deprecation warning while opening the FileBrowser. see: http://code.google.com/p/pharo/issues/detail?id=1797 -- Pavel

1 0

Re: [Pharo-project] [ANN] Magma 1.0 release 44
by Chris Muller Feb. 24, 2010

Feb. 24, 2010

Hi Ramiro, something happened between Pharo1.0-10502-rc1dev09.12.2. and 10508 related to Networking. Please see: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021912.h… I am not sure what happened. Perhaps someone on the Pharo team would elaborate? - Chris On Tue, Feb 23, 2010 at 6:54 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name> wrote: > Hi Chris, > Once again, thanks for your work. > One question though, is this version running fine on the latest Pharo 1.0 ? > I haven't been able to start a server successfuly, I get a primitive has > failed. > It doesn't run on Pharo 1.1 or Squeak trunk but you didn't mention those :) > I loaded it in a fresh Pharo 1.0 image using: > ScriptLoader new installer. > Installer ss project: 'Magma'; > install: '1.0r44 (server)'. > > Cheers > > r > > On Wed, Feb 17, 2010 at 8:46 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> I am pleased to announce the immediate availability of Magma 1.0 >> release "44" for both Squeak, 3.9, 3.10 and Pharo. Â Although I am >> looking into alternatives for future releases, for now I am still >> distributing Magma in my traditional ways: >> >> Â - On SqueakMap - three one-click installable packages. >> >> Â - In the "1.0r44" Monticello Configuration in the "Magma" project of >> squeaksource, there are three one-click installable configurations >> (client, server, tester). >> >> Â - The "r44Final" Monticello Configuration in the "MagmaTester" >> project of squeaksource is the one-click installable MagmaTester >> package. >> >> As has always been the case, ONLY ONE of the three packages needs to >> be installed, the full and proper configuration is loaded with >> one-click. >> >> Compared to r43, this is mostly a maintenance release without any >> major new functionality, but with improved robustness in the HA and >> luxury querying as well as several other fixes. Â Here are the specific >> improvements over 43: >> >> Â Â Â Â - Made several HA fixes and improvements, many identified by Bart >> Gaquie by testing with more than a two-server Magma Node. Â Many thanks >> Bart. >> Â Â Â Â - Updated MaQueryExecutor>>#fractionComplete to answer an unreduced >> Fraction instead of a reduced one. Â This convey's more information; >> since the denominator represents the total number of elements in the >> final result. Â Thanks again to Bart Gauqie. >> Â Â Â Â - Upgraded MagmaCollectionReader>>#release to allow give a >> well-behaved application much freer access to the "luxury" query >> features of MagmaCollections. Â It is essential for applications >> employing luxury query features of Magma for ad-hoc querying, to >> #release the Reader returned from the query so that resources on the >> server can be freed. >> Â Â Â Â - Now properly truncating the applied.images file, so it doesn't >> grow >> and grow.. >> Â Â Â Â - Now, when a repository is opened locally, if it's location has >> never been set (new repository) or was a different *local* location, >> then update it to the new aMagmaLocalLocation. Â If it was formerly a >> network-hosted server, do not update since we could be here simply >> just for re-opening that repository. Â So, to go from a remote >> repository to a local one, you have to manually update the node's >> primaryLocation. >> Â Â Â Â - Server no longer allows any clients to log in with the system >> name, >> since it is sometimes checked for special-purpose server housekeeping. >> Â Â Â Â - Updated MagmaSession's standard printing method, again! >> Â Â Â Â - Added MagmaCollectionReader>>#sortBy:makeDistinct:descending: and >> #sortBy:makeDistinct:descending:. >> Â Â Â Â - Made MaRepositoryDisconnectRequest asynchronous, it now returns >> considerably faster! >> Â Â Â Â - Fix for a recent MagmaCollection optimization. >> Â Â Â Â - Removed hard-reference to OSProcess. >> Â Â Â Â - Patch for #removeListener to avoid DependentsArray problem. >> Â Â Â Â - Fixed a ReadStrategy regression. >> _______________________________________________ >> Magma mailing list >> Magma(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/magma > > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

3 2