February 2014 - Pharo-dev - lists.pharo.org

Fosdem Videos and Pharo. 4 presentation

by Torsten Bergmann

Feb. 11, 2014

Re: [Pharo-dev] [Vm-dev] NB and assembly methods (WAS: a lot of non-constructive things I refuse to talk about :)

by Esteban Lorenzano

On 11 Feb 2014, at 20:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > > > On Tue, Feb 11, 2014 at 7:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 11 February 2014 10:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > PS. I am hacking on protobuf in Pharo 3.0 and noticed cool NB assembler in some places - are such methods creeping into base libraries now? What does that mean for other CPUs? Sorry, for changing subject - feel free to reply under different subject. > > Hi Goran, > > Yesâ¦ since NB and Athens, there are some methods in assembler spread around. Is my opinion that all assembler-containing methods should be refactored into a more comprensible unit (and that can be changed by another set of assembly instrucction when we achieve multiplatform-NB). Today they are all along Athens, and if we continue this path they will be all along Pharo soon. I would better modularise that. > But Igor maybe has something different to say :) > > Esteban > > not much to add to what i already been said: > - have any other CPU which can run pharo JIT? No? Will talk when it will be available. > > There's an unfortunate chicken-and-egg problem here. The way we develop a new platform with Cog is to build a simulator for the CPU and run the VM simulator above the CPU simulator. But, by making Pharo non-portable because NB only works on x86 you've made it extremely difficult to use a Pharo image to develop the new platform. That will be really important when x86-64 comes into the picture, which it shoudl sometime later this year. In fact its worse. Because there is no simulator support for NB I can't even start up a Pharo image on the current simulator and that's directly affecting my ability to sup[port ClÃ©ment in the Sista work. Note that we already have an ARM simulator and unfortunately Pharo can't run on that simulator either. Some way of making NB get out of the way except on x86 until it is portable would be much appreciated. Eliot, I made NB optional in Pharo3â¦ you should not have problems (from that side) to simulate the image. But Iâm also willing to help in anything else that is needed. Just point me your problem and I will try to solve it :) Esteban > > Doing anything before that is just waste of time. > > -- > Best regards, > Igor Stasenko. > > > > -- > best, > Eliot

Feb. 11, 2014

Re: [Pharo-dev] [squeak-dev] Unethical behaviour on GSoC 2010 (was The truth on GSOC, ESUG and bad attitude)

by Mariano Martinez Peck

Hi all, I was trying to keep aways from the discussion but now I am directly involved as the "co-admin" of GSoC 2010. First, Janko, I don't see at all your point here. Whether it was true or not, making this PUBLIC and NOW does not make sense. It only makes clear the only thing you want to do is to bash Stef. So it is clearly something personal. Second...I will tell you what I remember. I do remember Stef suggesting/complaining about Newspeak as well as other none-very-smalltalk-related projects (I don't remember which were the other). I remember Stef was not the only one, but most of the mentors agreed to the same. And in fact, it made sense. WE wanted to use ESUG infrastructure. That means using its resources, its setup, its administrator, accountant, etc. Do you think all this setup comes from free? So....even if it was not the case, but imagine for a second that ESUG has certain thoughts about being used as the GSoC organization, then I think we should listen and discuss to get to an agreement. Otherwise, it is easy, use your own organization and that's all. I am NOT saying we should do what ESUG says.... I am just saying ESUG board opinions should be considered along with the community if ESUG wants to be used as Mentoring Organization. Same reason if we would like to use Newspeak for some Smalltalk-related projects. Third, I never ever remember Stef "forcing" me to do that. I cannot remember more than a "recommendation". If there is something I did (I do not even remember), I did it myself. But again... I really don't understand at all why this discussion now.... On Mon, Feb 10, 2014 at 1:38 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si>wrote: > Time therefore to expose that sad story from GSoC 2010. So that the > community can judge by themselves if my claims are insults or real. > > For the start, this was not a money matter but meddling into project > selection process. > > Here is the story: > > On GSoC 2010 Gilad Bracha proposed a Newspeak/Smalltalk Import/Export > Tool project idea [1]. After the idea was put on ideas list [2], > StÃ©phane Ducasse ordered my co-admin to remove Gilad's idea from the > list. Co-admin told that to me. I was shocked that someone can come to > such an idea to remove something even in the idea phase from the GSoC. > Of course I rejected such an order immediately. > > Even more, co-admin was at that time just starting the postgraduade > study under the Mr.Ducasse mentorship. You can imagine how he felt, like > between two fires. It is reasonable therefore to suspect that Mr.Duccase > uses his power as a mentor over postgraduate student to try to achieve > his goal. > > What was the motivation of Mr.Ducasse to made such a blatant act was not > quite clear to me. And is also not important. Important is that such > removal attempts are totally unacceptable. Only GSoC mentors have that > right by reviewing and voting on the projects to be finally selected for > stipendiums. > > In any case, this incident was a start of my thinking and working on > GSoC to be as transparent, neutral and independent as possible. > > Best regards > Janko > > [1] http://gsoc2010.esug.org/projects/newspeak-tool > [2] http://gsoc2010.esug.org/ideas > > > > > Dne 10. 02. 2014 15:30, piÅ¡e StÃ©phane Ducasse: > > I can tell you that until now I took that as a little crisis of Janko > but now this makes me sick. > > I do not think that I will stand in the same room than him in the future. > > > > Sorry Janko you are insulting people publicly but you mention that you > don't. > > I will check if I have a lawyer to handle this situation because you > cannot have just words against me. > > I will check with the inria lawyer first. > > > > Stef > > > > > > > >> I do not understand the motivation of Janko, especially since he is > apparently alone to think that way. > >> It is impressive to see how fragile the community is. > >> Thanks Paolo and thanks the ESUG board for handling this difficult > situation! > >> > >> Cheers, > >> Alexandre > >> > >> > >> On Feb 10, 2014, at 7:14 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >>> I support it, too. > >>> > >>> The only path to action I see is to act. And in this situation, Paolo > was the only one that offered a pragmatic way out. Thank you, Paolo! :) > >>> > >>> So, I suggest this: > >>> - we take Marcus' suggestion and have the present issue be handled at > the next ESUG general assembly. Like this we ensure that the problem is > going to be addressed in a more effective environment (namely, more > structured, and not via mail). > >>> - we go forward with Paolo as an admin. Like this we ensure that > action happens now. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> > >>> On Mon, Feb 10, 2014 at 1:05 PM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>> I support this, along with a general require that you keep this > discussion in private. > >>> > >>> Esteban > >>> > >>> On 10 Feb 2014, at 12:10, Stephan Eggermont <stephan(a)stack.nl> wrote: > >>> > >>>> I no longer have confidence in Janko running as GSoC admin > >>>> and want Paolo to take over as admin for Esug as mentoring > organisation. > >>>> > >>>> Stephan Eggermont > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Esug-list mailing list > >>>> Esug-list(a)lists.esug.org > >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >>> > >>> > >>> _______________________________________________ > >>> Esug-list mailing list > >>> Esug-list(a)lists.esug.org > >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Smalltalk GSoC mentors" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com. > >> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > Janko MivÅ¡ek > Smalltalk GSoC Admin Team > > -- Mariano http://marianopeck.wordpress.com

