April 2010 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Experiences with non RDBs?

by Norbert Hartl

Hi, I think I don't need to refer to your concrete example. Basically an object is a named key-value store. So a class A with instance variable a,b,c is just something like A a -> valueOfA b -> valueOfB c -> valueOfC A subclass of A would either have the same amount of variables or more. So subclass B of A could look like B a -> valueOfA b -> valueOfB c -> valueOfC d -> valueOfD If you have a serialized form of a B you need to know that it is a B in order to read all of the 4 values back into the right object type. - in OODBs this case is easy. The serialization contains everything from the key-values and the class that they belong to. Sometimes the data format on disk is the same as in memory so there is less to do. The difference between magma and gemstone is that magma is an addition to an image. That means you have your smalltalk image in memory and than you have magma. With magma you define a persisted root object, e.g. a Dictionary. Everything you attach to the Dictionary will be persisted if you do a commit. Well, you need to do your changes inside a transaction but there are always ways to make this look nearly transparent. In gemstone everything is already persisted including all the classes and objects. As soon as you attach a newly created object somewhere that is already persistent it will be persisted, too. The easiest way of handling your data is to keep an instance variable in your class that holds the instances. Et voila, that's all! All you objects are persisted. Speaking of seaside gemstone can be used doing autocommits on a request basis so you don't have to care at all about transactions. You just use your objects and that is it. Querying is like using collections. If you need special kind of querying either for your problem or performance you can provide a special type of collection that is optimized for the problem - In XMLDBs / document databases (CouchDB) you just have a representation of that key-value store. Be it an xml element or a Javascript object in JSON format they are both key-value stores. You then need to serialize/deserialize those formats. Reading a subclass is just a matter of providing the right class name when reading the serialized format. References can be handled multiple ways, but default ones will be id/idref in XML and link/Uri in restful ways. Querying in XMLDB is using xpath, in CouchDB and document databases I don't know if there is a general query support - In SQL databases the instance variables are mapped to columns of a table or multiple tables and each row is an object. Relationships of objects are handled by keys in the tables. A 1:1 relationships contains a key of the relation source in the relation target table. A n:m relationship needs an intermediate table that maps relation source keys to relation target keys. Talking about inheritance this gets easily complicated. Basically there are two options. You can solve it like everyone would expect it, let's say more BNF like. You would have a table A for class A and a table B for class B. Now in all tables of objects that reference A or B you need an additional information which class is meant: A or B. The tables than could be joint correctly after evaluation the additional value. Another strategy is to do multiple lookups until you've found the right value. The other approach is to make one table that is a super set of all needed variables. The keys are unique among all the subclasses and can be lookuped up more easily. But you waste some space because a lot of the columns would be empty. In any case you need to change your database schema if you change your model. Joins and number of requests can grow easily so that your application will be slowed down. Glorp gives you all of these strategies if you want them. My personal advize would be to avoid inheritance in that scenario completely or do only the simplest cases possible. Relational databases and object oriented approaches just don't fit together. You need to decide if your problem is more of the one or the other type. Then take one of those two approaches. Querying is based on column types and joins. Glorp is providing a query protocol that is similar to collections. You just need to use some things differently due to the nature of the layer below is different. Hope this helps, Norbert On 08.04.2010, at 09:02, Friedrich Dominicus wrote: > Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > >> I just wonder about experiences with non relational databases like e.g >> - Magma >> - Gemstone >> - others > Ok to get a bit more concrete assume I have a simple inheritance as > in the example > > Object subclass: #ClosedFigure > instanceVariableNames: 'sideA sideB sideC alpha beta gamma' > classVariableNames: '' > poolDictionaries: '' > category: 'Pharo-Mailing-List-Example'! > > !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:21'! > area > ^0 ! ! > > !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:07'! > circumreference > ^ 0! ! > > > > Object subclass: #ModelLine > instanceVariableNames: 'length beginPoint endPoint' > classVariableNames: '' > poolDictionaries: '' > category: 'Pharo-Mailing-List-Example'! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > beginPoint > ^ beginPoint! ! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > beginPoint: anObject > beginPoint := anObject! ! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > endPoint > ^ endPoint! ! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > endPoint: anObject > endPoint := anObject! ! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > length > ^ length! ! > > !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! > length: anObject > length := anObject! ! > > > !ModelLine methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:19'! > initialize > super initialize. > length := 0.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > ModelLine class > instanceVariableNames: ''! > > !ModelLine class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:33'! > new: initialLength > ^ self new length: initialLength > ! ! > > > ClosedFigure subclass: #ModelRectangle > instanceVariableNames: 'lengthSideA lengthSideB' > classVariableNames: '' > poolDictionaries: '' > category: 'Pharo-Mailing-List-Example'! > > !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! > lengthSideA > ^ lengthSideA! ! > > !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! > lengthSideA: anObject > lengthSideA := anObject! ! > > !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! > lengthSideB > ^ lengthSideB! ! > > !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! > lengthSideB: anObject > lengthSideB := anObject! ! > > > !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:35'! > area > ^ lengthSideA * lengthSideB ! ! > > !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:32'! > lengthSideA: lenA lengthSideB: lenB > super initialize. > lengthSideA := lenA. > lengthSideB := lenB.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > ModelRectangle class > instanceVariableNames: ''! > > !ModelRectangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:39'! > lengthSideA: lenA lengthSideB: lenB > ^ self new lengthSideA: lenA lengthSideB: lenB.! ! > > > ClosedFigure subclass: #ModelTriangle > instanceVariableNames: 'height length' > classVariableNames: '' > poolDictionaries: '' > category: 'Pharo-Mailing-List-Example'! > > !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:51'! > area > ^ 1/2 * length * height ! ! > > !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! > height > ^ height! ! > > !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! > height: anObject > height := anObject! ! > > !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! > length > ^ length! ! > > !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! > length: anObject > length := anObject! ! > > > !ModelTriangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:47'! > length: aLength height: aHeight > super initialize. > length := aLength. > height:= aHeight. ! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > ModelTriangle class > instanceVariableNames: ''! > > !ModelTriangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:49'! > length: aLength height: aHeight > ^ self new length: aLength height: aHeight.! ! > > > > Now this is as simple as can be. I have a Parent and two derived > classes. How would I make this stuff persistent, and how would it look > in different persistence solutions. > > Let us assume. I would store the outline e.g in an OrderedCollection of > Lines or whatever. What about other "ClosedFigures" like e.g circles, > ellipses etc. How do I model inheritance in the diverse OR mappers. How > does that work in let's say > - Magma > - Glorp > - GemStone > - whatever you choose > > How would I query the database on let's side length of some lines of > the Closed Figure, or let's say I like to query a few closed figures on > their circumreference or area. > > Or asked anotherway. How is inheritance handled in the diverse > persistence tools.. > > Another question is how easy or difficult is it to have let's say > something like a person with addresses, phone numbers etc. > > How would I have to query let's say the street address of a certain > Person. e.g > > Regards > Friedrich > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 8, 2010

