- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SmalltalkHub update

by Benjamin

COOOOOOOOOOOOOOOOOOOOOLLLLLLLLLLLLLLLLLL Ben On Jun 30, 2012, at 3:21 PM, petton.nicolas(a)gmail.com wrote: > > Hi! > > SmalltalkHub received some love lately and now includes the following > improvements: > > - Project pages now include a contributors tab > - Contributors can now be set in the 'settings' tab of projects > - The list of users watching are now visible in the 'watchers' tab > - The search field in the header is now implemented. This is the first > part of the search feature of SmalltalkHub, an advanced search page > will be added later. > > Cheers, > Nico > > -- > Nicolas Petton > http://nicolas-petton.fr >

June 30, 2012

Re: [Pharo-project] SmalltalkHub update

by Guillermo Polito

Sexy! :D Tx Nico! On Sat, Jun 30, 2012 at 3:21 PM, <petton.nicolas(a)gmail.com> wrote: > > Hi! > > SmalltalkHub received some love lately and now includes the following > improvements: > > - Project pages now include a contributors tab > - Contributors can now be set in the 'settings' tab of projects > - The list of users watching are now visible in the 'watchers' tab > - The search field in the header is now implemented. This is the first > part of the search feature of SmalltalkHub, an advanced search page > will be added later. > > Cheers, > Nico > > -- > Nicolas Petton > http://nicolas-petton.fr > >

June 30, 2012

[Pharo-project] SmalltalkHub update

by petton.nicolas＠gmail.com

Hi! SmalltalkHub received some love lately and now includes the following improvements: - Project pages now include a contributors tab - Contributors can now be set in the 'settings' tab of projects - The list of users watching are now visible in the 'watchers' tab - The search field in the header is now implemented. This is the first part of the search feature of SmalltalkHub, an advanced search page will be added later. Cheers, Nico -- Nicolas Petton http://nicolas-petton.fr

June 30, 2012

Re: [Pharo-project] **IMPORTANT** MUST READ: Pharo Association and Consortium

by StÃ©phane Ducasse

On Jun 30, 2012, at 12:46 PM, Herve Verjus wrote: > Hi All, > > thank you Stef for this piece of information. > > I will subscribe as individual member. > > Let's say, you're doing a good job, I enjoy a lot using Pharo, that let's me permit do/use funny and usefull things, teaching students, make some research software prototypes, etc. > I have to say I would probably not succeed in convincing my university staff to subscribe to the consortium. I personnaly vote for that, I will try and will do my best but I'am not optimistic :-( > I understand that the fees are intended for enterprises or organizations that aim to make business arround and/or with Pharo. I and my lab are not in such a perspective. Maybe I would succeed in convincing IAE director for some hundred euros for supporting your work...not for 1000 or more. Nevertheless, I will try. Thanks there is also the sponsoring possibility and the association can provide a bill for a pharo "distribution" So you can try to play with different budgets. > > All the best, > > Herve

June 30, 2012

Re: [Pharo-project] [Moose-dev] Magritte / XML bridge

by StÃ©phane Ducasse

>> >> > Well, it started as an excersize to avoid having to do things like that :) >>> hope that helps, >> >> Do you know how relationships are handled :) > > Relationships are one of the weaker points in magritte. Yes. I think that we should increase the use of magritte so that it can improve. > It would need some love to make it more usable. In Magritte-XML we took a few side ways. > When it comes to descriptions in relationships it is important who is in control of the "real" description of an object. In Magritte-Xml we support two use cases. The default option is to support inheritance. That means if you navigate a relationship each object is asked for its description. This way an object you get can be a subclass of the object you described. The second option I need more often is to inject descriptions into a relationship. Meaning the description of the relationship defines the description for the contained objects. This way I can alter the use of my objects by the way the objects are approached/by use case. This can be done by setting #reference: on your relationship description and by specifying "beDescribedByReference" to the relationship description. Sadly I couldn't come up with a nicer selector :) > As an example I use > > COUserSession>>#userDescription > <magritteDescription> > ^MAToOneRelationDescription new > accessor: #user; > label: 'User of App'; > classes: (Array with: COUser); > beDescribedByReference; > reference: (COUser new remoteDescription kind: COUser); > beXmlElement; > beInlined; > priority: 20; > yourself > > Here "remoteDescription" includes a reduced view of the user for remote usage. It contains just two values of the user instead of everything. By additionally defining "beInlined" you can prevent the relationship to create an additional element. Otherwise the relationship would create a xml element and the object as well. > While I'm writing this I'm not sure if the setting for kind: is still needed. Nick did something so you don't need to set it like this, I think. I hope he will read this and clarifies the use. Somehow. I have to play with it. And if you come at esug I would really like to sit with you. One of my simple use case is that I have a container and elements and I would like to save in xml the container and its elements. Now the relation between container and elements is a relationship. > > Regarding your other mail. I cannot tell much about the option descriptions in Magritte-Xml. I never used them myself and so I'm no expert. Jan could say something about them and IIRC Nick (again) did something with the multiple option description. I will look deeper into it now > > hope that helps, > > Norbert

