August 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Postmark email library

by vmusulainen

I try loading from smalltalkhub.com with same results. Ant at smalltalkhub.com wrong link to external site (http://articles.tulipemoutarde.be/send-email-from-pharo-with-postmark) - wrong http://tulipemoutarde.be/2011/12/29/send-email-from-pharo-with-postmark.html - right -- View this message in context: http://forum.world.st/Postmark-email-library-tp4254680p4705887.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 31, 2013

Re: [Pharo-users] Postmark email library

by StÃ©phane Ducasse

I did not get a minute to look at it. Did you try on your side? Stef On Aug 30, 2013, at 1:51 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > > On Aug 30, 2013, at 9:45 AM, vmusulainen <vmusulainen(a)mail.ru> wrote: > >> Sure! >> >> I use pharo 2.0 (21.0) >> >> Attempt 1. >> >> Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Gofer" >> >> Gofer new >> repository: 'http://ss3.gemstone.com/ss/postmark'; >> package: 'ConfigurationOfPostMark'; >> package: 'PostMark-Core'; >> package: 'PostMark-Tests'; >> load > > this is the configurationOfPostmark that have the responsibility of loading the other packages and projects it needs. > I will try to have a look but on Smalltalkhub > > Stef > >> >> DoIt at workspace >> >> Result: Expection "ByteString doesNotUnderstand: #goferReferences" >> >> Attempt 2. >> >> Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Monticello >> Registration" >> Add repository => select package "PostMark-Core-FrancoisStephany.11", press >> "Load" >> >> Result: >> "This package depends on the following classes: >> JsonObject >> You must resolve these dependencies before you will be able to load these >> definitions: >> PMEmail >> addAttachment:content:contentType: >> addAttachmentAndCompress:archiveName: >> attachAndCompressFile: >> attachFile: >> >> Select Proceed to continue, or close this window to cancel the operation." >> >> Attempt 3. >> see http://ss3.gemstone.com/ss/postmark.html/Wiki >> >> Gofer it >> url: 'http://ss3.gemstone.com/ss/postmark'; >> package: 'ConfigurationOfPostMark'; >> load. >> (Smalltalk at: #ConfigurationOfPostMark) project stableVersion load. >> >> DoIt at workspace >> >> Result: "The symbolic version #stable is not defined in >> ConfigurationOfPostMark for the current platform." >> >> >> >> -- >> View this message in context: http://forum.world.st/Postmark-email-library-tp4254680p4705729.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >

Aug. 31, 2013

Re: [Pharo-users] Group and member with Voyage

by Esteban A. Maringolo

I think that the question could be rephrased as: How to map a collection with elements of different classes? Am I asking for too much? Esteban A. Maringolo 2013/8/30 Esteban A. Maringolo <emaringolo(a)gmail.com>: > More or less, I have this working. > > In the Group class I have a description named: > descriptionMembers > <mongoDescription> > ^VOMongoToManyDescription new > attributeName: 'members'; > accessor: #members; > kind: Member; > beLazy; > yourself > > > And in the Member class I have > descriptionGroups > <mongoDescription> > ^VOMongoToManyDescription new > attributeName: 'groups'; > accessor: #groups; > kind: Group; > beLazy; > yourself > > > > But what if Member is an abstract class and the elements can be any of > SingleMember or ComplexMember?, each one is stored in a separate > collection in Mongo. > > If I do specify #kind: Member in my #descriptionMembers it won't work. > > Any ideas? > > Regards, > > > Esteban A. Maringolo > > > 2013/8/30 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> 2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: >>> It seems that I mistook the question for something easy enough for me to answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't really give the proper answer. >> >> Thanks anyway, it is a problem you'll never find in GemStone/S ;-)

Aug. 31, 2013

Re: [Pharo-users] Group and member with Voyage

by Esteban A. Maringolo

More or less, I have this working. In the Group class I have a description named: descriptionMembers <mongoDescription> ^VOMongoToManyDescription new attributeName: 'members'; accessor: #members; kind: Member; beLazy; yourself And in the Member class I have descriptionGroups <mongoDescription> ^VOMongoToManyDescription new attributeName: 'groups'; accessor: #groups; kind: Group; beLazy; yourself But what if Member is an abstract class and the elements can be any of SingleMember or ComplexMember?, each one is stored in a separate collection in Mongo. If I do specify #kind: Member in my #descriptionMembers it won't work. Any ideas? Regards, Esteban A. Maringolo 2013/8/30 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: >> It seems that I mistook the question for something easy enough for me to answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't really give the proper answer. > > Thanks anyway, it is a problem you'll never find in GemStone/S ;-)

Aug. 30, 2013

Re: [Pharo-users] Group and member with Voyage

by Esteban A. Maringolo

2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: > It seems that I mistook the question for something easy enough for me to answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't really give the proper answer. Thanks anyway, it is a problem you'll never find in GemStone/S ;-)