Re: [Pharo-users] removing packages

by Marcus Denker

On Apr 8, 2010, at 2:35 AM, Yoandy RodrÃguez MartÃnez wrote: > Hi everybody: > > Is there a way to remove packages other than Monticello repository browser?? > You can do it via code: remove package + code: (MCPackage named: 'ObjectMetaTools') unload. Just remove the MC package, keep the classes: (MCPackage named: 'System') workingCopy unregister. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 8, 2010

Re: [Pharo-users] Experiences with non RDBs?

by Igor Stasenko

On 8 April 2010 10:02, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > >> I just Â wonder about experiences with non relational databases like e.g >> - Magma >> - Gemstone >> - others > Ok to Â get a bit more concrete assume I have a simple inheritance as > in the Â example > [snip] > Or asked anotherway. How is inheritance handled in the diverse > persistence tools.. > > Another question is how easy or difficult is it to have let's say > something like a person with addresses, phone numbers etc. > > How would I have to query let's say the street address of a certain > Person. e.g > I can't say for OR mappers, but for OODBs like Gemstone or Magma, everything is handled seamlessly. You need to care only about your data model, and can do anything, what naturally you want to do with your data. OODB handling all of it behind the scenes. All what is you have to do is to designate the transaction boundaries, where you dealing with data, so you can abort /commit it at some logical point. The rest of stuff can be used without caring about persistence - you working with objects as if they are just objects , as if you having your data in image. As simple as that. Of course, there are indexes and other helpful stuff, which could help you work more efficiently with larger data sets, but it is optional. So, while in RDBMS your are a servant of database (because you have to follow all requirements for every query/data model you put there), with OODB - it is a database your servant and doing everything for you, without much interference and without dictating you how your data structures should be organized. So, i think this answering your question about inheritance: if you need inheritance, just use it. :) > Regards > Friedrich > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