June 30, 2012

[Pharo-project] [update 2.0] #20174

by Marcus Denker

20174 ----- Issue 6192: [Bug]: FileReference>>#extension causes error if no extension http://code.google.com/p/pharo/issues/detail?id=6192 Issue 6198: Extension missing http://code.google.com/p/pharo/issues/detail?id=6198 Issue 6130: Use of freetype will crash on Windows due to FS changes http://code.google.com/p/pharo/issues/detail?id=6130 -- Marcus Denker -- http://marcusdenker.de

June 30, 2012

[Pharo-project] [update 2.0] #20173

by Marcus Denker

20173 ----- Issue 6221: Move Text tests to TextTests package http://code.google.com/p/pharo/issues/detail?id=6221 Issue 6220: Fix StartupPreferences http://code.google.com/p/pharo/issues/detail?id=6220 Issue 6208: Directly browse single matched methods on implementors / senders search http://code.google.com/p/pharo/issues/detail?id=6208 Issue 6207: FileBrowser does not open on Windows http://code.google.com/p/pharo/issues/detail?id=6207 Issue 6203: Spotlight improvemen http://code.google.com/p/pharo/issues/detail?id=6203 -- Marcus Denker -- http://marcusdenker.de

June 30, 2012

Re: [Pharo-project] **IMPORTANT** MUST READ: Pharo Association and Consortium

by Herve Verjus