Aug. 30, 2013

Re: [Pharo-users] [ANN] Aida 6.6 Web Framework Released

by StÃ©phane Ducasse

>> >> >> New version of Aida/Web framework and application server >> (http://www.aidaweb.si) is here with: >> >> - optimization on HTTP level to send first byte to the client as soon >> as possible >> - streaming of HTML, specially header to get first byte out >> immediately, >> - gzip compression of all text stuff like CSS, JS etc >> - CSS Sprites support added >> - internal vs. extarnal IP detection, to control access rights >> accordingly >> - Geolocation support improved >> - all JS and CSS libraries updated to latest versions, Twitter >> Bootstrap v3 added in parallel to v2.x > > Great work, thanks, Janko. + 1 Janko if you need scripts to migrate to SmalltalkHub let me know.

Aug. 30, 2013

Re: [Pharo-users] Group and member with Voyage

by James Foster

Hi Esteban, It seems that I mistook the question for something easy enough for me to answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't really give the proper answer. James On Aug 30, 2013, at 11:13 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi James, > > Thanks for your response. You are right, the Pattern is quite common, > if not ubiquous in all systems. > > My particular question is related with Voyage+MongoDB, and also could > apply to Magritte (given the fact Voyage "inherits" its descriptions > model). > > I sucessfully implemented this pattern with ORMs using an intermediary > table for the relation, or even reifying the relation as a first class > object. > I also used the #select: technique to avoid duplication of > "responsibility" and caching at one side of the relation. > But I always did it "in memory" with no mapping et all, just plain old > smalltalk objects (POSO?) and using ORM solutions. > > What I need to know now is: > 1) How to do this with voyage+MongoDB > 2) I want to have a two way relation, it is both members and groups > have a collection (members know their groups and viceversa). This > requires additional maintenance, but with a higher performance, and > doesn't require me to load all groups if I'm just materializing one > member. > > > Regards! > > Esteban A. Maringolo > > > 2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: >> Hi Esteban, >> >> What you have described is quite common and there are a variety of ways of designing this sort of object model. If you were dealing with a relational database, then you would have a Group table, a Member table, and a Membership table. The Membership table would have one row for each member/group pair and the member ID and group ID would be the primary columns (perhaps with other things like date joined, date expired, etc.). With an index on the member ID and group ID, one could quickly find all the groups for a member and all the members for a group, and each piece of data would exist in only one place ("normalized"). One could take a similar approach with objects, having three collections containing Groups, Members, and Memberships respectively. You could have an accessor in Group that returned members based on a select from the Memberships collection and an accessor in Member that returned groups based on a select from the Memberships collection. >> >> Alternatively, if you wanted to avoid the #'select:' call in one or both lookups, you can cache the respective subcollections in Group and/or Member and drop the Memberships collection. If you cache in only one place (e.g., each Group has a collection of Members), then you can add a method in Member that does a #'select:' of Groups where a Group has the Member. If you cache in both places then your getters/setters in each can update the other (with the understanding that you are duplicating data to get performance efficiency). >> >> Again, this problem is very common. Consider students in classes, persons with addresses, persons with hobbies, etc. Your choices are basically (1) three collections, no duplicates, select for both queries; (2) two collections, no duplicates, cache for one query, select for the other query; and (3) two collections, caches for each query. Which is preferable depends on your typical sizes and lookup patterns. If performance is not an issue, then start with whatever is simplest for you to code. I lean toward the three collections with the lookup penalty (GemStone's ability to index collections makes this approach very efficient), but if most of your lookups are from one side or the other and scanning the full collection is slow, then cache in one or both places. >> >> If you have a composite, the analysis is similar since Smalltalk does not require static typing of variables. You just need to take care that your accessors can give back the expected objects. >> >> James >> >> On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> Hi all, >>> >>> Let's say I have a class Group and a class Member. >>> >>> aGroup has many members. >>> and aMember can belong to many groups. >>> >>> What is the "proper" voyageDescription for those one to many relations? >>> >>> Should I do something extra? >>> >>> Everytime I add a member to the group, both the member and the group >>> get their references updated. >>> Now when I add a member to a group and save it, I also save the >>> member. Is there another way to avoid this? >>> >>> Any recommended practice for this? >>> >>> Next level question: What if it gets composite? it is... a Group has >>> other Groups as members :) >>> >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> >> >> > >