April 8, 2010

Re: [Pharo-users] Experiences with non RDBs?

by Friedrich Dominicus

Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > I just wonder about experiences with non relational databases like e.g > - Magma > - Gemstone > - others Ok to get a bit more concrete assume I have a simple inheritance as in the example Object subclass: #ClosedFigure instanceVariableNames: 'sideA sideB sideC alpha beta gamma' classVariableNames: '' poolDictionaries: '' category: 'Pharo-Mailing-List-Example'! !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:21'! area ^0 ! ! !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:07'! circumreference ^ 0! ! Object subclass: #ModelLine instanceVariableNames: 'length beginPoint endPoint' classVariableNames: '' poolDictionaries: '' category: 'Pharo-Mailing-List-Example'! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! beginPoint ^ beginPoint! ! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! beginPoint: anObject beginPoint := anObject! ! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! endPoint ^ endPoint! ! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! endPoint: anObject endPoint := anObject! ! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! length ^ length! ! !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'! length: anObject length := anObject! ! !ModelLine methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:19'! initialize super initialize. length := 0.! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! ModelLine class instanceVariableNames: ''! !ModelLine class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:33'! new: initialLength ^ self new length: initialLength ! ! ClosedFigure subclass: #ModelRectangle instanceVariableNames: 'lengthSideA lengthSideB' classVariableNames: '' poolDictionaries: '' category: 'Pharo-Mailing-List-Example'! !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! lengthSideA ^ lengthSideA! ! !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! lengthSideA: anObject lengthSideA := anObject! ! !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! lengthSideB ^ lengthSideB! ! !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'! lengthSideB: anObject lengthSideB := anObject! ! !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:35'! area ^ lengthSideA * lengthSideB ! ! !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:32'! lengthSideA: lenA lengthSideB: lenB super initialize. lengthSideA := lenA. lengthSideB := lenB.! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! ModelRectangle class instanceVariableNames: ''! !ModelRectangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:39'! lengthSideA: lenA lengthSideB: lenB ^ self new lengthSideA: lenA lengthSideB: lenB.! ! ClosedFigure subclass: #ModelTriangle instanceVariableNames: 'height length' classVariableNames: '' poolDictionaries: '' category: 'Pharo-Mailing-List-Example'! !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:51'! area ^ 1/2 * length * height ! ! !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! height ^ height! ! !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! height: anObject height := anObject! ! !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! length ^ length! ! !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'! length: anObject length := anObject! ! !ModelTriangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:47'! length: aLength height: aHeight super initialize. length := aLength. height:= aHeight. ! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! ModelTriangle class instanceVariableNames: ''! !ModelTriangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:49'! length: aLength height: aHeight ^ self new length: aLength height: aHeight.! ! Now this is as simple as can be. I have a Parent and two derived classes. How would I make this stuff persistent, and how would it look in different persistence solutions. Let us assume. I would store the outline e.g in an OrderedCollection of Lines or whatever. What about other "ClosedFigures" like e.g circles, ellipses etc. How do I model inheritance in the diverse OR mappers. How does that work in let's say - Magma - Glorp - GemStone - whatever you choose How would I query the database on let's side length of some lines of the Closed Figure, or let's say I like to query a few closed figures on their circumreference or area. Or asked anotherway. How is inheritance handled in the diverse persistence tools.. Another question is how easy or difficult is it to have let's say something like a person with addresses, phone numbers etc. How would I have to query let's say the street address of a certain Person. e.g Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

April 8, 2010

removing packages

by Yoandy RodrÃguez MartÃnez

Hi everybody: Is there a way to remove packages other than Monticello repository browser??

April 8, 2010

Re: [Pharo-users] Experiences with non RDBs?

by Mariano Martinez Peck

