February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Magma 1.0 release 44

by Mariano Martinez Peck

Miguel will be probably able to help you. On Wed, Feb 24, 2010 at 8:09 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks we will have a look. > Note that Installer is not available from ScriptLoader (ScriptLoader is not > a public class and nobody should use it) > Either use gofer which is the default loader or install installer manually. > > > Stef > > On Feb 24, 2010, at 5:38 AM, Chris Muller wrote: > > > 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 > >> > >> > > > > _______________________________________________ > > 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 >

Feb. 24, 2010

Re: [Pharo-project] Why a package management system

by Mariano Martinez Peck

On Wed, Feb 24, 2010 at 11:09 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >Janko, I don't know what it "decent" for you, but did you try Metacello-OB > >and Metaceller ? > > I think what is still missing is a common tutorial showing all the details > and pieces that are already here today. Not everybody reads the blog posts > from Dale or follows the mailinglists. > > Yes, that's true. > Is there a preview/early draft for the book chapter on Metacello > available? Could it be posted/discussed here? > > In the chapter, I didn't talk anything about UI. Nothing about Metacello-OB neither Metaceller. I am not sure if we should put it as the chapter is large enought by the moment. Maybe another chapter or a new chapter in a future PBE. But maybe we can include it...I don't know. I don't like the idea of writing a whole chapter all together. Everybody will discuss, disagree, fight, etc. I do share and will share the draft of the chapter for those who are really interested, but in private mail. I know there are people interested: Stef, Dale, maybe Miguel and Doru, and you. I don't have a real draft yet (still writing) but as soon as I have it I can share with those people. Forget any progress from me for this week and the next one. My girlfriend came to visit me to France (I didn't see her for 3 months) Cheers Mariano > Thx > T. > > > > -- > NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

[Pharo-project] Why a package management system

by Torsten Bergmann

>Janko, I don't know what it "decent" for you, but did you try Metacello-OB >and Metaceller ? I think what is still missing is a common tutorial showing all the details and pieces that are already here today. Not everybody reads the blog posts from Dale or follows the mailinglists. Is there a preview/early draft for the book chapter on Metacello available? Could it be posted/discussed here? Thx T. -- NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! http://portal.gmx.net/de/go/dsl02

Feb. 24, 2010

Re: [Pharo-project] Shout

by Mariano Martinez Peck

If you see ConfigurationOfShout >> version10: you will see: package: 'Shout' with: 'Shout-nice.83'; package: 'ShoutWorkspace.1' with: 'ShoutWorkspace.1-tween.4'; package: 'ShoutTests' with: 'ShoutTests-tween.9'. from http://www.squeaksource.com/shout On Tue, Feb 23, 2010 at 10:09 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I would like to know which version of shout we are using and relying on. > Apparently one version was integrated on squeak and I would like to make > sure > that the one we use continue to get improved. > One of these days we will have to think about the status of important > packages that > are external to pharo: shout, XMLSupport.... > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

Re: [Pharo-project] Why a package management system

by Mariano Martinez Peck

2010/2/24 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > On 24. 02. 2010 02:55, Dale Henrichs wrote: > > > If Metacello spurs some folks with "obviously better ideas" to produce a > Package Management system that we > > can all use, then it will have been worth the effort:) > > Until the better mousetrap appears, I will continue to slog along on > Metacello. > > That's a good plan, Dale. Metacello has a momentum right now and with > continuing it has a chance to become a de-facto tool on top of > Monticello for PMS. I just hope that the momentum will continue to some > decent GUI tools as well :) > > Janko, I don't know what it "decent" for you, but did you try Metacello-OB and Metaceller ? > Best regards > Janko > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by Igor Stasenko

On 24 February 2010 10:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > looks like a good master or PhD :) > Interesting but need more cycle to think and play with it. Yes, there's a lot of things to think of. What i imagine is a distributed network of publicly available databases (repositories) where users could easily pick what to load , or update their images without ANY problems using a single mouse click. So, i, for instance could subscribe to Pharo-1.0-stable update stream and to Seaside 3.0-stable update stream. And at any moment i can click 'synchronize' and i'll get the exact match of my code in my own image with code, stored currently in those repos. > Stef > > On Feb 24, 2010, at 8:36 AM, Igor Stasenko wrote: > >> Few more words. >> >> Deltas/packages. >> >> All we need for Delta is to identify the starting point (an image >> state, from where you started changing it). In contrast to >> DeltaStreams model, where it tries to capture both an 'old' and 'new' >> state, so it can be reverted, we don't need it anymore, >> since we can directly see what was the image state before we applied >> the changes to it. Having all of the history preserved and tracked is >> very powerful thing! >> So, Delta only needs to reference to starting point (URI or some ID, >> which identifies it, and in case of need can be easily found on the >> web). >> >> What is cool about it? >> Suppose, initially, all images started from some release (say Pharo >> 1.0), so all users sharing the same sources/image state. >> Now what happens when you start forking or making changes? >> Users creating a deltas and storing them in the database , and their >> images now knowing that they are derived from Pharo 1.0 point but also >> has some changes stored in separate branch or 'fork'. >> >> Now, what happens if user wants to load the changes made by another >> user: system can easily find the common ancestral point (since all >> deltas knowing its own ancestral point). >> And there is two use cases: >> a) you doing a full synchronization with some remote source. This is >> useful, when all of us want to use the very same image. This is >> primarily a good thing for team-based development or Releases(R). >> b) you doing a partial synchronization (or merge) with remote source. >> In this case you creating own fork, which derived from , say Pharo 1.0 >> + some changes from user Foo, Bar, Baz etc and getting own, unique >> version of image. >> >> So no matter in what way you hacking/mixing the changes, you never >> lost track of the system history, which means that for any two images >> which derived from some common ancestral point we could could always >> automatically generate a diff between them. It means that no matter >> how far you went in your hacking - others could always load or >> cherry-pick your code! >> >> Packages? Since model, i describing, operating at lower granularity >> level (individual changes to methods/classes/doits), which means that >> any package can be represented as a set of those >> methods/classes/doits, there should be no problem >> integrating/interacting at a package level. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Lukas Renggli