Feb. 11, 2014

[ANN] ScriptManager 1.7 Release for upcoming Pharo 3.0

by Torsten Bergmann

Thanks to Sven van Caekenberghe the ScriptManager tool hosted in project http://smalltalkhub.com/#!/~TorstenBergmann/ScriptManager/ now also provides the ability to import/export not only to a single binary fuel file but also to a folder with readable scripts. This is a good idea and may also help to use external editors or versioning systems like git or others on the custom scripts. I also reworked the menues to be in alignment with the common style and polished the package for Pharo 3.0 as a new release version 1.7. Just open the config browser in Pharo 3.0 and load "ScriptManager". After loading it will be available under Tools -> ScriptManager. Have fun T.

Feb. 11, 2014

Re: [Pharo-dev] NB and assembly methods (WAS: a lot of non-constructive things I refuse to talk about :)

by Eliot Miranda

Hi Igor, On Tue, Feb 11, 2014 at 7:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 11 February 2014 10:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >> > PS. I am hacking on protobuf in Pharo 3.0 and noticed cool NB assembler >> in some places - are such methods creeping into base libraries now? What >> does that mean for other CPUs? Sorry, for changing subject - feel free to >> reply under different subject. >> >> Hi Goran, >> >> Yes... since NB and Athens, there are some methods in assembler spread >> around. Is my opinion that all assembler-containing methods should be >> refactored into a more comprensible unit (and that can be changed by >> another set of assembly instrucction when we achieve multiplatform-NB). >> Today they are all along Athens, and if we continue this path they will be >> all along Pharo soon. I would better modularise that. >> But Igor maybe has something different to say :) >> >> Esteban >> > > not much to add to what i already been said: > - have any other CPU which can run pharo JIT? No? Will talk when it will > be available. > There's an unfortunate chicken-and-egg problem here. The way we develop a new platform with Cog is to build a simulator for the CPU and run the VM simulator above the CPU simulator. But, by making Pharo non-portable because NB only works on x86 you've made it extremely difficult to use a Pharo image to develop the new platform. That will be really important when x86-64 comes into the picture, which it shoudl sometime later this year. In fact its worse. Because there is no simulator support for NB I can't even start up a Pharo image on the current simulator and that's directly affecting my ability to sup[port ClÃ©ment in the Sista work. Note that we already have an ARM simulator and unfortunately Pharo can't run on that simulator either. Some way of making NB get out of the way except on x86 until it is portable would be much appreciated. Doing anything before that is just waste of time. > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Benjamin

On 11 Feb 2014, at 17:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Câest cool. Thank you Ben. I had some more ideas like making a common STON format for prefs. But maybe you have some more ideas. Or we can just kill this proposal.\\ Maybe we should discuss it then :) Ben

