- Pharo-users - lists.pharo.org

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

Lets Talk about Pharo Help tool

by Torsten Bergmann

Kilon wrote on "Pharo dev-list" >So my attention came to help tool, I think I get how it works, I started >making the documentation with it, questions is if there is anything more to >it than the functionality I am seeing in the Help docs. Maybe a third party >lib that adds more features ? > >Is there a plan to extend it ? Some time ago I created the "old" in image help tool so one can easily access help directly from the image. It was accepted and integrated into the standard image. It is usable and some projects/packages use it. But since media is (by default) not yet that rich within Pharo and mostly people also would like to see the documentation on the web I created a successor called "PharoOnlineHelp". This also allows you to be more independent with your docu from the help system itself. The new help system: ==================== - is called "Pharo Online Help" - uses only a single "marker" pragma - supports markdown - can be viewed/served online - is not part of the standard image but can be easily loaded How to use it: ============= - take a fresh Pharo 2.0 image from http://files.pharo.org/platform - open the config browser (Tools -> ConfigurationBrowser) - select "PharoOnlineHelp" from the list and easily install it - now in menu "Help" you will find "Help server", click on "Start server" on the control panel - if you are on Windows you can click on "Browse" to open a browser, in any other case go to http://localhost:8080 with your web browser You can now click and browse the available docu that is in the image. It also has an API help and links to most Pharo resources. If you want to extend the "Intro" tutorial section for instance with a "Native Boost" tutorial you can: - create an own class as subclass of Object in your own package - implement a class side message with a pragma #onlineTutorial nativeBoostTutorialOn: aBuilder <onlineTutorial> (aBuilder tutorial: #'Introduction to NativeBoost') description: 'An overview and introduction to the Native boost interface'; addLesson: ... - see class "PharoTutorial" for an example or this picture: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20130224/9… NOTE: the tutorials are written in Markdown, so you can: - write a blog post or website with a tutorial and later aggregate it/link to it in Pharo online help - use and embed rich media like youtube videos, web pages, ... - use Markdown editors like http://dillinger.io/ to write the docu Hope this will answer your questions. You can use the old help but I would rather like people to see jumping to the new online help. Bye Torsten

Sept. 10, 2013

Fwd: ESUG 2013 Started!

by Marcus Denker

Begin forwarded message: > Subject: ESUG 2013 Started! > Date: September 10, 2013 9:45:44 AM GMT+02:00 > To: "esug-list(a)lists.esug.org Members" <esug-list(a)lists.esug.org> > > ESUG 2013 in Annecey started with great success! > > After a productive and fun Camp Smalltalk (with great food), the main conference started Monday. > > Videos > ======= > This year we again record all taks. The talks are uploaded to Youtube as fast as possible. > https://www.youtube.com/user/esugboard > > Slides > ===== > Slides are collected as pdfs and uploaded to SlideShare. > > - PDF: http://esug.org/data/ESUG2013/ > - SlideShare: http://www.slideshare.net/esug/ > (later) > > Pictures > ======== > - Stephan Eggermont: > http://www.flickr.com/photos/35787002@N03/sets/72157635427445171/ > - Adriaan van Os > http://www.a3aan.st/esug2013/index.php/list/ > > Twitter > ====== > > The twitter hash tag is #esug2013. ESUG has an account > https://twitter.com/esugsmalltalk >

Sept. 10, 2013