Hi All, thank you Stef for this piece of information. I will subscribe as individual member. Let's say, you're doing a good job, I enjoy a lot using Pharo, that let's me permit do/use funny and usefull things, teaching students, make some research software prototypes, etc. I have to say I would probably not succeed in convincing my university staff to subscribe to the consortium. I personnaly vote for that, I will try and will do my best but I'am not optimistic :-( I understand that the fees are intended for enterprises or organizations that aim to make business arround and/or with Pharo. I and my lab are not in such a perspective. Maybe I would succeed in convincing IAE director for some hundred euros for supporting your work...not for 1000 or more. Nevertheless, I will try. All the best, Herve On 28/06/12 14:19, StÃ©phane Ducasse wrote: > Dear Pharoers and Smalltalkers > > This mail is really important so read it carefully. Especially the last part of the mail is important for the > immediate future: we need your support and input. Read section ***Support*** at the end of this mail. > > Context > ======= > After taking into account feedback from companies and pharo users in different occasions and > discussing with the INRIA lawyers and the team in charge of the administrative aspect of the consoritum > here is the setup we finally want for the consortium. We will have two separated entities: > - one french law 1901 association for individuals and > - one consortium for institutions (companies, research groups, laboratories, universities...) managed by INRIA > > We hope that in the long run the consortium will be fully managed by the association > but in the current bootstrap phase INRIA is a good solution. > > ============== > The Pharo Association > ============== > The goal of the association is to promote Pharo. It will have its own web site. > > Individual Memberships (managed by the Pharo Association) > ---------------------- > There are two individual memberships > - Individual Pharo Association Member: Yearly fee 40 Euros > - Golden Individual Pharo Association Member: Yearly fee 99 Euros > > You will get > a nice goody, > reduction access to conferences, > reduction for training and access to teaching material, > be part of the pharo groups on social networks, > be part of the pharoAssociation-individual-members mailing-list, > get access and registered to the pharo association web site. > > Others (managed by the Pharo Association) > ---------------------- > The association will be able to issues bills so you will be able to buy a Pharo distribution > when your organization cannot be a member, a sponsor or doing a donation to the Pharo consortium. > > End of Pharo Association Description > > > > =========================== > The Pharo Consortium (managed by INRIA) > =========================== > The goal of the consortium is to structure and build an umbrella to foster business around Pharo and to promote Pharo. > > A company, user group, research group, team or institution can be a consortium member, not individual member. > > There are three levels of fees and corresponding benefits. You decide your degree of support. > The annual fees are > - Bronze 1000 Euros > - Silver 2000 Euros > - Gold 4000 Euros > > Consortium members main advantages are > ---------------------------------------- > Non individual members of the consortium get the following advantages: > > - privileged access to the core development team via a specific mailing-list > pharo-core-team-for-members(a)lists.gforge.inria.fr > > - influence priorities of the next development. The member will be able to propose > agenda points and items for the executive team. They will be requested one month in > advance before the committee meeting. > > - get access to privileged core engineer time (to address pharo core problems) > > - Bronze member gets > one day of engineering time > + is automatically a diamond sponsor. > > - Silver > + two days of engineering time > + one job description for job dashboard > + is automatically a diamond sponsor.. > > - Gold four > + 4 days of engineering time > + multiple job description for job dashboard > + is automatically a diamond sponsor. > > - Training special prices and possibility to become pharo trainer > - Pharo consortium member can also ask and pay for extra support days at INRIA engineer prices (around 600 Euros) per day. > - Member can offer to their client access to the possibility to pay for extra support days at INRIA engineer prices (around 600 Euros) per day. > - The core team can provide contact with experts for certain areas of development. > > Pharo Consortium Gouvernance: steering committee > ---------------------------------------- > The consortium will be managed as follows: There will be a steering committee and an Executive Team. > > * A steering committee is composed of one representative of each member (except individuals). > > * The chairman of this committee will be Inria > > * Steering Committee Role : > - The Steering Committee follows the execution of the PHARO R&D Team > - It validates and gives input about the task list of the Executive Team. > - It can propose members of the executive team. > - It prepares, organizes conferences, seminars or other animations to promote PHARO and have new members > - It revises the annual fee > * Decisions taking: after consultation and collect of representative member points of views, Inria takes the final decision. > > * The steering committee will communicate via a private mailing-list. It may meet physical once a year. > > * An agenda to reach conclusion will be established by Inria on proposals of the members (the members will be queried a month in advance). > > Technical Executive Committee (akaR&D task) > ---------------------------------------- > * The Executive Team is composed of members proposed by the steering board and RMOD Team > * Its roles is to > * Study, analyze and validate external contributions for PHARO > * Report to the steering committee > * Present a task list to the steering committee. > * Propose, schedule and implement tasks in conformance with the tasks list. > * Coordinate the release Pharo and its VMs > > Pharo consortium Sponsoring > --------------------------- > Orthogonally to memberships, an entity can be a sponsor of the consortium without being a pharo consortium member. > Pharo consortium are de factor platinium sponsor. Sponsors will get their logos name exposed to the consortium web site. > There are two kinds of sponsors: > - normal 500 Euros > - diamond 1000 Euros > > Job board > --------- > Non consortium member companies will be able to pay a fee (1000 Euros) to post job offers to the job board. > > End of Pharo Consortium Description > > > ===================== > *** Support and Answer needed*** > ===================== > > To be able to pay an engineer by the consortium, INRIA needs to make projection, build budget, pay attention to visa > and other important administrative tasks. To deal with the risk that the consortium may not collect enough to pay a full salary > we are considering to ask INRIA to help us financially. To do so we have to give some concrete figures to > INRIA and motivate our request. In addition, our team (RMOD) on its own budget will try to compensate by allocating extra resources > However, this will be only a one shot. In addition, some of our team members have been approached by google to work on chrome and dart > Virtual Machines. So if we really get a future we should build it now. > > Many of you told us that they want to support the consortium, now we need to know what would be amount of membership, sponsoring > you could give. So please read carefully this mail and send us a mail at stephane.ducasse(a)inria.fr with the same subject than this one. > We will collect the information and build a case to present to INRIA. > Thanks in advance for Pharo and for the future that we are building together. > > The RMOD team and the Pharo board > >

June 30, 2012

Re: [Pharo-project] [Moose-dev] Magritte / XML bridge

by Norbert Hartl

Am 29.06.2012 um 15:17 schrieb StÃ©phane Ducasse: > > On Jun 29, 2012, at 10:54 AM, Norbert Hartl wrote: > >> >> Am 28.06.2012 um 21:15 schrieb StÃ©phane Ducasse: >> >>> Hi guys >>> >>> I would like to show in the magritte chapter I'm revisiting a bit more meat. >>> I'm playing with magritte 30 and I would like to know if there is a way to save objects based on their magritte description. >>> >> Yes, there is. There is a description in an old blog post of mine [1]. Don't be misled that magritte2 is mentioned there. It works as well with magritte3 (thanks to Nick Ager). You can get it >> >> Gofer new >> renggli: 'magritte3addons'; >> package: 'ConfigurationOfMagritte3AddOns'; >> load >> >> and load the default. > > Excellent I will read it. > I'm reading magicMagritte right now. > > BTW the Twitters stuff of nick is gorgeous :) > >> >> In a nutshell: >> >> You add to your descriptions "beXmlAttribute" or "beXmlElement". Then you can store an object with >> >> myObject magritteDescription toXml: myObject > > Ok cool. > I did that by hand in the past > > importElement: aXMLItem > > | anElement | > anElement := (self class mappingTable at: aXMLItem name) new. > self updateBackLinkOf: anElement. > anElement magritteDescription do: > [ :each | > | auth | > auth := aXMLItem attributeAt: each accessor readSelector asString. > (#(nil 'nil' ) includes: auth) ifFalse: > [ auth := each fromString: auth. > each accessor > write: auth > to: anElement ]]. > self base add: anElement. > ^ anElement > Well, it started as an excersize to avoid having to do things like that >> >> hope that helps, > > Do you know how relationships are handled :) Relationships are one of the weaker points in magritte. It would need some love to make it more usable. In Magritte-XML we took a few side ways. When it comes to descriptions in relationships it is important who is in control of the "real" description of an object. In Magritte-Xml we support two use cases. The default option is to support inheritance. That means if you navigate a relationship each object is asked for its description. This way an object you get can be a subclass of the object you described. The second option I need more often is to inject descriptions into a relationship. Meaning the description of the relationship defines the description for the contained objects. This way I can alter the use of my objects by the way the objects are approached/by use case. This can be done by setting #reference: on your relationship description and by specifying "beDescribedByReference" to the relationship description. Sadly I couldn't come up with a nicer selector :) As an example I use COUserSession>>#userDescription <magritteDescription> ^MAToOneRelationDescription new accessor: #user; label: 'User of App'; classes: (Array with: COUser); beDescribedByReference; reference: (COUser new remoteDescription kind: COUser); beXmlElement; beInlined; priority: 20; yourself Here "remoteDescription" includes a reduced view of the user for remote usage. It contains just two values of the user instead of everything. By additionally defining "beInlined" you can prevent the relationship to create an additional element. Otherwise the relationship would create a xml element and the object as well. While I'm writing this I'm not sure if the setting for kind: is still needed. Nick did something so you don't need to set it like this, I think. I hope he will read this and clarifies the use. Regarding your other mail. I cannot tell much about the option descriptions in Magritte-Xml. I never used them myself and so I'm no expert. Jan could say something about them and IIRC Nick (again) did something with the multiple option description. hope that helps, Norbert

June 30, 2012

Re: [Pharo-project] Is there a backup place for

by StÃ©phane Ducasse

not that I know but indeed if would be good to have a replication mechanism. Stef On Jun 30, 2012, at 10:37 AM, Friedrich Dominicus wrote: > http://source.lukas-renggli.ch > ? > > At least today it is not reachable from here. > > Regards > Friedrich >

June 30, 2012