Aug. 30, 2013

Re: [Pharo-users] Group and member with Voyage

by Esteban A. Maringolo

Hi James, Thanks for your response. You are right, the Pattern is quite common, if not ubiquous in all systems. My particular question is related with Voyage+MongoDB, and also could apply to Magritte (given the fact Voyage "inherits" its descriptions model). I sucessfully implemented this pattern with ORMs using an intermediary table for the relation, or even reifying the relation as a first class object. I also used the #select: technique to avoid duplication of "responsibility" and caching at one side of the relation. But I always did it "in memory" with no mapping et all, just plain old smalltalk objects (POSO?) and using ORM solutions. What I need to know now is: 1) How to do this with voyage+MongoDB 2) I want to have a two way relation, it is both members and groups have a collection (members know their groups and viceversa). This requires additional maintenance, but with a higher performance, and doesn't require me to load all groups if I'm just materializing one member. Regards! Esteban A. Maringolo 2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: > Hi Esteban, > > What you have described is quite common and there are a variety of ways of designing this sort of object model. If you were dealing with a relational database, then you would have a Group table, a Member table, and a Membership table. The Membership table would have one row for each member/group pair and the member ID and group ID would be the primary columns (perhaps with other things like date joined, date expired, etc.). With an index on the member ID and group ID, one could quickly find all the groups for a member and all the members for a group, and each piece of data would exist in only one place ("normalized"). One could take a similar approach with objects, having three collections containing Groups, Members, and Memberships respectively. You could have an accessor in Group that returned members based on a select from the Memberships collection and an accessor in Member that returned groups based on a select from the Memberships collection. > > Alternatively, if you wanted to avoid the #'select:' call in one or both lookups, you can cache the respective subcollections in Group and/or Member and drop the Memberships collection. If you cache in only one place (e.g., each Group has a collection of Members), then you can add a method in Member that does a #'select:' of Groups where a Group has the Member. If you cache in both places then your getters/setters in each can update the other (with the understanding that you are duplicating data to get performance efficiency). > > Again, this problem is very common. Consider students in classes, persons with addresses, persons with hobbies, etc. Your choices are basically (1) three collections, no duplicates, select for both queries; (2) two collections, no duplicates, cache for one query, select for the other query; and (3) two collections, caches for each query. Which is preferable depends on your typical sizes and lookup patterns. If performance is not an issue, then start with whatever is simplest for you to code. I lean toward the three collections with the lookup penalty (GemStone's ability to index collections makes this approach very efficient), but if most of your lookups are from one side or the other and scanning the full collection is slow, then cache in one or both places. > > If you have a composite, the analysis is similar since Smalltalk does not require static typing of variables. You just need to take care that your accessors can give back the expected objects. > > James > > On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> Hi all, >> >> Let's say I have a class Group and a class Member. >> >> aGroup has many members. >> and aMember can belong to many groups. >> >> What is the "proper" voyageDescription for those one to many relations? >> >> Should I do something extra? >> >> Everytime I add a member to the group, both the member and the group >> get their references updated. >> Now when I add a member to a group and save it, I also save the >> member. Is there another way to avoid this? >> >> Any recommended practice for this? >> >> Next level question: What if it gets composite? it is... a Group has >> other Groups as members :) >> >> >> Regards! >> >> Esteban A. Maringolo >> >> > >

