September 2013 - Pharo-users

Re: [Pharo-users] Smalltalk positions in research in France

by Sebastian Tleye

Hi Damien, thank you :) I talked to him today, he is also part of the team in Douai. I have to wait now for an answer El 10/09/2013, a las 14:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > Hi guys > > you can be interested by the following position. > > stef > >> From: LoÃ¯c LAGADEC <loic.lagadec(a)ensta-bretagne.fr> >> Subject: Profils de postes >> Date: September 9, 2013 5:28:59 PM GMT+02:00 >> To: stephane.ducasse(a)gmail.com, stephane.ducasse(a)inria.fr, loic.lagadec(a)ensta-brest.Fr >> >> Several smalltalk-centric positions open in Brest (http://www.brest-metropole-tourisme.fr/en/) We also welcome students internship on demand. >> >> The Phd, engineer and postdoc will be located in the ENSTA Bretagne engineering school (www.ensta-bretagne.eu) and be part of the UMR 6285 Lab-STICC lab. >> >> >> Contact : Loic.lagadec(a)ensta-bretagne.Fr >> >> >> - Engineer (1 year) : Start ASAP >> >> In the scope of the ANR (INS 2011) ARDYT project, we are hiring an engineer for 12 months. The objective of this work is to contribute to the refactoring and improve the (VW written) Biniou Framework (modelling Embedded reconfigurable devices to produce software development environments). Biniou is currently being extended with new features and requires to define a versioning and testing policy. >> >> - Phd : Start January 2014 >> >> >> In the scope of the FP7 ERATO project, the PhD student will contribute to set up a Professional environment to exploit a new European FPGA (reconfigurable device) dedicated to space application. >> >> One important contribution will be to expose a manipulation API to application Designers while protecting the hardware intellectual property. Also some compression schemes used for video coding will be stressed against practical experimentation when downsizing the bitstream (binary representation of the application). >> >> >> - postdoc (2 years) : Start january-june 2014 >> >> In the scope of the FP7 ERATO project, the candidate will contribute to define and develop a Pharo environment to model a new FPGA and to meter performances in a faulty environment (satellite). This postdoc is a perfect opportunity for a Smalltalk expert to transpose its skills to an applicative domain. Depending on the qualification of the candidate, she/he will be co advisor of the PhD student. >> >

Sept. 10, 2013

Re: [Pharo-users] Benchmark

by StÃ©phane Ducasse

Hello Natalia I started to write a chapter on Smark for a future Pharo book. So may be we could write it together :) I can give you access to it if you are interested Stef On Sep 10, 2013, at 1:15 AM, Natalia Moskovchuk <natalia.moskovchuk(a)unikernel.net> wrote: > Thank all of you for help. I have successfuly added benchmarks to my project. > And additionaly I wrote simple step by step tutorial about how to write > benchmarks in Pharo for people like me)). > Best regards, > Natalia > > > > -- > View this message in context: http://forum.world.st/Benchmark-tp4705781p4707388.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 10, 2013

Re: [Pharo-users] a fix for ConfigurationOfBitmapCharacterSet on smalltalkhub

by StÃ©phane Ducasse

thanks I will fix it. Stef On Sep 10, 2013, at 12:37 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi - > > The current version has an error in the #version100: method. > > There are spaces that precede the version info for the > Collections-BitmapCharacterSet package. A fixed version is: > > > > version100: spec > <version: '1.0' imports: #('1.0-baseline')> > spec > for: #common > do: [ > spec blessing: #release. > spec description: 'Latest versions from Squeaksource'. > spec package: 'Collections-BitmapCharacterSet' with: > 'Collections-BitmapCharacterSet-JAA.5'. > spec package: 'Collections-Tests-BitmapCharacterSet' with: > 'Collections-Tests-BitmapCharacterSet-JAA.5' ] > > > Thanks > > Paul >

Sept. 10, 2013

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

by Esteban Lorenzano