> Then the question is how you compile 1@-2 and how you provide backward > compatibility. You don't, because this is easy to fix, the ANSI standard is very clear, and it does not prevent code from being loaded. The situation occurs mostly in very old code: Cursor class>>initBottomRight Cursor class>>initResizeLeft Cursor class>>initNormalWithMask Cursor class>>initResizeTopLeft Cursor class>>initCorner Cursor class>>initCrossHair Cursor class>>initSquare Cursor class>>initResizeTop Cursor class>>initResizeTopRight Cursor class>>initBottomLeft DisplayHostWindow>>test2 FlapTab>>fitContents FontChooserMorph>>createWindow Form>>findShapeAroundSeedBlock: Form>>pageImage:at:corner: Form class>>xorHack: Form class>>toothpaste: FuzzyLabelMorph>>drawOn: GroupboxMorph>>newLabelMorph GroupboxMorph>>initialize MethodFinder>>testRandom MethodFinder>>testFromTuple: Morph>>changeColorTarget:selector:originalColor:hand: PaintBoxMorph>>init4 PaintBoxMorph>>fixUpColorPicker Point>>fourNeighbors Point>>eightNeighbors PolygonMorph>>nudgeForLabel: PreDebugWindow>>adjustBookControls SVColorSelectorMorph>>mouseEnterDragging: SVColorSelectorMorph>>mouseDown: SystemWindow>>minimizeOrRestore SystemWindow>>minimizeAfterGeneratingThumbnail TTSampleFontMorph>>drawCharactersOn: TTSampleStringMorph>>computeTransform TabGroupMorph>>initialize UIThemeW2K>>tabSelectorMorphMinExtentFor: I did not find a single occurrence in Seaside, Magritte, Pier, OmniBrowser, RB, NewCompiler, XML, PetitParser, GraphViz, and dozens of other packages from SqueakSource that I have in my image. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 24, 2010

[Pharo-project] HelpSystem & Class comments

by Torsten Bergmann

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

Feb. 24, 2010

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by Nicolas Cellier

2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this was not really my question :) I know that a tree does not twice the same node > do you know when it changed in squeak or pharo and the reason? > > Stef I return the question: so why answer a Set ? For multiple inheritance experiments or for some tools conveniency ? Nicolas > > On Feb 23, 2010, at 11:02 PM, Nicolas Cellier wrote: > >> The single inheritance hierarchy is a Tree... >> I don't see any interest in answering a Set. >> Some tools might expect a Set... >> If so, they just have to use withAllSubclasses asSet. >> >> If my own tool expect a LinkedList, I ain't gonna change the Kernel >> library for my conveniency, or am I ? >> >> Nicolas >> >> 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> 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 >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

Re: [Pharo-project] Pharo won't make a VM in linux

by Mariano Martinez Peck

Javier: I cannot help you, but I can advice you to ask this VM related questions not only in Pharo but also in the VM mailing list: vm-dev(a)lists.squeakfoundation.org as you will probably receive more help :) Cheers Mariano 2010/2/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > Made some tests to find out what is happening, and found the problem. I can > confirm that this happens both in squeak and pharo. The thing is that > B3DAccelerator doesn't work as internal plugin in unix. Making it external > worked fine. > > This lead me to some questions: > > - To make it work as internal the only thing needed is to add that -lGL to > the linking process. Does anybody know how to modify the cmake files to do > that? Maybe it's just a thing of adding a line to > unix/plugins/B3DAcceleratorPlugin/config.cmake or unix/vm/config.cmake?? > > - Does anybody build the VM in unix? using cmake? > > Regards, > Javier. > > > On Mon, Feb 22, 2010 at 1:07 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> I'm cross-posting to vm-dev because I get the same errors with Squeak >> 3.10.2.7179 image. I have >> >> GL_VERSION = 3.2.0 NVIDIA 190.53 >> >> After navigating trough the makefiles, I found I was right, it's not >> linking to opengl. The linking command was autogenerated and sitting in >> blddir/CMakeFiles/squeakvm.dir/link.txt. Adding -lGL to it solved that >> problem. Does anybody know what caused the missing "-lGL" and how to solve >> it? >> >> Now I can get back to trying to compile alien! >> >> Regards, >> Javier. >> >> >> >> But I don't think it's a version problem, these undefined functions are >> there since OpenGL 1. the >> >> On Sun, Feb 21, 2010 at 4:27 PM, Martin McClure <martin(a)hand2mouse.com>wrote: >> >>> Javier PimÃ¡s wrote: >>> > >>> > 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? >>> >>> What version of OpenGL do you have installed on your machine? I haven't >>> looked at the details, but I believe that the interface changed quite a >>> lot between OpenGL 1.x and OpenGL 2.x, so if B3D is expecting 2.x and >>> you have 1.x, or the other way around, you might get problems like this. >>> >>> Regards, >>> >>> -Martin >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010