Aug. 30, 2013

Re: [Pharo-users] Group and member with Voyage

by James Foster

Hi Esteban, What you have described is quite common and there are a variety of ways of designing this sort of object model. If you were dealing with a relational database, then you would have a Group table, a Member table, and a Membership table. The Membership table would have one row for each member/group pair and the member ID and group ID would be the primary columns (perhaps with other things like date joined, date expired, etc.). With an index on the member ID and group ID, one could quickly find all the groups for a member and all the members for a group, and each piece of data would exist in only one place ("normalized"). One could take a similar approach with objects, having three collections containing Groups, Members, and Memberships respectively. You could have an accessor in Group that returned members based on a select from the Memberships collection and an accessor in Member that returned groups based on a select from the Memberships collection. Alternatively, if you wanted to avoid the #'select:' call in one or both lookups, you can cache the respective subcollections in Group and/or Member and drop the Memberships collection. If you cache in only one place (e.g., each Group has a collection of Members), then you can add a method in Member that does a #'select:' of Groups where a Group has the Member. If you cache in both places then your getters/setters in each can update the other (with the understanding that you are duplicating data to get performance efficiency). Again, this problem is very common. Consider students in classes, persons with addresses, persons with hobbies, etc. Your choices are basically (1) three collections, no duplicates, select for both queries; (2) two collections, no duplicates, cache for one query, select for the other query; and (3) two collections, caches for each query. Which is preferable depends on your typical sizes and lookup patterns. If performance is not an issue, then start with whatever is simplest for you to code. I lean toward the three collections with the lookup penalty (GemStone's ability to index collections makes this approach very efficient), but if most of your lookups are from one side or the other and scanning the full collection is slow, then cache in one or both places. If you have a composite, the analysis is similar since Smalltalk does not require static typing of variables. You just need to take care that your accessors can give back the expected objects. James On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi all, > > Let's say I have a class Group and a class Member. > > aGroup has many members. > and aMember can belong to many groups. > > What is the "proper" voyageDescription for those one to many relations? > > Should I do something extra? > > Everytime I add a member to the group, both the member and the group > get their references updated. > Now when I add a member to a group and save it, I also save the > member. Is there another way to avoid this? > > Any recommended practice for this? > > Next level question: What if it gets composite? it is... a Group has > other Groups as members :) > > > Regards! > > Esteban A. Maringolo > >

Aug. 30, 2013

Re: [Pharo-users] Benchmark

by Esteban Lorenzano

yes, it was just a proof of concept, waiting for their own dedicated machine(s) On Aug 30, 2013, at 7:03 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > However benchmark on the CI are not on a dedicated machine so it is not very reliable .... > > > 2013/8/30 Camillo Bruni <camillobruni(a)gmail.com> > That you just need to run it from the command line which is not related to the benchmark project. > Currently it seems like the ci has some troubles, so I cannot get to the configuration either. > > > On 2013-08-30, at 17:25, Natalia Moskovchuk <natalia.moskovchuk(a)unikernel.net> wrote: > > > Thanks. I already saw this video. I cann't see configuration on > > https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it? > >

Aug. 30, 2013