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

[Pharo-project] [update 1.1] #11214

by Marcus Denker

11214 ----- Issue 1945: registration mechanism for the menu Very nice, Alain!!! Issue 1974: remove #disableSubmorphFocusForHand: (part 1) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 17, 2010

Re: [Pharo-project] ConfigurationOfXMLSupport...

by Alexandre Bergel

Hi George, I will be delighted to incorporate some improvements in XML-Support. Currently, the simplest way to contribute is to send me an email with the location of some improvement. I look at them, and if they come with unit tests and they make sense to me, then I include them. Someone deeply committed will become administrator of the squeaksource repository. I saw your fix (0007441), I will look at them right after sending this email. I haven't checked bugs.squeak.org for a long time, but apparently the last improvements proposed by jaayer(a)zoho.com (thanks for this!) includes some of the change proposed on bugs.squeak.org (e.g., 0007465). The comments of the new revision are included below. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= * All searching and enumerating methods have been moved from XMLNode to XMLNodeWithElements. Unless you can think of a scenario where it would make sense to send any of them to a string or PI node, I think this is both a safe and sensible move. * XMLNodeWithElements no longer contains an "elementsAndContents" collection. Instead it has a single "nodes" OrderedCollection that contains all child nodes in the order in which they appeared. The collection returned by #elementsAndContents (and enumerated via #elementsAndContentsDo:) is recreated using #nodes. * #addElement: is now just for elements, and #addNode can be used for everything else (#addElement can still handle non-element nodes, though). #removeNode: and #removeElement: have also been added. Since, for backwards compatibility, the #add* methods don't return the object added, neither will the #remove* method return that which was removed. * Because the costly depth-first traversing #firstTag* and #tagsNamed* methods send #elementsDo: so many times, it makes sense to speed-up #elementsDo: by having it enumerate a separate collection just containing elements; thus, an "elements" collection has been added for that purpose. The repetitive identity checks in the XMLElement versions of those methods have been moved into a single #isNamed: method, which expects a symbol but can also handle strings by sending its argument #asSymbol before making #== comparisons. (#asSymbol is free for symbols, so you only pay if you use strings to specify tag names.) * #tagsNamed:ifReceiverDo:, despite what its name implies (the plural "tags"), does no searching/enumeration. Outside of the implementations of other #tagsNamed:* messages, I doubt anyone uses this, so I have renamed it #ifNamed:do:. * #tagsNamed:ifReceiverOrChildDo: does not work. The XMLElement version evaluates the block if it is so named and then invokes the superclass version of #tagsNamed:ifReceiverDo:, which is an empty method. Since it doesn't work and is ridiculously named, I have removed it. * #tagsNamed:ifReceiverDoAndRecurse: is, oddly enough, exactly equivalent to #tagsNamed:do:. I have removed the XMLElement version and reimplemented the XMLNode(WithElements) version to just send #tagsNamed:do: (although I'd prefer to remove it altogether). * XMLNodeWithElements has a new instance variable: "elementsDictionary," an IndentityDictionay where keys are the qualified and unqualified names of child elements and values are OrderedCollections of so-named elements. This makes #elementAt: have O(1) complexity rather than O(n) and a->b->c traversal have O(n) complexity (where n is the number of nodes counting the root, the target, and all ancestors between) rather than the previous worst-case of O(n^2). This comes at the cost of additional memory and time to add/ remove elements. You can rewrite Pastell accessors in terms of #elementsAt: and #elementAt:. * The #contentsDo: and #elementsAndContentsDo: messages can now only be sent to XMLElements. It makes no sense to send them to documents or other kinds of nodes, as no other kind of node has text content. * I moved #parent and #parent: out of XMLNodeWithElements and put them in XMLNode instead, as every node in the DOM tree save the root has a parent. They actually work now, too, meaning that "((XMLDOMParser parseDocumentFrom: '<p>foo<b>bar</b></p>' readStream) firstTagNamed: #b) parent" will return the "p" element, not nil as it would before. * How often have you sent #parseDocumentFrom: with an XML string as its argument (instead of a stream) and gotten a "message not understood" error? XMLDOMParser's #parseDocumentFrom:useNamespaces: method now sends #readStream to "aStream" if it is not already a stream, so you will no longer receive such errors. * #addEntity:value: has been removed. It has not been touched in ten years and sends a message (#entities) that is not understood. * Confusing "entityName" parameter names in methods expecting element/ tag names were replaced with "aSymbol." * (This package also contains the #=/#hash methods submitted as a feature addition to bugs.squeak.) Lastly, this codebase has had too many hands touching it and looks too inconsistent. I suggest configuring your formatter like so: RBConfigurableFormatter maxLineLength: 80; newLinesAfterMethodPattern: 2; newLinesAfterMethodComment: 2; retainBlankLinesBetweenStatements: true; stringInsideBlocks: ''. And then reformatting XMLNode and its subclasses -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On 17 Feb 2010, at 08:18, George Herolyants wrote: > Btw, how can I contribute to XML-Support? Is there some process? > Because I've created two issues on bugs.squeak.org a month ago and > still don't know if they were noticed or not? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 17, 2010