Feb. 11, 2014

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Norbert Hartl

Am 11.02.2014 um 16:43 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: > > Le 11 fÃ©vr. 2014 Ã 16:15, Norbert Hartl a Ã©crit : > >> >> Am 11.02.2014 um 14:48 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: >> >>> Hi Norbert, >>> >>> Le 11 fÃ©vr. 2014 Ã 11:05, Norbert Hartl a Ã©crit : >>> >>>> I try really hard to move to 3.0 at the moment. To me versionner became that important that this is a requirement for me to change the version. Iâm testing the bleeding edge version of versionner in 3.0 and this looks really cool. But somehow I cannot create a development version of my project. Whatever I try the only thing I can achieve is that versionner is producing a new baseline method. I used all of the three buttons at the top and did also examine all of the menus (those that work). >>>> >>>> Any hints? >>> >>> I wrote a small documentation on Versionner: http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner. >>> With Versionner, a development version is always a baseline. If none is found, it will create one from the selected version. >>> Why is it a baseline? because you don't want to update your configuration each time you publish new packages. >>> >>> When you are ready to release, Versionner creates: >>> a numbered version with fixed packages revisions, >>> and the next development version (a baseline). >>> >>> Tell me if you need more information. >> >> Iâm not sure I understand. On the symbolic version front we have bleedingEdge that is loading a baseline without exact version information (it loads the newest packages). Then we have development versions that have specific package versions but are not released (not tagged stable). And we have releases that have a sense of to-be-published. >> Now we have only baselines/development and released versions? > > Yes. It is quite strange to have three levels of stability. A few users use that and we tried to find a simple process to manage configurations. > As in many other languages, you develop, release, then develop again. > In another way, I can also understand that you prefer another process or that you need an "extra" level. > >> I liked to have the three levels because it matches all the requirements in my workflow. That is baseline = development, development = be used by other projects/collaborators before it is released, stable = ready to be released. > > your definition of the development version looks like a release-candidate. Why not publish (yes release ;) ) a RC version for this purpose? > >> Anyway if it is the case that there is only baseline and released version I do not understand why the versions are having the blessing development. How are those supposed to be tagged stable? > > They shouldn't. I fixed that friday and it will be integrated soon. > >> At the moment I find it quite confusing how it is. I need maybe one or two more hints. > > I understand. Versionner was thought to encourage people to follow a workflow that may be different of their current one. > But there is still place to discussion, move and adding some other functionalities. > > Versionner needs feedback and will evolve from feedback. > Ok. What I wrote above is just what Iâm used to and what is my current way of working. But I must confess that this extra level of mine is probably not necessary. At least it complicates things and you can always argue that if you want three then the next one wants to have four levels. I need to think about a way how to build up my workflow on top of versionner not within. thanks for the great work! The new UI looks really great! Norbert

Feb. 11, 2014

Re: [Pharo-dev] [Esug-list] Smalltalk dialects and GSoC

by Igor Stasenko