no, it should not be implemented, no need to make him answer false (in fact, I never tried, but I'm pretty sure that is you reimplement isVoyageRoot to answer false in the subclasses most probably you will get a class that is transient :( ). reason is that voyage looks the root class of a hierarchy by noticing where is #isVoyageRoot = true implemented. (again, each time I look in this "design decisions" I feel a bit ashamed... but well, they looked good at the moment :) ) Esteban On Sep 10, 2013, at 5:06 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Esteban, > > I didn't know about the #isVoyageRoot difference based on where was the method defined. > > I mean... if I define > Member class>>#isVoyageRoot > ^true > > why sould SingleMember answer false? > > Do I have to redefine it to answer false in each of Member subclasses? > > Regards! > > > > > > Esteban A. Maringolo > > > 2013/9/10 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > what happens is that if you declare a "kind", you forces all elements to be of that specific class. > Solution is just not add that property: > > <mongoDescription> > ^VOMongoToManyDescription new > attributeName: 'members'; > accessor: #members; > "kind: Member; " "<-- NO!" > beLazy; > yourself. > > And same happens in the <mongoContainer> description in the top of your hierarchy... you must NOT declare a kind. > Also, if you want all members to go in just one collection. #isVoyageRoot has to be implemented in the top of the hierarchy and not in the subclasses > > Member "<-- #isVoyageRoot = true here!" > SingleMember > ComplexMember > > what happens then is that voyage will create a collection and for each document it stores in it will also store the attribute '#instanceOf', which will be used to retrieve the correct object. > > Esteban > > > what happens then is that > > On Aug 31, 2013, at 12:53 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > 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 ;-) > > > > >

Sept. 10, 2013

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

by Esteban A. Maringolo

Esteban, I didn't know about the #isVoyageRoot difference based on where was the method defined. I mean... if I define Member class>>#isVoyageRoot ^true why sould SingleMember answer false? Do I have to redefine it to answer false in each of Member subclasses? Regards! Esteban A. Maringolo 2013/9/10 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > what happens is that if you declare a "kind", you forces all elements to > be of that specific class. > Solution is just not add that property: > > <mongoDescription> > ^VOMongoToManyDescription new > attributeName: 'members'; > accessor: #members; > "kind: Member; " > "<-- NO!" > beLazy; > yourself. > > And same happens in the <mongoContainer> description in the top of your > hierarchy... you must NOT declare a kind. > Also, if you want all members to go in just one collection. #isVoyageRoot > has to be implemented in the top of the hierarchy and not in the subclasses > > Member > "<-- #isVoyageRoot = true here!" > SingleMember > ComplexMember > > what happens then is that voyage will create a collection and for each > document it stores in it will also store the attribute '#instanceOf', which > will be used to retrieve the correct object. > > Esteban > > > what happens then is that > > On Aug 31, 2013, at 12:53 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 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 ;-) > > > > >

Sept. 10, 2013

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

by Esteban Lorenzano

I just answered that :) On Sep 10, 2013, at 5:00 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > Esteban, > > That's totally fine for me. I've been doing explicit saves in ORMs since more than a decade. I can live with that. > > My question was to have more than one class of element in the same collection mapping. > > Regards! > > > Esteban A. Maringolo > > > 2013/9/10 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > I just found some time to see this... there is a problem with saving/updating circular references that I "solved" by not solve it at all :( > here is the thing: > > when you create a new group and add a new user, the #save message will find the new objects (in this case group and user) and save both. > Now, when you are updating, I do not have any way (so far), to know which part of the graph is actually updated and needs to be saved (and we all will agree that persisting each time all structure will not be efficient). > So I just do not do it, I'm sorry :( > That mean that if the referenced object is not new, it is not stored... just the "first level" object is... > > I know is not a good solution, but what I do is to save each element of the graph separated: > > user := User new save. > group := Group new > add: user; > save. > > so, taking each updated element as a unity will do the job. > > I know, I know... this is not optimal (and in fact is pretty bad), but well... is what I could do at the moment and never had the time to enhance it. > > Esteban > > > On Aug 30, 2013, at 3:12 AM, 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 > > > > >

Sept. 10, 2013

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

by Esteban A. Maringolo

Esteban, That's totally fine for me. I've been doing explicit saves in ORMs since more than a decade. I can live with that. My question was to have more than one class of element in the same collection mapping. Regards! Esteban A. Maringolo 2013/9/10 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > I just found some time to see this... there is a problem with > saving/updating circular references that I "solved" by not solve it at all > :( > here is the thing: > > when you create a new group and add a new user, the #save message will > find the new objects (in this case group and user) and save both. > Now, when you are updating, I do not have any way (so far), to know which > part of the graph is actually updated and needs to be saved (and we all > will agree that persisting each time all structure will not be efficient). > So I just do not do it, I'm sorry :( > That mean that if the referenced object is not new, it is not stored... > just the "first level" object is... > > I know is not a good solution, but what I do is to save each element of > the graph separated: > > user := User new save. > group := Group new > add: user; > save. > > so, taking each updated element as a unity will do the job. > > I know, I know... this is not optimal (and in fact is pretty bad), but > well... is what I could do at the moment and never had the time to enhance > it. > > Esteban > > > On Aug 30, 2013, at 3:12 AM, 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 > > > > >

Sept. 10, 2013

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

by Esteban Lorenzano

Hi, what happens is that if you declare a "kind", you forces all elements to be of that specific class. Solution is just not add that property: <mongoDescription> ^VOMongoToManyDescription new attributeName: 'members'; accessor: #members; "kind: Member; " "<-- NO!" beLazy; yourself. And same happens in the <mongoContainer> description in the top of your hierarchy... you must NOT declare a kind. Also, if you want all members to go in just one collection. #isVoyageRoot has to be implemented in the top of the hierarchy and not in the subclasses Member "<-- #isVoyageRoot = true here!" SingleMember ComplexMember what happens then is that voyage will create a collection and for each document it stores in it will also store the attribute '#instanceOf', which will be used to retrieve the correct object. Esteban what happens then is that On Aug 31, 2013, at 12:53 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 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 ;-) >

Sept. 10, 2013

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

by Esteban Lorenzano

Hi, I just found some time to see this... there is a problem with saving/updating circular references that I "solved" by not solve it at all :( here is the thing: when you create a new group and add a new user, the #save message will find the new objects (in this case group and user) and save both. Now, when you are updating, I do not have any way (so far), to know which part of the graph is actually updated and needs to be saved (and we all will agree that persisting each time all structure will not be efficient). So I just do not do it, I'm sorry :( That mean that if the referenced object is not new, it is not stored... just the "first level" object is... I know is not a good solution, but what I do is to save each element of the graph separated: user := User new save. group := Group new add: user; save. so, taking each updated element as a unity will do the job. I know, I know... this is not optimal (and in fact is pretty bad), but well... is what I could do at the moment and never had the time to enhance it. Esteban On Aug 30, 2013, at 3:12 AM, 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 >

Sept. 10, 2013

Smalltalk positions in research in France

by StÃ©phane Ducasse

Hi guys you can be interested by the following position. stef > From: LoÃ¯c LAGADEC <loic.lagadec(a)ensta-bretagne.fr> > Subject: Profils de postes > Date: September 9, 2013 5:28:59 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com, stephane.ducasse(a)inria.fr, loic.lagadec(a)ensta-brest.Fr > > Several smalltalk-centric positions open in Brest (http://www.brest-metropole-tourisme.fr/en/) We also welcome students internship on demand. > > The Phd, engineer and postdoc will be located in the ENSTA Bretagne engineering school (www.ensta-bretagne.eu) and be part of the UMR 6285 Lab-STICC lab. > > > Contact : Loic.lagadec(a)ensta-bretagne.Fr > > > - Engineer (1 year) : Start ASAP > > In the scope of the ANR (INS 2011) ARDYT project, we are hiring an engineer for 12 months. The objective of this work is to contribute to the refactoring and improve the (VW written) Biniou Framework (modelling Embedded reconfigurable devices to produce software development environments). Biniou is currently being extended with new features and requires to define a versioning and testing policy. > > - Phd : Start January 2014 > > > In the scope of the FP7 ERATO project, the PhD student will contribute to set up a Professional environment to exploit a new European FPGA (reconfigurable device) dedicated to space application. > > One important contribution will be to expose a manipulation API to application Designers while protecting the hardware intellectual property. Also some compression schemes used for video coding will be stressed against practical experimentation when downsizing the bitstream (binary representation of the application). > > > - postdoc (2 years) : Start january-june 2014 > > In the scope of the FP7 ERATO project, the candidate will contribute to define and develop a Pharo environment to model a new FPGA and to meter performances in a faulty environment (satellite). This postdoc is a perfect opportunity for a Smalltalk expert to transpose its skills to an applicative domain. Depending on the qualification of the candidate, she/he will be co advisor of the PhD student. >

Sept. 10, 2013