Re: [Pharo-project] [Moose-dev] New version of XMLParser

by Tudor Girba

Hi Alex, Could you give us a hint of where the problems can appear? Cheers, Doru On 17 Feb 2010, at 19:14, Alexandre Bergel wrote: > Dear List, > > I incorporated some changes of XMLParser proposed by jaayer(a)zoho.com > These changes may break some existing applications. For example, I > had to adapt CAnalyzer. > ConfigurationOfXMLSupport has now #version102: > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Obvious things are difficult to teach."

Feb. 17, 2010

[Pharo-project] New version of XMLParser

by Alexandre Bergel

Dear List, I incorporated some changes of XMLParser proposed by jaayer(a)zoho.com These changes may break some existing applications. For example, I had to adapt CAnalyzer. ConfigurationOfXMLSupport has now #version102: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 17, 2010

Re: [Pharo-project] databases

by Dave Woodward

On 2/17/10 9:44 AM, Gabriel Brunstein wrote: > I didnÂ´t know the advantages and disadvantages of Gemstone over Magma, > I've found http://gemstonesoup.wordpress.com/2009/03/09/why-glass/ > with this comment: > > "Denis, the most obvious difference is that magma is used from a > smalltalk image (squeak, pharo,â¦) as a database add-on. Gemstone _is_ > the database and the image you run. > > In gemstone even the system classes are in the image that are > persistent. Some parts of gemstone oodb are built in a native > language. They are optimized in more traditional way for the speed of > objects acquiry. Magma is done in pure smalltalk and should therefor > be really flexible in what you can do with it. > > From the programming side they arenât that different. You build your > object graph in both and you need to attach this graph somewhere that > it doesnât get garbage collected. In Magma you have one database root > where you attach your stuff. In Gemstone you can attach things just > everywhere because everything is part of the persistent things. > > I donât know both that well. But Magma you can download and there you > go. It is just a piece of software you load and you have a OO > persistence layer. This is very good for deploying along with an > image. I never tested to use magma as a server. Lately magma came up > with some cool features like distributed databases, offline objects > and high availability. I like to do some stuff with it. > > On the other hand gemstone you must deploy in more server like > environment. It eats a certain amount of your memory. But you get a > server that performs really well, has proven scalability, cares more > about security and user based data separation. It is something fast > and solid for me. With the remote debugging features it is the ideal > database for my purposes so that were the reasons to choose it. > > I hope this helps you little bit in understanding. Magma and gemstone > are in principal the same: they are OODBS. But for me the usage > scenarios are completely different." > > > what do you think about it? maybe you can include something of that. I'm using Magma on a project where there is a central server running Seaside & Magma that is the "master" application. There are also a few users who have a one-click Seaside & Magma image running on their local machines that launches Mozilla Prism to the local Seaside using OSProcess. I'm using Magma to maintain a local read-only copy of the master that can catch itself up when online. I'm also using Gjaller-like transactions that are generated against the domain model, and later sent to the master server to be "applied" when the user comes online again. I considered using Gemstone, but the problem with Gemstone for this particular case is its "server-ness". It runs a few different processes that all do different things (the DB, the memory caches, VMs, etc.). So in my situation I couldn't have a nice "one-click" setup that could be deployed on client machines that could also handle being disconnected from the "master" database. > > > > 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com>> > > Really great informations : > > > Scenarioâs > > In different situations, there are different storage needs > > 1. You are writing a small demonstration program to show your > customers, and want to populate the system with some > representative data. Add a class instance variable to store > the instances, and simply save the image. > 2. You have a small system with a few hundred/thousand objects, > and are not dependent on external systems. A prevayler-like > system like SandstoneDB might be a perfect fit. Each object > save means a disk access, so scaling ends with disk speed. A > few old versions of the data are kept around, so backing up > or reverting is easy. If you want a readable representation, > SIXX might help. > 3. You have a legacy (relational) database, with extensive > reporting written for it. Use an ORM. > 4. You have a complex and large object model that has to > support changing the object model while developing. The > solution is an OODB. Gemstone is the large and proven > commercial offering. It has a free version for smaller > databases (4GB data, 1 core, 1G ram), and has proven > scalability to 500 machines. Magma is an open source OODB, > seeing active development and growing more and more advanced > functionality. > > > > Laurent Laffont > > > > On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont > <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: > > No :) Thanks for the link ! > > Laurent Laffont > > > > On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont > <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > > Hello Laurent, > > I assume you are aware of: > > http://www.seaside.st/documentation/persistence > > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 -- Dave Woodward ................................................... www.promedmedical.net 317.332.6438 davewoodward(a)promedmedical.net

Feb. 17, 2010

Re: [Pharo-project] databases

by GermÃ¡n Arduino