On 11 February 2014 18:08, Paolo Bonzini <bonzini(a)gnu.org> wrote: > Il 11/02/2014 17:53, Bert Freudenberg ha scritto: > >> I think a Newspeak<->Smalltalk translator, written in Smalltalk, would be >>> eligible for GSoC under the ESUG organization. >>> >>> If it were to be written in Newspeak, I would still want to have it >>> in the ideas list. Perhaps the student itself could propose to use >>> Smalltalk instead, or it could be a backup in case we lose a student due >>> to conflicts with other organizations. However, the chances for it to >>> get into the program would be slimmer. >>> >> >> How about a project for a new or extended Smalltalk VM? Written in >> non-Smalltalk, but running a Smalltalk, e.g. Squeak? >> > > Of course, everything must be considered on a case-by-case basis. There > is no hard and fast rule. > > Right. I didn't said it's easy to correctly/perfectly draw a line. But you have to draw it.. and once you did, you will always have chances to find someone left aboard and screaming about bias and blatantly unethical behavior, instead of peacefully discussing and providing arguments. > With my GNU Smalltalk hat on, I would redirect VM ideas to the GNU > organization, and only use ESUG slots for projects that have more porting > potential. But I understand that not all dialects have the same > opportunity. > > No, i think any Smalltalk VM is clearly a good topic to run under ESUG umbrella. > > Paolo > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Best regards, Igor Stasenko.

Feb. 11, 2014

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Christophe Demarey

Le 11 fÃ©vr. 2014 Ã 16:15, Norbert Hartl a Ã©crit : > > Am 11.02.2014 um 14:48 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: > >> Hi Norbert, >> >> Le 11 fÃ©vr. 2014 Ã 11:05, Norbert Hartl a Ã©crit : >> >>> I try really hard to move to 3.0 at the moment. To me versionner became that important that this is a requirement for me to change the version. Iâm testing the bleeding edge version of versionner in 3.0 and this looks really cool. But somehow I cannot create a development version of my project. Whatever I try the only thing I can achieve is that versionner is producing a new baseline method. I used all of the three buttons at the top and did also examine all of the menus (those that work). >>> >>> Any hints? >> >> I wrote a small documentation on Versionner: http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner. >> With Versionner, a development version is always a baseline. If none is found, it will create one from the selected version. >> Why is it a baseline? because you don't want to update your configuration each time you publish new packages. >> >> When you are ready to release, Versionner creates: >> a numbered version with fixed packages revisions, >> and the next development version (a baseline). >> >> Tell me if you need more information. > > Iâm not sure I understand. On the symbolic version front we have bleedingEdge that is loading a baseline without exact version information (it loads the newest packages). Then we have development versions that have specific package versions but are not released (not tagged stable). And we have releases that have a sense of to-be-published. > Now we have only baselines/development and released versions? Yes. It is quite strange to have three levels of stability. A few users use that and we tried to find a simple process to manage configurations. As in many other languages, you develop, release, then develop again. In another way, I can also understand that you prefer another process or that you need an "extra" level. > I liked to have the three levels because it matches all the requirements in my workflow. That is baseline = development, development = be used by other projects/collaborators before it is released, stable = ready to be released. your definition of the development version looks like a release-candidate. Why not publish (yes release ;) ) a RC version for this purpose? > Anyway if it is the case that there is only baseline and released version I do not understand why the versions are having the blessing development. How are those supposed to be tagged stable? They shouldn't. I fixed that friday and it will be integrated soon. > At the moment I find it quite confusing how it is. I need maybe one or two more hints. I understand. Versionner was thought to encourage people to follow a workflow that may be different of their current one. But there is still place to discussion, move and adding some other functionalities. Versionner needs feedback and will evolve from feedback. Thanks, Christophe.

Feb. 11, 2014

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Sean P. DeNigris

It's hard to think this one through without use casesâ¦ On the positive, it may be better to mark every numbered version as #'release' and then use semantic versioning to update if you run into trouble (i.e. release 2.0 and if you have to adjust the packages, 2.0.1). Because now that we have stable versions, there seem to be two competing systems - the tag of the numbered version and the symbolic version. In practice, it looks like a lot of numbered versions never get updated (i.e. versions that are symbolic #'stable' are not #'release' in the version spec) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-3-0-versionner-and-creating-a-development-versi… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 11, 2014