Hi Friederich: few weeks ago we have a interesting discussion. As a good programmer, we should reuse :) http://n4.nabble.com/databases-td1558285.html#a1559265 http://n4.nabble.com/databases-td1558558.html#a1559709 On Wed, Apr 7, 2010 at 8:41 AM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > I just wonder about experiences with non relational databases like e.g > The only project I used was Glorp...but I will answer you the little I know. > - Magma > Is a OODB that seems to work pretty good. Now it is very easy to install in Pharo using the Metacello ConfigurationOfMagma. Notice that Magma work only in Pharo / Squeak as I am aware of. Some people say the performance is good and other not very good. > - Gemstone > GLASS seems to be an excellent choice for several projects. You can just download the VMWare and run it. I think it fits well for midium/big projects. It is good that you can scale A LOT. OF course, if you scale a lot, you will probably have to pay. Look at the GLASS conditions. Another important thing is that Gemstone is the Smalltalk in itself. It is not like magma. IT IS AN SMALLTALK, but that supports ACID ;) So...you may have some little problems while migrating from Pharo to Gemstone as some messages may behave diffrently. Or maybe even don't have some classes in one smalltalk but yes in the other one. Gemstone is headless. So, you cannot develop in Gemstone. You need a GemClient. So...and excellent choice is to develop with Pharo and deploy to Gemstone... > - others > > and/or limits of the diverse ORM mappers. > - Glorp > Glorp is developed in VW. The port to squeak/pharo is old. I only supports posgresql backend. To fix that, we developed GlorpDBX. For more information, read: http://www.squeakdbx.org/GLORP integration We have it working with PostgreSQL, MySQL and Oracle. Cheers Mariano - Magritte > - others > > Regards > Friedrich > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

April 7, 2010

Re: [Pharo-users] Experiences with non RDBs?

by Norbert Hartl

And I'm using gemstone :) All of the persistence solutions have specialities that make them useful. Be it - GOODS that is supposed to be language neutral. You can share your objects between smalltalk and java e.g. - Magma is smalltalk only but full-featured OODB that is easy to set up and it is quite powerful. For server deployment I can't say. It is that Chris always states that you can achieve decent performance but other people always complain about its performance - CouchDB/document databases. Is also kind of language neutral. When "just persist and query" is your main concern (which is it most of the time) than CouchDB might be a good choice. With this you can access your objects from either the server or from the client using javascript. Should be fairly ease to do - gemstone if you consider persistence as just a necessity because your memory is not persisted by default and it is too small to keep everything. Or in other words if you just want to care about _your_ problems and not the problem of the persistence ;) - SQL to integrate legacy application or to feature a business problem that is relational in its nature which OO problems are not per se - XMLDB if your problem domain is not only about document but about XML documents and X**** search capabilties. And there a lot more that are combinations of any of the above etc. Norbert On 07.04.2010, at 12:36, StÃ©phane Ducasse wrote: > I know > > Inceptive.be is using GOODS. > Hilaire used magma > Netstyle.ch postgres > > Now this is easter holidays here so people are busy eating chocolate. > > Stef > > On Apr 7, 2010, at 8:41 AM, Friedrich Dominicus wrote: > >> I just wonder about experiences with non relational databases like e.g >> - Magma >> - Gemstone >> - others >> >> and/or limits of the diverse ORM mappers. >> - Glorp >> - Magritte >> - others >> >> Regards >> Friedrich >> >> >> -- >> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim >> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 7, 2010

Re: [Pharo-users] Experiences with non RDBs?

by StÃ©phane Ducasse

I know Inceptive.be is using GOODS. Hilaire used magma Netstyle.ch postgres Now this is easter holidays here so people are busy eating chocolate. Stef On Apr 7, 2010, at 8:41 AM, Friedrich Dominicus wrote: > I just wonder about experiences with non relational databases like e.g > - Magma > - Gemstone > - others > > and/or limits of the diverse ORM mappers. > - Glorp > - Magritte > - others > > Regards > Friedrich > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 7, 2010

Re: [Pharo-users] Fwd: A problem about SCouchDB library

by Igor Stasenko