2010/2/17 Dave Woodward <davewoodward(a)promedmedical.net> > On 2/17/10 6:46 AM, GermÃ¡n Arduino wrote: > > > > 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com> > >> Hi, >> >> I would like to learn on Pharo + databases. I've seen there's several >> solutions in both object and relational databases. >> - Which (open source) object database should I start with (most used) ? >> > > > Magma is the option I select, but not tried yet on Pharo. > > > Magma 1.0v43 works on Pharo, > Good to know.

Feb. 17, 2010

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort

by Paolo Bonzini

> I understand and I agree with Pharo not to implement #sort and #sort: > in SequenceableCollection, because it does not make sense for most > subclasses. SortedCollection, Heap and Interval are already sorted; Interval and SortedCollection are only sorted according to one particular sort block, which may not be the default sort block (e.g. for decreasing intervals). For Interval the only sensible solution is #shouldNotImplement, but for SortedCollection it is plausible to make #sort or #sort: change the collection's sort block. > and for LinkedList sorting does not really make sense. Why not? Unlike arrays you can do linked list mergesort without auxiliary space (though the linked list already has O(n) overhead so that means without extra space compared to what the data structure already needs), and it is still guaranteed O(n log n). Of course I'm not really suggesting to implement LinkedList>>#sort. :-) > So I don't really know what to do to fix the Seaside test. We could > ask the Pharo guys to integrate OrderedCollection>>#sort and > OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too > late? Grease-Squeak should provide it. Paolo

Feb. 17, 2010

Re: [Pharo-project] databases

by Johan Brichau

On 17 Feb 2010, at 13:47, Dave Woodward wrote: > There is also GOODS, but I don't think that's being maintained (so you're on your own getting it to work). GOODS itself is still being maintained and the Squeak interface works just fine in Pharo too. We have it working in a project. ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Feb. 17, 2010

Re: [Pharo-project] databases

by Gabriel Brunstein

I didnÂ´t know the advantages and disadvantages of Gemstone over Magma, I've found http://gemstonesoup.wordpress.com/2009/03/09/why-glass/ with this comment: "Denis, the most obvious difference is that magma is used from a smalltalk image (squeak, pharo,â¦) as a database add-on. Gemstone _is_ the database and the image you run. In gemstone even the system classes are in the image that are persistent. Some parts of gemstone oodb are built in a native language. They are optimized in more traditional way for the speed of objects acquiry. Magma is done in pure smalltalk and should therefor be really flexible in what you can do with it. >From the programming side they arenât that different. You build your object graph in both and you need to attach this graph somewhere that it doesnât get garbage collected. In Magma you have one database root where you attach your stuff. In Gemstone you can attach things just everywhere because everything is part of the persistent things. I donât know both that well. But Magma you can download and there you go. It is just a piece of software you load and you have a OO persistence layer. This is very good for deploying along with an image. I never tested to use magma as a server. Lately magma came up with some cool features like distributed databases, offline objects and high availability. I like to do some stuff with it. On the other hand gemstone you must deploy in more server like environment. It eats a certain amount of your memory. But you get a server that performs really well, has proven scalability, cares more about security and user based data separation. It is something fast and solid for me. With the remote debugging features it is the ideal database for my purposes so that were the reasons to choose it. I hope this helps you little bit in understanding. Magma and gemstone are in principal the same: they are OODBS. But for me the usage scenarios are completely different." what do you think about it? maybe you can include something of that. 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com> > Really great informations : > Scenarioâs > > In different situations, there are different storage needs > > 1. You are writing a small demonstration program to show your > customers, and want to populate the system with some representative data. > Add a class instance variable to store the instances, and simply save the > image. > 2. You have a small system with a few hundred/thousand objects, and are > not dependent on external systems. A prevayler-like system like SandstoneDB > might be a perfect fit. Each object save means a disk access, so scaling > ends with disk speed. A few old versions of the data are kept around, so > backing up or reverting is easy. If you want a readable representation, SIXX > might help. > 3. You have a legacy (relational) database, with extensive reporting > written for it. Use an ORM. > 4. You have a complex and large object model that has to support > changing the object model while developing. The solution is an OODB. > Gemstone is the large and proven commercial offering. It has a free version > for smaller databases (4GB data, 1 core, 1G ram), and has proven scalability > to 500 machines. Magma is an open source OODB, seeing active development and > growing more and more advanced functionality. > > > > Laurent Laffont > > > > On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> No :) Thanks for the link ! >> >> Laurent Laffont >> >> >> >> On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: >> >>> Hello Laurent, >>> >>> I assume you are aware of: >>> >>> http://www.seaside.st/documentation/persistence >>> >>> Stephan >>> >>> _______________________________________________ >>> 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. 17, 2010

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort

by Marcus Denker

On Feb 17, 2010, at 3:17 PM, Lukas Renggli wrote: > That would be great and would avoid that we have to conditionally load > methods depending on what version of Pharo is used. As far as I see > this is really just OrderedCollection>>#sort and > OrderedCollection>>#sort: and they have no external dependencies. Ok, I will do an update tonight. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 17, 2010