On 7 April 2010 11:36, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Ahh, ok I got confused. Which one is your implementation? > it lies in sqs/SCouchDB repo. > Cheers, > Doru > > > On 7 Apr 2010, at 03:11, Igor Stasenko wrote: > >> On 7 April 2010 02:09, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I noticed that http://www.squeaksource.com/JSON.html has no license >>> specified. Is that on purpose or is it actually open source? >>> >> Huh? Strange.. i don't remember clearly, but i think i checked the >> license before >> making own fork of JSON. >> I had to fork, because i don't own that repository, and implementation >> was not very convincing to me :) >> >>> Cheers, >>> Doru >>> >>> >>> On 7 Apr 2010, at 01:04, Igor Stasenko wrote: >>> >>>> I just uploaded newer version of both >>>> json and scouchdb-core. >>>> >>>> Please, let me know, if problem still persists. >>>> >>>> On 7 April 2010 00:46, zekUs <zekzekus(a)gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am using latest pharo image. I installed scouchdb and other libraries >>>>> from >>>>> squeaksource. >>>>> >>>>> As isaid before the inspected stream content looks ok. >>>>> >>>>> I will try with a fresh image. May be it works. >>>>> >>>>> Thanks for replies. >>>>> >>>>> On Apr 7, 2010 12:33 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: >>>>> >>>>> ..resend :) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Igor Stasenko <siguctua(a)gmail.com> >>>>> Date: 7 April 201... >>>>> >>>>> Oh, i wasn't subscribed to pharo-users (but already do). >>>>> Thanks for forwarding the mail to me. >>>>> I replied to zekzekus privately. >>>>> >>>>> In short: i can't reproduce the problem in my image. >>>>> Maybe its because i running it in squeak-based image, not pharo.. >>>>> But i tend to use/write the code which can't be affected by fork >>>>> differences. >>>>> So, zekzekus , please let me know, what image you using and i will try >>>>> in >>>>> it. >>>>> >>>>> On 6 April 2010 18:41, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> I don't know if Igor ... >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-users mailing list >>>>> Pharo-users(a)lists.gforge.i... >>>>> >>>>> _______________________________________________ >>>>> Pharo-users mailing list >>>>> Pharo-users(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They > both matter." > > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

April 7, 2010

Re: [Pharo-users] Fwd: A problem about SCouchDB library

by Tudor Girba

Ahh, ok I got confused. Which one is your implementation? Cheers, Doru On 7 Apr 2010, at 03:11, Igor Stasenko wrote: > On 7 April 2010 02:09, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I noticed that http://www.squeaksource.com/JSON.html has no license >> specified. Is that on purpose or is it actually open source? >> > Huh? Strange.. i don't remember clearly, but i think i checked the > license before > making own fork of JSON. > I had to fork, because i don't own that repository, and implementation > was not very convincing to me :) > >> Cheers, >> Doru >> >> >> On 7 Apr 2010, at 01:04, Igor Stasenko wrote: >> >>> I just uploaded newer version of both >>> json and scouchdb-core. >>> >>> Please, let me know, if problem still persists. >>> >>> On 7 April 2010 00:46, zekUs <zekzekus(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I am using latest pharo image. I installed scouchdb and other >>>> libraries >>>> from >>>> squeaksource. >>>> >>>> As isaid before the inspected stream content looks ok. >>>> >>>> I will try with a fresh image. May be it works. >>>> >>>> Thanks for replies. >>>> >>>> On Apr 7, 2010 12:33 AM, "Igor Stasenko" <siguctua(a)gmail.com> >>>> wrote: >>>> >>>> ..resend :) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Igor Stasenko <siguctua(a)gmail.com> >>>> Date: 7 April 201... >>>> >>>> Oh, i wasn't subscribed to pharo-users (but already do). >>>> Thanks for forwarding the mail to me. >>>> I replied to zekzekus privately. >>>> >>>> In short: i can't reproduce the problem in my image. >>>> Maybe its because i running it in squeak-based image, not pharo.. >>>> But i tend to use/write the code which can't be affected by fork >>>> differences. >>>> So, zekzekus , please let me know, what image you using and i >>>> will try in >>>> it. >>>> >>>> On 6 April 2010 18:41, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com> >>>> wrote: >>>>> >>>>> I don't know if Igor ... >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.i... >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 7, 2010